Archive

Author Archives: underdark

The aim of QGIS Processing Framework developed by Polymeris is to provide a generic framework for accessing existing geo-processing functionality of e.g. SAGA, GRASS, Orfeo Toolbox, etc. This should enable users to script their geo-processing work in python console and allow development of a tool to graphically build workflows using VisTrails an “open-source scientific workflow and provenance management system”.

For a first impression, Polymeris has published some screenshots of QGIS with SAGA modules loaded: [1],[2]

This project is big and if it turns out well, QGIS will profit enormously from it. Both scriptable geoprocessing functionality and a graphic workflow builder can improve user experience a lot if they are implemented well. You can follow further development on the project homepage on GitHub.

On Wednesday, Allan Maungu announced MXD2QGS, a converter that exports layers from an Arcmap 10 document into a Quantum GIS project file. The tool is built as an ArcToolbox and can be downloaded from the blog.

I’d be very interested to hear whether this tool works for you.

For everyone working with spatial databases in QGIS there comes a time when “Add PostGIS/SpatiaLite Layer” and “RT Sql Layer” start to be annoying. You always have to retype or copy-paste your SQL queries into the user interface if you need to change the tiniest thing in the layer’s definition.

This is where “Fast SQL Layer” can be a real time saver. Fast SQL Layer is a new plugin for QGIS by Pablo T. Carreira. It basically adds an SQL console for loading layers from PostGIS/SpatiaLite into QGIS. And it even comes with syntax highlighting!

Installation

Fast SQL Layer comes with one dependency: Pygments, which is used for syntax highlighting.

On Ubuntu, all you have to do is install it with apt-get:

sudo apt-get install python-pygments

For Windows with OSGeo4W, @Mike_Toews posted this on gis.stackexchange:

I downloaded and extracted Pygments-1.4.tar.gz, then in an OSGeo4W shell within the Pygments-1.4 directory, type python setup.py build then python setup.py install

Usage

When you activate the plugin in plugin manager, a dock widget will appear which contains the console and some fields for specifying the database connection that should be used. Then, you can simply write your SQL query and load the results with one click.

Fast SQL plugin

In this example, I renamed “gid” to “id”, but you can actually edit the values in the drop down boxes to adjust the column names for id and geometry:

A second layer loaded using Fast SQL plugin

It certainly needs some polishing on the user interface side but I really like it.

Please note that this post was written in 2011 and the server addresses have changed. Please refer to data.wien.gv.at for the latest links.

The city of Vienna has started their open data initiative. They’re offering data on a variety of topics, including: infrastructure, population, education, environment and traffic.

For use in GIS, they serve the data through WMS and WFS:

Both WMS and WFS work well with the developer version of QGIS.

Looking forward to new datasets. Announcements should be published via RSS feed.

In a previous post, I’ve described how to create catchment areas with pgRouting shortest_path() function. The solution described there calculates costs from the starting node (aka vertex) to all other nodes in the network. Depending on the network size, this can take a long time. Especially, if you are only interested in relatively small catchment areas (e.g. 50 km around a node in a network covering 10,000 km) there is a lot of unnecessary calculation going on. This is where you might want to use driving_distance() instead.

Driving_distance() offers a parameter for maximum distance/cost and will stop calculations when the costs exceed this limit. But let’s start at the beginning: installing the necessary functions.

Installation

If you have followed my guide to installing pgRouting, you already have some routing functions installed – but not driving_distance(). Weirdly, the necessary SQL scripts are not shipped with the .zip file available on pgRouting’s download page. You need:

routing_dd.sql
routing_dd_wrappers.sql

Both are available through the project repository at Github. Get them and execute them in your pgRouting-enabled database. Now, you should be ready.

Calculating driving distances

To calculate driving distances, we need a query very similar to shortest_path():

CREATE OR REPLACE FUNCTION driving_distance(
sql text,
source_id integer,
distance float8,
directed boolean,
has_reverse_cost boolean)
RETURNS SETOF path_result

The only new value is “distance”. That’s the maximum distance/cost you want to be contained in the result set. “distance” has to be specified in the same units as the cost attribute (which is specified in the “sql” text parameter).

Note: In my opinion, the name “(driving) distance” is misleading. While you can use distance as a cost attribute, you’re not limited to distances. You can use any cost attribute you like, e.g. travel time, fuel consumption, co2 emissions, …

The actual query for a catchment area of 100 km around node # 2000 looks like this:

SELECT * FROM driving_distance('
      SELECT gid AS id,
          start_id::int4 AS source,
          end_id::int4 AS target,
          shape_leng::float8 AS cost
      FROM network',
      2000,
      100000,
      false,
      false)

Interpreting the result

These are the first lines of the result set:

vertex_id;edge_id;cost
294;7262;97400.433506144
297;7236;98012.620979231
335;1095;96849.456306244
347;7263;93617.693852324
364;7098;93573.849081386
366;2551;92702.443434779
378;7263;91994.328368081

The cost attribute contains the total cost of travel from the starting node to the vertex_id node.
We will only be using vertex_id and cost. The use of edge_id is a mystery to me.

Visualizing the result

The easiest way to visualize driving_distance() results is using RT Sql Layer plugin. We need to join the results of driving_distance() with the table containing node geometries:

SELECT *
   FROM node
   JOIN
   (SELECT * FROM driving_distance('
      SELECT gid AS id,
          start_id::int4 AS source,
          end_id::int4 AS target,
          shape_leng::float8 AS cost
      FROM network',
      2000,
      100000,
      false,
      false)) AS route
   ON
   node.id = route.vertex_id

If you color the nodes based on the cost attribute, it will look something like this:

result of pgRouting driving_distance() visualized in QGIS

This post covers the topic of creating MULTI* geometries or GEOMETRYCOLLECTIONs in PostGIS using ST_Collect or ST_Union.

Often it doesn’t matter if you use ST_Collect or ST_Union. Both will return MULTI* geometries or – if different geometry types or multi geometries are mixed – GEOMETRYCOLLECTIONS.

Why you might want to use ST_Collect instead of ST_Union

ST_Collect is much faster than ST_Union [1]. That’s already a good argument. It’s faster because it does not dissolve boundaries or check for overlapping regions. It simply combines geometries into MULTI*s or GEOMETRYCOLLECTIONs.

This leads to reason two for why you might prefer ST_Collect: Dissolving boundaries and overlapping regions – like ST_Union does – can lead to undesired effects. For example, combining three LINESTRING geometries that partially overlap, results in a MULTILINESTRING consisting of more than three lines. The input lines are split where they overlap each other or themselves.

Analysis and visualization based on the resulting geometries might lead to incorrect conclusions if the user is not aware of the processes performed by the union command.

[1] http://postgis.refractions.net/documentation/manual-svn/ST_Collect.html

This is how to create a Linestring connecting two coordinate pairs in SpatiaLite:

spatialite> SELECT AddGeometryColumn ('tablename','line_geom',4326,'LINESTRING',2);
spatialite> UPDATE tablename SET line_geom = LineFromText('LINESTRING('||startx||' '||starty||','||endx||' '||endy||')', 4326);

For a quick test, let’s calculate the length:

spatialite> SELECT GLength(line_geom) FROM tablename LIMIT 5;

This year, three QGIS projects made it into Google Summer of Code. Congratulations to all successful students!

These are the accepted OSGEO projects:

QGIS

GRASS

  • GRASS WXGUI WMS service rendering
  • Completion of wxGUI Nviz extension for 3D data visualization in GRASS GIS
  • r.in.modis for GRASS GIS
  • Graphical User Interface for the hydrological tools r.stream* in GRASS GIS

pgRouting

  • Multi-modal public transit routing for pgRouting
  • Time Dependent \ Dynamic Shortest Path Algorithm Implementation for pgRouting

gvSIG

  • Add support to vector data formats for gvSIG Mini
  • Design and implement an API for tiled vectorial support of geo-location data services for gvSIG Mini
    Integration of GGL2 into gvSIG

Opticks

  • Development of a ship detection and classification toolkit for SAR imagery in Opticks
  • Astronomical processing tools for Opticks
  • Photography processing tools for Opticks

Geoserver

  • Enhancing Geoserver Authentication

uDig

  • Catalog View of uDig
  • OSM data mining and editing capabilities in uDig and Geotools

MapServer

  • INSPIRE View Service for MapServer

Others

  • Geoprocessing with Neo4j Spatial
  • PyOSSIM: Python bindings for OSSIM libraries

For a full list including student names check http://www.google-melange.com/gsoc/org/google/gsoc2011/osgeo.

Gistutor.com features a nice tutorial covering raster-based terrain analysis techniques with QGIS and “Raster based terrain analysis” plugin.

Topics covered include: slope analysis, aspect analysis, ruggedness index analysis, total curvature analysis, and shaded relief.

Kudos to Mapperz on gis.stackexchange.com for the pointer.

PostGIS – our favorite spatial db – is nearing its 2.0 release! We are promised even better performance and stability and many new capabilities especially in the three new areas: raster data, topology, and 3D.

Raster

In 2.0, PostGIS Raster (formerly known as WKT Raster) will be fully integrated into the main application. Raster images are stored in special raster tables, which can be loaded from and exported to any GDAL-supported format. Additionally, there are functions for analyzing and operating on the pixel data. Rasters can be for example: vectorized, averaged, checked for intersections with vector geometries and edited inside the database.

For more information on what you can do with Rasters, check: PostGIS Doc, Chapter 8. Raster Reference.

Topology

PostGIS 2.0 represents the beginning of topology support in PostGIS. It will be possible to transform standard geometry into topological data, validate topology, and edit nodes and edges. Topology can be exported to GML.

Topology is covered in PostGIS Doc, Chapter 10. Topology.

3D

PostGIS 2.0 adds two 3D geometry types: polygonal surfaces and triangular irregular networks (TINs). Additional support operators for common tasks like finding areas (and volumes) of regions in 3D are included as well. Another improvement in this area is that existing spatial indices have been made 3D-aware, and a library of 3D-functions has been added. This allows calculation of distances and intersections in 3D, 3-dimensional bounding-boxes and many more things like 3D shortest-paths.

For a list of functions that support 3D, check PostGIS Doc, Chapter 12.

Read more on lwn.net.