Strk's Blog

Dedicated to those who do not want to surrender to proprietary services for code and tickets management: integrating Cartman with Mutt. The scenario is Trac instances that send email notifications on ticket activity, as is the case with the OSGeo ones (there’s been some recent discussion about the role of its infrastructure). The Cartman command to comment on a ticket (say #33) of a project (say postgis) would be: cm -s postgis 33 As you usually comment on some input received by mail (either a new ticket or another comment), building that command line requires eye-parsing for project name and ticket number, and then typing it on the shell.

Keeping GIS data in full-resolution and simplifying it on demand is a known challenge: simplification has to be fast and its output has to be topologically consistent. We saw how to get a topologically consistent simplified version of a full layer, but that method isn’t fast enough for on-demand usage. Also, we saw how to perform a fast simplification by sacrificing the degree or generalization so that the introduced inconsistency would not be visible on a rendering surface.

New bug fix and improvement release for the 3.3 series of GEOS is out. Changes since 3.3.3: Do not abort on NaN overlay input (#530) Reduce CommonBitsRemover harmful effects during overlay op (#527) Better cross-compiler support (#534) Enable overlay ops short-circuits (#542) Envelope-based short-circuit for symDifference (#543) Fix support for PHP 5.4 (#513) Fix TopologyPreservingSimplifier invalid output on closed line (#508) Reduce calls to ptNotInList, greatly speeding up Polygonizer (#545)

Following a recent research about how to simplify a multipolygon layer while keeping topological relationships intact, here’s my take on that, using the PostGIS topological support. The data French administrative subdivisions, called “départements”, will be used. Data can be downloaded here. It is composed by 96 multipolygons for a total of 47036 vertices. Principle of simplification We convert a layer’s Geometries to TopoGeometries We simplify all edges of the built topology We convert the (now-simplified) TopoGeometries back to Geometries Steps The following steps assume you loaded the shapefile into a table named “france_dept”.

The long-awaited full featured PostGIS 2.0.0 is finally out. Coupled with GEOS 3.3.3 (released a few days before) and GDAL-1.9.0, it brings you the best spatial database system in town, complete with raster analysis and topology modeling support. Complete announcement, with list of changes, here. It’s been an great pleasure to work with the rest of the team on getting this release ready for shipping, drawing a line after over two years of hard work on new features.

I’ve been spending the last few days profiling and optimizing the new simple-to-topological converter you will find in PostGIS 2.0.0 thanks to a community effort. The most expensive operation was found to be the ST_AddEdgeModFace function, which adds an edge and checks if such edge creates a new face. Face-splitting detection was implemented using a brute force approach consisting in invoking the GEOS polygonizer and then checking if any polygon created contained the newly added edge in its boundary.

The second bugfix release in the 3.3 branch of GEOS was released today. This is the version required by the topology support shipped with the upcoming PostGIS 2.0 release. Everyone is recommended to upgrade. Changes can be read here, package can be downloaded here.

An early tester of the new PostGIS Topology submitted an interesting dataset which kept me busy for a couple of weeks fixing a bunch of bugs related to numerical stability/robustness. Finally, the ST_CreateTopoGeo function succeeded and imported the dataset as a proper topological schema. Here’s what it looks like: Edges of the built topology At a first glance it doesn’t seem to be particularly problematic. Here’s the composition summary: =# select topologysummary('small_sample_topo'); topologysummary -------------------------------------------------------- Topology small_sample_topo (2042), SRID 0, precision 0 83 nodes, 156 edges, 74 faces, 0 topogeoms in 0 layers But the devil hides at high zoom levels.

PostGIS implementation of the ISO SQL/MM Topology-Geometry model is finally complete. The SQL/MM model is just a portion of the whole topology support, but an important one, including schema definition and functions to create and populate the schema with primitive components (nodes, edges, faces). In addition to the base model, PostGIS adds a TopoGeometry data type for use wherever you would normally use a Geometry type, except the former will be defined by references to primitive, shared, topological components.

The first bugfix release in the 3.3 branch of GEOS was released today. Anyone running 3.3.0 is recommended to upgrade. Changes can be read here, package can be downloaded here. By the way… did you try the PHP binding yet ? Configure with --enable-php to take a look !

As projects move their code under git control, people get frustrated about being unable to do most basic operations they are used to perform with SVN or CVS. That’s a fact, so let’s see if I can relief some pain by sharing what I know or learn as I crawl the learning curve myself. Yesterday I’ve met with Markus Neteler and he was complaining about being unable to checkout the release branch of QuantumGIS without filling up his laptop hard drive.

GEOS 3.3.0 is out: http://download.osgeo.org/geos/geos-3.3.0.tar.bz2 This release introduces a fair amount of new C-API interfaces and a brand new PHP binding. Full details in the NEWS file: http://trac.osgeo.org/geos/browser/tags/3.3.0/NEWS As with any release since 3.0.0 there is complete binary compatibility with clients linked against the C-API. These include, but are not limited to, PostGIS. For a list of known clients: http://trac.osgeo.org/geos/wiki/Applications (add yours, if not already listed!) GEOS is a C++ port of the JTS Topology Suite.

I’ve setup git mirrors of PostGIS, GEOS and MapServer SVN repositories updated hourly. You can clone the git repositories and re-attach to the SVN ones with this simple script (untested): for repo in postgis geos mapserver; do git clone git://github.com/strk/${repo}.git cd ${repo} git svn init http://svn.osgeo.org/${repo}/trunk git update-ref refs/remotes/git-svn refs/heads/master git svn fetch cd - done After that you can run git svn rebase to get changes from SVN or git pull to get changes from GIT (may be one hour late)

There is no problem importing OSM data into PostgresSQL / PostGIS. In part one of the article we’ve seen Geofabrik’s shapefiles having a text data truncation problem, but using osm2pgsql everything gets into an UTF-8 database without a failure. It’s as simple as: $ osm2pgsql -l -c -S default.style africa.osm.bz2 -d osm The -l switch aks for keeping lat/long projection, -c requests creation of the schema, -d specifies the database to use.

This week I’ve been presented with a problem importing OpenStreetMap data of Africa from GeoFabrik’s shapefile export into a PostgreSQL / PostGIS database. The problem consisted in a loss of information during the transport, resulting in wrongly encoded strings (road names) ending up in the db. This was during a feasibility study. So, is that feasible ? Let’s take a look. I downloaded the shapefiles and tried to import the roads one using shp2pgsql with no options, and here’s the result: