Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

amenity=shelter rendered too prominently #3346

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 7 comments
Closed

amenity=shelter rendered too prominently #3346

openstreetmap-trac opened this issue Jul 23, 2021 · 7 comments

Comments

@openstreetmap-trac
Copy link

Reporter: axk
[Submitted to the original trac issue database at 9.37pm, Tuesday, 23rd November 2010]

[http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dshelter amenity=shelter] (some hut to protect against bad weather conditions[, like] roofed benches in a forest, [...] a [http://en.wikipedia.org/wiki/Bothy Bothy], or small alpine huts) is currently rendered by mapnik starting at zoom level 13 (without name) and zl 15 (with name). this is way too prominent, making amenity=shelter, which typically is just a maybe 4 x 5 meter space with a roof, look more important than features that are actually more important, like a church (rendered from zl 16), certain highways, etc. the size of the 4 x 5 meter amenity=shelter symbol at zl 13, by the way, is about 200 meters. see also http://www.mail-archive.com/talk[at]openstreetmap.org/msg22803.html ([OSM-talk] mapnik shelter rendering) and [http://www.openstreetmap.org/?lat=11.0498&lon=124.6057&zoom=13&layers=M an example zl 13 where shelters should not appear].

i think the cause of this bug is ticket:1689 (which introduces amenity=shelter and [http://wiki.openstreetmap.org/wiki/Proposed_features/Alpine_hut tourism=alpine_hut] rendering). initially, both tags where rendered from zl 16 only. the op then [ticket:1689#comment:4 asked for rendering at zl 13] - but for alpine huts only. this last part didn't get noticed by the implementer, which is why we have the current situation.

please fix by rendering amenity=shelter from zl 16 (without name) and zl 18 (with name) only. thanks!

@openstreetmap-trac
Copy link
Author

Author: rickmastfan67
[Added to the original trac issue at 6.06am, Friday, 3rd December 2010]

I'll second this. I've see the shelter's pop up in the middle of Downtown's and it SO looks out of place, it's that bad.

@openstreetmap-trac
Copy link
Author

Author: !i!
[Added to the original trac issue at 1.51pm, Tuesday, 18th January 2011]

I agree to this users.

The current shelter rendering is fine for path in the wild, where it's important to know shelters. But nowadays we tag shelters of playgrounds or smoking cabins or every similar that offers protection in a city during rain and is public use.

@openstreetmap-trac
Copy link
Author

Author: flaimo
[Added to the original trac issue at 11.49pm, Friday, 25th March 2011]

amenity=shelter is also used for those little bus shelters at public transport platforms, which leads to a lot of rendered shelters in inner cities.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 12.45am, Saturday, 26th March 2011]

It's the same problem we have with islands and airports. Both the very large ones and the smallest ones are tagged exactly the same. As nodes, they carry no other hint about their size or importance.

@openstreetmap-trac
Copy link
Author

Author: flaimo
[Added to the original trac issue at 6.08pm, Tuesday, 29th March 2011]

actually you can, at least for public transport shelters, differentiate them from "normal" shelters, if they are members of a relation tagged with public_transport=stop area. see this proposal for details: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Stop_Area

@openstreetmap-trac
Copy link
Author

Author: flaimo
[Added to the original trac issue at 12.50pm, Sunday, 29th May 2011]

i have initiated a proposal for shelter_type which got approved today: http://wiki.openstreetmap.org/wiki/Proposed_features/shelter_type

and

http://wiki.openstreetmap.org/wiki/Key:shelter_type

with this additional key it should be possible to render shelters in the mountains more prominently than bus shelters for example.

@openstreetmap-trac
Copy link
Author

Author: axk
[Added to the original trac issue at 6.25pm, Friday, 11th May 2012]

looking at r25726, this seems to have been fixed by ldp 14 months ago. thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant