[gdal-dev] OSM driver with z_order values

[Jukka Rahkonen]

Jeff McKenna <jmckenna <at> gatewaygeomatics.com> writes:

> 
> Hi all,
> 
> I've successfully used the OSM driver[1] to convert from the OSM pbf 
> binary format into another (in my case Postgres/PostGIS, and testing 
> with Japan dataset).  The time to do this is much much faster than other 
> tools such as osm2pgsql (once I learned the "PG_USE_COPY YES" parameter 
> the time went from more than 3 hours down to minutes).
> 
> That is the good news.  The bad news is that I am stuck now because the 
> OSM driver does not set z_order (rendering order) values, which are 
> important for display in MapServer (and Mapnik etc.).  Tools like 
> osm2pgsql and imposm do set those values[2].
> 
> Now I realize that I could go through the osm2pgsql/imposm code and set 
> those myself manually somehow, once I figure out the exact logic used by 
> those tools, but, I am wondering if this could be added to the OGR/OSM 
> driver itself, as it is so useful for many mapping projects (?).
> 
> Call this a wishlist email then, but I just thought I'd file the request :)


Hi Jeff,

Imposm and osm2pgsql utilities are more or less made to one purpose that is
to generate database for rendering with more or less standard styles and
therefore they can have fixes rules for creating z_orders. I am not sure if
the GDAL OSM driver has such a strong same-for-all use case.

I would make a little test first:
- add column "z_order"
- create indexes for highway, tunnel, and bridge which is probably a good
idea anyway (consider also the other fields used in SELECTs during rendering
time)
- udpdate z_order by your rules with CASE...WHEN...THEN...ELSE it should be
one or a couple SQL statements and thus fast.
http://www.sqlite.org/lang_expr.html speaks about short-circuit which may
mean that the indexes above are not even needed for making populating
z_order faster but at rendering time they are anyway good to have
- create index for z_order


All the SQL post-process commands can be run with GDAL as well from a script
as ogrinfo commands with -sql parameter. If you still aim to something
better, create also simplified geometries for the most heavy geometries and
save them as additional geometry fields which saves space because there is
no need to copy the attributes. A few more lines of SQL will be needed for
creating spatial indexes and adding new geometries into geometry_columns.

Finally you just need to publish the rendering rules (mapfile I guess),
osmconf.ini and   post-process SQL all together and you should have an
easily deliverable package with optimized data access which you probably
would like to name as "MS4OSM". I volunteer to test the package. Actually I
have done some tests myself but been too lazy for putting everything
together into a single executable script.

-Jukka Rahkonen-