Proposal talk:Office=diplomatic

From OpenStreetMap Wiki
Jump to navigation Jump to search

Comments

"but are not embassies as defined by international law"

How the difference is visible in a ground survey done by somebody who is not an international law expert? Mateusz Konieczny (talk) 17:05, 21 October 2018 (UTC)

It's pretty easy. Consulates have signs that read, "Consulate of ..." or "Consulate General of ..." Embassies have signs that read, "Embassy of ..." I'll see if I can dig up some photos. Apm-wa (talk) 17:14, 21 October 2018 (UTC)

17 November 2018

On 11/17/2018 7:45 AM, Allan Mustard wrote:

Pursuant to a request from another mapper to wait another week after 10 November before calling for a vote, I postponed the start of voting on the office=diplomatic proposal to today. Voting is now open. Please see https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic for the final version of the proposal, which underwent much modification from the original--please be sure to acquaint yourself with the proposal and to review the discussion page. If you have questions to which you cannot find answers on the discussion page (which contains the vast bulk of e-mail discussion) please feel free to e-mail me directly.
I thank the many contributors of ideas, suggestions, and just plain great intellectual discussion of this proposal as it evolved from a simple "amenity=consulate" fix to a more comprehensive solution of how to deal with all manner of diplomatic missions. It was not only valuable for me to get all the perspectives you offered (and to tap your experience as mappers), it was just plain fun, too!
Best regards to all, and please do not forget to vote!
Allan Mustard
apm-wa

13 November 2018

On 11/13/2018 7:26 PM, Paul Allen wrote:

On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi wrote:
BTW, can you quickly explain, to a newbie like me, who has voting rights and what the voting process will be? Can you point me to any documents about that?
Voting is by editing the voting section of the proposal. Anyone who has registered to be able to
edit the wiki can vote.
The wiki page https://wiki.openstreetmap.org/wiki/Proposal_process#Voting explains how the
author of the proposal can set up a vote and can be used to figure out how to vote. You edit
the wiki.
--
Paul

On 11/13/2018 7:11 PM, Sergio Manzi wrote:

Me too. I let my "namespacing" modification proposal die: this is not the time and the place.
BTW, can you quickly explain, to a newbie like me, who has voting rights and what the voting process will be? Can you point me to any documents about that?
Regards,
Sergio
On 2018-11-13 12:54, Paul Allen wrote:
...
I'd vote for it because it is a thing of craftsmanship and beauty. Well, maybe not for that
reason exactly, but because I cannot conceive of anything better or see any serious flaws
in it.

On 11/13/2018 7:04 PM, Sergio Manzi wrote:

Colin,
I subscribe to every single word of your post... bravo!
Regards,
Sergio
On 2018-11-12 22:37, Colin Smale wrote:
At moments like this I like to invoke one of my heroes: Albert Einstein. One famous saying attributed to him is: As simple as possible, but no simpler.
If you simplify complex realities too much, you lose valuable detail. If it's complex, it's complex. If you want to leave out a level of detail, such as being able to distinguish between the different types of services provided on behalf of multiple "tenant" countries in a diplomatic mission, then so be it, but let's discuss whether it is desirable to leave that out, and whether the resultant ambiguity is acceptable. Data modelling means constructing an approximation to reality, and is all about what details to keep in and what to leave out. Once it is left out, it cannot be reconstructed from the rest of the data. (If it can, your data model is not properly normalised.)
If OSM is being limited to being suboptimal because of politics and the inability to reach consensus, I would rather the system was fixed instead of condemning the whole business to eternal mediocrity.

On 11/13/2018 4:54 PM, Paul Allen wrote:

On Tue, Nov 13, 2018 at 2:37 AM Warin wrote:
That way each vote is on one issue only not the lot bundled together.
And then some people will vote against the initial proposal because it does not adequately address known issues and is therefore incomplete. They would fear that as soon as it is approved people will start using it and resort to ad-hockery to fill in the gaps, resulting in a mish-mash of inconsistent tagging before the next step is approved. Remember that this proposal went forward because people want it and they want it now. They WILL fill any gaps with ad-hoc tagging as soon as it is approved.
I'd prefer a fully-formed proposal which addresses all conceivable future complications. As this one has. I agree that a complex proposal might contain some good stuff and some bad stuff, but this one has been very well-thought out by an expert in the field and then subject to all the nit-picking this list can throw at it.
I'd vote for it because it is a thing of craftsmanship and beauty. Well, maybe not for that reason exactly, but because I cannot conceive of anything better or see any serious flaws in it.
--
Paul

On 11/13/2018 7:34 AM, Warin wrote:

What I am suggesting;
Stage 1 - Vote on office=diplomatic as a replacement for amenity=embassy
Once that is past
Stage 2 - vote on diplomatic=embassy/consulate/?
with embassy=embassy/high_commission/?
consulate=consulate/consulate_general/?
?=?/?
Stage 3 .. if you have further things.
That way each vote is on one issue only not the lot bundled together.

12 November 2018

On 11/12/2018 6:09 AM, Allan Mustard wrote:

Yes, absolutely. For example, the Turkmen ambassador in Brussels is accredited to both Belgium and the European Union. It's not hypothetical at all, but rather very much real life.
On 11/12/2018 1:51 AM, Graeme Fitzpatrick wrote:
On Sun, 11 Nov 2018 at 21:42, Allan Mustard: wrote:
target=* where * is the two-character ISO 3166-1 alpha-2 code for the receiving (accrediting) country or organization or the generally accepted English acronym for an international organization (e.g., UN, OSCE, NATO, WTO). If a mission is accredited to multiple countries or organizations, * will constitute a semicolon-delimited list of tags, e.g., target=US;CA for a mission accredited to both the United States and Canada.
Thanks - once again sums things up beautifully - you must be good at this sort of stuff! :-)
Just for the sake of asking a theoretical question that I know would probably never appear in real life :-)
Would / could you also use the multi-letter codes as you show eg NATO, WTO, SEATO?
& a mixture of them, so the British Ambassador to Belgium, who is also the delegate / representative to NATO (if there is such a thing?), would be
country=GB
target=BE;NATO
Thanks
Graeme

11 November 2018

On 11/11/2018 8:35 PM, Allan Mustard wrote:

Proposed primary (first-level) key in the current version of the proposal is office=diplomatic.
On 11/11/2018 4:56 PM, Sergio Manzi wrote:
Hello Allan,
sorry, I'm a late comer to the discussion, so there might be something I've/am missed/missing, but...
From your description I understand that "embassy=*", "consulate=*" and "liaison=*" will be new first level keys: wouldn't it be better to make them secondary level keys under the "diplomatic" namespace, exactly as you are proposing for "services" (and maybe also add "services"" as a possible value for "diplomatic=*") ?
We should then have:
diplomatic:embassy=* with key values of [yes, high_commission, nunciature, interests_section, mission, delegation, branch_embassy, residence]
diplomatic:consulate=* with key values of {yes, consulate_general, consular_agency, consular_office, honorary_consul]
diplomatic:liaison=* with key values of [liaison_office, representative_office, subnational];
Cheers,
Sergio

On 11/11/2018 4:22 PM, Allan Mustard wrote:

Colin is correct. I have added target=* to the proposal. country=* is already there. If there are multiple target countries (the U.S. Embassy in Colombo, for example, also covers the Maldives in addition to Sri Lanka) would it not be possible to tag as target=LK;MV ?
On 11/11/2018 3:52 PM, Colin Smale wrote:
On 2018-11-11 11:27, Warin wrote:
On 11/11/18 20:05, Colin Smale wrote:
On 2018-11-11 07:49, Graeme Fitzpatrick wrote:
But wouldn't it be covered by the name eg "Australian Embassy to Russia"?
We should not rely on free-text fields like "name" to convey information that belongs in a structured form...
The text clearly identifies the object as;
an Embassy
The 'from' country as Australia
the 'to' country ... as Russia ... though this may also include other countries too ..and would be indicated by an enclosure by that county.
You miss the point... The fact that the words "Australian Embassy" and/or "to Russia" occur in the "name" tag is not enough for an automated processor to unambiguously understand that the sending nation is the Commonwealth of Australia and the receiving nation is the Russian Federation. All these words can be written in any language of the world. Hence the need for the "from," "to" and "function" concepts to be modelled with a curated list of values - there are only so many countries and international organisations (in this sense) in the world, and those lists are pretty static.
Enclosure won't work for missions to international organisations or the Vatican either. There are (IIRC) also arrangements between countries such that the embassy of A in country B also represents country C under certain circumstances. This also doesn't fit nicely with the "from"/"to" model. On wikipedia they are called "De facto embassies":
https://en.wikipedia.org/wiki/De_facto_embassy

On 11/11/2018 9:07 AM, Allan Mustard wrote:

Good catch, Eugene, thanks. Especially useful for missions to multilateral organizations (e.g., EU, NATO, UN, WTO, Shanghai Cooperation Organization, etc.)
On 11/11/2018 7:33 AM, Eugene Alvin Villar wrote:
Just a suggestion. Under the "Additional tags routinely used would include" section, name=* and country=* are listed. I think the target=* tag (for the receiving country) should also be included since it is already documented in the amenity=embassy page. (I am not sure if "target" is a good term for this tag but it is already in use so it might be okay to just adopt it as is.)

10 November 2018

On 11/10/2018 2:20 PM, Warin wrote:

On 10/11/18 17:12, Graeme Fitzpatrick wrote:
As far as I'm concerned, it can go to vote!
I to am fairly happy.
However there is no need to rush.
---------------------
The spectre of office=visa hangs.
If embassies/consulates remained in the 'amenity' key then there would be the opportunity of tagging inside the embassies/consulates with office=visa ..
An office within an office poses problems.
Still thinking.
Another week?

On 11/10/2018 9:10 PM, Allan Mustard wrote:

Sometimes, you can. It depends on the type of liaison office. AIT and TECRO both issue visas. The State of Virginia office in New Delhi, obviously not.
On 11/10/2018 9:02 PM, Martin Koppenhoefer wrote:
You can not usually get a visa from a liaison office, or can you?

On 11/10/2018 9:02 PM, Martin Koppenhoefer wrote:

On 10. Nov 2018, at 06:23, Allan Mustard: wrote:
I plowed through the comments and have rewritten and moved the amenity=consulate proposal to office=diplomatic. You may find the rewritten proposal here:
https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic
There has been a lot of discussion and it certainly is impossible to satisfy everyone. The current iteration of the proposal in my eyes would seem like a step back, if we look only at the main tag.
Currently we can identify embassies with just one standard tag, and although it is not perfect because consulates are mixed in, which have a different diplomatic status, I would say it “works” for most applications (also because the name and further tags often make it clear what kind of diplomatic representation it is). If you are in need of a visa, a consulate might work just as well.
If we start moving these into a new tag office=diplomatic, with the definition “Diplomatic, consular, or non-diplomatic representation of a foreign country or subnational government in a host country as defined by the Vienna Convention on Diplomatic Relations, Vienna Convention on Consular Relations, UN Charter, other multilateral agreement on diplomatic missions, or bilateral agreement.”, in other words it now includes also non-diplomatic representations, i.e. has become a broader category, hence less information, at least with basic tagging. You can not usually get a visa from a liaison office, or can you?
Plus the potential confusion with private companies that offer support or consultancy for diplomatic procedures (e.g. visa applications), as were mentioned in this thread before.
Even if I don’t agree with the main choice, I still see good value in the proposal. You have documented a lot of useful subtags, thank you for this! Provided a lot of these properties are added on an object, it wouldn’t really matter what the main tag is, but in reality many mappers just add one tag and a name, so it may take time until we reach at a decent level of dissemination, and in the meantime we’d sometimes not be able to distinguish facilities which offer diplomatic services to citizens from those that don’t.
The subtags work with any main tag, so this part is much appreciated anyway. ;-)
Cheers, Martin

On 11/10/2018 10:23 AM, Allan Mustard wrote:

Kind folks,
Comments on the proposal tapered off after Eugene's November 4 post, so I plowed through the comments and have rewritten and moved the amenity=consulate proposal to office=diplomatic. You may find the rewritten proposal here:
https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic
Now, unless there is consensus that we need another two weeks of comment, I intend within the next two days to submit this proposal for a vote. If you object to this and believe we need another two weeks of comments since amenity=consulate was moved to office=diplomatic, please say so! I'm happy either way, and thank you all for your interest, ideas, and comments.
Very best regards to all,
apm-wa

4 November 2018

On 11/4/2018 5:09 PM, egil wrote:

On 2018-11-01 20:12, Eugene Alvin Villar wrote:
On Thu, Nov 1, 2018 at 11:14 AM Allan Mustard: wrote:
  • shift to office=diplomatic and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate and other as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.
This is my preferred option for the following reasons:
1. It reuses the existing office=* primary key, which is already in use (for example, by the main OSM tile layer), as opposed to introducing diplomatic=* as a primary key. Furthermore, I am in favor of not having too many top-level primary keys unless they make a lot of sense (like healthcare=* which is a really broad category, so it makes sense to break this off as a primary key).
2. It does not clutter the overused amenity=* key and allows renderers and users to treat diplomatic and quasi-diplomatic objects in the same way and in a simpler way as opposed to tagging amenity=[embassy, consulate, <some yet unspecified value:].
3. The three values for the secondary tag diplomatic=[embassy, consulate, other] plus adding further details to [embassy, consulate, other]=* makes it easy for mappers to add the level of detail they are comfortable with. If a mapper is unsure what the object is, they can just tag it as office=diplomatic. Then other slightly more knowledgeable mappers can specify diplomatic=*, which seems enough for most casual map users. Then other really knowledgeable mappers can further add [embassy, consulate, other]=* for even more detail and more specialized mapping applications.

1 November 2018

On 11/1/2018 9:57 PM, Allan Mustard wrote:

How about amenity=embassy, amenity=consulate, plus amenity=representation to capture those facilities that are neither pudding nor frozen, er, sorry, neither embassies nor consulates? Any heartburn there? Then we use diplomatic=* as an additional tag (i.e., continue current practice) to specify different flavors, er, types of diplomatic/consular mission? Should I modify the proposed feature to that?
apm-wa

On 11/1/2018 4:24 PM, Daniel Koć wrote:

W dniu 01.11.2018 o 09:12, Warin pisze:
A problem will be the lack of rendering for some time.
Speaking of rendering - it might be useful to know that there is a map
service called OpenDiplomaticMap, which is also a quality assurance tool:
https://anders.hamburg/osm/diplomatic

On 11/1/2018 2:00 PM, Johnparis wrote:

OK, I take back what I said. And if Allan, Markus and Martin all think that's the way to go, I'm fine with that.
On Thu, Nov 1, 2018 at 9:46 AM SelfishSeahorse: wrote:
On Thu, 1 Nov 2018 at 09:41, Martin Koppenhoefer: wrote:
I haven't seen anyone (recently) who supports your original proposal of keeping amenity=embassy and adding amenity=consulate. So I believe your first summary is inaccurate.
I do. For me this is most consistent with the rest of the system, requires the least modifications and I don’t see why it shouldn’t work.
+1
Regards
Markus

On 11/1/2018 1:12 PM, Warin wrote:

On 01/11/18 17:20, Johnparis wrote:
I haven't seen anyone (recently) who supports your original proposal of keeping amenity=embassy and adding amenity=consulate. So I believe your first summary is inaccurate.
Instead what I have seen is suggesting that amenity=diplomatic is possibly a better fit than office=diplomatic.
So I would suggest dropping the first alternative entirely and modifying the second to read:
* shift to amenity=diplomatic
+1
or office=diplomatic (which one to use has yet to be decided) and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate, and other (or some other euphemism as yet undetermined) as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.
The problem I have with office=* is that it is not meant to outline the premisses (parking, entry road - right out to the external fence). Some have been mapped to there extents, others are single nodes.
The advantage is that it is a simple 1:1 change that removes eh problem value of 'embassy' and replaces it with 'diplomatic'.
A problem will be the lack of rendering for some time.


On 11/1/2018 11:20 AM, Johnparis wrote:

I haven't seen anyone (recently) who supports your original proposal of keeping amenity=embassy and adding amenity=consulate. So I believe your first summary is inaccurate.
Instead what I have seen is suggesting that amenity=diplomatic is possibly a better fit than office=diplomatic.
So I would suggest dropping the first alternative entirely and modifying the second to read:
* shift to amenity=diplomatic or office=diplomatic (which one to use has yet to be decided) and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate, and other (or some other euphemism as yet undetermined) as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.
Cheers,
John

On 11/1/2018 8:12 AM, Allan Mustard wrote:

Dear Colleagues,
Eleven days into the RFC, we have three competing lines of thought regarding even a primary tag for diplomatic missions, and similarly little consensus on additional (secondary and tertiary) tags that would preserve and expand information. The three lines of thought are:
* retain amenity=* as the primary tag but tag consulates separately from embassies (this is the original proposal, which after being criticized resurfaced a few days ago).
* shift to office=diplomatic and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate and other as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.
* "promote" diplomatic=* to primary tag status, with embassy, consulate, and other (or some other euphemism as yet undetermined) as the key values as well as additional (secondary) tags that are used to specify further the type of diplomatic or non-diplomatic mission as needed.
Nearly all the discussion is posted to the talk page of Proposed Features/Consulate in the wiki, https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Consulate for those interested in reviewing it.
Now, as we approach the two-week mark, it would be helpful to get a sense of whether there is any consensus out there about which of the three main lines of thought is preferred over the others. The preferences of the community responding to this RFC are not clear to me. Please let me know which direction you believe would be best, bearing in mind both the realities of the OSM universe (relative sophistication of mappers, the desire not to burden unduly renderers of maps, and the degree to which anybody reads the wiki articles) and our shared desire to make OSM as accurate and information-rich as possible. Which of the above approaches do you think is "best" by those criteria?
Very best regards to one and all who have contributed to this discussion, and many thanks for your ideas and expressions of concern.
apm-wa

31 October 2018

From: Allan Mustard October 31, 2018 at 12:58:22 PM GMT+5

Sounds like you just volunteered to do a session on tagging at the next SOTM and to help me write the wiki articles supporting whatever we end up voting on :-)
I hear you on tagging but don’t agree that a current inadequacy of tagging is a reason to torpedo improvement to accuracy and clarity.
The vast majority of users will not care if it is a consulate or consulate general. They will want the location so they know where to go to apply for a visa or a passport. Let’s not be hypnotized by the complexity—simple top-level choices for simple mappers that can be expanded with additional tags by more experienced mappers. It will make rendering easier and the database more accurate. That is my objective here.
Sent from my iPhone
On Oct 31, 2018, at 9:45 AM, Warin wrote:
On 31/10/18 12:33, Allan Mustard wrote:
Some responses to Warin:
On 10/31/2018 3:45 AM, Warin wrote:
Errr.
By combining Embassy with High Commission there is a decrease in information.
No information is lost. "High Commission" is an embassy by another name, between Commonwealth members. The term "high commission" would be preserved both in the embassy=* tag and the name=* tag.
Mappers don't do sub tags well
Example;
Over 11,000 amenity=embassy
Some 4,000 diplomatic=*
Less than half the 'embassies' have the tag diplomatic, yet over 95% have a name tag.
So they will use the name tag (that renders) together with the
amenity=embassy tag (that renders) but they are reluctant to use the diplomatic tag (that does not render).
I think the same will occur to these embassy=* tags.
Another decrease in information is consulate and consult general ... there may be more if I dig.
The VCDR does not mention embassy. It has 'mission' and 'consular' but no 'embassy', nor 'high commission' etc.
As I pointed out in an earlier post, "embassy" technically and legally consists of the people dispatched to a foreign country on a diplomatic mission. By convention and in vernacular use, "embassy" is used to denote the physical structure of the diplomatic mission in which said people operate. The VCDR is a legal document (a treaty). It uses legal language. I have provided a great deal of detail (much of which would be captured in the wiki, ultimately) describing the various flavors of diplomatic missions, which broadly speaking fall into three categories: embassies, consulates, and other. If you doubt my word, as you seem to, please consult with your local ministry of foreign affairs. If you are willing to take the word of Wikipedia, its article on diplomatic missions is pretty good: https://en.wikipedia.org/wiki/Diplomatic_mission#Naming
Then the real fun begins. As I have read through the various comments and suggestions, it has occurred to me that the following hierarchy of tags would potentially fill the bill:
The three values/categories (embassy, consulate, other) would have specific subcategories. If you wanted to do a key search in overpass turbo, it would still be possible. The subcategories would be
* embassy=[embassy/yes, nunciature, high_commission, interests_section, mission, delegation, branch_embassy]
* consulate=[consulate/yes, consulate_general, consular_agency, consular_office, honorary_con
The above 'consolidations' ... loose information.
How do they lose information? All information is preserved in the additional tags.
Those additional tags probably won't be used, see above.
If required that consolidation can be done in rendering.
But, I think, most renders now ignore them and simply render all of them the same. And, I think, that will continue for quite some time.
If a render chose to distinguish between them then they can do so, they cannot distinguish between an embassy and a high commission if that information is not there.
I cannot conceive of a circumstance under which anyone would want to render embassies and high commissions differently. They are different names for the same level of diplomatic mission (a mission covered by the VCDR and headed by an ambassador). If a renderer wanted to distinguish them, it could be done with an IF statement testing the existence of the string "high_commission" in either the name=* tag or the embassy=* tag. Same goes for an overpass turbo search.
If there no difference then they would be the same name.
Could be construed as the same kind of thing as the tag 'minor_mission'.  :)
Embassies and consulate are now rendered the same, that will probably continue, even if they have different tags.

On 10/31/2018 6:33 AM, Allan Mustard wrote:

Some responses to Warin:
On 10/31/2018 3:45 AM, Warin wrote:
Errr.
By combining Embassy with High Commission there is a decrease in information.
No information is lost. "High Commission" is an embassy by another name, between Commonwealth members. The term "high commission" would be preserved both in the embassy=* tag and the name=* tag.
The VCDR does not mention embassy. It has 'mission' and 'consular' but no 'embassy', nor 'high commission' etc.
As I pointed out in an earlier post, "embassy" technically and legally consists of the people dispatched to a foreign country on a diplomatic mission. By convention and in vernacular use, "embassy" is used to denote the physical structure of the diplomatic mission in which said people operate. The VCDR is a legal document (a treaty). It uses legal language. I have provided a great deal of detail (much of which would be captured in the wiki, ultimately) describing the various flavors of diplomatic missions, which broadly speaking fall into three categories: embassies, consulates, and other. If you doubt my word, as you seem to, please consult with your local ministry of foreign affairs. If you are willing to take the word of Wikipedia, its article on diplomatic missions is pretty good: https://en.wikipedia.org/wiki/Diplomatic_mission#Naming
Then the real fun begins. As I have read through the various comments and suggestions, it has occurred to me that the following hierarchy of tags would potentially fill the bill:
The three values/categories (embassy, consulate, other) would have specific subcategories. If you wanted to do a key search in overpass turbo, it would still be possible. The subcategories would be
* embassy=[embassy/yes, nunciature, high_commission, interests_section, mission, delegation, branch_embassy]
* consulate=[consulate/yes, consulate_general, consular_agency, consular_office, honorary_con
The above 'consolidations' ... loose information.
How do they lose information? All information is preserved in the additional tags.
If required that consolidation can be done in rendering.
But, I think, most renders now ignore them and simply render all of them the same. And, I think, that will continue for quite some time.
If a render chose to distinguish between them then they can do so, they cannot distinguish between an embassy and a high commission if that information is not there.
I cannot conceive of a circumstance under which anyone would want to render embassies and high commissions differently. They are different names for the same level of diplomatic mission (a mission covered by the VCDR and headed by an ambassador). If a renderer wanted to distinguish them, it could be done with an IF statement testing the existence of the string "high_commission" in either the name=* tag or the embassy=* tag. Same goes for an overpass turbo search.

On 10/31/2018 6:40 AM, Allan Mustard wrote:

On 10/31/2018 3:11 AM, Joseph Eisenberg wrote:
If the consensus is that "other" sucks as an option I'm certainly open to other suggestions, but we need something for diplomatic missions headed by neither an ambassador/charge d'affaires (i.e., subject to the VCDR) nor a consul (i.e., subject to the VCCR).
diplomatic=minor_mission? If there's neither a consul nor an ambassador, it must be somehow minor ;-)
Nobody wants to be called "minor" in diplomacy. Wars have been fought over lesser insults. If that's the only other suggestion, then my proposal will remain "other" :-o The head of the OSCE mission here in Ashgabat is a former ambassador and will certainly take umbrage with me if her mission is somehow described as "minor".
if these are all exclusive, it could also be:
amenity=[embassy, consulate, minor_mission]
I think we are past the point of calling diplomatic missions "amenity". We're now down to either "office=diplomatic" or "diplomatic=*" There has been broad consensus expressed that diplomatic missions are not amenities.

On 10/30/2018 11:47 PM, Martin Koppenhoefer wrote:

Am Di., 30. Okt. 2018 um 18:48 Uhr schrieb Allan Mustard <allan@mustard.net::
Not really dropping. More like reorganizing. As someone who has spent hours puzzling over Maperitive's rendering rules, deciding how to build them so that particular categories of POIs will be rendered in specific ways, I am quite sensitive to the need for consistency and a finite number of possible permutations while also accommodating the need to cover every eventuality. Hierarchies are designed for exactly that purpose. After much back and forth at this point I am proposing a hierarchy that I believe meets all needs without being overly complex, and which will accommodate the novice mapper (diplomatic=embassy, period) and the advanced mapper (diplomatic=embassy, embassy=interests_section, etc.).
diplomatic=* would become a top-level, primary tag. It would have three categories: embassy, consulate, other.
to make this work, projects like osm carto would either have to add a column for this key to their dbs or mappers would have to add something like amenity=diplomatic on top of all tags (and likely it will lead to the second way of doing it). It would make sense, if amenity=diplomatic was sufficient information for a significant number of people, it doesn't make sense if amenity=diplomatic does not convey the required information.
If the consensus is that "other" sucks as an option I'm certainly open to other suggestions, but we need something for diplomatic missions headed by neither an ambassador/charge d'affaires (i.e., subject to the VCDR) nor a consul (i.e., subject to the VCCR).
diplomatic=minor_mission? If there's neither a consul nor an ambassador, it must be somehow minor ;-)
Then the real fun begins. As I have read through the various comments and suggestions, it has occurred to me that the following hierarchy of tags would potentially fill the bill:
The three values/categories (embassy, consulate, other) would have specific subcategories. If you wanted to do a key search in overpass turbo, it would still be possible. The subcategories would be
  • embassy=[embassy/yes, nunciature, high_commission, interests_section, mission, delegation, branch_embassy]
  • consulate=[consulate/yes, consulate_general, consular_agency, consular_office, honorary_consul]
  • other=[liaison_office, representative_office, subnational]
if these are all exclusive, it could also be:
amenity=[embassy, consulate, minor_mission]
diplomatic=[(embassy/yes), nunciature, high_commission, interests_section, mission, delegation, branch_embassy, (consulate/yes), consulate_general, consular_agency, consular_office, honorary_consul, liaison_office, representative_office, subnational]
we would save on keys and the main level (most mappers interested) would be in the amenity space and have just 3 different, simple tags with reasonable level of detail.
or amenity=[embassy, consulate, minor_mission]
embassy=[embassy/yes, nunciature, high_commission, interests_section, mission, delegation, branch_embassy]
consulate=[consulate/yes, consulate_general, consular_agency, consular_office, honorary_consul]
minor_mission =[liaison_office, representative_office, subnational]
diplomatic=[trade_office, assistance_office, cultural_center, user_defined]
(integrating your diplomatic:type)
Cheers,
Martin

30 October 2018

On 10/30/2018 10:46 PM, Allan Mustard wrote:

Not really dropping. More like reorganizing. As someone who has spent hours puzzling over Maperitive's rendering rules, deciding how to build them so that particular categories of POIs will be rendered in specific ways, I am quite sensitive to the need for consistency and a finite number of possible permutations while also accommodating the need to cover every eventuality. Hierarchies are designed for exactly that purpose. After much back and forth at this point I am proposing a hierarchy that I believe meets all needs without being overly complex, and which will accommodate the novice mapper (diplomatic=embassy, period) and the advanced mapper (diplomatic=embassy, embassy=interests_section, etc.). And by the way, it is radically different from my original proposal.

diplomatic=* would become a top-level, primary tag. It would have three categories: embassy, consulate, other. If the consensus is that "other" sucks as an option I'm certainly open to other suggestions, but we need something for diplomatic missions headed by neither an ambassador/charge d'affaires (i.e., subject to the VCDR) nor a consul (i.e., subject to the VCCR).

Then the real fun begins. As I have read through the various comments and suggestions, it has occurred to me that the following hierarchy of tags would potentially fill the bill:

The three values/categories (embassy, consulate, other) would have specific subcategories. If you wanted to do a key search in overpass turbo, it would still be possible. The subcategories would be

* embassy=[embassy/yes, nunciature, high_commission, interests_section, mission, delegation, branch_embassy]

* consulate=[consulate/yes, consulate_general, consular_agency, consular_office, honorary_consul]

* other=[liaison_office, representative_office, subnational]

(if I have missed any, please don't condemn me, just diplomatically mention it, as it's late at night here). These subcategories would allow overpass turbo searches as well as proper rendering by applications. They would also constitute a finite universe that covers all contingencies (possibilities are indeed finite), making rendering and searching much easier.

Now the super fun: as I plowed through the comments, I realized we need some functional categories, too, what in OSM are sometimes called subtypes. I am inspired by the way we specify types of motor fuel available at a gas station:

* diplomatic:type=[trade_office, assistance_office, cultural_center, user_defined] If these are located away from the main chancery (which happens a lot), they need to be mapped separately; if however such offices are inside the main chancery (which also happens a lot) they would not be mapped separately.

We have also discussed having a tag like this, or something similar:

* diplomatic:services:[non-immigrant visas, immigrant visas, citizen services]=[yes/no]

As to some of Johnparis' specific questions/objections:

I find this sentence in one of your emails to be particularly problematic on this subject:

A trade mission (aka "trade commissioner", "commercial office", "trade representative") can be part of any of the three categories; it is not accredited separately.

If someone needs to be an expert on international law to determine the tag, there's a problem with the tagging scheme.

You don't need to be an expert. You just need to be able to read. If a trade office is attached to an embassy, it is tagged as diplomatic=embassy. If it is attached to a consulate, it is tagged as diplomatic=consulate. If it is part of a liaison office or similar "other" category, it is tagged diplomatic=other. You don't have to be a lawyer or international relations expert; you just have to read the sign on the door or peruse the establishment's website to figure it out.

delegation -- not mentioned
UN -- not mentioned -- probably should be same as permanent_mission
trade_delegation -- not mentioned
visa -- not mentioned (I believe these are for private companies that handle visas on behalf of consulates -- where to categorize?)

delegation is typically considered a type of embassy (U.S. Delegation to the United Nations, for example). It is headed by an ambassador. Refer back to the rule of thumb that if it has an ambassador, it is an embassy.

UN is not a separate type of diplomatic establishment. It is an international organization. UN headquarters should be tagged office=* but its diplomatic missions abroad should be tagged as diplomatic=other. They are not headed by ambassadors (please see my previous comments on this subject). Same holds for OSCE, OECD, and so on.

trade_delegation is another name for trade_office=trade_representative=commercial_office, and we should seek some modicum of standardization to avoid overproliferation of tags. If I were an American chauvinist, I would insist on commercial_office, since that is what the U.S. Department of Commerce calls its offices in embassies and consulates abroad, but I'm not, and so will not. If I were an agricultural chauvinist, I would insist on a special category for agricultural trade office, but will not.

visa is something stamped in your passport and is not a type of diplomatic mission. This is a shining example of why we need to bring some order to the chaos that is tagging of diplomatic missions. Private companies do not issue visas; they process visa applications but the visas are issued by consular officers in the consulate. If a private company is performing that function, the tag should IMHO be office=company, and the description used to advise that it handles visa applications. It is not a diplomatic establishment; it is a contractor. At least in the case of U.S. consulates, the consulate website will tell you that such-and-such private company processes visa applications and to go there to fill out your forms and get your fingerprints taken. It is not correct to tag such a private firm as a consulate.

I would advocate for office=diplomatic as the main tag rather than trying to create a new main tag.

I advocated for that early on and was shouted down (please see https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Consulate). Who else out there wants to revisit the question of office=diplomatic versus moving diplomatic=* to a top-level tag? Please speak up!

Best regards to all, and back to my non-papers. Keep those cards and letters coming in!

apm-wa

On 10/30/2018 2:57 PM, Johnparis wrote:

The problem I see is that, as I understand it, Allan is proposing to drop some existing diplomatic=* values, such as diplomatic=permanent_mission. And the proposed substitute is to rely on the name=* tag.
Martin pointed out a problem where something not an embassy has a name like an embassy. But also the proposal to "just search on the name" will fail if, for example, the tagging is something like this:
office=diplomatic
diplomatic=other
name=مهمة تجارية من ليبيا
If you're looking for trade missions, I doubt very much that you'll find that one. On the other hand, you will find it if the tag diplomatic=mission is used (I'm not proposing that as a value, but see below).
On a similar note, I don't think the subtags proposed under "other" will ever gain widespread use. "Other" means "end of the road" to most people. Basically, anything you're thinking of under "other" that warrants its own category should be elevated one level, and "diplomatic=other" should be dropped. The trick is deciding on what categories are significant enough to merit a separate tagging value. Currently you're at "embassy, consulate," but I'd challenge you to go further.
I find this sentence in one of your emails to be particularly problematic on this subject:
A trade mission (aka "trade commissioner", "commercial office", "trade representative") can be part of any of the three categories; it is not accredited separately.
If someone needs to be an expert on international law to determine the tag, there's a problem with the tagging scheme.
Looking at taginfo (thanks for the correct link, Martin), I see that there are very, very few subtags currently in use for diplomatic=*
embassy
consulate
consulate_general -- folded into consulate under current proposal -- this makes sense to me
honorary_consulate -- folded into consulate -- is that right? My experience with honorary consuls is that they are more like private citizens promoting trade
high_commission -- folded into embassy -- sensible
permanent_mission -- not mentioned -- should be folded into embassy?
delegation -- not mentioned
UN -- not mentioned -- probably should be same as permanent_mission
trade_delegation -- not mentioned
visa -- not mentioned (I believe these are for private companies that handle visas on behalf of consulates -- where to categorize?)
non_diplomatic -- becomes "other" -- I think this should be dropped entirely
You also had a partial list of proposed tags for "other" ...
liaison_office
representative_office
subnational
trade_office
cultural_center
assistance_office
These are all candidates for values of diplomatic=* (I doubt most need their own category, and thus should be dropped). In particular the "subnational" tag is already implied by the existence of a hyphen in the "sending_country" (US-VA for Virginia, for instance).
Finally, on the question of whether to make the main tag "office" or "diplomatic" -- this reminds me of the discussion several years back for the Internet's top-level domains (.com, .edu, .uk, etc...), which are now free-for-all. As Martin pointed out, certain existing programs (like the openstreetmap.org map) assume a small subset of top-level tags, and adding to that small subset is not easy. So I would advocate for office=diplomatic as the main tag rather than trying to create a new main tag.
John

29 October 2018

On 10/29/2018 3:23 PM, Martin Koppenhoefer wrote:

On 29. Oct 2018, at 11:18, Martin Koppenhoefer <dieterdreist@gmail.com: wrote:
At the moment mappers can simply tag by using the name
here’s an example for a misleading name tag:
https://www.openstreetmap.org/node/332554285
Cheers, Martin

On 10/29/2018 3:18 PM, Martin Koppenhoefer wrote:

a good system keeps things simple for basic information and makes it possible to add more detail if desired. While the name tag can give indications about these details, I believe we should also strive to formalize tags for these subclasses and properties, because it allows for semantic processing (e.g. searching for objects with specific properties).
Cheers, Martin

On 10/29/2018 3:10 PM, Warin wrote:

At the moment mappers can simply tag by using the name
embassy
high commission
nunciature
consulate
consulate_general
etc.
OSm normally sides with the mappers rather than the renders, keep the mappers job easy and they will continue to add things. Make it hard and they will give up.
So I would continue with the present system where the mappers can use the name to determine the status. If the renders want they can chose;
do all diplomatic things the same (as in now the case) or distinguish between things .. possibly combining things as you have. This could be sated on the wiki under rendering.

Allan Mustard 8:43 AM to Graeme

Graeme, Why only U.S. diplomats? I think OSM should encourage diplomats from ALL countries (even Australia :-) to contribute. If that were to happen, coverage of restaurants and bars would be nearly 100% :-)

On Mon, Oct 29, 2018 at 7:49 AM Graeme Fitzpatrick wrote:
On Mon, 29 Oct 2018 at 11:45, Allan Mustard wrote:
Would the lay person know all this? Not until reading the wiki articles we will need to compose if a primary diplomatic=* tag is adopted. Sometimes it is not completely obvious and you have to do a little research.
Thanks again Allan - explained beautifully!
Parsing all of this constitutes a good excuse to recruit diplomats to OSM to help with mapping :-)
& which would then allow "ambassadors" to prowl all round their host country, making notes on fine details with no questions being asked, because they're only mapping for OSM, NOT the US Govt :-)
Thanks
Graeme

Allan Mustard 6:45 AM (1 hour ago) to Graeme, OSM

Here are some rules of thumb:

  • If it displays a sign reading "embassy", "high commission", "nunciature", or "interests section", it is a safe bet that it should be tagged "embassy".
  • If the sending side has made loud public pronouncements and published widely that its embassies are now called "people's bureaus" or some other formulation, it can be safely tagged "embassy".
  • If it has a sign on it that says "consulate", it is a consulate, and the sign will specify what flavor of consulate.

After that it is safest to ask somebody at the institution in question whether it is part of the embassy or consulate (like my American Center) or not (like TIFA), though status can sometimes be divined by reading the institution's website. If all else fails, check the host country's diplomatic list and see if the chief of mission is on it. If s/he is not listed, the institution is not diplomatic (diplomatic=other). If s/he is listed but has a non-diplomatic title (e.g., "director" or "coordinator" as opposed to "ambassador", "charge d'affaires", "minister", "counselor", "first/second/third secretary", or "attache") the mission is pretty clearly not under the VCDR (diplomatic=other). Here we walk a fine line. TIFA is an agency of the Turkish government, hence diplomatic=other. American Councils, which operates our American Corners in Turkmenistan, is an NGO operating under contract with the U.S. government, so our American Corners are not diplomatic, but rather NGO offices (office=ngo). Parsing all of this constitutes a good excuse to recruit diplomats to OSM to help with mapping :-)

Two more examples and I'll stop--I can hear the eyes rolling all the way from Ashgabat:

  • The Apostolic Nunciature in Ashgabat is headed most of the time by a charge d'affaires because the nuncio is resident in Ankara and only visits periodically. The charge d'affaires is nominally the "cultural attache". Since it is a nunciature, we know it is under the VCDR.
  • The European Bank for Reconstruction and Development, the Asian Development Bank, and the United Nations missions in Ashgabat (there are two) enjoy diplomatic status under the Bretton Woods arrangement (the banks) and the UN Charter. Technically that makes the EBRD and ADB diplomatic missions, but we tag them as banks, not as embassies (under the new construct we might however tag them diplomatic=other in addition to tagging them as banks). The lead UN Mission, in a new construct with diplomatic=* as a primary tag, would be tagged diplomatic=other since its head is called "resident coordinator" and the UN Mission is covered by the UN Charter, not the VCDR.

Would the lay person know all this? Not until reading the wiki articles we will need to compose if a primary diplomatic=* tag is adopted. Sometimes it is not completely obvious and you have to do a little research.

On 10/29/2018 3:08 AM, Graeme Fitzpatrick wrote:
On Mon, 29 Oct 2018 at 02:32, Allan Mustard wrote:
  • The USAID office is part of the American Embassy but is in a separate office flat in a building across town, so would be a node tagged diplomatic=embassy, embassy=assistance office.
  • The Turkish counterpart, TIFA, does not enjoy diplomatic status so would be tagged diplomatic=other, other=assistance office.
  • The Libyan Economic Cooperation Bureau would be diplomatic=other, other=trade office because it is accorded diplomatic status by bilateral agreement, not the VCDR (there is no Libyan Embassy here).
  • The American Center would be a node in an office building tagged diplomatic=embassy, embassy=cultural center, while the Iranian Cultural Center would be a building with the same tags, since both enjoy diplomatic status as sections of their respective embassies.
  • The Russian Consulate General has its own building and grounds separate from the embassy, so would be an enclosed way tagged as diplomatic=consulate, consulate=consulate general.
Thank you for a very detailed, very interesting post, Allan.
One question, please.
Is there any way that a layman such as myself would know that "The Libyan Economic Cooperation Bureau would be diplomatic=other, other=trade office because it is accorded diplomatic status by bilateral agreement, not the VCDR", or is this sort of thing only known to Govt / diplomatic staff?
Thanks
Graeme

28 October 2018

On 10/28/2018 9:31 PM, Allan Mustard wrote:

Please let me clarify. The three categories [embassy, consulate, other] are based on their status as diplomatic missions as defined by international law, which is how governments look at them, label them, and relate to them. Within those categories functional differences can and often do exist, which I believe is the question you raised below.
Let's posit a hypothetical analogy using dessert shops:
primary key is shop=*
shop=[dessert, ...]
dessert=[pastry, frozen, pudding]
pastry=[cake, cookie, tart, pie, biscuit]
cake=[chocolate, Black Forest, ...]
...
frozen=[ice cream, frozen custard, frozen yogurt, sherbet]
ice cream=[chocolate, vanilla, strawberry, neapolitan, cookie dough, mango, raspberry swirl, ...]
...
pudding=[gelatin, custard, mousse]
gelatin=[strawberry, lemon, orange, ...]
custard=[chocolate, tapioca, lemon, ...]
mousse=[chocolate, raspberry, mango, ...]
(Sorry, Hallowe'en is coming so I'm distracted by thoughts of sweets.)


At this point we begin to proliferate pretty seriously: is chocolate ice cream so different from vanilla that it deserves its own value, so we can tag the shop accurately? Do we even need to specify the types of frozen desserts in a tag? These are all good questions, especially if you have a sweet tooth as I do, but if a user wants to run an overpass turbo job to find all shops serving strawberry frozen custard, that user will not likely find that level of detail in OSM. We need to decide what level of detail we can reasonably expect to be maintained by a volunteer community while also providing an adequate level of information to our users.


Now let's shift back to the proposal of diplomatic=[embassy, consulate, other], and start by addressing your specific examples: "trade mission," "liaison office," "interests section". A trade mission (aka "trade commissioner", "commercial office", "trade representative") can be part of any of the three categories; it is not accredited separately. Assuming we intend to adopt the diplomatic=* tag as a primary tag, a trade mission could be tagged diplomatic=embassy, consulate, or other, depending on its diplomatic status. An interests section is probably best tagged as diplomatic=embassy since it enjoys diplomatic privileges under the VCDR. A liaison office, on the other hand, may or may not enjoy diplomatic privileges but if it does, it is only on the basis of a bilateral agreement, not under the VCDR, so on reflection it should probably be tagged diplomatic=other (see the Wikipedia article https://en.wikipedia.org/wiki/De_facto_embassy).


To me there are three and only three secondary tags: pastry, frozen, pudding, er, sorry, embassy, consulate, other. The rules for tagging at this level would be determined by what treaty applies: the VCDR or other multilateral international treaty such as the UN Charter (diplomatic=embassy), VCCR (diplomatic=consulate), or only a special bilateral agreement that may or may not confer immunities (diplomatic=other).


Now, are there sui generis names of diplomatic facilities? Yes. For example, Libya used to call its embassies "people's bureaus". When the Soviet Union was formed, it stopped calling its chief diplomats ambassadors, and for ideological reasons (traditional diplomatic titles were considered bourgeois) said its diplomatic missions were staffed by "polpreds" (plenipotentiary representatives) and its missions were now called "polpredstvo". After a few years of being always at the bottom of every diplomatic list, the Soviets resumed normal diplomatic nomenclature. How much do we care about ideological labeling of an embassy that enjoys protection under the VCDR? They were embassies, pure and simple.


So, let's pretend we're taking the example of the dessert shop and applying it to the proposed diplomatic=* primary tag. Here is a possible permutation:


primary key is diplomatic=*
diplomatic=[embassy, consulate, other]
embassy=[chancery, branch office, nunciature, interests section, residence, trade office, high commission, mission, legation, cultural center, assistance office, ...]
consulate=[consulate, consulate general, consular agency, consular office, honorary consul]
other=[liaison office, representative office, subnational, trade office, cultural center, assistance office, ...]


N.B. that the tertiary tags now begin to overlap the name=* tag, and it is my understanding that duplication of information is generally frowned upon in OSM--please correct me if that impression is incorrect. That said, if our hypothetical user wants to pull out all cultural centers or U.S. state rep offices in a country by tag value, it would be possible. Note also that we are also mixing apples and oranges here, as "nunciature" is simply a different name for an embassy, as is "high commission", whereas cultural centers and trade offices located separately from the chancery are functionally distinct branches of an embassy, easily distinguished by their prominent signage ("please visit us and absorb culture/buy our goods").


Here are some illustrations based on Ashgabat, a capital city with about three dozen diplomatic missions.


* The USAID office is part of the American Embassy but is in a separate office flat in a building across town, so would be a node tagged diplomatic=embassy, embassy=assistance office.
* The Turkish counterpart, TIFA, does not enjoy diplomatic status so would be tagged diplomatic=other, other=assistance office.
* The Libyan Economic Cooperation Bureau would be diplomatic=other, other=trade office because it is accorded diplomatic status by bilateral agreement, not the VCDR (there is no Libyan Embassy here).
* The American Center would be a node in an office building tagged diplomatic=embassy, embassy=cultural center, while the Iranian Cultural Center would be a building with the same tags, since both enjoy diplomatic status as sections of their respective embassies.
* The Russian Consulate General has its own building and grounds separate from the embassy, so would be an enclosed way tagged as diplomatic=consulate, consulate=consulate general.


An example from New Delhi, where I was stationed for three years:


* The State of Virginia (U.S.) Office would be tagged diplomatic=other, other=subnational.


Sorry for the long-winded reply but I thought your question deserved a comprehensive response.


apm-wa
On 10/28/2018 3:52 PM, Paul Allen wrote:
On Sun, Oct 28, 2018 at 5:48 AM Allan Mustard: wrote:
[...]
d) diplomatic=* would include only [embassy, consulate, other], with "other" covering anomalies without status under the VCDR or VCCR (e.g., AIT, TECRO, and subnational representations);
e) further refining of the type of facility would be apparent in the name=* tag, obviating the need for additional subtags; and
[,,,]
It depends. Are all of the facilities that would be tagged as "other" sui generis or do some of them
fall into specific categories? If there are specific categories that some of them fall under, then
giving them their own values instead of other would be sensible.
Tag values are cheap and promote consistency. Consider somebody wanting to use overpass-turbo
to find a particular type of diplomatic facility. A search for diplomatic="fubar" is a nice, easy query. A
search for diplomatic="other" and name~"fubar" works if you're sure the name is going to contain
"fubar" somewhere within it. If you don't know in advance what the name is then with only
diplomatic=other you're not going to be able to narrow it down to a specific category of other (if
specific categories of other exist).
OTOH, if "trade missions," "liaison offices," "interests sections," and the like are merely marketing
terms for "I can't believe it's not an embassy" then "other" suffices.
--
Paul

On 10/28/2018 10:47 AM, Allan Mustard wrote:

First of all, big thanks to all discussants who have pitched ideas and asked probing questions--I think we are moving toward a more elegant solution than what I originally proposed.
As of 28 October 2018, one week into the RFC, here is where I think we are (stay tuned for further developments, film at 11):
a) consulates are not embassies;
b) neither embassies nor consulates are amenities;
c) embassies and consulates are government offices, but there is a trend toward thinking office=diplomatic is suboptimal and diplomatic=* needs to be elevated to primary tag status;
d) diplomatic=* would include only [embassy, consulate, other], with "other" covering anomalies without status under the VCDR or VCCR (e.g., AIT, TECRO, and subnational representations);
e) further refining of the type of facility would be apparent in the name=* tag, obviating the need for additional subtags; and
f) diplomatic:services:[non-immigrant visas, immigrant visas, citizen services]=[yes/no] tags would be desirable.
I have two questions:
1) Should I withdraw the current amenity=consulate proposal and submit a new one based on the above (no harm to my ego involved; I am not emotionally tied to the original proposal), or
2) Modify the current proposal to fit the above with an eye to a vote on or about November 4?
Or is this premature and should I allow discussion on the current proposal to continue?
In any event please note that I have been posting most e-mail responses to the Talk:Proposed features/Consulate page at https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Consulate so the record of our discussion will be preserved. I have also added some counterproposals and suggested modifications to the main proposal page.
Many thanks to one and all again,
cheers,
apm-wa

From: Allan Mustard

Date: October 28, 2018 at 9:05:53 AM GMT+5
Embassies and consulates are not open to the public, either. You have to make appointments for visa interviews, notarials, passport applications, business counseling, pretty much any service. The lone exception in Ashgabat is the OSM mapper who drops by to share something with the ambassador and needs no appointment to see me. Yes, this actually happened once! My point is that diplomatic facilities are no more open to the public than are private companies.
As an aside, in the case of American Embassies security is tighter since the 1998 bombings in Dar es Salaam and Nairobi. Getting through embassy security is similar to going to a first-world airport, including magnetometers, X-ray scanners, and hand wands. They are definitely not open to the public.
As for the question of embassies and consulates including residential space, I think it prudent and sufficiently accurate to focus on the primary intended use of the object. We do that all the time when mapping (a CVS pharmacy in Arlington, Virginia, is and should be tagged as a pharmacy, not as a stationer or convenience shop or liquor store even though it also sells office supplies and snack foods, even beer and wine). Same logic applies here, methinks.
If anyone wants to write a non-paper on the subject, please feel free ;-)
Sent from my iPhone
On Oct 28, 2018, at 12:31 AM, marc marc wrote:
Le 27. 10. 18 à 19:11, Paul Allen a écrit :
I wouldn't vote against office=diplomatic, I just hope
something better turns up before the vote.
I have the same feeling and I see two inconsistencies. private company offices are generally spaces that are not open to the public (you must make an appointment, it is not a shop) while an embassy is often "open to the public" oriented, at least for some services.
an consulate sometimes containing the consul's residence, I have trouble to tag the whole with a main tag office=*
maybe the office tag can be moved to "usefull combinaison" or "possible combinaison". if the consulate look like to be "office only", the a mapper may add the office tag, but not mandatory.

On 10/28/2018 10:18 AM, Allan Mustard wrote:

I'm not philosophically opposed to diplomatic=* as a primary tag. I am merely concerned about the mechanics of doing that, and how it would affect rendering, etc., since it is currently a secondary tag and would not render if "promoted" to primary tag status, at least until some volunteers who know what they are doing update the various rendering rules. I've learned the hard way as a bureaucrat not to assume that my bright idea will not create undue burdens on those who must implement it, so am proceeding with caution, and seeking a happy medium of accuracy and minimal burden on the community.
On 10/28/2018 1:18 AM, Paul Allen wrote:
On Sat, Oct 27, 2018 at 7:50 PM Allan Mustard wrote:
From where I sit (literally!), as a bureaucrat who spends many hours most days in an office, that tag fits diplomatic functions more closely than any other tag I've encountered so far
The rest of us are merely speculating based upon how it seems from the outside. If you think
office is the most appropriate designation you've seen (and, I assume, you can think of) then office
it is. Unless we make diplomatic the primary tag.
--
Paul

27 October 2018

On 10/27/2018 11:50 PM, Allan Mustard wrote:

Ahh, but an office does so much more than paperwork. An office houses officials (of the government, of NGOs, of companies and corporations, of a motion picture studio, a military commander, a food processor, the list goes on and on). It is not all paperwork. Some of it is actually fun.
From where I sit (literally!), as a bureaucrat who spends many hours most days in an office, that tag fits diplomatic functions more closely than any other tag I've encountered so far, even if some of our best work is done outside and in some cases very far from the office, as my Mapillary imagery attests.

On 10/27/2018 10:11 PM, Paul Allen wrote:

On Sat, Oct 27, 2018 at 5:38 PM Allan Mustard: wrote:
Given the effort required to create a new main key, and the split in opinions whether diplomatic=* should be a new main key, I am leaning toward office=diplomatic, diplomatic=[embassy, consulate, other] as a happy medium.
From my happy little Dunning-Krugeresque perspective (I don't know much about it, so it must be simple) of the technical innards, I'm not sure that there's any more effort required to have diplomatic as a new main key. I suspect that editors may find it slightly simpler to have diplomatic as a main key than a subordinate one. As far as the carto side goes, I saw an old youtube video on the subject which seemed to imply that adding anything in any manner could have drastic effects on rendering time, so I don't know which approach would be better for that.
The biggest problem with a new main key is political. Everyone has an opinion... There are those who want to merge everything into a very small number of categories and those who do not. You just produced very compelling arguments against amenity=diplomatic (an embassy or consulate does so much more). I think that applies, to a lesser extent, to office=diplomatic. An embassy doesn't really fit my mental category of "office" any more than a shop or filling station or hospital does (even though they all process paperwork, it's not their main purpose however much of their time it takes up). That said, I wouldn't vote against office=diplomatic, I just hope something better turns up before the vote.
--
Paul

On 10/27/2018 9:41 PM, Allan Mustard wrote:

I agree. Keep it to three: [embassy, consulate, other]. If the mapper doesn't know, he can check the Ministry of Foreign Affairs website. The information will typically be there.
apm-wa
On 10/27/2018 9:20 PM, Frederik Ramm wrote:
Hi,
On 27.10.2018 11:57, Eugene Alvin Villar wrote:
Tagging something as office=diplomatic then diplomatic=non-diplomatic
sounds silly and oxymoronic. Why not simply diplomatic=other? Also we
should allow diplomatic=yes if the mapper doesn't know the exact type.
Therefore diplomatic=[embassy, consulate, other, yes].
Would "yes" not be implied already by office=diplomatic? If someone
wasn't sure they could just use office=diplomatic without diplomatic=*.
(Side note, I've seen diplomatic offices that were so cordoned off by
local security forces that you wouldn't even come close enough to
determine whether this is a government facility or a diplomatic one. Of
course you can always ask the guards but maybe that only makes you
suspicious ;)
Bye
Frederik

On 10/27/2018 8:36 PM, Philip Barnes wrote:

On 27 October 2018 16:17:09 BST, Johnparis: wrote:
I was waiting for Martin to weigh in on the amenity vs. office question.
To me, a consulate falls squarely within the definition of amenity. It certainly serves "tourists" (including expats/foreigners/etc.). When I am visiting a new country, my country's consulate is one of the most important places for me to know about.
I would think that puts you in a minority, it is not something I have ever considered.
I suspect it is something most people find out about if it all goes very wrong.
And if I'm considering a visit to another country, finding that country's consulate is essential if I need a visa.
The only visa I have ever needed was to visit the US in the 70s. That was done by post. These days they are not needed.
Phil (trigpoint)

On 10/27/2018 8:17 PM, Johnparis wrote:

I was waiting for Martin to weigh in on the amenity vs. office question.
To me, a consulate falls squarely within the definition of amenity. It certainly serves "tourists" (including expats/foreigners/etc.). When I am visiting a new country, my country's consulate is one of the most important places for me to know about. And if I'm considering a visit to another country, finding that country's consulate is essential if I need a visa.
I'm not averse to office=diplomatic, but I do think amenity=diplomatic is a better fit.
As to the diplomatic=* subkey, I will say that "diplomatic=non_diplomatic" has been documented for some time. I do find it an oxymoron. I *think* the intent was to cover diplomatic missions not covered by either of the two main conventions. So "diplomatic=non_convention" might be a better value, though not very conversational English. "diplomatic=other" is a catch-all, but in that case you might as well just omit the subkey. I do think, however, upon reviewing the examples cited, that "diplomatic=mission" might be better. I don't see any particular reason to remove the other documented values for diplomatic=* from the wiki. I defer to Allan and other experts on this.
John

On 10/27/2018 7:56 PM, Martin Koppenhoefer wrote:

sent from a phone
On 27. Oct 2018, at 06:50, Allan Mustard <allan(at)mustard.net: wrote:
So here is where I sense we are 24 hours later, on Day 6:
a) consulates are not embassies;
b) neither embassies nor consulates are amenities;
c) embassies and consulates are government offices, but there is a trend toward thinking office=diplomatic is a better choice than office=government; and
d) the office=diplomatic tag in tandem with diplomatic=* would meet OSM guidelines and support more accurate mapping.
If my sense of growing consensus is correct, I suggest that diplomatic=* would include only [embassy, consulate, non-diplomatic].
I am not an English native speaker, but from the dictionary reading I did not get the impression amenity is very far fetched for embassies, certainly less than for prisons.
From a data structure perspective, for certain applications (e.g. osm-carto) a “main” key must be present in order to have the object not filtered out during database import. As I believe embassies should be in our “standard set” of data, a main key is desirable.
I would see embassies as a good fit for osm amenity (indeed it is already there), they are different to other offices because of their particular status, and “office” is also not in the very core.
Cheers, Martin

On 10/27/2018 6:40 PM, Mateusz Konieczny wrote:

26. Oct 2018 21:53 by daniel(at)xn--ko-wla.pl:
Historically the problem is lack of experience with moving to new, better defined and more rich schemes in OSM Carto (like public_transport or healthcare). The excuse was a written rule to "prevent unfavorable fragmentation of tag use" ( https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose ). My take is that there is also different case ("favorable" fragmentation), which is a smooth migration, but that was not considered valid by others, probably to stay neutral and move along only when tagging habits really do change for good. But for some well known tags I think this is not helping, since lack of rendering in OSM Carto is not neutral fact for mappers ("It's an important feedback mechanism for mappers to validate their edits" from the same sentence, but nobody ever mentioned it, including me...).
Again: that's what I personally think and others my have different opinions. Yet if somebody else agrees, it makes sense to discuss it in our issue tracker:
https://github.com/gravitystorm/openstreetmap-carto/issues
I would not call it "excuse".
There is combination of various effects
- some people want rendering before tagging is actually widely used
- some people want rendering before tagging is properly discussed
- some people want rendering before tagging is supported in editors
- some people want rendering before tagging is supported in any other map style, despite that there are ones focusing on a given topic
- some people want rendering of tagging that is highly controversial to improve their position in a dispute
- some people want rendering of tagging that is obnoxious to render
- it is undesirable to have tagging discussions on issue tracker of a single rendering
- it is undesirable to have tagging decisions on issue tracker of a single rendering

On 10/27/2018 9:38 PM, Allan Mustard wrote:

Paul, et al,
FYI new embassy compounds under construction around the world typically include both office space and residences for some of the personnel. The new Saudi complex in Ashgabat, the Chinese, Belarus and Russian embassies in Ashgabat, and the American complex under construction here all include residences for embassy staff (not only the ambassadors), for example. I agree that micromapping is a bridge too far; we should simply map them as embassies. Overall this strikes me as a non-issue. Yes, we live at embassies, we work at embassies, and the residential quarters often double as work space. Tag 'em as embassies, period. That goes for ambassadors' residences, too, though I must warn you that most ambassadors don't want their residences mapped for security reasons.
As for the debate over amenity vs. office, an embassy is much more than an amenity, and so is a consulate. There is an argument in favor of calling them amenities, but the concept of an embassy or consulate as an amenity is based on the POV of a tourist or business traveler, and does not include the totality of what an embassy, consulate, and non-diplomatic mission (it would be a stretch to categorize the non-dip PLO and Taliban offices abroad as amenities, for example) do every single day. It is IMHO too limiting. Office=* is a better descriptor. If you have strong feelings on this, please voice them, and please tell me what I am missing.
Given the effort required to create a new main key, and the split in opinions whether diplomatic=* should be a new main key, I am leaning toward office=diplomatic, diplomatic=[embassy, consulate, other] as a happy medium. If there is not some sort of revelation over the next week, when we hit the two-week mark for the RFC I am leaning toward a gut and rewrite of the amenity=consulate proposal (or withdrawal of the current proposal and submission of a new one) along those lines. I welcome another week of discussion before making a decision on what to put to a vote.
As for oxymorons, welcome to my world! Wait a minute, I have another non-paper to read.  :-)
And Paul, you can find the switchboard telephone number of my embassy in OSM.
apm-wa
On 10/27/2018 6:22 PM, Paul Allen wrote:
On Sat, Oct 27, 2018 at 5:52 AM Allan Mustard: wrote:
[Good stuff, almost all of which I agree with]
If we want to split hairs, we can point out that "embassy" is technically an incorrect term for any building since an "embassy" consists solely of people assigned to conduct diplomatic relations with a foreign government, both resident and non-resident. The "chancery" https://en.wikipedia.org/wiki/Chancery_(diplomacy) is the office building, complex, or office flat where the embassy operates. I don't think we want to be quite that doctrinaire (office=chancery, anyone?) since "embassy" is the term in common if somewhat imprecise use for a building or campus where a diplomatic mission operates.
We have to walk a fine line between what is technically correct and the expectations of mappers and
users. So I'd go with "embassy" and clarify the situation in the wiki for the benefit of pedants. There
could be another ambassador out there mapping for OSM who might take exception to that
decision without an explanation of the thinking behind it, and it's certain this mailing list has many,
many pedants.
c) embassies and consulates are government offices, but there is a trend toward thinking office=diplomatic is a better choice than office=government; and
d) the office=diplomatic tag in tandem with diplomatic=* would meet OSM guidelines and support more accurate mapping.
I 100% agree that office=diplomatic is better than office=government. I'm split on dropping office
entirely and using diplomatic as the main key. The ambassador also sleeps in his/her
residence and I think micromapping the building to distinguish between office and non-office
functions is overkill.
If my sense of growing consensus is correct, I suggest that diplomatic=* would include only [embassy, consulate, non-diplomatic].
Perhaps, but I'd write the proposal to not insist absolutely that only those three terms are
permissible because otherwise mappers end up with square peg/round hole should the
unforeseen arise. OTOH, you have a very thorough understanding of what might arise, and I can
only guess, so maybe those three will always be adequate. Except that, as others have noted,
diplomatic=non-diplomatic is oxymoronic, and diplomatic=other would be better.
P.S. Regarding the question posed overnight as to whether one may simply drop in on an ambassador's residence, any of you who are contributing substantively to this discussion are welcome to drop by my residence in Ashgabat any time you are in town :-) Just please call ahead to make sure I'll be home.
If I'm ever in Ashgabat, I'll give you a call. I consider the probability of this happening similar to
the odds of me winning the jackpot on the lottery then getting hit by lightning as I go to collect
the prize. Especially as I have never bought a lottery ticket and never will. But strange things
happen, so I'll keep your offer in mind. :)
--
Paul

On 10/27/2018 6:21 PM, Mateusz Konieczny wrote:

26. Oct 2018 21:27 by allan(at)mustard.net:
Regarding the question of using office=* as the primary key or diplomatic=* I note that the Key:diplomatic wiki article admonishes:
Note
Do not use diplomatic=* without amenity=embassy since it is not independently recognised by renderers.
How do we get around that (probably a naive question on my part since I am not a programmer)?
short guide:
1) initially use diplomatic=* double tagged with amenity=embassy
2) wait until usage grows a bit
3) request support in editors (JOSM, iD, Vespucci) for this new tag
4) request rendering support in map styles

On 10/27/2018 3:59 PM, Allan Mustard wrote:

Yes, it is silly and oxymoronic, but so are "non-papers" (a paper that is not a paper), something we diplomats use pretty often.
The problem with calling AIT and TECRO embassies has naught to do with my status as a U.S. diplomat. It is that they are not embassies in terms of the Vienna Convention on Diplomatic Relations, and that's the ultimate authority. I raised this whole issue because a consulate is not an embassy; having opened that can of worms it is illogical to correct that error only to insert another. If you prefer "other" to Wikipedia's "non-diplomatic" I can probably live with that. I cannot, however, agree with calling AIT, TECRO, the Taliban office in Doha, or for that matter the State of Virginia office in New Delhi "embassies". They would be "other" and not "embassy" simply because they are not embassies. They do not enjoy diplomatic immunities or diplomatic status under the VCDR, any more than consulates do. Now excuse me for a few minutes, please, as I have a non-paper to read.
BTW even though the United States does not recognize Palestine, I mapped the Palestinian Embassy in Ashgabat as soon as it opened because in the OSM domain calling it an embassy falls under OSM rules, not U.S. government rules. Turkmenistan recognizes Palestine and grants its "embassy" that status under the VCDR. I mapped it as a private citizen, not as an officer of the United States, and my mapping does not reflect U.S. government policy in any way, shape, or form.
On 10/27/2018 2:57 PM, Eugene Alvin Villar wrote:
On Sat, Oct 27, 2018 at 12:52 PM Allan Mustard: wrote:
If my sense of growing consensus is correct, I suggest that diplomatic=* would include only [embassy, consulate, non-diplomatic].
Tagging something as office=diplomatic then diplomatic=non-diplomatic sounds silly and oxymoronic. Why not simply diplomatic=other? Also we should allow diplomatic=yes if the mapper doesn't know the exact type. Therefore diplomatic=[embassy, consulate, other, yes]. (So diplomatic=embassy applies to regular embassies, Commonwealth of Nations' high commissions, Vatican apostolic nunciatures, etc.)
It also offers a potentially neat solution for dealing with the non-diplomatic representations of Taiwan and the United States in each others' countries
I think we should call a spade a spade. While the Taipei Economic and Cultural Representative Office (TECRO) in the U.S. and the American Institute in Taiwan (AIT) are not de jure embassies in order to adhere to the so-called "One China" policy, these offices are de facto embassies with their head officers having (I think) ambassadorial rank with largely the same rights and privileges. Since OSM mapping the mainland Chinese territory is already an illegal activity w.r.t. the PRC's laws, I don't think assigning the diplomatic=embassy tag to the ROC-related diplomatic representative offices would make things worse and would cause a diplomatic incident. (Well, you as a diplomat, probably cannot say so because you are bound by your Department of State's adherence to the One China policy, but almost every other mapper isn't a diplomat so we are free to map however we want. [I can already see the BuzzFeed headline: "U.S. envoy to Turkmenistan admits Americans have diplomatic relations with Taiwan".])
and other non-diplomatic representations, such as the Taliban office in Doha.
(This sounds interesting! [Goes and browses the "Taliban in Qatar" Wikipedia article])
I think limiting the number of options for diplomatic=* to three would simplify mapping (and avoid confusing mappers not steeped in the lore of diplomacy); the particular type of diplomatic mission is in any case reflected in the name=* tag and needs not be duplicated in the diplomatic=* tag (e.g., "High Commission of Malaysia", "Embassy of Poland", "U.S. Interests Section", "Consulate General of Japan"). If the status of a mission changes (e.g., the upgrade of the U.S. Interests Section in Havana to an embassy), changing the name would suffice; no re-tagging would be necessary.
I generally agree with this idea, but with the Taiwanese caveat I mentioned above.
P.S. Regarding the question posed overnight as to whether one may simply drop in on an ambassador's residence, any of you who are contributing substantively to this discussion are welcome to drop by my residence in Ashgabat any time you are in town :-) Just please call ahead to make sure I'll be home.
That's a great offer! Although I probably would not be visiting Central Asia in the foreseeable future; my passport is in the bottom half of the Henley Passport Index so I don't have as much opportunities to travel as citizens in other countries. :)
BTW, for other people on this thread who are not aware: yes, Allan, the U.S. ambassador to Turkmenistan, is an active OSM mapper and has substantially contributed to mapping Turkmenistan in OSM outside of his official duties. https://wiki.openstreetmap.org/wiki/Turkmenistan

On 10/27/2018 9:50 AM, Allan Mustard wrote:

If we want to split hairs, we can point out that "embassy" is technically an incorrect term for any building since an "embassy" consists solely of people assigned to conduct diplomatic relations with a foreign government, both resident and non-resident. The "chancery" https://en.wikipedia.org/wiki/Chancery_(diplomacy) is the office building, complex, or office flat where the embassy operates. I don't think we want to be quite that doctrinaire (office=chancery, anyone?) since "embassy" is the term in common if somewhat imprecise use for a building or campus where a diplomatic mission operates.

IMHO defining the ambassador's residence as an "office" would not be wholly incorrect and only slightly mysterious to mappers and users of our map, since the ambassador's residence is where a lot of work gets done. Half of my residence is devoted to space for official entertaining, and I have a home office. Also, WRT the point of certain ambassadors' residences being historic manors, that's not really a big issue since the vast majority of ambassadors' residences are neither historic nor manors (my modest two-bedroom house certainly is neither, and many ambassadors here in Ashgabat reside in apartments). If there is strenuous objection to my opinion on this, please offer an alternative to office=diplomatic!

So here is where I sense we are 24 hours later, on Day 6:

a) consulates are not embassies;
b) neither embassies nor consulates are amenities;
c) embassies and consulates are government offices, but there is a trend toward thinking office=diplomatic is a better choice than office=government; and
d) the office=diplomatic tag in tandem with diplomatic=* would meet OSM guidelines and support more accurate mapping.

If my sense of growing consensus is correct, I suggest that diplomatic=* would include only [embassy, consulate, non-diplomatic]. The Wikipedia article on diplomatic missions is not bad with respect to its descriptions of different types of diplomatic missions: https://en.wikipedia.org/wiki/Diplomatic_mission. It also offers a potentially neat solution for dealing with the non-diplomatic representations of Taiwan and the United States in each others' countries and other non-diplomatic representations, such as the Taliban office in Doha. I think limiting the number of options for diplomatic=* to three would simplify mapping (and avoid confusing mappers not steeped in the lore of diplomacy); the particular type of diplomatic mission is in any case reflected in the name=* tag and needs not be duplicated in the diplomatic=* tag (e.g., "High Commission of Malaysia", "Embassy of Poland", "U.S. Interests Section", "Consulate General of Japan"). If the status of a mission changes (e.g., the upgrade of the U.S. Interests Section in Havana to an embassy), changing the name would suffice; no re-tagging would be necessary.

There is a recurring sentiment in the discussion to add diplomatic:services:*=[yes/no]. From my POV the services listed would consist of [immigrant visas, non-immigrant visas, citizen services]. Those are the broad categories of services consulates and embassies offer their clienteles. For instance, if the consular section of an embassy or a consulate offers non-immigrant visas, it usually offers all types of them (tourist, student, academic exchange, temporary work, etc.). Yes, there are exceptions, but that's what websites are for, and I don't think it is OSM's job to delve so deeply in the details in order to let Mexican migrant farm workers know that H1B visas are only available via the American Consulate General in Ciudad Juarez. Our solution to this is to add the website URL for the convenience of OSM users. All embassies and consulates offer services to commercial interests of their fellow countrymen (or at least, they are supposed to) so I see no need to add diplomatic:services:commercial=[yes/no]. In those cases where an embassy includes a separately officed trade representation (as Russia tends to do), the purpose of that mission is obvious from the name=* tag.

apm-wa

P.S. Regarding the question posed overnight as to whether one may simply drop in on an ambassador's residence, any of you who are contributing substantively to this discussion are welcome to drop by my residence in Ashgabat any time you are in town :-) Just please call ahead to make sure I'll be home.

On 10/27/2018 12:38 AM, Paul Allen wrote:

On Fri, Oct 26, 2018 at 8:28 PM Allan Mustard: wrote:
Regarding the question of using office=* as the primary key or diplomatic=* I note that the Key:diplomatic wiki article admonishes:
Note
Do not use diplomatic=* without amenity=embassy since it is not independently recognised by renderers.
How do we get around that (probably a naive question on my part since I am not a programmer)?
It is a matter of convincing the programmers that going down this route is a good idea. Which
calls for diplomatic skills rather than programming skills. Do you know anyone with suitable
qualifications? :)
--
Paul

On 10/27/2018 12:53 AM, Daniel Koć wrote:

W dniu 26.10.2018 oВ 21:27, Allan Mustard pisze:
Regarding the question of using office=* as the primary key or diplomatic=* I note that the Key:diplomatic wiki article admonishes:
Note
Do not use diplomatic=* without amenity=embassy since it is not independently recognised by renderers.
I would be happy to render them in OSM Carto (default map style on OSM.org):
1. It makes sense to me and usage of this tag seems to be proper, however I don't know about the others involved there. Probably someone needs to make the ticket and discuss subject if needed.
2. Not every diplomatic object is embassy, this seems like good choice to not tag things for rendering...
Historically the problem is lack of experience with moving to new, better defined and more rich schemes in OSM Carto (like public_transport or healthcare). The excuse was a written rule to "prevent unfavorable fragmentation of tag use" ( https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose ). My take is that there is also different case ("favorable" fragmentation), which is a smooth migration, but that was not considered valid by others, probably to stay neutral and move along only when tagging habits really do change for good. But for some well known tags I think this is not helping, since lack of rendering in OSM Carto is not neutral fact for mappers ("It's an important feedback mechanism for mappers to validate their edits" from the same sentence, but nobody ever mentioned it, including me...).
Again: that's what I personally think and others my have different opinions. Yet if somebody else agrees, it makes sense to discuss it in our issue tracker:
https://github.com/gravitystorm/openstreetmap-carto/issues

On 10/27/2018 1:08 AM, Eugene Alvin Villar wrote:

office=government
On Sat, Oct 27, 2018 at 2:53 AM Paul Allen: wrote:
If you can come up with a better value than "diplomatic" then do so.В If you don't like it being under
the office key, maybe have diplomatic=* as the primary key rather than a secondary key under
office (although that may well contravene OSM naming conventions I've never heard of).В But if
we can have healthcare=doctor as an alternative to amenity=doctors or office=doctor then I don't see why
diplomatic=embassy would be a bad idea.
In my opinion, having healthcare=* as a primary key makes a lot of sense because the medical and healthcare profession and services encompasses a really wide range of "amenities" from doctor's offices where you can visit for consultations, to dentists, to hospitals with emergency and surgery facilities, to dialysis centers, to veterinarians, and even to alternative medical facilities like acupuncture clinics if we really want to go down that path.
On the other hand. diplomatic offices and services encompass a range that is much too narrow such that I don't think having diplomatic=* as a primary key seems appropriate. I would prefer if we just have the office=diplomatic + diplomatic=* tag combination instead. This nicely parallels and complements the office=government + government=* tag combination[1] that we already have, but instead applying to foreign governments.
[1] https://wiki.openstreetmap.org/wiki/Tag:office=government

On 10/27/2018 1:13 AM, Daniel Koć wrote:

W dniu 26.10.2018 o 22:08, Eugene Alvin Villar pisze:
On the other hand. diplomatic offices and services encompass a range that is much too narrow such that I don't think having diplomatic=* as a primary key seems appropriate. I would prefer if we just have the office=diplomatic + diplomatic=* tag combination instead. This nicely parallels and complements the office=government + government=* tag combination[1] that we already have, but instead applying to foreign governments.
[1] https://wiki.openstreetmap.org/wiki/Tag:office=government
It matches nicely, indeed, but on the other hand this is probably not an office:
https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence

On 10/27/2018 4:15 AM, Eugene Alvin Villar wrote:

On Sat, Oct 27, 2018 at 4:32 AM Daniel Koć: wrote:
W dniu 26.10.2018 o 22:08, Eugene Alvin Villar pisze:
On the other hand. diplomatic offices and services encompass a range that is much too narrow such that I don't think having diplomatic=* as a primary key seems appropriate. I would prefer if we just have the office=diplomatic + diplomatic=* tag combination instead. This nicely parallels and complements the office=government + government=* tag combination[1] that we already have, but instead applying to foreign governments.
[1] https://wiki.openstreetmap.org/wiki/Tag:office=government
It matches nicely, indeed, but on the other hand this is probably not an office:
https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence
True, this is not an office. An ambassador/diplomat's residence enjoys the same extraterritorial rights and privileges as other diplomatic facilities like embassies and consulates.
But this actually implies that diplomatic=* itself is not a good primary key. You really do not expect citizens of either the host or the sending country to just visit an ambassador's residence unannounced and without invitation. (Maybe you can visit it if the ambassador is hosting a party and you're invited.) Therefore, such residences should be rendered differently from embassies and consulates and more like how other notable residences are rendered (maybe like the White House or Buckingham Palace). This implies that using diplomatic=ambassadors_residence needs a different primary tag than office=diplomatic depending on the actual form of the residence. The residence can be a manor (historic=manor) such the U.S. ambassador's residence in Buenos Aires[1], a regular house (building=house) such as the Argentinian ambassador's residence in London[2], or a hotel suite (tag nonexistent, unless we use the Simple Indoor Tagging scheme) such as the U.S. ambassador to the UN's residence in New York[3].
[1] https://en.wikipedia.org/wiki/Bosch_Palace
[2] https://en.wikipedia.org/wiki/49_Belgrave_Square
[3] https://en.wikipedia.org/wiki/Residence_of_the_United_States_Ambassador_to_the_United_Nations

On 10/27/2018 4:18 AM, Graeme Fitzpatrick wrote:

On Sat, 27 Oct 2018 at 06:32, Daniel Koć: wrote:
It matches nicely, indeed, but on the other hand this is probably not an office:
https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence
I'd agree that the residence is probably not an office=.
We've agreed that tagging the "embassy" / residence as landuse= or building= won't work because of those cases that it's only a flat / unit, not a freestanding building.
What's that leave us with?
government= with debate over whether that means host or sending govt, or
amenity= (probably diplomatic)
Have I missed any options? :-)
Thanks
Graeme

On 10/27/2018 4:56 AM, Warin wrote:

On 27/10/18 10:18, Graeme Fitzpatrick wrote:
On Sat, 27 Oct 2018 at 06:32, Daniel Koć: wrote:
It matches nicely, indeed, but on the other hand this is probably not an office:
https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence
I'd agree that the residence is probably not an office=.
We've agreed that tagging the "embassy" / residence as landuse= or building= won't work because of those cases that it's only a flat / unit, not a freestanding building.
What's that leave us with?
government= with debate over whether that means host or sending govt, or
amenity= (probably diplomatic)
Have I missed any options? :-)
Yes.
Just use the key diplomatic=* .. no other key to be used.
Can be used on a node where the feature is a small section of a multi-storey building
Can be used as a way where an entire property - not just a building - can be mapped.
The key office=* should not be used, does not cover an ambassadors residence, does not cover mapping the entire property.
------------------------------------------
Migration away from amenity=embassy?
First add the tag diplomatic=*
There are about 4,000 diplomatic key uses in the data base while some ~11,500 amenity=embassy uses exist.
I have performed this for some ~200 amenity=embassy uses to generate a diplomatic key.
Look at the name - if it contains;
high - generate diplomatic=high_commission - should occur in capital cities of the British Commonwealth and not elsewhere
embassy generate diplomatic=embassy - should occur in capital cities
general - generate diplomatic=consulate_general - should not occur in capital cities
and so on.
As usual a manual check can revel errors. Like a embassy school tagged as embassy, re-tagged as school.
For the renders;
Render diplomatic=* the same as amenity=embassy.
While this does not distinguish between the various values it does not imply that they are all embassies.
If there is enough interest then some means of distinguishing between them can be developed, similar to, say, shops.
That done the tag amenity=embassy can be removed.
================
That is my present thinking. Subject to change.

On 10/27/2018 12:03 AM, Daniel Koć wrote:

W dniu 26.10.2018 o 20:52, Paul Allen pisze:
If you can come up with a better value than "diplomatic" then do so. If you don't like it being under
the office key, maybe have diplomatic=* as the primary key rather than a secondary key under
office (although that may well contravene OSM naming conventions I've never heard of). But if
we can have healthcare=doctor as an alternative to amenity=doctors or office=doctor then I don't see why diplomatic=embassy would be a bad idea.
Yes, I also think that we don't have to (over)use amenity or office keys. We have diplomatic key spacename already defined and used (2015 was groundbreaking here), so I would go with that in general:
https://wiki.openstreetmap.org/wiki/Key%3Adiplomatic
https://taginfo.openstreetmap.org/keys/diplomatic#values

26 October 2018

On 10/26/2018 11:52 PM, Paul Allen wrote:

On Fri, Oct 26, 2018 at 6:10 PM Allan Mustard <allan (at)mustard.net> wrote:
a) consulates are not embassies;

Indeed. If they were the same thing they'd have the same name. :)

b) embassies and consulates are government offices, but there is no agreement that office=government is appropriate;

I suspect that many of us (me, for one) who have not been intimately involved with diplomatic missions interpret "government" as meaning the government (national, provincial or local) of the specified country. Yes, technically, embassies are extensions of the government of the sending country but they don't feel like government offices to me. If I curse the government, as I frequently do, I'm thinking of my national government not all the embassies in my country.

c) neither is an amenity;

Heartily agreed.

d) office=diplomatic is a reasonable option that while not utterly precise is close enough (I don't love it but can live with it), and that in tandem with diplomatic=[embassy, consulate, etc.] would meet OSM guidelines?

If you can come up with a better value than "diplomatic" then do so. If you don't like it being under the office key, maybe have diplomatic=* as the primary key rather than a secondary key under office (although that may well contravene OSM naming conventions I've never heard of). But if we can have healthcare=doctor as an alternative to amenity=doctors or office=doctor then I don't see why diplomatic=embassy would be a bad idea.

Also consider diplomatic:service=* or something along those for visas, etc. There are probably lots of things like that (such as help with import licensing) that may or may not be offered by any particular mission. You're the person who knows about these things and it's better if you cover all the options now than have people invent them on an ad hoc basis later and come up with things that turn out to be sub-optimal.

-- Paul

On 10/26/2018 10:08 PM, Allan Mustard wrote:

Colin, et al,
Thanks for this. You have not misunderstood the doctrine at all, but you have not quite taken it to its full conclusion. The examples you cite involve interaction between the embassy and the outside world (pizza delivery, lease contracts, employment contracts of local staff, radio transmitters, and diplomatic vehicles maneuvering on host-country roads). Radio (wireless) is specifically covered in the Vienna Convention because radio waves propagate beyond the boundaries of the embassy. That said, if a murder is committed on embassy premises, the sending side has jurisdiction (in the case of the United States, the Bureau of Diplomatic Security of the U.S. Department of State). Once the lease is signed, the embassy cannot be evicted even if the rental payment is not paid (for a similar issue see this news item https://www.wusa9.com/article/news/local/dc/how-dc-plans-to-deal-with-derelict-embassies/485736302 about a derelict embassy building in Washington, DC). Once the embassy chancery is constructed, if the sending side decides to renovate the interior of the embassy, it is done in accord with sending-side construction standards, not necessarily host-country standards. No, pizza is not considered an export, but it is an item of trivial value akin to the duty-free bottle of fine single malt Scotch I brought back from Dubai two weeks ago; however, if I import 1,250 pounds of consumables via sea freight, they enter the host-country import statistics. Regarding personnel, host-country personnel must be hired and paid in accord with host-country law in most cases, though in many countries embassies pay in dollars despite host-country laws requiring payment in local currency and cite extraterritoriality as the legal grounds for this. Sending side personnel (like me) are hired, paid, and fired in accord with sending side rules, period. And yes, we pay fines, but we don't pay taxes. Please note that immunities and extraterritoriality are defined not only in the Vienna Convention at this point but also by court precedents established over the past 57 years, which is one reason the Department of State has a large staff of lawyers.
As to why the .gov top-level domain is used only by government bodies in the United States, that's because Al Gore DARPA invented the internet and DARPA is a U.S. institution, so we got first dibs, that's all. Many other governments use their two-byte country top-level domain with either go. or gov. in front of it, e.g., go.jp for the Japanese government, gov.uk for the UK government, and so on. In response to some of the comments, a) no, that doesn't mean the U.S. government is the only government, and I never said that; b) yes, these gov.xx and go.xx domains are used for embassies' and consulates' e-mail and websites, and c) the point I'm trying to make is that embassies and consulates are government offices, even if not of the host country--their staff are government employees, their budgets come from a government somewhere, and their property is government property.
I believe we are approaching some sort of consensus that amenity=embassy is not adequate and that something needs to be done to correct this. Are we in agreement that
a) consulates are not embassies;
b) embassies and consulates are government offices, but there is no agreement that office=government is appropriate;
c) neither is an amenity;
d) office=diplomatic is a reasonable option that while not utterly precise is close enough (I don't love it but can live with it), and that in tandem with diplomatic=[embassy, consulate, etc.] would meet OSM guidelines?
We're only five days into the RFC so lots of time left to comment!
cheers,
Allan Mustard
apm-wa
On 10/26/2018 1:28 PM, Colin Smale wrote:
On 2018-10-26 03:26, Allan Mustard wrote:
Under the legal doctrine of extraterritoriality, the embassy or consulate is considered to be located in the sending country for purposes of legal jurisdiction. Extraterritoriality is virtually unlimited in the case of an embassy; it is more limited in the case of a consulate but still exists
Allan,
That doesn't sound quite right. As I read the UN conventions, the diplomatic staff have some immunities which are linked to their personal status and not linked to their being in the embassy buildings. The premises themselves are inviolable by the host state, which means local laws sometimes cannot actually be enforced without invitation from the Ambassador. However, the embassy as a premises is still part of the receiving country. Delivering pizza to them is not an export. The lease contract is under the laws of the host country. Employment contracts for support staff can be under the law of the host country. Their radio transmitters need to be licensed by the host country. Diplomatic cars have to pay speeding fines and parking tickets. But in the case of violations, the only sanction available to the host country is basically withdrawal of recognition of diplomatic staff.
Have I misunderstood your interpretation of "extraterritoriality"

On 10/26/2018 9:41 PM, Eugene Alvin Villar wrote:

On Fri, Oct 26, 2018 at 10:27 AM Warin <61sundowner (at)gmail.com: wrote:
In OSM I would expect the term government not to be a foreign government but a resident one.
Uniquely, Italy hosts its own embassy to the Holy See (aka Vatican City). So technically, you could use "government" for that single embassy. ;-)

On 10/26/2018 2:54 PM, Johnparis wrote:

Thanks for refocusing the discussion, Martin.
I think the new tag should be amenity=diplomatic.
A major reason is the instance where both an embassy and a consulate share a node. If the new tag is amenity=consulate, you would either need two nodes in the case where they share a space, which is acceptable but not ideal, or else a single node with amenity=embassy;consulate, which as I understand it is on the verge of forbidden.
Another advantage of amenity=diplomatic as the new tag is that it would be clear that anything tagged "amenity=embassy" has not switched over to the new model, making quality control easier. If the new tag is amenity=consulate, it would be unclear whether a consulate tagged as "amenity=embassy" has been switched to the new model, making quality control more difficult.
Whatever we agree upon, the new tagging structure won't get into general use unless (a) it's a preset in ID, and (b) it's rendered in the standard map.
John

Am Fr., 26. Okt. 2018 um 08:38В Uhr schrieb Graeme Fitzpatrick <graemefitz1 (at)gmail.com>:

On Fri, 26 Oct 2018 at 16:12, Martin Koppenhoefer <dieterdreist (at)gmail.com> wrote:
what kind of proofs Warin’s point, because .gov is for US government domains while you are not in the US.
But for a counter example :-):
Australian Embassy in Paris
Embassy Emails:
General questions :В info.paris (at)dfat.gov.au
Consular and passport questions:В consular.paris (at)dfat.gov.au
it is not a counter example, it is the same situation: australian embassy in France using an australian government domain.В
FWIW, I don't have strong feelings about the landuse value to apply, but I do not believe we should use _only_ landuse to define any kind of _feature_ (and embassies and consulates are "features" in my reading).
So regardless of the landuse value that applies or not, we should resolve the question how to tag 1 consulate or 1 embassy.
Even if we have not yet found agreement on consulates, it seems we do agree that the "diplomatic" key can be useful in this context.
Question is whether we would want to introduce a new amenity=diplomatic tag as general tag or if we keep amenity=embassy and introduce amenity=consulate (which still would leave room for a diplomatic key for subclasses and which still would let us add more detail about provided services etc. with other related tags).
Is there someone who believes we should stick to the current scheme and keep consulates as a subclass of amenity=embassy, although they are not embassies?
Cheers,
Martin

On 2018-10-26 03:26, Allan Mustard wrote:

Under the legal doctrine of extraterritoriality, the embassy or consulate is considered to be located in the sending country for purposes of legal jurisdiction. Extraterritoriality is virtually unlimited in the case of an embassy; it is more limited in the case of a consulate but still exists

On 10/26/2018 1:28 PM, Colin Smale wrote: Allan,

That doesn't sound quite right. As I read the UN conventions, the diplomatic staff have some immunities which are linked to their personal status and not linked to their being in the embassy buildings. The premises themselves are inviolable by the host state, which means local laws sometimes cannot actually be enforced without invitation from the Ambassador. However, the embassy as a premises is still part of the receiving country. Delivering pizza to them is not an export. The lease contract is under the laws of the host country. Employment contracts for support staff can be under the law of the host country. Their radio transmitters need to be licensed by the host country. Diplomatic cars have to pay speeding fines and parking tickets. But in the case of violations, the only sanction available to the host country is basically withdrawal of recognition of diplomatic staff.

Have I misunderstood your interpretation of "extraterritoriality"?

On 10/26/2018 1:25 PM, Warin wrote:

On 26/10/18 17:37, Graeme Fitzpatrick wrote:
On Fri, 26 Oct 2018 at 16:12, Martin Koppenhoefer <dieterdreist (at)gmail.com: wrote:
what kind of proofs Warin’s point, because .gov is for US government domains while you are not in the US.
But for a counter example :-):
Australian Embassy in Paris
Embassy Emails:
General questions :В info.paris (at)dfat.gov.au
Consular and passport questions:В consular.paris (at)dfat.gov.au
DFAT by the way is the Australian Dept of Foreign Affairs & Trade
And the uk government uses *.gov.uk , The Japanese use *.go.jp, the French use *.gouv.fr
I am certain there are many more examples of this.
And these email addresses and domains are used both locally and internationally.
However in OSM landuse=government does not imply US government everywhere!

On 10/26/2018 11:37 AM, Graeme Fitzpatrick wrote:

On Fri, 26 Oct 2018 at 16:12, Martin Koppenhoefer <dieterdreist (at)gmail.com: wrote:
what kind of proofs Warin’s point, because .gov is for US government domains while you are not in the US.
But for a counter example :-):
Australian Embassy in Paris
Embassy Emails:
General questions : info.paris (at)dfat.gov.au
Consular and passport questions: consular.paris (at)dfat.gov.au
DFAT by the way is the Australian Dept of Foreign Affairs & Trade
Thanks
Graeme

On 10/26/2018 7:26 AM, Warin wrote:

In OSM I would expect the term government not to be a foreign government but a resident one.
So I would use a different term, office=diplomatic for example.
On Fri, Oct 26, 2018 at 10:44 AM Martin Koppenhoefer <dieterdreist (at)gmail.com:wrote:
Am Fr., 26. Okt. 2018 um 08:38 Uhr schrieb Graeme Fitzpatrick <graemefitz1 (at)gmail.com::
On Fri, 26 Oct 2018 at 16:12, Martin Koppenhoefer <dieterdreist (at)gmail.com:wrote:
what kind of proofs Warin’s point, because .gov is for US government domains while you are not in the US.
But for a counter example :-):
Australian Embassy in Paris
Embassy Emails:
General questions : info.paris (at)dfat.gov.au
Consular and passport questions: consular.paris (at)dfat.gov.au
it is not a counter example, it is the same situation: australian embassy in France using an australian government domain.
FWIW, I don't have strong feelings about the landuse value to apply, but I do not believe we should use _only_ landuse to define any kind of _feature_ (and embassies and consulates are "features" in my reading).
So regardless of the landuse value that applies or not, we should resolve the question how to tag 1 consulate or 1 embassy.
Even if we have not yet found agreement on consulates, it seems we do agree that the "diplomatic" key can be useful in this context.
Question is whether we would want to introduce a new amenity=diplomatic tag as general tag or if we keep amenity=embassy and introduce amenity=consulate (which still would leave room for a diplomatic key for subclasses and which still would let us add more detail about provided services etc. with other related tags).
Is there someone who believes we should stick to the current scheme and keep consulates as a subclass of amenity=embassy, although they are not embassies?
Cheers,
Martin

Allan Mustard <allan (at)mustard.net>
8:14 AM (12 minutes ago)
to Tag

My official email address ends in .gov :-). And diplomats are by definition government employees.

Sent from my iPhone

>On Oct 26, 2018, at 7:26 AM, Warin <61sundowner (at)gmail.com> wrote:
>
>In OSM I would expect the term government not to be a foreign government but a resident one.
>So I would use a different term, office=diplomatic for example.
>
>>On 26/10/18 12:26, Allan Mustard wrote:
>>Embassies and consulates are definitely government facilities/offices. Under the legal doctrine of extraterritoriality, the embassy or consulate is considered to be located in the sending country for purposes of legal jurisdiction. Extraterritoriality is virtually unlimited in the case of an embassy; it is more limited in the case of a consulate but still exists. Thus office=government, government=[diplomatic, consular}, diplomatic=[embassy, high_commission, nunciature, legation, interests_section, branch_embassy, liaison_office] might be what we are looking for.
>>>On 10/25/2018 2:24 PM, Colin Smale wrote:
>>>On 2018-10-25 06:42, Graeme Fitzpatrick wrote:
>>>
>>>
>>>>On Thu, 25 Oct 2018 at 11:41, Warin <61sundowner (at)gmail.com> wrote:
>>>>Err no.
>>>>
>>>>The 'government' is not 'foreign' but of federal/state/local jurisdiction to that place.
>>>>
>>>>landuse=diplomatic???
>>>>
>>>>Yes, but that patch of ground is owned by the "Australian" govt - it's just that it's located in the US or where-ever!
>>>
>>>For the avoidance of doubt, it is owned by the "Australian govt" in the same sense that I own my house (but it may also be rented or leased). It is not outside of the host country's jurisdiction, if that's what you were implying by "owned".

On 10/26/2018 6:26 AM, Allan Mustard wrote:

Embassies and consulates are definitely government facilities/offices. Under the legal doctrine of extraterritoriality, the embassy or consulate is considered to be located in the sending country for purposes of legal jurisdiction. Extraterritoriality is virtually unlimited in the case of an embassy; it is more limited in the case of a consulate but still exists. Thus office=government, government=[diplomatic, consular}, diplomatic=[embassy, high_commission, nunciature, legation, interests_section, branch_embassy, liaison_office] might be what we are looking for.
On 10/25/2018 2:24 PM, Colin Smale wrote:
On 2018-10-25 06:42, Graeme Fitzpatrick wrote:
On Thu, 25 Oct 2018 at 11:41, Warin <61sundowner (at)gmail.com: wrote:
Err no.
The 'government' is not 'foreign' but of federal/state/local jurisdiction to that place.
landuse=diplomatic???
Yes, but that patch of ground is owned by the "Australian" govt - it's just that it's located in the US or where-ever!
For the avoidance of doubt, it is owned by the "Australian govt" in the same sense that I own my house (but it may also be rented or leased). It is not outside of the host country's jurisdiction, if that's what you were implying by "owned".

On 10/26/2018 6:54 AM, Allan Mustard wrote:

On reflection landuse=* is probably not a good approach since many embassies and consulates are not stand-alone buildings on a parcel of land, but rather are offices in an office building (flats in a block of flats as Andrew wrote). See for example the Embassy of Qatar in Ashgabat, which occupies office space in a business center, and is mapped as a node (point) inside the way that represents the business center. It is one of many (there are two more in that business center). The business center at the Ak Altyn Hotel houses three embassies. Each is a node inside the way that is the business center.
apm-wa
On 10/25/2018 4:53 PM, Andrew Hain wrote:
Embassies that extend over multiple sites or are neighbours (the embassies of Ecuador and Colombia in London are flats in a block of flats) don’t correspond to the normal meaning of the landuse tag.
--
Andrew
From: Allan Mustard <allan (at)mustard.net:
Sent: 25 October 2018 02:25:07
To: tagging (at)openstreetmap.org
Subject: [Tagging] Feature Proposal - RFC - (consulate)
I like Graeme's idea. Round peg in round hole. How would people feel about modifying the current Consulate proposal to encompass this? Or should I leave the proposal for amenity=consulate as it is?
On 10/25/2018 3:13 AM, Graeme Fitzpatrick wrote:
Just had a thought :-)
Would this work under the landuse=government / civic_admin / public_admin that was being discussed t'other day?
Maybe something like:
landuse=government
government=diplomatic (rendering with the current "embassy" flag)
diplomatic=embassy / consulate etc
services=visa; passport etc
Thanks
Graeme

25 October 2018

On 10/25/2018 3:13 AM, Graeme Fitzpatrick wrote:

Just had a thought :-)
Would this work under the landuse=government / civic_admin / public_admin that was being discussed t'other day?
Maybe something like:
landuse=government
government=diplomatic (rendering with the current "embassy" flag)
diplomatic=embassy / consulate etc
services=visa; passport etc
Thanks
Graeme

On 10/25/2018 2:36 AM, Warin wrote:

I think of it as the miscellaneous folder of OSM, if it cannot fit anywhere else it goes in here. The 'I give up' option.

On 10/25/2018 1:54 AM, Paul Allen wrote:

On Wed, Oct 24, 2018 at 9:40 PM Warin <61sundowner (at)gmail.com:wrote:
On 25/10/18 02:52, Paul Allen wrote:
An alternative ... just use the diplomatic key alone.
I could live with that. I think. I have a vague feeling of unease about it, for some reason I can't put :my finger on. Maybe because it's an adjective and I think of keys as being nouns. Problem is, diplomat=embassy would be silly.
I'm not happy with service:*=* acting as distinctions as service is used elsewhere for other things.
It complicates editors as they have to do selective matching to figure out which particular
service:* tags to offer up with a particular main tag.
Humm the 'sells' tag has the same problem.
That doesn't mean we should compound the error. Each time something like sells is used the editor has to have special-case code to handle it properly. Or it just offers every possible sells=* even when most are inappropriate in that context, which leads to errors and confusion.
Free form entry is a reasonable way around this .. at least until some use has been made of it to see what is 'frequent' in use.
AKA "I wish we'd thought this through properly back in the beginning instead of ending up with a mix of :incompatible tagging methods because people invent random stuff." That's how we ended up with amenity=embassy...

Paul

On 10/25/2018 1:51 AM, Kevin Kenny wrote:

I'm not going to worry too much about that particular tagging. 'amenity=*' is so overloaded in OSM (amenity=prison? Really?) that it can't possibly get any worse. Since I already have to account for a great many different sorts of cases when processing 'amenity=*' for rendering or analysis, one more would be lost in the noise. I tend to think of OSM's 'amenity' as having a meaning not too far removed from 'thing'.

24 October 2018

On 10/24/2018 9:50 PM, Paul Allen wrote:

On Wed, Oct 24, 2018 at 5:27 PM Allan Mustard <allan (at)mustard.net: wrote:
I have no idea why amenity=embassy first came into existence.
The usual reasons. Somebody needed to tag an embassy, couldn't find a documented way of
doing it so used the first tag that came to mind.
There is another proposal to create amenity=diplomatic and then use the diplomatic=* tag to define more precisely what type of facility an object is. I have added it to the proposal wiki, but assume you would not like it, either.
Not under amenity, no. Maybe it works for other people, but my mental map of what constitutes
an amenity doesn't include embassies and consulates. Even though embassies and consulates
both sometimes hold parties.
Paul, are you proposing office=diplomatic and diplomatic=[embassy, mission, nunciature, consulate, consulate_general, consular agency, honorary_consul], or something else?
Something along those lines. I'm not sure office is a good fit either. We have amenity=doctors
and office=doctor but there are attempts to move those under healthcare, which I think is a better
way of handling them. I definitely don't like amenity here and office is only slightly better. A better
fit would be diplomatic_mission=consulate|embassy|nunciate|whatever but underscores in keys
seem to be out of favour. Is there another encompassing term?
As for objection to the service=* tag, would a new consular:*=* tag be a better solution? Just asking. I'm not well versed in programing editors. It would be something like consular:immigrant_visas=yes, consular:nonimmigrant_visas=yes, consular:citizen_services=yes, etc.
Only if there is no need for an equivalent embassy: tag. That is everything that need be dealt with
for an embassy is listing which consular functions it also performs (if any). This assumes an
underlying model where an embassy can (but may not) do anything a consulate can but all
embassies have the same non-consular functions. Otherwise, if we had an all-encompassing
term like diplomatic_mission=* we could then have diplomatic_mission:citizen_services=yes. Or
something like that. I'm making this up as I go along. :)
As for whether embassies serve "any purpose other than housing spies," as a diplomat now for over 30 years, I can assure you that at least in the case of U.S. embassies, we diplomats do a lot more than that.
That's how it worked until recent times. Now diplomacy-by-tweet seems to be the norm in the US. :(
However, your experience does mean you have a good idea of what the tagging scheme needs to
cover so it can be made coherent and possibly anticipate future needs. It's always a pain to introduce
a new way of doing things and then find out a year down the line that it can't handle something.
--
Paul

On 10/24/2018 9


27 PM, Allan Mustard wrote:
Well, at the moment the question as articulated in the wiki is whether to split the existing amenity=embassy (which encompasses both embassies and consulates) into amenity=embassy and amenity=consulate. If in the view of the OSM community amenity=consulate is inappropriate, then logically so is amenity=embassy, and we need a new proposal to change it. I have no idea why amenity=embassy first came into existence. There is another proposal to create amenity=diplomatic and then use the diplomatic=* tag to define more precisely what type of facility an object is. I have added it to the proposal wiki, but assume you would not like it, either.

Paul, are you proposing office=diplomatic and diplomatic=[embassy, mission, nunciature, consulate, consulate_general, consular agency, honorary_consul], or something else? I'll be happy to add your proposal to the list of counterproposals on the wiki and promote discussion of it.

As for objection to the service=* tag, would a new consular:*=* tag be a better solution? Just asking. I'm not well versed in programing editors. It would be something like consular:immigrant_visas=yes, consular:nonimmigrant_visas=yes, consular:citizen_services=yes, etc.

As for whether embassies serve "any purpose other than housing spies," as a diplomat now for over 30 years, I can assure you that at least in the case of U.S. embassies, we diplomats do a lot more than that. Please take a look at the integrated country strategy of my embassy, here: https://www.state.gov/documents/organization/285262.pdf for a taste of what a small U.S. embassy does. The larger U.S. embassies do much more. I cannot speak for the embassies of other nations.

On 10/24/2018 8:52 PM, Paul Allen wrote:

On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard <allan (at)mustard.net> wrote:
Please do continue to comment and to offer suggestions, and to pose questions.

This is pretty much based on gut feelings and may be partially or completely wrong...

I don't think "amenity" is a suitable tag for a consulate. Amenities are parks, or toilets, or similar. "Should we go to the park or the consulate for a picnic today?" "I'm busting for a crap, where's the nearest consulate?" And I'm damned sure an embassy isn't an amenity (I'm not even sure, in these days of telecommunications, if it serves any purpose other than housing spies, but if heads of state do still use embassies for formal communication between governments they're definitely not amenities).

Embassies and consulates seem a slightly better fit in office=government, but still a square peg with the corners filed down a little trying to fit into a round hole.

I'm not happy with service:*=* acting as distinctions as service is used elsewhere for other things. It complicates editors as they have to do selective matching to figure out which particular service:* tags to offer up with a particular main tag. It is also less easy to comprehend at a glance. I'd say diplomatic=* is a better way to go because it is more obvious and easier for editors.

I don't know what the answer is, all I can say is I'm not overly happy with what has been suggested so far.

-- Paul

Tagging Digest, Vol 109, Issue 136

Message: 2 Date: Wed, 24 Oct 2018 21:47:09 +1100 From: Warin <61sundowner (at)gmail.com>

On 24/10/18 20:50, Martin Koppenhoefer wrote:


Am Mi., 24. Okt. 2018 um 03:48 Uhr schrieb Allan Mustard <allan (at)mustard.net <mailto:allan (at)mustard.net>>:

One of the commenters has suggested an additional tag indicating
what services a consulate or embassy provides, and that is one
option. Not all consulates or consular sections of embassies
offer all visa types, for example. The existent service=* tag
could possibly be used. For example, one could add to either a
consulate or an embassy the tag service=[citizen services;
notarials; apostiles; immigrant visas; non-immigrant visas].
Thoughts?

the service tag is already used for several different purposes (e.g. subtype of service road, subtype of service rail), which creates some inconvenience for data consumers (it is not necessarily a big problem, but some people have denounced this in the past) and as the services offered by a consulate will likely be more than one, I would suggest using a scheme like we use for payment or available fuels, i.e. a property list of yes/no (no is usually omitted), see here for reference: https://wiki.openstreetmap.org/wiki/Key:payment

For consulates, using the examples you gave, this would translate to: service:notarials=yes service:apostiles=yes service:immigrant_visas=yes service:non-immigrant_visas=yes etc.

Or (if there are only two types of visas), you could also combine the latter two to service:visas=immigrant / non-immigrant / both / yes (if you don't know which types) / no (no visas at all)

These headstands are applied to avoid multiple values for the same key, and are required because keys must be unique in OSM.

You can add these suggested properties to your proposal, but you could also put them in another proposal (if you believe there is support for amenity=consulate but the tags about offered services could be disputed).

As these services are also available at some other 'embassies' they should get there own proposal so they can be used in things like 'consulate_general', 'mission' etc.

For visas I'd go simple .. service:via=yes/no/* There will be multiple types for different countries .. sorting through them will be too much for most, yes and no will probably be the most popular and useful.

Still think best to have all these embassies/consulates/etc under one tag - the renders can then use the same symbol for all of them .. like they did for shops until they got inventive. The same will happen here, eventually consulates will be separated from embassies.

Message: 3 Date: Wed, 24 Oct 2018 21:50:56 +1100 From: Warin <61sundowner (at)gmail.com> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <ec70bf31-e4cf-3337-3b58-54b84e853ffc (at)gmail.com> Content-Type: text/plain; charset="utf-8"; Format="flowed"

Very happy to have left it alone!

I'll wait for awhile before I tag it. At present it looks like it might get diplomatic=mission

On 24/10/18 20:08, Allan Mustard wrote:
Nuncios are specifically named in the Vienna Convention on Diplomatic Relations, as are envoys, ministers, and chargés d’affaires:
  • Article 14*
1.Heads of mission are divided into three classes, namely:
(a) That of ambassadors or nuncios accredited to Heads of State, and other heads of mission of equivalent rank;
(b) That of envoys, ministers and internuncios accredited to Heads of State;
(c) That of chargés d’affaires accredited to Ministers for Foreign Affairs.
Tue, 23 Oct 2018 20:36:02 -0400 Kevin Kenny <kevin.b.kenny (at)gmail.com
<mailto:kevin.b.kenny (at)gmail.com>> wrote:
The Holy See is sovereign, so its nunciatures are embassies by another name.
On Tue, Oct 23, 2018 at 8:20 PM Warin <61sundowner (at)gmail.com
<mailto:61sundowner (at)gmail.com>> wrote:
Umm .. here is some sort of exception.
"Apostolic Nunciature of The Holy See" ...
Ok .. what is it (in OSM terms)? Presently in the data base as amenity=embassy

Tagging Digest, Vol 109, Issue 134

Message: 1 Date: Tue, 23 Oct 2018 23:30:31 +0200 From: Colin Smale <colin.smale (at)xs4all.nl> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <db118d80665373702af28749e9e492ea (at)xs4all.nl> Content-Type: text/plain; charset="utf-8"

On 2018-10-23 23:15, Paul Allen wrote:

An embassy must be tagged/taggable to indicate whether it also offers consular services such as visas. The proposal wiki contains a suggestion to use services [1]=visa;passport;refuge;ticket_home etc. An embassy offering none these consular services will need to be tagged services=none to prevent interpretation of a missing services=* tag as "unknown" or "all services".


Message: 4 Date: Wed, 24 Oct 2018 11:19:26 +1100 From: Warin <61sundowner (at)gmail.com> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <fc7347c8-b63e-cd57-e088-be332a1d0b72 (at)gmail.com> Content-Type: text/plain; charset=windows-1251; format=flowed

Umm .. here is some sort of exception.

"Apostolic Nunciature of The Holy See" ...

Ok .. what is it (in OSM terms)? Presently in the data base as amenity=embassy

Message: 5 Date: Tue, 23 Oct 2018 20:36:02 -0400 From: Kevin Kenny <kevin.b.kenny (at)gmail.com> To: "Tag discussion, strategy and related tools" <tagging (at)openstreetmap.org> Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <CALREZe8acRoqtgVveD++xFfyb7jWBQWrtWzSJZSAO0DdvaSH5g (at)mail.gmail.com> Content-Type: text/plain; charset="utf-8"

The Holy See is sovereign, so its nunciatures are embassies by another name.

On Tue, Oct 23, 2018 at 8:20 PM Warin <61sundowner (at)gmail.com> wrote:

Umm .. here is some sort of exception.

"Apostolic Nunciature of The Holy See" ...

Ok .. what is it (in OSM terms)? Presently in the data base as amenity=embassy

Message: 6 Date: Wed, 24 Oct 2018 06:46:57 +0500 From: Allan Mustard <allan (at)mustard.net> To: tagging (at)openstreetmap.org Subject: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <5bcc4920-6ffb-0321-b3ac-86c5cd0c12e8 (at)mustard.net> Content-Type: text/plain; charset="cp1251"

One of the commenters has suggested an additional tag indicating what services a consulate or embassy provides, and that is one option. Not all consulates or consular sections of embassies offer all visa types, for example. The existent service=* tag could possibly be used. For example, one could add to either a consulate or an embassy the tag service=[citizen services; notarials; apostiles; immigrant visas; non-immigrant visas]. Thoughts? 

   From: Colin Smale <colin.smale (at)xs4all.nl>

   One further thought... There is also a big functional difference
   between an embassy and a consulate. The former is more
   government-oriented, whereas consulates provide services to
   individual citizens. I know this is a big generalisation, but I hope
   you will agree there is an important difference. BUT some embassies
   also provide consular services, and some don't - they might direct
   you to another address for your visa or whatever. If we tag
   embassies and consulates distinctly, how do we add a secondary tag
   to an embassy to indicate whether they do consular work or not?

Tagging Digest, Vol 109, Issue 133

Message: 1 Date: Tue, 23 Oct 2018 22:55:58 +0500 From: Allan Mustard <allan (at)mustard.net> To: tagging (at)openstreetmap.org Subject: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <f1e8203e-692b-723d-14cb-9d727f309aa7 (at)mustard.net> Content-Type: text/plain; charset="cp1251"

Colin Smale <colin.smale (at)xs4all.nl> wrote:

The location of an embassy in the capital is surely not prescribed by law, but by expedience isn't it? The ambassador wants/needs to be near the action in order to carry out their primary role - interfacing with the host country government. Answer: Yes. The location of an embassy is typically negotiated with the host country government and is indeed a matter of expedience in most cases.

There are also examples of countries with split capitals. I am in one now (Netherlands) - the capital is Amsterdam, but the embassies are in The Hague, which is the seat of government but not the capital. Answer: Yes, there are exceptions to every rule! That's why defining an embassy as the mission where one finds an ambassador is the easiest and most reliable way of defining an embassy. To the casual observer, an embassy is a building with a sign on it that reads "Embassy" (as long as it isn't a Embassy Suites Hotel or something similar) and a consulate is a building with a sign containing the word "Consulate".

Why is the location even relevant to this discussion, anyway? Answer: Because in the OSM space there is confusion of embassies and consulates. A consulate is not an embassy, but in OSM the amenity=embassy tag is applied to consulates. I am proposing to correct that, and to do that, mappers must understand both the differences between an embassy and a consulate and how to differentiate between them. Thanks for your help!

Message: 2 Date: Tue, 23 Oct 2018 20:17:01 +0200 From: Colin Smale <colin.smale (at)xs4all.nl> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <c4b7412dab813482c19325fe50db4c2a (at)xs4all.nl> Content-Type: text/plain; charset="utf-8"

One further thought...

There is also a big functional difference between an embassy and a consulate. The former is more government-oriented, whereas consulates provide services to individual citizens. I know this is a big generalisation, but I hope you will agree there is an important difference. BUT some embassies also provide consular services, and some don't - they might direct you to another address for your visa or whatever. If we tag embassies and consulates distinctly, how do we add a secondary tag to an embassy to indicate whether they do consular work or not?

Message: 3 Date: Tue, 23 Oct 2018 20:27:04 +0200

Message: 4 Date: Tue, 23 Oct 2018 19:50:05 +0100 From: Paul Allen <pla16021 (at)gmail.com> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <CAPy1dOJRVQh1OYLgOOEbA3_AKrrHNd9JBrjbPpEA8DY94ZLH4Q (at)mail.gmail.com> Content-Type: text/plain; charset="utf-8"

On Tue, Oct 23, 2018 at 7:18 PM Colin Smale <colin.smale (at)xs4all.nl> wrote:

I know this is a big generalisation, but I hope you will agree there is an important difference. An even bigger difference is that Consulate have a menthol filter but Embassy have a plain filter.

I don't recall ever seeing a brand of cigarette called "Legation" though. -- Paul

Message: 5 Date: Tue, 23 Oct 2018 22:20:05 +0200 From: Colin Smale <colin.smale (at)xs4all.nl> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <32529aaa278e2621e55a3bc0af53476e (at)xs4all.nl> Content-Type: text/plain; charset="utf-8"

What's your point, Paul?

Message: 6 Date: Tue, 23 Oct 2018 22:15:06 +0100 From: Paul Allen <pla16021 (at)gmail.com> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <CAPy1dOKB=5fuMVoy=HukdNc0GBvGNHv=ufAJMuN92i-x-nECUw (at)mail.gmail.com> Content-Type: text/plain; charset="utf-8"

That there are distinctions between embassies and consulates. And that some of us are old enough to remember them. And that that those memories are repeatedly triggered by every post in this thread. And that I have a crappy sense of humour. -- Paul

Tagging Digest, Vol 109, Issue 132

Message: 1 Date: Tue, 23 Oct 2018 18:57:22 +0500 From: Allan Mustard <allan (at)mustard.net> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <3a59f9d8-b687-349e-4264-01586fe07c40 (at)mustard.net> Content-Type: text/plain; charset="cp1251"

Please continue to comment on this proposal:

https://wiki.openstreetmap.org/wiki/Proposed_features/Consulate

I have posted comments received via the tagging mailing list to the discussion page of this proposal:

https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Consulate

Please feel free to add comments either directly to the discussion page or via the tagging mailing list.

Regarding Warin's comment,

They did conform to the 'rule' of embassy/high commission only in the capital.

There is a small number of highly visible exceptions to the rule of embassies and of missions equivalent to embassies being located in the capital. The various missions of member states to the United Nations in New York and Geneva as well as the missions to the WTO in Geneva come to mind (these are all missions to a multilateral organization). Fortunately most other such international organizations are located in national capitals (OECD in Paris, NATO and the European Union in Brussels, OSCE and some UN agencies in Vienna, other UN agencies in Rome). The easy way to determine if a mission is equivalent to an embassy is to find out who is in charge of it, which can be learned by Googling the mission's website. Generally speaking, if the head of the mission is an ambassador or charge d'affaires, the mission should be tagged amenity=embassy. If the "principal officer" bears a title with the word "consul" in it, the amenity in question is a consulate. The obsolete head of mission titles "minister plenipotentiary" and "envoy extraordinary" have fallen into disuse and I don't think it likely we will encounter them.

I am tempted to add some text to the Key:amenity=embassy article outlining exactly what an embassy is and how to recognize one, since an embassy can be called different things (embassy, nunciature, mission, legation, high commission, etc.) depending on who is sending it and to whom it is accredited.


next part --------------

An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181023/a75b731f/attachment-0001.html>

Message: 2 Date: Tue, 23 Oct 2018 16:08:54 +0200 From: Johnparis <okosm (at)johnfreed.com> To: "Tag discussion, strategy and related tools" <tagging (at)openstreetmap.org> Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <CAEVvu1OthLOXXa2Dy7JiVnRYk5F-93Uk7Su1OfpSvrRJ5i0wZA (at)mail.gmail.com> Content-Type: text/plain; charset="utf-8"

I believe there is already a list of embassy types on the wiki :

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dembassy#Types_of_embassies

You might want to verify/expand as needed.

On Tue, Oct 23, 2018 at 3:58 PM Allan Mustard <allan (at)mustard.net> wrote:

Please continue to comment on this proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Consulate
I have posted comments received via the tagging mailing list to the discussion page of this proposal:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Consulate
Please feel free to add comments either directly to the discussion page or via the tagging mailing list.
Regarding Warin's comment,
They did conform to the 'rule' of embassy/high commission only in the capital.
There is a small number of highly visible exceptions to the rule of embassies and of missions equivalent to embassies being located in the capital. The various missions of member states to the United Nations in New York and Geneva as well as the missions to the WTO in Geneva come to mind (these are all missions to a multilateral organization). Fortunately most other such international organizations are located in national capitals (OECD in Paris, NATO and the European Union in Brussels, OSCE and some UN agencies in Vienna, other UN agencies in Rome). The easy way to determine if a mission is equivalent to an embassy is to find out who is in charge of it, which can be learned by Googling the mission's website. Generally speaking, if the head of the mission is an ambassador or charge d'affaires, the mission should be tagged amenity=embassy. If the "principal officer" bears a title with the word "consul" in it, the amenity in question is a consulate. The obsolete head of mission titles "minister plenipotentiary" and "envoy extraordinary" have fallen into disuse and I don't think it likely we will encounter them.
I am tempted to add some text to the Key:amenity=embassy article outlining exactly what an embassy is and how to recognize one, since an embassy can be called different things (embassy, nunciature, mission, legation, high commission, etc.) depending on who is sending it and to whom it is accredited.


_______________________________________________ Tagging mailing list Tagging (at)openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Message: 3 Date: Tue, 23 Oct 2018 16:56:41 +0200 From: Colin Smale <colin.smale (at)xs4all.nl> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <fef7676e802694d2a137d58bffba023e (at)xs4all.nl> Content-Type: text/plain; charset="utf-8"

On 2018-10-23 15:57, Allan Mustard wrote:

Regarding Warin's comment,
They did conform to the 'rule' of embassy/high commission only in the capital.
There is a small number of highly visible exceptions to the rule of embassies and of missions equivalent to embassies being located in the capital. The various missions of member states to the United Nations in New York and Geneva as well as the missions to the WTO in Geneva come to mind (these are all missions to a multilateral organization). Fortunately most other such international organizations are located in national capitals (OECD in Paris, NATO and the European Union in Brussels, OSCE and some UN agencies in Vienna, other UN agencies in Rome). The easy way to determine if a mission is equivalent to an embassy is to find out who is in charge of it, which can be learned by Googling the mission's website. Generally speaking, if the head of the mission is an ambassador or charge d'affaires, the mission should be tagged amenity=embassy. If the "principal officer" bears a title with the word "consul" in it, the amenity in question is a consulate. The obsolete head of mission titles "minister plenipotentiary" and "envoy extraordinary" have fallen into disuse and I don't think it likely we will encounter them.

The location of an embassy in the capital is surely not prescribed by law, but by expedience isn't it? The ambassador wants/needs to be near the action in order to carry out their primary role - interfacing with the host country government.

There are also examples of countries with split capitals. I am in one now (Netherlands) - the capital is Amsterdam, but the embassies are in The Hague, which is the seat of government but not the capital.

Why is the location even relevant to this discussion, anyway?

Tagging Digest, Vol 109, Issue 130

Message: 2 Date: Tue, 23 Oct 2018 09:21:25 +1100 From: Warin <61sundowner (at)gmail.com> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <c26887dc-d0a2-1817-c739-53110d975385 (at)gmail.com> Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 22/10/18 21:32, Martin Koppenhoefer wrote: Am Mo., 22. Okt. 2018 um 01:17В Uhr schrieb Johnparis <okosm (at)johnfreed.com <mailto:okosm (at)johnfreed.com>>:

I guess this means I am leaning towards Warin's argument. There are only 445 objects tagged amenity=embassy (if I read Taginfo correctly) so this would be pretty simple.

as of now there are almost 11500 amenity=embassy https://taginfo.openstreetmap.org/tags/amenity=embassy


Very few of them have the tag diplomatic=* !!!!

So I looked in 'my' area .. most of them did not have diplomatic=*.

So I have added the tag diplomatic based on the location (capital/non capital) and the content of the name (embassy/high commission/consulate general/consulate). 95 have been tagged embassy/high_commission in the capital. And I have added some 33 consulates, 55 consulate generals. They did conform to the 'rule' of embassy/high commission only in the capital.

Looks to be a relatively simple job... I don't think there should be any problem to adding the diplomatic tag as I have done using the information all ready available in OSM, but for safety checked with the locality.

Tagging Digest, Vol 109, Issue 126

Message: 2 Date: Mon, 22 Oct 2018 16:10:19 +1100 From: Warin <61sundowner (at)gmail.com: To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <99fd0cda-a002-1a6b-7779-92b787765b6c (at)gmail.com: Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 22/10/18 09:56, Graeme Fitzpatrick wrote:

On Mon, 22 Oct 2018 at 08:42, Warin <61sundowner (at)gmail.com <mailto:61sundowner (at)gmail.com:: wrote:
I would opt for; depreciating amenity=embassy .. as they are used for embassies, consulates etc .. so you don't know what they are (unless it has a detailed sub tag) introducing amenity=diplomatic and use the sub tag diplomatic=* to detail what it is - embassy/consulate/*
Yep, straight-forward & simple :-)

I fit in with 'simple' .

I just looked at some amenity=embassy around me .. probably added a fair few of them myself. Few of them have any diplomatic=*.

So I searched on consulate general .. and got 55 with that in their name, so being fairly certain they are in fact consulate generals I add the tag diplomatic=consulate_general, 55 of them. I'll check the others later.

Message: 4 Date: Mon, 22 Oct 2018 12:32:11 +0200 From: Martin Koppenhoefer <dieterdreist (at)gmail.com> To: "Tag discussion, strategy and related tools" Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: CABPTjTC1Y3EH_zJSdq7UvyTeN5hSfs-J=S_4doL8TjctmmGp-w (at)mail.gmail.com Content-Type: text/plain; charset="utf-8"

Am Mo., 22. Okt. 2018 um 01:17 Uhr schrieb Johnparis <okosm (at)johnfreed.com>:

I guess this means I am leaning towards Warin's argument. There are only 445 objects tagged amenity=embassy (if I read Taginfo correctly) so this would be pretty simple.

as of now there are almost 11500 amenity=embassy https://taginfo.openstreetmap.org/tags/amenity=embassy

Cheers, Martin

Tagging Digest, Vol 109, Issue 123

Message: 1 Date: Mon, 22 Oct 2018 10:14:50 +1100 From: Warin <61sundowner (at)gmail.com: To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <9f6fb324-2041-8d28-3884-9dc2f1e78a9f (at)gmail.com: Content-Type: text/plain; charset="utf-8"; Format="flowed"

That should be possible - it would come up with both tags - amenity=diplomatic with diplomatic=embassy, or amenity=diplomatic with diplomatic=consulate

If you type 'tennis' what does ID come up with? sport=tennis with a selection of leisure=pitch, or something=sports_centre ..

On 22/10/18 09:54, Joseph Eisenberg wrote:

As a new mapper, I would not have though to type “diplomatic” when searching for a tag for an embassy or consulate. It’s nice if mappers can just type “embassy” or “consulate” into the ID editor and have it pop up.
So I like amenity=consulate
On Mon, Oct 22, 2018 at 7:42 AM Warin <61sundowner (at)gmail.com
<mailto:61sundowner (at)gmail.com:: wrote:
On 22/10/18 09:09, Martin Koppenhoefer wrote:
:
: sent from a phone
:
:: On 21. Oct 2018, at 19:20, Johnparis <okosm (at)johnfreed.com <mailto:okosm (at)johnfreed.com wrote:
::
:: Question : there is existing tagging for such places, specifically
::
:: amenity=embassy + diplomatic=consulate
::
:: Frankly, I have never been happy with this tagging because a
consulate isn't really a subset of an embassy. It's a different
sort of animal, but related. Same genus, different species if you
will.
:
: I agree. I am fine with the proposed tagging by Alan.
The proposed addition of amenity=consulate then conflicts with the
present definition of amenity=embassy - both would be available to
tag a consulate!!!
:
: Shifting both, embassies and consulates under a diplomatic main
key would require retagging of both, embassies and consulates, but
the embassies are already tagged ok.
At present all embassies and consulates can be and at least some
are tagged as amenity=embassy!
There is no distinction with the present OSM wiki definition of
amenity=embassy.
:
: Also from a practical point of view, it is faster to type one
tag than two.
Certainly. Faster again to type nothing. Mappers who want to add
detail will do so.
: If a map renderer doesn’t want to distinguish between the two,
it can use the bare amenity=diplomatic as long as people are using
it together with diplomatic=passport_check or something like this
(think tourism=information), and will have to look for
diplomatic=embassy as well, so they could in the first place
change their rule to “amenity is embassy or consulate”, and be
future proof
That would require typing of more than one tag.
Do you want fast?
Then you will need one tag that says all you want ... one tag for
a consulate that does vias, another tag for a consulate that does
not do visas .. etc etc..
Reality: more than one tag would be required to have a system that
is not litered with one tags that do so much detail.
-------------------
I would opt for;
depreciating amenity=embassy .. as they are used for embassies,
consulates etc .. so you don't know what they are (unless it has a
detailed sub tag)
introducing amenity=diplomatic and use the sub tag diplomatic=* to
detail what it is - embassy/consulate/*

Message: 2 Date: Mon, 22 Oct 2018 01:15:57 +0200 From: Johnparis <okosm (at)johnfreed.com: To: "Tag discussion, strategy and related tools" <tagging (at)openstreetmap.org: Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <CAEVvu1MnKmeSv39a3YX-+R_shXVtKj3QwdrP9t=B0Ek7SXDERg (at)mail.gmail.com: Content-Type: text/plain; charset="utf-8"

The ID preset is a separate issue; presumably this would be easily changed by the ID developer once the tag is agreed.

The "diplomatic" subtag already exists under amenity=embassy, so creating a top-level amenity=diplomatic suits the logic side of my brain, but I don't feel strongly about this. Both Warin's and Martin's arguments make sense to me.

In either case, all the consulates would need to be retagged (which I think is a good idea). So the only question is whether to leave embassies as separate animals. Either way the *current usage* of amenity=embassy (as documented in the wiki) would need an overhaul, so perhaps a new tag would make things clearer.

I guess this means I am leaning towards Warin's argument. There are only 445 objects tagged amenity=embassy (if I read Taginfo correctly) so this would be pretty simple.

On Mon, Oct 22, 2018 at 12:55 AM Joseph Eisenberg < joseph.eisenberg (at)gmail.com: wrote:

As a new mapper, I would not have though to type “diplomatic” when
searching for a tag for an embassy or consulate. It’s nice if mappers can
just type “embassy” or “consulate” into the ID editor and have it pop up.
So I like amenity=consulate
On Mon, Oct 22, 2018 at 7:42 AM Warin <61sundowner (at)gmail.com: wrote:
On 22/10/18 09:09, Martin Koppenhoefer wrote:
sent from a phone
On 21. Oct 2018, at 19:20, Johnparis <okosm (at)johnfreed.com: wrote:
Question : there is existing tagging for such places, specifically
amenity=embassy + diplomatic=consulate
Frankly, I have never been happy with this tagging because a consulate
isn't really a subset of an embassy. It's a different sort of animal, but
related. Same genus, different species if you will.
I agree. I am fine with the proposed tagging by Alan.
The proposed addition of amenity=consulate then conflicts with the
present definition of amenity=embassy - both would be available to tag a
consulate!!!
Shifting both, embassies and consulates under a diplomatic main key
would require retagging of both, embassies and consulates, but the
embassies are already tagged ok.
At present all embassies and consulates can be and at least some are
tagged as amenity=embassy!
There is no distinction with the present OSM wiki definition of
amenity=embassy.
Also from a practical point of view, it is faster to type one tag than
two.
Certainly. Faster again to type nothing. Mappers who want to add detail
will do so.
If a map renderer doesn’t want to distinguish between the two, it can
use the bare amenity=diplomatic as long as people are using it together
with diplomatic=passport_check or something like this (think
tourism=information), and will have to look for diplomatic=embassy as well,
so they could in the first place change their rule to “amenity is embassy
or consulate”, and be future proof
That would require typing of more than one tag.
Do you want fast?
Then you will need one tag that says all you want ... one tag for a
consulate that does vias, another tag for a consulate that does not do
visas .. etc etc..
Reality: more than one tag would be required to have a system that is not
litered with one tags that do so much detail.
-------------------
I would opt for;
depreciating amenity=embassy .. as they are used for embassies,
consulates etc .. so you don't know what they are (unless it has a detailed
sub tag)
introducing amenity=diplomatic and use the sub tag diplomatic=* to detail
what it is - embassy/consulate/*

Tagging Digest, Vol 109, Issue 120

Message: 4 Date: Sun, 21 Oct 2018 18:25:06 +0000 (UTC) From: Jerry Clough - OSM <sk53_osm (at)yahoo.co.uk> To: tagging (at)openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <694681522.20789466.1540146306797 (at)mail.yahoo.com> Content-Type: text/plain; charset="utf-8"

It looks as though the key in use is diplomatic in conjunction with amenity=embassy.

There are several mapped in the Brazilian city of Curitiba. The reason I'm aware of these was that a friend was the Polish consul during the early 1990s.

Jerry

Tagging Digest, Vol 109, Issue 119

Message: 1 Date: Sun, 21 Oct 2018 19:20:16 +0200 From: Johnparis <okosm (at)johnfreed.com> To: "Tag discussion, strategy and related tools" <tagging (at)openstreetmap.org> Subject: Re: [Tagging] Feature Proposal - RFC - (consulate) Message-ID: <CAEVvu1OWJoF4pQuH8Bs0DFTKUhBcr70cHmaE1auGAATVxn6=qw (at)mail.gmail.com> Content-Type: text/plain; charset="utf-8"

To answer the question from Mateusz, most consulates have a plaque outside with the name, such as "Consulat de Mali", and they are physically separate from the embassies even in cities (like Paris, where I live) where a country might have both (such as the USA does).

Question : there is existing tagging for such places, specifically

amenity=embassy + diplomatic=consulate

Frankly, I have never been happy with this tagging because a consulate isn't really a subset of an embassy. It's a different sort of animal, but related. Same genus, different species if you will.

It would make more sense to me, if you were to make a change at the top level, to do this:

amenity=diplomatic + diplomatic=embassy for embassies amenity=diplomatic + diplomatic=consulate for consulates

This is more in keeping with the hierarchical structures of other tag types.

I see that "office=diplomatic" was proposed along these lines in 2010-11, on the theory that these are more offices than amenities, but frankly I think amenity is better, since those are supposedly things to help tourists, which consulates, at least, are specifically aimed at.

I don't really like amenity=consulate, but I do agree that it's better than the current amenity=embassy + diplomatic=consulate for consulates.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Office%3Ddiplomatic&oldid=2516122"