-
Notifications
You must be signed in to change notification settings - Fork 819
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
amenity=embassy is deprecated, show office=diplomatic or diplomatic=consulate with the flag symbol instead #3886
Comments
Right now there are 10k amenity=embassy, 3.1k office=diplomatic and 3.1k diplomatic=embassy (if other non-embassy diplomatic offices should be rendered here would be a different question). I don't think this is enough to indicate a clear adoption of a different tagging yet but it might well be on the way of getting there so it is certainly a good idea to keep an eye on this. What we could consider i think is removing the rendering of the old tagging before we actually start rendering the new tagging. That would essentially mean adopting a position of neutrality because the old tag has ceased to be the universally accepted method of mapping while the new tagging has not (yet) been universally adopted as a replacement. |
I would start with writing about rendering ideas on tagging list before making any decision. |
The office-proposal was voted positively with a good ratio in Nov 2018, however it said to "deprecate the amenity=embassy tag over a period of time". There is a bit a tug-of-war to put the red label on the amenity page, since. Question is how long is the period of time, half a year is certainly quite short. Why would we render none of them for a while, @imagico? Why not render both of them for a while? Non-embassy diplomatic offices could be rendered as any other office=*, if they aren't already. |
All `office=` values are rendered with a dark blue circular marker and
a text label currently.
|
Because that would give feedback indicating both is equally OK - this kind of tagging proliferation and creation of synonyms we don't want to support. Note this is not a waiting time question, for us the actual adoption of a tag by mappers is the key. In the past when tagging conventions changed (like highway=ford to ford=yes or wood=* to leaf_type=*) we were very conservative in adopting this (due to technical constraints mostly of course). We don't have to and should not wait until a previously used tag has gone completely out of use but we definitely should consider carefully the degree of adoption of a tagging scheme before endorsing it by rendering it. As said i would be in favor of removing rendering of amenity=embassy right now but i think adoption of a new tagging is not broad enough to render it (and there has not even been a suggestion on how exactly anyway - the whole point of the new tagging is to be better differentiated so a one-to-one replacement is not possible). As @jeisenbe pointed out a generic office dot is currently rendered as an office=* catchall so this would already go beyond the level of neutrality here. |
@elumbella - it would be good to open an issue at other map styles which would be affected by this change. The most important would be the HDM style, which is also on the main openstreetmap.org page and currently renders embassies, since it is focused on features which are important to NGOs and humanitarian workers. See https://github.com/hotosm/HDM-CartoCSS/issues I would recommend waiting a few more months to see how things develop. The number of embassies has stopped going up. The trend line is about 20% to 25% below where it would have been expected to have reached by now: The number of Changing the rendering of EDIT: also, not all |
@imagico, You have an interesting idea of "neutrality". Break embassy rendering for everyone? 😆 |
iD is already switching JOSM has a ticket open, so |
The tag |
@bhousel - if you want to change my mind an actual argument could be helpful... |
amenity=embassy is hugely more popular against a ridiculous number of office=diplomatic, and the thing that somebody has nothing better to do and tagged it as "deprecated" in wiki does not mean (according to actual data in the database) that actual mappers agree that it is "deprecated". |
@tomass it's better to discuss the tagging issues on the Tagging mailing list, or make a formal proposal - though you should look through the long discussions about the previous proposal at https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/office%3Ddiplomatic to understand how the new tags developed. Also see https://josm.openstreetmap.de/ticket/17562 which will have more influence and will probably happen sooner than changes we make here. |
There should be a mandatory requirement to have mapped at least 100000 objects or even more before proposing any change of tagging. As currently people who do not have practical experience propose pointless re-tagging and other people who do not have practical experience push such proposals through. |
What about rendering office=diplomatic additionally to amenity=embassy? That would be a compromise for now, wouldn't it? Otherwise we can also wait until all editors have adopted the new tagging scheme (looking at you, JOSM) and make a hard switch (stop rendering the latter and start rendering the former). However your suggestion is to not render any of them at all? Or did I misunderstand? Since office=diplomatic has a few subcatgories (embassy, consulate, liaison) one might also think about a more differentiated rendering for these subcategories. But that's a different story, just a quick thought. @jeisenbe Thanks for the in-depth analysis. It seems that the old amenity=embassy is still in heavy use. The wiki also recommends against automatic re-tagging of those (I imagine that not all amenity=embassy's are actually embassies but also consulates etc). So we will be stuck with plenty of those for a while. Stopping rendering of those seems a bit premature to me. However, adding rendering for the new tagging scheme should be considered IMHO. |
This is a completely different discussion, @tomass. This tagging scheme has been accepted last year. If you're not content with this you can always challenge the proposal. |
I think we should render both tags for now, since things are in the state of flux and removing old tag now would be unexpected and avoidable disservice to the users. Speaking from experience, any sane migration takes time, overlaps and compromises to make things run as smooth as possible and not enrage users. Moreover https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dembassy#How_to_map encourages just adding new tags. We can choose when we would like to stop rendering old tags and announce it to the rest of community, so migration ends at some point and it's not hanging forever, on the other hand. It is crucial to see the whole process of migration, not just separate decisions. |
This is beginning to be a bit of a chicken and egg problem. The map will not update because the tagging/data is not there yet. On the other side there are people warning me to not remove So, to contribute to this conversation I have some data.
The data shows that
Another thing that is apparent from the data is the misuse of the While the data suggest that it is not the time to drop the rendering of edit: had a bounding box on the data. this is now for the whole world |
All |
Thanks @wvanderp for the data. As previously indicated we do not want to render newly created synonyms here so rendering office=diplomatic + diplomatic=embassy as a synonym for amenity=embassy will likely not find approval. As also said: Ideas how to render office=diplomatic in a differentiated fashion would be welcome. Also personally i would be in support of removing rendering of amenity=embassy right now because it is clearly not the universally accepted tagging any more and as @jeisenbe says office=diplomatic is already rendered in a generic fashion providing some feedback. It is also quite clear from the dynamics of tagging numbers that a full adoption of the office=diplomatic scheme is likely. So someone should consider how to render this because the solution to render office=diplomatic with a generic office dot but rendering office=diplomatic + diplomatic=embassy in a completely different way like current amenity=embassy would be confusing. |
Did you consider how proper migration process works, especially that for some time both systems (old and new) should be supported to achieve smooth migration path? |
Don't know what you consider a "proper migration process" to be but we have documented goals, established practice as well as negative counter-examples all advising clearly against introducing the rendering of new synonyms for existing tags. I know you have different preferences as indicated in past discussions (like #2548) but as it has been demonstrated back then that there is no consensus for such changes. So a change introducing a distinct rendering of office=diplomatic + diplomatic=embassy will most likely only find support if it is combined with or preceded by a change removing rendering of amenity=embassy. |
So, do you consider abrupt change being fair for the users? Did you consider encouraging wild automated edits this way? Was there any documentation, consensus or anything on this way of migration? IIRC, on the contrary - there was a lengthy process for migration deprecated tags. Also the documentation says:
This certainly does sound to me like considering passing some time, not pushing people to hurry up. |
I am not having the same discussion as in #2548 and elsewhere all over again - the OSM wiki is not authoritative for our decision making here, we look at how mappers actually use tags. We have an established practice how to do things, we have documented goals and we have a responsibility towards the OSM community supporting them in consistent use of tags and not supporting meaningless proliferation of tagging. I pointed out clearly above that what will eventually likely be needed is a concept how to render the new tagging system in an intuitive form. Sidestepping this by lobbying for ignoring this need and just pretending the new tagging to be a synonym for the old one and that it would be a good idea to render it as such is non-constructive. |
But it clearly states the intended process, which you propose to ignore - not something I would call "responsible for OSM community". And if wiki is not anything special, then why do you rely on deprecation note or whatever wiki says at all? It lacks the consistency.
When was such deprecation done in an abrupt manner, as you propose? |
If you want to discuss established practice and policy please open a separate issue. |
If I understand it right it is the policy to only render synonyms in very rare cases. So, I see two ways forward:
Is my conclusion correct. Are the any other paths forward? Did I miss any traditions? |
According to the wiki, there are three subkeys for office = diplomatic:
IMHO, each of these could have the symbol for what amenity = embassy has right now, which is the flag symbol. I have no clue on how to distinguish them visually as most people will have trouble distinguishing these types of diplomatic offices anyway (I have just learned about liaisons during this discussion). Obviously, there is a difference, but most of these have their specific descriptor in the name (e.g. "Embassy of the United Sates of America", "Consulate of Argentina"). So it might be appropriate to just render office = diplomatic with the flag icon. Hence, I'm no visual artist or designer, so maybe someone else can come up with distinguishable and recognizable visual representations. |
For your information: |
Expected behavior
Diplomatic offices such as embassies, consulates etc (see office=diplomatic for full list) without the amenity=embassy tag should be rendered with the flag symbol
Actual behavior
Only amenity=embassy is rendered, however, this tag is deprecated
Links and screenshots illustrating the problem
https://www.openstreetmap.org/node/6665879459 is rendered, but tagged with the deprecated amenity=embassy
https://www.openstreetmap.org/node/2953707091 is not rendered, but tagged correctly
(edit: corrected first link)
The text was updated successfully, but these errors were encountered: