Fix layering order for "construction=*" highway categories

[jeisenbe]

Related to #3579

Changes proposed in this pull request:

• Use osm_id as the last way to determine rendering order for roads-fill, so that different highway=construction roads will always layer in the same order, at different zoom levels. This change will take effect immediately.
• Add "construction=" values to the z-order table in openstreetmap-carto.lua, so that the different categories of highway=construction will render in proper order (eg construction=motorway on top, construction=service on bottom). This will take effect on database reload, and for new or edited features.

Explanation

Highway=construction is currently set to z = 10 in the z-order table, so that it will render below almost all highways and paths. However, the different types of construction=*, such as construction=motorway, construction=trunk_link, construction=service, all have the same z value, so they are laid in apparently random fashion. The layering order often changes from one zoom level to the next.

These two commits will eventually fix this problem.

The change to project.mml, adding osm_id as a final fall-back for ordering, will at least cause all highway=construction to rendering in a consistent way between zoom levels, effective immediately.

The improvement to rendering for different classifications of highway=construction is part of the lua transformations, and will take effect gradually for new and edited features, and then for old features when the database is next reloaded.

EDITED: the lua transformation changes have been removed for now, because a database reload is not yet planned

Test rendering with links to the example places:

EDITED: These were with the first commits

Before
A6 - New Trunk Interchange - Northern Ireland
https://www.openstreetmap.org/#map=16/54.7629/-6.4847

• construction=trunk_link above construction=trunk
  z15 Before
  
  z16 Before
  

After z15

After z16

Murry's Island - Northern Ireland
https://www.openstreetmap.org/#map=15/54.7734/-6.5189

• New trunk road crosses an under-construction minor road and an under-construction secondary road (right) and an under-construction tertiary road (left)
  z15 Before
  
  z15 After
  

Castledawson - new residential area
https://www.openstreetmap.org/#map=16/54.7692/-6.5512
z16 Before

z17 Before

After z16

After z17

EDITED: See new test renderings below

[imagico]

Support for ordering by osm_id, regarding z_order (and therefore database related) changes see #3644 (comment).

[jeisenbe]

I could add a new SQL-based order just in the project.mml file for roads-fill only. But I thought that changing the z-order list in lua was better for rendering speed. Thoughts @imagico, @pnorman?

…

On Thu, Jan 17, 2019 at 8:04 PM Christoph Hormann ***@***.***> wrote: Support for ordering by osm_id, regarding z_order (and therefore database related) changes see #3644 (comment) <#3644 (comment)> . — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3646 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshCqmtUl4f6IcqauLaeRCuC2sWFauks5vEFjZgaJpZM4aERZK> .

[imagico]

Your choice of approach is perfectly fine IMO but it will have to wait until the next database reload. I don't think adding complexity to the road layers' SQL to circumvent this would be a good idea.

Just have a bit of patience here - the last database reload was in August - openstreetmap/chef#155 (comment) and for previous discussion about database reload patterns see #1286. While this is a problem that would be good to fix it is not a high impact problem that frequently causes serious problems for map users or mappers.

[jeisenbe]

Ok, I’ve removed the z-order changes. So the PR only adds ordering by osm_id now

…

On Thu, Jan 17, 2019 at 9:06 PM Christoph Hormann ***@***.***> wrote: Your choice of approach is perfectly fine IMO but it will have to wait until the next database reload. I don't think adding complexity to the road layers' SQL to circumvent this would be a good idea. Just have a bit of patience here - the last database reload was in August - openstreetmap/chef#155 (comment) <openstreetmap/chef#155 (comment)> and for previous discussion about database reload patterns see #1286 <#1286>. While this is a problem that would be good to fix it is not a high impact problem that frequently causes serious problems for map users or mappers. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3646 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshOZWX4M1JdIbHE2e2y2Cp8iG1tcJks5vEGdagaJpZM4aERZK> .

[pnorman]

SQL looks good in principle, but I haven't tested it.

I was going to comment on splitting up the construction changes, but I see @imagico has already done that.

[jeisenbe]

New tests with the current commit:
https://www.openstreetmap.org/#map=6/54.7629/-6.4847

• layering order is now consistent between different zoom levels

z17

z16

z15

[jeisenbe]

Thanks! I plan to submit a new PR with the lua changes, at the time of the next database reload.

…

On Fri, Jan 25, 2019 at 8:34 AM Matthijs Melissen ***@***.***> wrote: Merged #3646 <#3646> into master. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3646 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshHuYAShfWDyTBePvoIudfbl9Jwb4ks5vGkMRgaJpZM4aERZK> .