[gdal-dev] OSM driver with z_order values

[Even Rouault]

Jeff,

> 
> 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 

Mostly due to the optimized custom node indexing and the local temporary 
sqlite DB I think

> such as osm2pgsql (once I learned the "PG_USE_COPY YES" parameter
> the time went from more than 3 hours down to minutes).

This is now the default in trunk.

> 
> 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 :)

That could be usefull I guess. The difficulty is to code that. Well, hard-coding 
that in the driver would not be too hard, but it wouldn't be pretty to put 
those empirical rules burried into C++ code (if new tags or tag values appear, 
etc..)

The osm2pgsql folks apparently have decided to code such parts in LUA : 
https://github.com/openstreetmap/osm2pgsql/blob/master/style.lua. Not sure we 
would want to link GDAL against the LUA interpreter. Although MapServer does 
JavaScript nowadays...
Actually digging more, I see they have also a C++ version probably used if LUA 
isn't available: 
https://github.com/openstreetmap/osm2pgsql/blob/master/tagtransform.cpp

The ideal would to find some syntax to do this in osmconf.ini. Actually, 
Jukka's mention of sqlite makes me think that the syntax could be SQL 
evaluated by SQLite.
Something like :

computed_fields = z_order
z_order_type = Integer
z_order_sql = "SELECT (CASE [highway] WHEN 'minor' THEN 3 WHEN 'road' THEN 3 
WHEN 'tertiary_link' THEN 4 ... ELSE 0) + (CASE WHEN [bridge] IS IN ('yes', 
'true', '1') THEN 10 ELSE 0 END) + (CASE WHEN [layer] IS NOT NULL THEN 10 * 
CAST([layer) AS INTEGER) ELSE 0 END) + ..."

And stuff in [] would be replaced by the corresponding field value.

That's something that could also potentially be done as the ogr2ogr level, 
since there's hardly anything driver specific in that, but finding the right U.I 
to specify per-layer computed fields isn't obvious.


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com