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:
https://github.com/gravitystorm/openstreetmap-carto/pull/1664
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.
_______________________________________________
dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/dev
