Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide some indoor objects #3031

Closed
kocio-pl opened this issue Jan 22, 2018 · 10 comments
Closed

Hide some indoor objects #3031

kocio-pl opened this issue Jan 22, 2018 · 10 comments

Comments

@kocio-pl
Copy link
Collaborator

There's a problem with some indoor objects visible on the map. The case of artworks in Louvre is evident here and I would just hide them:

https://www.openstreetmap.org/node/4549412825#map=19/48.86058/2.33905

Are there any other objects which are used indoor and should not be visible? What about toilets, for example - there are here also, but many of them (if not all) are indoor really for weather/privacy reasons, even if not tagged this way:

https://www.openstreetmap.org/way/457696553#map=19/48.86095/2.33843

This issue is also related to hiding underground features - see #1977.

@dieterdreist
Copy link

dieterdreist commented Jan 22, 2018 via email

@polarbearing
Copy link
Contributor

Yes a different tag would be appropriate, like exhibition=artwork or so.
As for the toilets, they are typically in their own or in another building anyway, so they should be rendered. Here it would be interesting if they could be used on their own (with fee or without, e.g. museum foyer); or if they are part of paying admission to the facility. In the latter case the redering could use the halftone as in the parking-P, but there seems no particular tag for this property

@kocio-pl
Copy link
Collaborator Author

I don't see a problem with tagging. Public is true in this case - it's not private, it just requires a fee, it's also definitely tourism-related. Even when you consider Wikipedia, "usually outside and accessible to all" is just a practical hint (usually), not strict definition.

@polarbearing
Copy link
Contributor

Sorry but you are stretching the "public" and "tourism-related" to the contrary of what the wikipedia article describes. It is all about directly accessible pieces, not exhibits in museums.

@kocio-pl
Copy link
Collaborator Author

For me this part supports more general interpretation:

Public art may include any art which is exhibited in a public space including publicly accessible buildings, but often it is not that simple.

This museum is not only national (which is not important on OSM, because we don't follow property type, only the object itself), but also "publicly accessible" - it's not access=private for example.

@dieterdreist
Copy link

dieterdreist commented Jan 22, 2018 via email

@dieterdreist
Copy link

dieterdreist commented Jan 22, 2018 via email

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 22, 2018

I'm trying to look from the OSM point of view, which might be not the same as Wikipedia (though it's always good if we don't diverge too much from a common knowledge without strong reasons). However when I was thinking of a fee as the only visible difference, that would mean probably access=customers, which is different than access=public, hence not a "public art". That would of course mean that tagging should be different. Do you agree with that interpretation?

If we don't find indoor objects currently visible on osm-carto which should be rather hidden, I will close this ticket in a few days.

@dieterdreist
Copy link

dieterdreist commented Jan 22, 2018 via email

@kocio-pl
Copy link
Collaborator Author

All of the people on the Tagging list thinks that you are right, so I will soon update the wiki to reflect it. It was proposed to use exhibit=* key instead in cases like these mentioned here.

Since there were no other examples of indoor data that we would like to hide, I'm just closing this issue.

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

No branches or pull requests

3 participants