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

Do not render building=proposed #4825

Closed
apophenic-treehugger opened this issue Jun 4, 2023 · 6 comments
Closed

Do not render building=proposed #4825

apophenic-treehugger opened this issue Jun 4, 2023 · 6 comments
Labels

Comments

@apophenic-treehugger
Copy link

Related: #4824

Expected behavior

building=proposed is not rendered. (the same as highway=proposed is not rendered).

Actual behavior

building=proposed is rendered the same as regular building=*

Screenshots with links illustrating the problem

See this building:
image
image

@apophenic-treehugger apophenic-treehugger changed the title Do not building=proposed Do not render building=proposed Jun 4, 2023
@HolgerJeromin
Copy link
Contributor

I am unsure if proposed highway should be part of osm database, but with proposed buildings I am pretty sure they should not be put in there.

@apophenic-treehugger
Copy link
Author

I agree that neither highway=proposed nor building=proposed should be in OSM.

However, the reality is that these objects do exist in the OSM database. The example I showed is part of a shopping mall that is definitely going to be constructed but where construction hasn't started yet. A local mapper has gone through the effort to already map it.

I share your opinion that this should not have been done before the start of construction. But I also do not want to destroy that mappers work (a mapper that does a lot of valuable mapping otherwise).

I think in the rendering department we have to deal with what is in the database, not with what we would wish to be in the database.

@imagico
Copy link
Collaborator

imagico commented Jun 4, 2023

building=proposed has 2354 uses and clearly there is no consensus that this is valid tagging.

Among mappers who do not care about the lack of verifiability the most broadly accepted way to map something like this is using lifecycle prefixes: https://wiki.openstreetmap.org/wiki/Lifecycle_prefix. See

https://taginfo.openstreetmap.org/keys/proposed:building

Closing as wontfix because adding code to the style to explicitly hide something that is tagged in a way that has no wide acceptance is not likely going to find support here.

@imagico imagico closed this as not planned Won't fix, can't repro, duplicate, stale Jun 4, 2023
@apophenic-treehugger
Copy link
Author

Thanks for the swift response. I understand.

But if I may ask this question of understanding: Why does carto then have extra code to suppress rendering highway=proposed?

Perhaps you can understand that to an amateur like me this seems inconsistent. So perhaps you can enlighten me?

@imagico
Copy link
Collaborator

imagico commented Jun 4, 2023

Why does carto then have extra code to suppress rendering highway=proposed?

It does not. The string proposed does not occur in our code base.

@imagico
Copy link
Collaborator

imagico commented Jun 5, 2023

I might have been a bit cryptic here in my replies so i will add a bit more detailed explanation of the background.

building=* tags in OSM are a bit special because they are one of the very few cases in tagging where the key carries meaning. That means by broad consensus among mappers anything tagged with building=* is a building independent of the value - with building=no as the only exception. We - and practically every other map style out there - therefore render everything tagged building=* as a building.

This is different for highway=*. Here the key does not carry meaning on its own, a feature with such tag gets its meaning only with a specific meaningful value. That can be one of the road classes (like highway=primary or highway=steps) but also something completely different - like highway=street_lamp or highway=bus_stop. Hence we - and most other map styles - render highway=* features only for specific values we explicitly want to show.

That means we implicitly render building=proposed just like building=yes or building=foo while we do not render highway=proposed - both without there being any explicit code to do that.

Now we could technically add building=proposed as an explicit exception not to render just like building=no. But we don't want to do that because of the reasons already mentioned.

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

No branches or pull requests

3 participants