[gdal-dev] OSM driver with z_order values

Jeff McKenna jmckenna at gatewaygeomatics.com
Thu Nov 6 15:49:55 PST 2014

On 2014-11-06 6:48 PM, Jukka Rahkonen wrote:
> 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-

Hi Jukka,

I think you are saying what I was thinking (but trying to avoid): 
modifying my osm2pgsql-to-imposm-schema.sql script[1] to something like 
"ogr-to-imposm-schema-script.sql".  I already started that but got stuck 
at the z_order calculation.  But before traveling down that path I 
thought I'd see if others were interested in having that calculation 
directly in the OSM driver, since it is so useful to many mapping 
projects.  It was just a thought.

I agree with your general plan, although I find it easier to just modify 
the existing schema script (once we figure out the logic used by 
osm2pgsql/imposm used for z_order).



Jeff McKenna
MapServer Consulting and Training Services

More information about the gdal-dev mailing list