[OSM-dev] osm2pgsql: meaning of z_order column in polygon and point tables

Paul Norman penorman at mac.com
Fri Jul 17 09:40:01 UTC 2015

On 7/17/2015 2:06 AM, Sven Geggus wrote:
> The Generation of the z_order column seems to be the only showstopper which
> is left to make an imposm3 generated databases suitable for rendering tiles
> with the osm standard style.
z_order is not a showstopper for the standard style - it uses it in two 
places, and I've just opened a PR to remove those: 

We're hoping to move back to z_order when osm2pgsql 0.88.0 is more 
common, as the current method for roads requires a 45 line lookup table, 
which has to be repeated for four different style queries.

> Am I right in the assumption, that z_order on polygons is only a matter of
> the layer tag and could thus be easily emulated using a simple database view
> which evaluates tags->'layer' in a hstore column?
I doubt anyone is using it on polygons and depending on behavior other 
than it sorting in the same order as COALESCE(layer::integer,0), which 
we call layernotnull in osm-carto. This leaves aside validation that 
layer can be turned into an integer, which is critical.

There is a difference in some cases - right now some features will sort 
before others on the same layer, regardless of way_area, but I doubt 
anyone is intentionally doing that.

> An area tagged railway=station is getting added 5 to the z_order column
> only because it is assumed to be a linestring rather than an area?
> Same goes for highway areas which are getting added 3 to the z_order column
> only because it is assumed to be a linestring rather than an area?
The z_order code in tagtransform.cpp applies to both polygons and 
linestrings, but is clearly designed around tagging for linear features.

This is of course completely different for lua tag transforms, where 
z_order may be computed any way the user wants.

https://github.com/openstreetmap/osm2pgsql/pull/374 might help 
understand both the recent changes, and the older behavior.

More information about the dev mailing list