banner_lidar

[toc]

LiDAR point cloud data are commonly delivered in the ASPRS LAS format. The format is supported by libLAS, a BSD-licensed C++ library for reading/writing these data. GRASS GIS 7 supports the LAS format directly when built against libLAS (as the case for most binary packages being available for download).

In this exercise we will import a sample LAS data set covering a tiny area close to Raleigh, NC (USA), belonging to the North Carolina sample data set. Sample LAS data download: https://grass.osgeo.org/sampledata/north_carolina/  (25MB).

For a full exercise, we will, however, assume that no GRASS GIS location is ready so far (so: newbies are welcome!) and create a new one initially.

1. Having the LAS file: now what?

In the first place, check the metadata of the LAS file using the lasinfo command (comes with libLAS; here only parts of the output shown):

lasinfo points.las
---------------------------------------------------------
  Header Summary
---------------------------------------------------------
  Version:  1.2
  Source ID:  0
  Reserved:  0
  Project ID/GUID:  '00000000-0000-0000-0000-000000000000'
  System ID:  'libLAS'
  Generating Software:  'libLAS 1.2'
[...]
  Spatial Reference:
None
[...]
---------------------------------------------------------
  Point Inspection Summary
---------------------------------------------------------
  Header Point Count: 1287775
  Actual Point Count: 1287775

  Minimum and Maximum Attributes (min,max)
---------------------------------------------------------
  Min X, Y, Z:   6066629.86, 2190053.45, -3.60
  Max X, Y, Z:   6070237.92, 2193507.74, 906.00
  Bounding Box:  6066629.86, 2190053.45, 6070237.92, 2193507.74
  Time:  0.000000, 0.000000
  Return Number:  1, 3
  Return Count:  1, 7
  Flightline Edge:  0, 0
  Intensity:  0, 256
  Scan Direction Flag:  0, 0
  Scan Angle Rank:  0, 0
  Classification:  2, 7
  Point Source Id:  0, 0
  User Data:  0, 0
  Minimum Color (RGB):  0 0 0 
  Maximum Color (RGB):  0 0 0 

  Number of Points by Return
---------------------------------------------------------
  (1) 1225886  (2) 61430  (3) 459

  Number of Returns by Pulse
---------------------------------------------------------
  (1) 30877  (2) 153  (5) 1225886  (6) 30706  (7) 153

  Point Classifications
---------------------------------------------------------
  647337 Ground (2) 
  639673 Low Vegetation (3) 
  740 Building (6) 
  25 Low Point (noise) (7) 
  -------------------------------------------------------
  0 withheld
  0 keypoint
  0 synthetic
  -------------------------------------------------------

We see: no spatial reference system indicated!
Luckily we know from here that the projection is  NAD83(HARN) / North Carolina, LCC 2SP metric, EPSG code 3358). Furthermore we see:

  • Number of Points by Return: 3 (i.e., first, mid, last)
  • Point Classifications: the points are already classified as “Ground” (class 2),  “Low Vegetation” (3),  “Building” (6), and Low Point (noise) (class 7). Something to play with later.

Time to create a GRASS GIS location and import the LAS file.

2. Creating a GRASS GIS location for the LAS file

Since we know the EPSG code of the projection, that’s an easy task. Please note that GRASS GIS can generate locations directly from SHAPE files (with .prj file), GeoTIFF and more.

We fire up GRASS GIS 7 and open the Location Wizard:

grass7_startup

In the Location Wizard, we first define a name for the new location:

grass7_loc_wizard1

We select the “EPSG code” method for creating a new location:

grass7_loc_wizard2

You can search for “North Carolina” and select the EPSG code 3358 from the list:

grass7_loc_wizard3

Next summary should show up as follows (be sure to have the metric projection shown!):

grass7_loc_wizard4

With “Finish” you reach this notification (indeed, nothing to change! It is already fine):

grass7_loc_wizard5

Since we want to import the LAS file, no need to manually define any region extent here – just say “No”:

grass7_loc_wizard6

While we could import the data also into the PERMANENT mapset, we prefer to create an own mapset “lasdata” for our LAS data (once you reach hundreds of maps to manage, you will be happy about the concept of mapsets):

grass7_loc_wizard7

Voilà, we get back to the initial startup screen and can now start our GRASS GIS session with our “nc_nad83_lcc” location and “lasdata” mapset within the location: “Start GRASS”!

grass7_loc_wizard8

3. Import of the LAS file

When creating a new location from a GeoTIFF or SHAPE file (or other GDAL supported format), then the data set is imported right away. This is not the case for LAS files, also due to the fact that we can directly apply binning statistics during import of the LAS file (e.g. percentiles, min or max) and create a raster surface from the points right away rather than importing them as vector points.

3. a) Creating a raster surface from LAS during import

The LAS import into a raster surface is available through r.in.lidar:

grass7_las_import1

First the LAS file needs to be selected and an output file name specified (in this example, we want to extract the 95th percentile as binning method, hence a reasonable map name):

grass7_las_import2

In the “Statistic” tab, we select the “percentile” method along with 95 as value:

grass7_las_import3

In the “Optional” tab we activate to extend the computational region from the LAS file and, since the spatial reference system metadata are lacking from the LAS file, also “override dataset projection” to use that predefined in the location. Finally, we define 5m as desired raster resolution for the resulting raster map:

grass7_las_import4

Upon conpletion of the import/binning, the new raster elevation map is shown after zooming to the map (r.in.lidar -e … restores upon completion the previous region settings, hence we may have to zoom):

grass7_las_import5

Now we can start to analyze or visually explore the imported LAS file.

4. Visual LiDAR data exploration

Using the wxNVIZ 3D viewer, we can easily fly through the new DEM. Switch in the Map Display to “3D view” (1). Note that the default rendering is initially done at low visual resolution for speed reasons. You can switch to “Rotate mode” as well to easily navigate with the mouse. In the “Data” tab (2) you can increase the visual resolution (3) to obtain a crisp view:

grass7_las_viz1

 

Now all kinds of analysis steps may follow.

Outlook

For true LiDAR processing as points, see the following GRASS GIS 7 modules: v.in.lidar (for point import), v.lidar.correction, v.lidar.edgedetection, v.lidar.growing, v.outlier, and v.surf.bspline.

[toc]

Recently, in order to nicely plan ahead for a birthday lunch at the agriturismo Malga Brigolina (a farm-restaurant near Sopramonte di Trento, Italy, at 1,000m a.s.l. in the Southern Alps), friends of mine asked me the day before:

Will the place be sunny at lunch time for making a nice walk?

[well, the weather was close to clear sky conditions but mountains are high here and cast long shadows in winter time].

paganella_rotaliana

A rather easy task I thought, so I got my tools ready since that was an occasion to verify the predictions with some photos! Thanks to the new EU-DEM at 25m I was able to perform the computations right away in a metric system rather than dealing with degree in LatLong.

Direct sunlight can be assessed from the beam radiation map of GRASS GIS’ r.sun when running it for a specific day and time. But even easier, there is a new Addon for GRASS GIS 7 which calculates right away time series of insolation maps given start/stop timestamps and a time step: r.sun.hourly. This shrinks the overall effort to almost nothing.

Creating the direct sunlight maps

The first step is to calculate where direct sunlight reaches the ground. Here the input elevation map is the European “eu_dem_25”, while the output is the beam radiation for a certain day (15 Dec 2013 is DOY 349).

Important hint: the computational region must be large enough to east/south/west to capure the cast shadow effects of all relevant surrounding mountains.

I let calculations start at 8am and finish at 5pm which an hourly time step. The authors have kindly parallelized r.sun.hourly, so I let it run on four processors simultaneously to speed up:

# calculate DOY (day-of-year) from given date:
date -d 2013-12-15 +%j
349

# calculate beam radiation maps for a given time period
# (note: minutes are to be given in decimal time: 30min = 0.5)
r.sun.hourly elev_in=eu_dem_25 beam_rad=trento_beam_doy349 \
      start_time=8 end_time=17 time_step=1 day=349 year=2013 \
      nprocs=4

The ten resulting maps contain the beam radiation for each pixel considering the cast shadow effects of the pixel-surrounding mountains. However, the question was not to calculate irradiance raster maps in Wh/m^2 but simply “sun-yes” or “sun-no”. So a subsequent filtering had to be applied. Each beam radiation map was filtered: if pixel value equal to 0 then “sun-no”, otherwise “sun-yes” (what my friends wanted to achieve; effectively a conversion into a binary map).
Best done in a simple shell script loop:

[Edit 30 Dec 2013: thanks to Anna you can simplify below loop to the r.colors call thanks to the new -b flag for binary output in r.sun.hourly!]

for map in `g.mlist rast pattern="trento_beam_doy349*"` ; do
    # rename current map to tmp
    g.rename rast=$map,$map.tmp
    # filter and save with original name
    r.mapcalc "$map = if($map.tmp == 0, null(), 1)"
    # colorize the binary map
    echo "1 yellow" | r.colors $map rules=-
    # remove cruft
    g.remove rast=$map.tmp
done

As a result we got ten binary maps, ideal for using them as overlay with shaded DEMs or OpenStreetMap layers. The areas exposed to direct sunlight are shown in yellow.

Trento direct sunlight 15 Dec 2013 Animation

Trento, direct sunlight, 15 Dec 2013 between 10am and 5pm (See here for creating an animated GIF). Quality reduced for this blog.

Time to look at some details: So, is Malga Brigolina in sunlight at lunch time?

Situation at 12pm (noon): predicted that the restaurant is still in shadow – confirmed in the photo:

malga_brigolina_direct_sunlight_15dec2013_12pm_foto

(click to enlarge)

Situation at 1:30/2:00pm: sun is getting closer to the Malga, as confirmed in photo (note that the left photo is 20min ahead of the map). The small street in the right photo is still in the shadow as predicted in the map):

malga_brigolina_direct_sunlight_15dec2013_14pm_foto(click to enlarge)

Situation at 3:00pm: sun here and there at Malga Brigolina:

malga_brigolina_direct_sunlight_15dec2013_15pm_3DSunlight map blended with OpenStreetmap layer (r.blend + r.composite) and draped over DEM in wxNVIZ of GRASS GIS 7 (click to enlarge). The sunday walk path around Malga Brigolina is the blue/red vector line shown in the view center.

Situation at 4:00pm: we are close to sunset in Trentino… view towards the Rotaliana (Mezzocorona, S. Michele all’Adige), last sunlit summits also seen in photo:

rotaliana_direct_sunlight_15dec2013_16pm_foto(click to enlarge)

Outcome

The resulting sunlight/shadow map appear to match nicely realty. Perhaps r.sun.hourly should get an additional flag to generate the binary “sun-yes” – “sun-no” maps directly.

trento_direct_sunlight_15dec2013_15pm_3DDirect sunlight zones (yellow, 15 Dec 2013, 3pm): Trento with Monte Bondone, Paganella, Marzolan, Lago di Caldonazzo, Lago di Levico and surroundings (click to enlarge)

GRASS GIS usage note

The wxGUI settings were as simple as this (note the transparency values for the various layers):

trento_direct_sunlight_wxGUI

Data sources:

Watch how the community based GRASS GIS 6.4 software development evolved! You can see how the individual contributors modify and expand the source code – click screenshot for Youtube video:

GRASS GIS 6.4 development visualization from 1999 to 2013 (with soundtrack)

  • Dec 29, 1999: GRASS GIS 5.0 is being stored in an online source code repository in December 1999…
  • Dec 02, 2000: The developers work on all parts of the code…
  • Jan 15, 2002: Working on the future GRASS GIS 5.1 release
  • Nov 25, 2002: Starting GRASS 5.1 development with code restructuring
  • Jun 14, 2004: GRASS GIS 5.7 released in June 2004
  • Nov 09, 2004: Source code restructuring to get a better directory layout (all other developers waiting…)
  • Nov 09, 2004: … thousands of files are modified in this operation …
  • Nov 10, 2004: All developers resume their activities after the restructuring
  • Jan 10, 2005: Preparing the GRASS GIS 6.0.0 release…
  • Apr 09, 2005: GRASS GIS 6.0.0 published, release branch being split off from trunk for easier maintenance
  • Feb 22, 2006: Release of GRASS GIS 6.0.2 and new source code refactoring startedApr 05, 2006: Heavy development activity in trunk (development branch) …
  • Oct 25, 2006: GRASS GIS 6.2.0 released in October 2006
  • Apr 10, 2007: Preparing the GRASS GIS 6.2.2 release…
  • Jun 16, 2007: GRASS GIS 6.2.2 released in June 2007
  • Nov 01, 2007: Raster and vector modules being actively maintained…
  • Apr 02, 2007: New graphical user interface development speeding up (wxGUI)
  • Feb 20, 2008: Copyright statements prettified in many files
  • May 31, 2008: New GRASS 6 development branch being split off from trunk (which becomes GRASS 7)
  • Jun 10, 2008: Developers moving over to new branch
  • Feb 23, 2009: GRASS 6.4 release branch split off from GRASS 6 development branch
  • Apr 03, 2009: GRASS GIS 6.4 preparations starting…
  • Feb 24, 2010: Intense maintenance in GRASS 6.4 release branch
  • Sep 15, 2010: GRASS GIS 6.4.0 released in September 2010
  • Apr 12, 2011: GRASS GIS 6.4.1 released in April 2011
  • Jun 27, 2011: GRASS GIS 6.4.svn matures for the upcoming 6.4.2 release
  • Aug 16, 2011: Intense maintenance in GRASS 6.4 release branch (GRASS GIS 7 development not shown here)…
  • Feb 19, 2012: GRASS GIS 6.4.2 released in February 2012
  • Nov 13, 2012: Backporting graphical user interface bugfixes from GRASS GIS 7 to GRASS GIS 6.4
  • Apr 17, 2013: Further maintenance in GRASS 6.4 release branch
  • Jul 10, 2013: Fixing odds ‘n ends for the new stable release
  • Jul 27, 2013: GRASS GIS 6.4.3 released in July 2013

The corresponding timeline is also available at
https://grass.osgeo.org/home/history/releases/

THANKS TO ALL CONTRIBUTORS!
https://grass.osgeo.org/development/

Rendering: Markus Neteler
Audio track editing: Duccio Rocchini & Antonio Galea

Music:
Le bruit peut rendre sourd – Track 6/18 Album “Sensation electronique” by Saelynh (CC-BY-NC-ND) https://www.jamendo.com/en/track/1236/le-bruit-peut-rendre-sourd

Software used:
Gource software: https://code.google.com/p/gource/ (GPL)
OpenShot video editor: https://www.openshotvideo.com/ (GPL

Inspired by Vaclav Petras posting about “Did you know that you can see streets of downtown Raleigh in elevation data from NC sample dataset?” I wanted to try the new GRASS GIS 7 Addon r.shaded.pca which creates shades from various directions and combines then into RGB composites just to see what happens when using the new EU-DEM at 25m.

To warm up, I registered the “normally” shaded DEM (previously generated with gdaldem) with r.external in a GRASS GIS 7 location (EPSG 3035, LAEA) and overlayed the OpenStreetMap layer using WMS with GRASS 7’s r.in.wms. An easy task thanks to University of Heidelberg’s www.osm-wms.de. Indeed, they offer a similar shading via WMS, however, in the screenshot below you see the new EU data being used for controlling the light on our own:

OpenStreetMap shaded with EU DEM 25m

OpenStreetMap shaded with EU DEM 25m (click to enlarge)

Next item: trying r.shaded.pca… It supports multi-core calculation and the possibility to strengthen the effects through z-rescaling. In my example, I used:

r.shaded.pca input=eu_dem_25 output=eu_dem_25_shaded_pca nproc=3 zmult=50

The leads to a colorized hillshading map, again with the OSM data on top (50% transparency):

eu_dem_25m_PCA_shaded_OSM_trento_rovereto_garda_lake

OpenStreetMap shaded with r.shaded.pca using EU DEM 25m (click to enlarge)

Yes, fun – I like it :-)

Data sources:

eu_dem_upper_garda_lake_riva_arco_italy

EU DEM 25m upper Garda Lake area with Riva del Garda and Arco (Italy). 3D view in wxNVIZ – GRASS GIS 7

The 25m European Digital Elevation Model (EU-DEM, Version 1) is a Digital Surface Model (DSM) representing the first surface as illuminated by the sensors:

eu_dem_s_michele_rotaliana_italy

EU DEM Rotaliana with Mezzocorona and S. Michele (Italy). Produced using Copernicus data and information funded by the European Union – EU-DEM layers.

Its elevations were captured at 1 arc second postings (2.78E-4 degrees). The tiles are provided at 25m resolution in EU-LAEA (EPSG. 3035) projection, temporal coverage: 2000, published in Oct 2013. It is a realisation of the Copernicus programme, managed by the European Commission, DG Enterprise and Industry. Metadata are provided here. According to their “Methodology” page it is a hybrid product based on SRTM and ASTER GDEM data fused by a weighted averaging approach and it has been generated as a contiguous dataset divided into 1 degree by 1 degree tiles, corresponding to the SRTM naming convention. In addition to the DEM data, a colour shaded relief image over Europe is provided.

From the metadata page: “The EU-DEM data are provided as is, i.e. without a formal validation yet. An independent statistical validation is scheduled as part of the GIO land monitoring service activities, and will be made available in the course of 2014.

Data download

Note that the GeoTIFF files are of major size, up to 5 GB:

Data import

The data come as ZIP compressed files, hence unzipping occurs (or simply use the fancy “vsizip” driver in GDAL).

Hint for GRASS GIS users: instead of importing the data, you can use the r.external command to register the GeoTIFF DEM file instead of imorting it within a EU LAEA projected location.

Enjoy!

eu_dem_trento_adige_s_michele_italy

GRASS GIS, commonly referred to as GRASS (Geographic Resources Analysis Support System), is the free Geographic Information System (GIS) software with the longest record of development as FOSS4G community project. The increasing demand for a robust and modern analytical free GIS led to the start of GRASS GIS 7 development in April 2008. Since GRASS 6 more than 10,000 changes have been implemented with a series of new modules for vector network analysis, image processing, voxel analysis, time series management and improved graphical user interface. The core system offers a new Python API and large file support for massive data analysis. Many modules have been undergone major optimization also in terms of speed. The presentation will highlight the advantages for users to migrate to the upcoming GRASS GIS 7 release.

See the slides:


neteler2013_foss4g_cee_romania_news_grassgis7

 

We are pleased to announce that the 50th ICA-OSGeo Lab has been established at the GIS and Remote Sensing Unit (Piattaforma GIS & Remote Sensing, PGIS), Research and Innovation Centre (CRI), Fondazione Edmund Mach (FEM), Italy. CRI is a multifaceted research organization established in 2008 under the umbrella of FEM, a private research foundation funded by the government of Autonomous Province of Trento. CRI focuses on studies and innovations in the fields of agriculture, nutrition, and environment, with the aim to generate new sharing knowledge and to contribute to economic growth, social development and the overall improvement of quality of life.

The mission of the PGIS unit is to develop and provide multi-scale approaches for the description of 2-, 3- and 4-dimensional biological systems and processes. Core activities of the unit include acquisition, processing and validation of geo-physical, ecological and spatial datasets collected within various research projects and monitoring activities, along with advanced scientific analysis and data management. These studies involve multi-decadal change analysis of various ecological and physical parameters from continental to landscape level using satellite imagery and other climatic layers. The lab focuses on the geostatistical analysis of such information layers, the creation and processing of indicators, and the production of ecological, landscape genetics, eco-epidemiological and physiological models. The team pursues actively the development of innovative methods and their implementation in a GIS framework including the time series analysis of proximal and remote sensing data.

The GIS and Remote Sensing Unit (PGIS) members strongly support the peer reviewed approach of Free and Open Source software development which is perfectly in line with academic research. PGIS contributes extensively to the open source software development in geospatial (main contributors to GRASS GIS), often collaborating with various other developers and researchers around the globe. In the new ICA-OSGeo lab at FEM international PhD students, university students and trainees are present.

PGIS is focused on knowledge dissemination of open source tools through a series of courses designed for specific user requirement (schools, universities, research institutes), blogs, workshops and conferences. Their recent publication in Trends in Ecology and Evolution underlines the need on using Free and Open Source Software (FOSS) for completely open science. Dr. Markus Neteler, who is leading the group since its formation, has two decades of experience in developing and promoting open source GIS software. Being founding member of the Open Source Geospatial Foundation (OSGeo.org, USA), he served on its board of directors from 2006-2011. Luca Delucchi, focal point and responsible person for the new ICA-OSGeo Lab is member of the board of directors of the Associazione Italiana per l’Informazione Geografica Libera (GFOSS.it, the Italian Local Chapter of OSGeo). He contributes to several Free and Open Source software and open data projects as developer and trainer.

Details about the GIS and Remote Sensing Unit at https://gis.cri.fmach.it/

Open Source Geospatial Foundation (OSGeo) is a not-for-profit organisation founded in 2006 whose mission is to support and promote the collaborative development of open source geospatial technologies and data.

International Cartographic Association (ICA) is the world authoritative body for cartography and GIScience. See also the new ICA-OSGeo Labs website.

banner_pansharpening

[toc]

In our first blog post (“Processing Landsat 8 data in GRASS GIS 7: Import and visualization“) we imported a Landsat 8 scene (covering Raleigh, NC, USA). In this exercise we use Landsat 8 data converted to reflectance with i.landsat.toar as shown in the first posting.

Here we will try color balancing and pan-sharpening, i.e. applying the higher resolution panchromatic channel to the color channels, using i.colors.enhance (former i.landsat.rgb).

Landsat 8 – RGB color balancing: natural color composites

After import, the RGB (bands 4,3,2 for Landsat 8) may look initially less exciting than expected.This is easy to fix by a histogram based auto-balancing of the RGB color tables.

landsat8_rgb_composite_unbalanced

To brighten up the RGB composite, we can use the color balancing tool of GRASS GIS 7:

grass7_landsat_rgb0

As input, we specify the bands 4, 3, and 2:

grass7_landsat_rgb1

Using a “Cropping intensity (upper brightness level)” of 99 (percent), the result look as follows:

landsat10_rgb_composite_autobalance_99percent_crop

For special purposes or under certain atmospheric/ground conditions it may be useful to make use of the functions “Preserve relative colors, adjust brightness only” or “Extend colors to full range of data on each channel” in the “Optional” tab of i.colors.enhance (former i.landsat.rgb).

landsat9_rgb_composite_preserve_relative_colors

You will need to experiment since the results depend directly on the image data.

Landsat 8 pansharpening

Pansharpening is a technique to merge the higher geometrical pixel resolution of the panchromatic band (Band 8) with the lower resolution color bands (Bands 4, 3, 2).

GRASS GIS 7 offers several methods through the command i.pansharpen.

1) Brovey transform:

landsat8_pansharpen_brovey1

This module runs in multi-core mode parallelized. The management of the resolution (i.e., apply the higher resolution of the panchromatic band) is performed automatically.

landsat8_pansharpen_brovey2

2. IHS transform

Here we select as above the bands in the i.pansharpen interface but use the “ihs” method.

landsat8_pansharpen_ihs1

HINT: If the colors should look odd, then apply i.colors.enhance (former i.landsat.rgb) to the pan-sharpened bands (see above).

Color-adjusted IHS pansharpening (with “Cropping intensity: strength=99”):

landsat8_pansharpen_ihs_color_adjusted

Comparison of Landsat 8 RGB composite (39m) and IHS pansharpened RGB composite (15m):

landsat8_rgb432_color_adjusted_zoom landsat8_rgb432_pansharpen_ihs_color_adjusted_zoom

3. PCA transform

Here we select as above the bands in the i.pansharpen interface but use the “pca” method.

landsat8_pansharpen_pca1

Likewise other channels may be merged with i.pansharpen, even when originating from different sensors.

Conclusions

Overall, the IHS pansharpening method along with auto-balancing of colors appears to perform very well with Landsat 8.

Edit 2015: See also pansharpening with i.fusion.hpf!

[toc]

Thanks to Volker Fröhlich’s efforts, a source code RPM package (SRPM) of QGIS 2.0.1 is now available for Fedora. If you are not yet F20 user (like me), you can just take the F20 package and compile it for F19 (or even F18) since there will be no backport of QGIS 2 to F19 (it comes with QGIS 1.8). But: we do want QGIS 2 on Fedora19!

Solution: compile it yourself.

1. Preparations

The best way is  to use “mock” which is used to recompile SRPMS in a separate local environment (“chroot”) without cluttering the system with extra packages needed for the compilation (run as “root”):

su
yum install mock

2. Get the source code

Next download the SRPM package from the Koji  server:
QGIS: https://koji.fedoraproject.org/koji/buildinfo?buildID=467757 (–> src – download) or check here for more recent versions.

3. Compile it locally as RPM package

The general compilation command (“mock”) would be:

mock -r my_fedora_version_config --rebuild my_source_rpm.src.rpm

So, check for Fedora version config name which is suitable for your system (“my_fedora_version_config“)

ls /etc/mock/

In my case of a 64bit machine, it is “fedora-19-x86_64”. Hence we can compile QGIS 2.0.1 directly from the SRPM file:

mock -r fedora-19-x86_64 --rebuild qgis-2.0.1-2.fc20.src.rpm

Note: the compilation takes 40min on my tiny core i3 laptop (ASUS X202). Use the time to donate some coins to the QGIS project :-)

4. Install and enjoy

Once the compilation job is done, i.e. the binary RPM files are available for installation. To install the freshly compiled QGIS 2.0.1 RPMs, run:

cd /var/lib/mock/fedora-19-x86_64/result/

# an existing QGIS1.8 installation will be replaced: 
yum localinstall qgis-2.0.1-2.fc19.x86_64.rpm \
qgis-grass-2.0.1-2.fc19.x86_64.rpm qgis-python-2.0.1-2.fc19.x86_64.rpm

# consider to cleanup (or keep it for the next update, it is about 1.5GB):
rm -rf /var/lib/mock/fedora-19-x86_64/
# leave the "root" shell
exit

Now we can happily use QGIS 2.0.1 on Fedora 19!

qgis

qgis201_on_fedora19

Dal 10 al 11 Ottobre 2013 si terrà a Bologna presso i laboratori della Scuola di Ingegneria e Architettura (V.le del Risorgimento, 2), e le sale conferenze della Regione Emilia-Romagna (V.le della Fiera, 8), la sesta conferenza italiana sul software geografico e sui dati geografici liberi (GFOSS DAY 2013).

Lo scopo principale della conferenza è quello di coinvolgere imprese, enti pubblici, scuole, università, centri di ricerca, sviluppatori, cittadini, operatori del settore ed appassionati dei temi del software libero geografico e degli open data.

Sarà inoltre possibile seguire in diretta streaming il convegno.

Registrati:

https://www.gfoss.it/drupal/gfossday2013/registrazione

La partecipazione alla conferenza è libera e gratuita ma è richiesta una registrazione (meglio anticipata) per consentire una migliore organizzazione dell’evento e garantire la stampa di badge e attestati.

L’accesso ai workshop è garantito fino al raggiungimento numero massimo di partecipanti.

Programma

https://www.gfoss.it/drupal/gfossday2013/programma

Sede della conferenza

https://www.gfoss.it/drupal/gfossday2013/locations

Parteciperete a #gfoss13? Ditelo al mondo!

Allegato Dimensione
Locandina_GFOSSDAY13.pdf 3.13 MB