Move public transport shelters to z18 or z19

[lakedistrictOSM]

amenity=shelter + shelter_type=public_transport Wiki: https://wiki.openstreetmap.org/wiki/Tag:shelter%20type=public%20transport?uselang=en-GB

As the wiki says, these are small shelters found at bus stops and train stations.

Currently they are rendered from z16, which means they are rendered before typically larger features like pubs, restaurants etc. This make them look like prominent, important places when really they're not. Following the size rules mentioned by @kocio-pl recently, these shelters should be rendered later because of their small size. I propose moving them to z18 or maybe z19.

https://www.openstreetmap.org/#map=16/54.3806/-2.8571

https://www.openstreetmap.org/#map=16/54.6197/-3.0480

[matkoniecz]

I would also render them with lower priority than bus stops.

[Elefant-aus-Wuppertal]

or maybe the shelters with shelter_type=public_transport can also be rendered in blue instead of brown, to show that they are related to public transport?

[Adamant36]

It would help resolve issues like #2431 if they were rendered at z19.

[maraf24]

his make them look like prominent, important places when really they're not.

In rural areas they can be the only shelters available in case of bad weather.

[Tomasz-W]

@maraf24 I can agree, but IMO it's still not a reason to render them at z17, I think z18 would be ok.

[Discostu36]

Just wanted to provide two additional examples to make the problem clear. The shelters are rendered while the bus stops are not:

Zoom 16:

Zoom 17:

[dch0ph]

[Following on from new discussion on #2431]

Summarising the various issues:

2431: As above, presenting problem is public transport (PT) shelters "hiding" bus stops. But solution of "prioritising" bus stops over shelters (i.e. when they are both being rendered at the same zoom level) doesn't seem a workable route.

3483 (this issue): Addresses same problem as #2431, but in a more natural way. At low zoom, the bus stop will always be rendered, the shelter will appear later. Second order issue of prioritisation at Z18/Z19.

4317 [closed]: Issue proposing a new icon specifically for PT shelter. This didn't get much traction and the issue was closed. No reason why a specific symbol couldn't be used at Z18/Z19, but there is no need to complicate this issue.

3124: Seems to be proposing a shelter-based symbol for bus stop with shelter. Not looking promising / largely independent of current proposal.

I've been testing the proposal of moving PT shelters to Z18+ and it works nicely. A public transport shelter is something small that you take advantage of, rather than a shelter you head to from a distance. It does clutter the map to render these from Z16.

Happy to submit a PR if general enthusiasm. This should close both #3483 and #2431, although #2431 has lots of suggestions for "stop + shelter" symbols that would fit better in #3124!

[imagico]

2431: As above, presenting problem is public transport (PT) shelters "hiding" bus stops. But solution of "prioritising" bus stops over shelters (i.e. when they are both being rendered at the same zoom level) doesn't seem a workable route.

This has been commented on in https://github.com/gravitystorm/openstreetmap-carto/issues/2431#issuecomment-1615161283 - and to be clear again: Changing priorities of shelter/bus_stop specifically would be ok, it is just not a workable route to address #3880 in general.

3483 (this issue): Addresses same problem as #2431, but in a more natural way. At low zoom, the bus stop will always be rendered, the shelter will appear later. Second order issue of prioritisation at Z18/Z19.

No, as written in #3880 the priorities need to be in sync with starting zoom levels, that does not mean changing starting zoom levels will fix priorities.

The choice of starting zoom level is a design decision and as such should not be influenced by our inability so far to fix #3880.

4317 [closed]: Issue proposing a new icon specifically for PT shelter. This didn't get much traction and the issue was closed. No reason why a specific symbol couldn't be used at Z18/Z19, but there is no need to complicate this issue.

The problem of #4317 was exclusively the lack of a suitable symbol. In general: I would strongly suggest that if the starting zoom level of shelters with shelter_type=public_transport is changed that also a symbol variant (which can differ is a subtle way) is used so the display rules are more intuitively understandable.

3124: Seems to be proposing a shelter-based symbol for bus stop with shelter. Not looking promising / largely independent of current proposal.

Part of #3124 could be aggregating shelter and bus stop into a single symbol - which would address the prioritization problem nicely. But technically this is somewhat difficult with current mapnik. The whole subject is discussed more in depth in https://imagico.de/blog/en/symbols-and-labels-3-augmenting-symbols/

I've been testing the proposal of moving PT shelters to Z18+ and it works nicely. A public transport shelter is something small that you take advantage of, rather than a shelter you head to from a distance. It does clutter the map to render these from Z16.

I would be in favor in principle of moving shelters with shelter_type=public_transport to a higher starting zoom level - with the following constraints:

1. Priorities would need to be adjusted of course
2. A symbol variant would be important for mappers to intuitively understand the rendering logic
3. I would be very hesitant to support moving the starting zoom level more than one up without a thorough demonstration that this is desirable, especially also at high latitudes. In lack of good arguments for that i would suggest to more conservatively move by one zoom level and evaluate the results in the map afterwards. This in particular applies here if both priorities and starting zoom levels are changed at the same time.

[dch0ph]

That all makes sense.

It's clear from @BertMule 's example in #2431 (https://www.openstreetmap.org/#map=19/51.44462/4.92706) (where the shelters override stops even at Z19) that simply delaying PT shelters to Z18 and hoping that distance will avoid the prioritisation is a half-baked solution.

I do think that Z18 is a good start point based on size and function, but agree that a conservative approach is reasonable if the aim to to (partially) tackle #3880. This case might be a good test bed for solutions?

I assume a sensible option to addressing prioritisation is to introduce

ORDER BY start_zoom ASC

as you propose in #3880, but without (as yet) the SQL level filtering? [only defining start_zoom for relevant POIs to start with]

I imagine that further sorting would be desirable in the longer term (#4676)?

A symbol variant would be important for mappers to intuitively understand the rendering logic

Yes, it would be a bit lazy otherwise. 3 starting options here:

1. Simply changing the colour to transportation icon blue (suggested by @Elefant-aus-Wuppertal above).
2. A new icon (existing colour). was proposed in #3124 for a stop with shelter (but is better as the shelter). Would need to be adapted to SVG.

It looked like you also had a PT shelter icon in (https://imagico.de/blog/en/symbols-and-labels-3-augmenting-symbols/) ?

3, Both a new icon and blue.

Option 2 may be the best; the shelter will always be larger (14 x 14, stop is 10 x 10) so there is the risk that a blue shelter might distract from the stop itself.

It would be a shame, however, to get blocked on the icon question, since a test for addressing #3880 as well the current issue would be a bigger prize.

[imagico]

I assume a sensible option to addressing prioritisation is to introduce

ORDER BY start_zoom ASC

as you propose in #3880, but without (as yet) the SQL level filtering? [only defining start_zoom for relevant POIs to start with]

In principle yes, the most viable way of prioritization of point symbols is by ordering in SQL.

But i would suggest to carefully separate between ideas for addressing #3880 and introducing means for explicit prioritization in amentiy-points in principle. The latter would be done using the same methods we use for defining priorities elsewhere - like

https://github.com/gravitystorm/openstreetmap-carto/blob/9fc6ed454169555b7b2f8a2ee4cc40d5ba67bffd/project.mml#L625

or

https://github.com/gravitystorm/openstreetmap-carto/blob/9fc6ed454169555b7b2f8a2ee4cc40d5ba67bffd/project.mml#L1381

while for the former this will depend on the approach taken to address #3880 and is likely to require a different method to scale to the level of complexity we have here overall and to avoid the duplication of logic. You especially need to keep in mind that the starting zoom level frequently varies among elements with the same feature value while explicitly prioritizing bus stops over shelters can be done based on the feature column alone.

[dch0ph]

while explicitly prioritizing bus stops over shelters can be done based on the feature column alone.

Don't you need the shelter_type hstore tag as well?

I was thinking that a more elegant solution was needed than the approach in #4836. I don't see how you can address #3880 without moving the "starting zoom" logic into the SQL, but it's not obvious how would do this is a generic way where the start zoom depends on different columns.

Perhaps there's a hybrid of JOIN(VALUES approach and the explicit CASE WHEN of #4836 to generate the starting zoom, but this might be beyond my SQL skills!

[imagico]

Don't you need the shelter_type hstore tag as well?

When you prioritize bus stops over shelters you can do so for all shelters and not just shelter_type=public_transport.

You still need a shelter_type column to be able to select the right symbol and starting zoom level in MSS of course.

Please discuss #3880 there and not here.

[dch0ph]

When you prioritize bus stops over shelters you can do so for all shelters and not just shelter_type=public_transport.

That would feel a kludge to me. If you had a "proper" shelter next to a bus stop, then you would want to consistently prioritise the "proper" shelter.

I do have a working solution, but it may raise as as many questions as answers:

    (SELECT
        *,
        CASE
          WHEN feature = 'shelter' THEN 15
          WHEN feature = 'highway_bus_stop' THEN 16
          WHEN feature = 'amenity_shelter_public_transport' THEN 17
        END AS start_zoom

            'amenity_' || CASE WHEN amenity = 'shelter' AND tags->'shelter_type' = 'public_transport' THEN 'shelter_public_transport' END,

[ahead of amenity_shelter in COALESCE]

      ORDER BY start_zoom ASC NULLS LAST,
        score DESC NULLS LAST,
        way_pixels DESC NULLS LAST

The "rewriting" of the feature column isn't necessary, but avoids duplicating logic in SQL and MSS. The MSS is then focussed on styling.

I don't see how to prioritise X over Y through ORDER BY without assigning a priority to everything. In the above, the default priority is NULL, and so may lead to odd behaviour - a lot of PT shelters may pop up! A reasonable default priority / start_zoom might be 16, i.e. "proper" shelters get a boost, PT shelters are disfavoured.

I also feel itchy about the sort ordering. It makes sense for larger areas to be prioritised, but this order is "hijacked" by putting other sort criteria above. score is fairly harmless since so few things get a score, but the start_zoom sort would currently push all the areas to the end. It would make more sense to me to prioritise way_pixels >start_zoom > score.

[imagico]

If you had a "proper" shelter next to a bus stop, then you would want to consistently prioritise the "proper" shelter.

I see no reason not to prioritize bus stops over shelters in general - they have the same starting zoom level.

I don't see how to prioritise X over Y through ORDER BY without assigning a priority to everything.

You already have a priority assigned to everything, it is just the same for most nodes.

I might have been a bit convoluted in https://github.com/gravitystorm/openstreetmap-carto/issues/2431#issuecomment-1615161283 - so trying to make it more clear now:

The amenity-points SQL code contains a lot of different things - stuff that is rendered with a symbol, a label or both. The labels get rendered separately in the text-point layer, but with the same code.

You don't have to assign a unique priority to every tagging that gets rendered right away - although that would ultimately be the goal for addressing #3880 of course. But you also should not just prioritize bus stops over everything else, that would work badly relatively to features shown earlier than bus stops (like hospitals).

Yes, anything you'd do here short of actually addressing #3880 would be messy in one way or the other. That is why i have mentioned repeatedly that solving #3880 would be of high strategic importance.

Regarding the way_pixels sorting - keep in mind that for all the landcover labels the starting zoom level also depends on polygon size. So for the landcover labels way_pixels sorting already implements sorting by starting zoom levels. For the POI symbols, however, it does not. And of course there are labels in other layers (like stations) that partly start earlier than amenity-points and partly later.

And another reminder that this is not the right issue to discuss prioritization.

[dch0ph]

I see no reason not to prioritize bus stops over shelters in general - they have the same starting zoom level.

My bad. In my walking-oriented derivative, shelters are prioritised and start at Z15.

You don't have to assign a unique priority to every tagging that gets rendered right away - although that would ultimately be the goal for addressing https://github.com/gravitystorm/openstreetmap-carto/issues/3880 of course. But you also should not just prioritize bus stops over everything else, that would work badly relatively to features shown earlier than bus stops (like hospitals).

So you could just do something like:

    CASE
      WHEN feature = 'amenity_shelter_public_transport' THEN 17
      ELSE 16
    END AS start_zoom

which would push PT shelters below everything else.

And another reminder that this is not the right issue to discuss prioritization.

Point taken, but I think we're agreed that simply changing the starting zoom without changing the relative priority of shelter vs. stop won't really fix things.

[imagico]

So you could just do something like:

    CASE
      WHEN feature = 'amenity_shelter_public_transport' THEN 17
      ELSE 16
    END AS start_zoom

which would push PT shelters below everything else.

I doubt this would work any better than prioritizing bus stops above everything else. You would end up with various POI types with later starting zoom level and often clearly lower priority to block shelters and make them vanish as you zoom in. In this specific case in particular things like elevators, vending machines and information boards come to mind.

Point taken, but I think we're agreed that simply changing the starting zoom without changing the relative priority of shelter vs. stop won't really fix things.

Yes. But i also want to emphasize this is my opinion only so far. Short of actually solving #3880 i have no really good solution to suggest so if any of the other maintainers sees a different viable route to go forward here i am open to that.

[dch0ph]

I doubt this would work any better than prioritizing bus stops above everything else. You would end up with various POI types with later starting zoom level and often clearly lower priority to block shelters and make them vanish as you zoom in. In this specific case in particular things like elevators, vending machines and information boards come to mind.

You're right. Swapping the "catch all"

CASE
  WHEN feature = 'highway_bus_stop' THEN 16
  ELSE 17
END AS start_zoom

would avoid the problem above (as well as the need to "rewrite" the feature column). It would mean that bus stops would oddly block any POIs with higher starting zoom (including "normal" shelters!), but there probably aren't many of those?

So there may be a partial / incremental solution to #3880 if starting from the "top down"?

[imagico]

It would mean that bus stops would oddly block any POIs with higher starting zoom (including "normal" shelters!), but there probably aren't many of those?

As already mentioned they would block stuff that already starts earlier (practically meaning: those would vanish as you zoom in).

So there may be a partial / incremental solution to https://github.com/gravitystorm/openstreetmap-carto/issues/3880 if starting from the "top down"?

I suggest to discuss strategies for solving #3880 there. As commented there already improving the drawing order in amenity-points does not have to be combined with addressing #3880. Any selective fix for some existing problems is welcome as long as it does not introduce new issues.

[dch0ph]

As commented there already improving the drawing order in amenity-points does not have to be combined with addressing https://github.com/gravitystorm/openstreetmap-carto/issues/3880. Any selective fix for some existing problems is welcome as long as it does not introduce new issues.

This is the bit I'm not really getting. Is there some way to selectively prioritise highway=bus_stop over PT shelter that I'm missing? I don't see how to do this in the SQL query, since any form of ORDER BY will require setting a "default" priority.

[imagico]

What you can do is aggregating different feature types into a common priority (despite them having different starting zoom levels) and this way you don't need to develop a full solution to #3880 while still being able to do some meaningful prioritization. For example you could

• aggregate all the high zoom level POIs (like shops, food&drink amenities etc.) into a common priority lower than bus stops.
• aggregate all landcover polygon labels into a common priority higher than that of bus stops (and secondarily sort by way_area of course like now).
• aggregate all landcover point labels (which start at z17) into a common priority lower than that of bus stops.

I am not claiming that either of these will work particularly well - i have not tried it. But in principle these are components that would allow you to do a partial explicit sorting in amenity-points without giving every feature class an explicit priority. And the bar is low because right now we don't do a meaningful prioritization at all for the most part. Hence anything other than an explicitly wrong order (like the mentioned prioritization of bus stops over hospitals) would be acceptable IMO.

[dch0ph]

That's seems a lot of engineering to address one prioritisation! Really you would want some kind of look-up table to return feature name + info useful for prioritisation, which is getting beyond what we do with the current all in-lined SQL (making apologies in advance for bringing up #3880 again).

Given that there isn't an easy immediate fix, a PR to push PT shelters down to Z17 would solve a large fraction of the problems. This would leave still leave the question of whether a distinct styling for PT shelters is first needed.