Marble Arch has disappeared

[SomeoneElseOSM]

(just a heads-up)

https://www.openstreetmap.org/relation/5640188#map=18/51.51292/-0.15956&layers=H

I'm guessing it's due to relationship membership of 5640188. I'm seeing the same issue in a different style. If I find out what it is I'll mention it here.

[skorasaurus]

I am not sure but I think The Marble Arch is not displaying because it doesn't have any tags that we are rendering; we are not rendering junction=yes as of this moment.

(on second look, yes, I see that the southern roads who are members of the relation should be rendered).

[SomeoneElseOSM]

@skorasaurus Yes - but the component ways of that relation should be valid. Something is "kicking them upstairs" expecting them to be rendered as part of a relation (which, as you say, isn't happening because just junction=yes isn't rendered). That "something" is likely osm2pgsql but I've not had chance to even check what version I'm running of that yet!

[SomeoneElseOSM]

Just looked into this - it's not osm2pgsql as such, it's the tag transforms. The corresponding code in OSM Carto is https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua has had extra "if line..." and "if area..." checks added to work it. I've just added a fix to my style at https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L3047 to resolve things there, arguably that's just a cludge and arguably it's a data problem anyway - https://overpass-turbo.eu/s/sRG - I don't think that those could really be called multipolygons in the usual sense.

However, based on https://github.com/hotosm/HDM-CartoCSS/wiki/Importing-data I guess that this style uses the C transforms in osm2pgsql by default? If so, it probably doesn't make a lot of sense to do a fix there to work around the data. Using OSM Carto's lua here would probably work out of the box since there doesn't seem to be anything style-specific at https://github.com/gravitystorm/openstreetmap-carto/commits/master/openstreetmap-carto.lua .

[jarek]

There is now a note on osm.org about this (https://www.openstreetmap.org/note/1591542) and I ended up looking at what's not shown on Humanitarian tiles. Here are my findings, if it helps anyone:

For comparison, Bayswater Road which is rendered in Humanitarian: https://www.openstreetmap.org/way/14196965 and Cumberland Gate which is not: https://www.openstreetmap.org/way/41517345 The difference is Bayswater Road has bicycle=yes, foot=yes, horse=yes. But I don't see how that should affect rendering of highway=trunk really.

Also e.g. https://www.openstreetmap.org/way/4237857 is highway=trunk with no access tags and it is rendered.

Maybe some weird bug in Humanitarian triggered because both ways are also outer borders of https://www.openstreetmap.org/relation/5640188 ?

Found another road which is not rendered: https://www.openstreetmap.org/way/148305759 Marylebone Road near Baker Street, again it is part of https://www.openstreetmap.org/relation/5640183 which is a multipolygon junction. So perhaps it's that somehow... although https://www.openstreetmap.org/way/2599447 is rendered...

And then https://www.openstreetmap.org/way/527125965 at Euston Circus is not rendered, although it does have access tags. It is part of a junction https://www.openstreetmap.org/relation/5640184, but so is https://www.openstreetmap.org/way/316158482 which is rendered.