Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Voting is not yet open.  Warin asked that the comment period be extended
for another week, so I am acceding to his request. 

apm-wa

On 11/13/2018 7:41 PM, Sergio Manzi wrote:
>
> Thanks!
>
> ... but I don't see a voting section in
> https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic
>
> Is this because voting is not open yet?
>
> Sergio
>
>
> On 2018-11-13 15:26, 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
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Sergio Manzi]

Thanks!

... but I don't see a voting section in 
https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic

Is this because voting is not open yet?

Sergio


On 2018-11-13 15:26, 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
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Paul Allen]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Sergio Manzi]

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.
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Sergio Manzi]

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.
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Paul Allen]

On Tue, Nov 13, 2018 at 2:37 AM Warin <61sundow...@gmail.com> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

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.


Once that is past On 13/11/18 12:22, Allan Mustard wrote:


Warin, may I please remind you that in your message of 31 October you 
were the mapper who expressed great concern about loss of data?


On 11/13/2018 2:37 AM, Colin Smale wrote:


On 2018-11-12 22:00, Warin wrote:


On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no 
reason the inverse would not work. I'll add it.


I think there are too many things in the proposal. Keep it simple. 
Yes the 'extras' might sound nice but they add complexity and each 
one is a point that can lead to someone objecting to that specific 
thing and leading to enough no votes that it fails.


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.





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Warin, may I please remind you that in your message of 31 October you
were the mapper who expressed great concern about loss of data?

On 11/13/2018 2:37 AM, Colin Smale wrote:
>
> On 2018-11-12 22:00, Warin wrote:
>
>> On 13/11/18 01:07, Allan Mustard wrote:
>>> Not contrived at all in these days of tight budgets. I see no reason
>>> the inverse would not work. I'll add it.
>>
>> I think there are too many things in the proposal. Keep it simple.
>> Yes the 'extras' might sound nice but they add complexity and each
>> one is a point that can lead to someone objecting to that specific
>> thing and leading to enough no votes that it fails.
>
> 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.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Colin Smale]

On 2018-11-12 22:00, Warin wrote:

> On 13/11/18 01:07, Allan Mustard wrote: 
> 
>> Not contrived at all in these days of tight budgets. I see no reason the 
>> inverse would not work. I'll add it.
> 
> I think there are too many things in the proposal. Keep it simple. Yes the 
> 'extras' might sound nice but they add complexity and each one is a point 
> that can lead to someone objecting to that specific thing and leading to 
> enough no votes that it fails.

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.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no reason 
the inverse would not work. I’ll add it.


I think there are too many things in the proposal. Keep it simple. Yes 
the 'extras' might sound nice but they add complexity and each one is a 
point that can lead to someone objecting to that specific thing and 
leading to enough no votes that it fails.


Make the proposal on office=diplomatic only and it should pass.

Then, if you want pursue the other items individually. Personally I 
don't like lumping things together and then separating them at a lower 
level when it was separated before - I refer to the diplomatic=* tag 
that is in use now compared to the proposed diplomatic=embassy(includes 
high commission etc)/consulate (includes consulate general)/and some 
other thing that I don't recall.





Sent from my iPhone

On Nov 12, 2018, at 12:31 PM, Colin Smale > wrote:



On 2018-11-11 21:51, Graeme Fitzpatrick wrote:

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
It's possible I guess to have the inverse of that as well, where the 
embassy of e.g. France also houses the ambassador of e.g. Monaco, 
both being accredited to the same receiving nation? (contrived example)
If a mission "represents" multiple countries, and the services 
offered are different, how could that be tagged? Something like the 
full Embassy of A also housing consular services for B.
Possibly two OSM objects, one for the embassy of A and a separate 
node for the services on behalf of B?

___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Yes, the UK embassies act on behalf of nationals of the British
Commonwealth if they have no representation in country.  I'd not tag
that, either.  They already know it :-)

On 11/12/2018 2:36 PM, Warin wrote:
> On 12/11/18 18:31, Colin Smale wrote:
>>
>> On 2018-11-11 21:51, Graeme Fitzpatrick wrote:
>>
>>> 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
>>>  
>> It's possible I guess to have the inverse of that as well, where the
>> embassy of e.g. France also houses the ambassador of e.g. Monaco,
>> both being accredited to the same receiving nation? (contrived example)
>>  
>> If a mission "represents" multiple countries, and the services
>> offered are different, how could that be tagged? Something like the
>> full Embassy of A also housing consular services for B.
>>  
>> Possibly two OSM objects, one for the embassy of A and a separate
>> node for the services on behalf of B?
>>  
> I do know that in the past one diplomatic establishment will act for
> another where the other has no representatives in that country. E.g
> Commonwealth countries would usually try to help one another out. And
> I think Russia also substitutes for some other adjacent countries. The
> services offered varied depending of the countries and place. I'd not
> tag it.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Not contrived at all in these days of tight budgets. I see no reason the 
inverse would not work. I’ll add it.

Sent from my iPhone

> On Nov 12, 2018, at 12:31 PM, Colin Smale  wrote:
> 
>> On 2018-11-11 21:51, Graeme Fitzpatrick wrote:
>> 
>> 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
>>  
> It's possible I guess to have the inverse of that as well, where the embassy 
> of e.g. France also houses the ambassador of e.g. Monaco, both being 
> accredited to the same receiving nation? (contrived example)
>  
> If a mission "represents" multiple countries, and the services offered are 
> different, how could that be tagged? Something like the full Embassy of A 
> also housing consular services for B.
>  
> Possibly two OSM objects, one for the embassy of A and a separate node for 
> the services on behalf of B?
>  
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

On 12/11/18 18:31, Colin Smale wrote:


On 2018-11-11 21:51, Graeme Fitzpatrick wrote:

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
It's possible I guess to have the inverse of that as well, where the 
embassy of e.g. France also houses the ambassador of e.g. Monaco, both 
being accredited to the same receiving nation? (contrived example)
If a mission "represents" multiple countries, and the services offered 
are different, how could that be tagged? Something like the full 
Embassy of A also housing consular services for B.
Possibly two OSM objects, one for the embassy of A and a separate node 
for the services on behalf of B?
I do know that in the past one diplomatic establishment will act for 
another where the other has no representatives in that country. E.g 
Commonwealth countries would usually try to help one another out. And I 
think Russia also substitutes for some other adjacent countries. The 
services offered varied depending of the countries and place. I'd not 
tag it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Colin Smale]

On 2018-11-11 21:51, Graeme Fitzpatrick wrote:

> 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

It's possible I guess to have the inverse of that as well, where the
embassy of e.g. France also houses the ambassador of e.g. Monaco, both
being accredited to the same receiving nation? (contrived example) 

If a mission "represents" multiple countries, and the services offered
are different, how could that be tagged? Something like the full Embassy
of A also housing consular services for B. 

Possibly two OSM objects, one for the embassy of A and a separate node
for the services on behalf of B?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

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
> thetwo-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
>  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Graeme Fitzpatrick]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

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 2018-11-11 12:40, Allan Mustard wrote:
>>
>> Here, please take a look at the updated Tagging section of the
>> proposal and see if that solves the issue.  I include a link to the
>> Wikipedia article on ISO 3166-1 alpha-2 codes.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic#Tagging
>>
>> *Current Proposal:*
>>
>>   * establish formally the office
>> =diplomatic
>> 
>> 
>>  primary
>> tag/key value combination, with the following additional
>> (secondary and tertiary) tags:
>>   o diplomatic
>> =* with
>> key values of [embassy, consulate, liaison]
>>   + embassy
>> 
>> =*
>>  with
>> key values of [yes, high_commission, nunciature,
>> interests_section, mission, delegation, branch_embassy,
>> residence]
>>   + consulate
>> 
>> =*
>>  with
>> key values of {yes, consulate_general, consular_agency,
>> consular_office, honorary_consul]
>>   + liaison
>> 
>> =*
>>  with
>> key values of [liaison_office, representative_office,
>> subnational];
>>
>>   * establish formally diplomatic:services:*=[yes/no] additional
>> (tertiary) tag with the following options:
>>  o
>>   + diplomatic:services:non-immigrant_visas*=[yes/no]
>>   + diplomatic:services:immigrant_visas=[yes/no]
>>   + diplomatic:services:citizen_services=[yes/no]; and
>>
>>   * deprecate the amenity=embassy tag over a period of time.
>>
>> Additional tags routinely used would include:
>>
>>   * country =* where
>> * is thetwo-character ISO 3166-1 alpha-2 code
>> for the sending
>> country or organization or the generally accepted English acronym
>> for an international organization (e.g., UN, OSCE);
>>   * name =* where * is
>> the name of the mission;
>>   * target =* where *
>> is thetwo-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.
>>
>> and of course the address and other contact information.
>>
>>
>> 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...

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Sergio Manzi]

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 2018-11-11 12:40, Allan Mustard wrote:
>
> Here, please take a look at the updated Tagging section of the proposal and 
> see if that solves the issue.  I include a link to the Wikipedia article on 
> ISO 3166-1 alpha-2 codes.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic#Tagging
>
> *Current Proposal:*
>
>   * establish formally the office 
> =diplomatic 
> 
>  primary tag/key value combination, with the following additional (secondary 
> and tertiary) tags:
>   o diplomatic =* 
> with key values of [embassy, consulate, liaison]
>   + embassy 
> =*
>  with key values of [yes, high_commission, nunciature, interests_section, 
> mission, delegation, branch_embassy, residence]
>   + consulate 
> =*
>  with key values of {yes, consulate_general, consular_agency, 
> consular_office, honorary_consul]
>   + liaison 
> =*
>  with key values of [liaison_office, representative_office, subnational];
>
>   * establish formally diplomatic:services:*=[yes/no] additional (tertiary) 
> tag with the following options:
>  o
>   + diplomatic:services:non-immigrant_visas*=[yes/no]
>   + diplomatic:services:immigrant_visas=[yes/no]
>   + diplomatic:services:citizen_services=[yes/no]; and
>
>   * deprecate the amenity=embassy tag over a period of time.
>
> Additional tags routinely used would include:
>
>   * country =* where * is 
> thetwo-character ISO 3166-1 alpha-2 code 
> for the sending country or 
> organization or the generally accepted English acronym for an international 
> organization (e.g., UN, OSCE);
>   * name =* where * is the name 
> of the mission;
>   * target =* where * is 
> thetwo-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.
>
> and of course the address and other contact information.
>
>
> 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 

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Here, please take a look at the updated Tagging section of the proposal
and see if that solves the issue.  I include a link to the Wikipedia
article on ISO 3166-1 alpha-2 codes.

https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic#Tagging

*Current Proposal:*

  * establish formally the office
=diplomatic


 primary
tag/key value combination, with the following additional (secondary
and tertiary) tags:
  o diplomatic
=* with key
values of [embassy, consulate, liaison]
  + embassy

=*
 with
key values of [yes, high_commission, nunciature,
interests_section, mission, delegation, branch_embassy,
residence]
  + consulate

=*
 with
key values of {yes, consulate_general, consular_agency,
consular_office, honorary_consul]
  + liaison

=*
 with
key values of [liaison_office, representative_office,
subnational];

  * establish formally diplomatic:services:*=[yes/no] additional
(tertiary) tag with the following options:
  o
  + diplomatic:services:non-immigrant_visas*=[yes/no]
  + diplomatic:services:immigrant_visas=[yes/no]
  + diplomatic:services:citizen_services=[yes/no]; and

  * deprecate the amenity=embassy tag over a period of time.

Additional tags routinely used would include:

  * country =* where *
is thetwo-character ISO 3166-1 alpha-2 code
for the sending
country or organization or the generally accepted English acronym
for an international organization (e.g., UN, OSCE);
  * name =* where * is the
name of the mission;
  * target =* where * is
thetwo-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.

and of course the address and other contact information.


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
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

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
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Host might be a nicer word, but in diplo-speak it is possible to have a
different host from the entity to which the mission is accredited (think
of the various missions to the World Trade Organization in Geneva:
target=WTO, host=CH.

On 11/11/2018 11:49 AM, Graeme Fitzpatrick wrote:
>
>
> On Sun, 11 Nov 2018 at 12:34, 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.)
>
>
> Would "host" be a nicer word?
>
> But wouldn't it be covered by the name eg "Australian Embassy to Russia"?
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Colin Smale]

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___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

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.


Yes there should be some human oversight. But given that 'we' are 
oversighting it, there should be little error generation.

Such over sight can include;
does it make sense?
checking where it is?
is there a website for it?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Colin Smale]

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...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

On 11/11/18 17:49, Graeme Fitzpatrick wrote:



On Sun, 11 Nov 2018 at 12:34, 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.)


Would "host" be a nicer word?

But wouldn't it be covered by the name eg "Australian Embassy to Russia"?



Think you will find the name on the front of the embassy is "Australian 
Embassy" ... no to anything.


https://russia.embassy.gov.au/



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Graeme Fitzpatrick]

On Sun, 11 Nov 2018 at 12:34, 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.)
>

Would "host" be a nicer word?

But wouldn't it be covered by the name eg "Australian Embassy to Russia"?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

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.)
>
> On Sat, Nov 10, 2018 at 1:25 PM 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
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Eugene Alvin Villar]

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.)

On Sat, Nov 10, 2018 at 1:25 PM 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
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

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?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Martin Koppenhoefer]

sent from a phone

> 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 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Paul Allen]

On Sat, Nov 10, 2018 at 5:25 AM Allan Mustard  wrote:

>
> 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.
>

Go for it.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Office=visa_application would handle that.  Or office=company, 
company=visa_application. Such offices are not diplomatic facilities, but 
rather are commercial (they are contractors). Thus they don’t fit under 
office=diplomatic anyway and don’t fall under the scope of this proposal.  That 
said, if you want another week, that’s ok. 

Sent from my iPhone

> On Nov 10, 2018, at 2:20 PM, Warin <61sundow...@gmail.com> 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?
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

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?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Graeme Fitzpatrick]

As far as I'm concerned, it can go to vote!

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

I think I'm going to borrow your text and make it the last version of
the proposal, then put it to a vote.  Today marks two weeks, so we can
call a vote if everybody's ready.  I go back on the road Tuesday
afternoon for a few days so will be off the grid, good time to get started.

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, ].
>> 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В 
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[egil]

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, ].
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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Eugene Alvin Villar]

On Fri, Nov 2, 2018 at 3:12 AM 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,  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.
>
> My second preferred option is amenity=diplomatic + subtags if people are
> really not too keen on office=diplomatic.
>

My first preferred option has another good reason (especially compared to
my second-preferred option):
4. It allows a backwards-compatible migration path for existing objects
that are already tagged with amenity=embassy: just add the
office=diplomatic and diplomatic=* tags and then we can delete
amenity=embassy once enough tools and map renderers have support for the
new tagging scheme. This is much less disruptive than moving things to
amenity=diplomatic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Eugene Alvin Villar]

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, ].
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.

My second preferred option is amenity=diplomatic + subtags if people are
really not too keen on office=diplomatic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

I would envision it including the state-level representations plus the
various non-diplomatic "liaison offices" and "institutes" (e.g.,
American Institute in Taiwan) that are pseudo-embassies and in many
cases lack both diplomatic status and immunities.  So
diplomatic_representation would probably be a bridge too far.

On 11/1/2018 10:16 PM, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 1. Nov 2018, at 17:57, 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?
>
> +1, maybe “representation” could become “diplomatic_representation” or would 
> that be incorrect for some of them? I see it is unwieldy, but 
> “representation” alone can mean a link of things, so I would suggest to be 
> more verbose.
>
>
> Cheers,
> Martin
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

sent from a phone

> On 1. Nov 2018, at 17:57, 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?


+1, maybe “representation” could become “diplomatic_representation” or would 
that be incorrect for some of them? I see it is unwieldy, but “representation” 
alone can mean a link of things, so I would suggest to be more verbose.


Cheers,
Martin


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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 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
> mailto:selfishseaho...@gmail.com>> wrote:
>
> On Thu, 1 Nov 2018 at 09:41, Martin Koppenhoefer
> mailto:dieterdre...@gmail.com>> 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
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

Daniel, many thanks for this tip.  I had not seen this before!  It will
be useful.

Responses to the e-mail have been posted (with some consolidation to
avoid unnecessary duplication) to the discussion page
.
 
Any more thoughts?

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
>
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Daniel Koć]

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


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Johnparis]

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
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[SelfishSeahorse]

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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

sent from a phone

> On 1. Nov 2018, at 07: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.


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.


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

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.



Cheers,

John


On Thu, Nov 1, 2018 at 4:14 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
___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Johnparis]

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 Thu, Nov 1, 2018 at 4:14 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
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

Am Mi., 31. Okt. 2018 um 02:41 Uhr schrieb Allan Mustard :

> 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".
>


I agree that minor may not be a good term if we want everybody to embrace
the tag. In my opinion, "other" is not acceptable as a key for something as
specific as the subtype of diplomatic missions which aren't either
embassies nor consulates. It is far too broad. "other_mission" would come
close to "other" but would give some indication on the context (maybe there
remains some ambiguity, because "mission" is used in different context too).



> 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.
>


While I still don't see a problem with amenity (the key is currently a home
for monasteries, churches, temples, mosques, hospitals, schools,
pharmacies, post offices, grave yards, pubs, police stations, townhalls,
community_centres, social_facilities, dentists, marketplaces, bus stations,
theatres, universities, courthouses, banks, embassies, prisons...), I could
live with office=diplomatic as well, while introducing a new main tag would
probably lead to disruption and would be a good way to ensure that
amenity=embassy never goes away (which it maybe won't anyway, people will
likely add additional tags and retain the amenity=embassy tag).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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 snd the database more 
accurate.  That is my objective here.



Sent from my iPhone

> On Oct 31, 2018, at 9:45 AM, Warin <61sundow...@gmail.com> 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. 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> 

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

On 31/10/18 04:46, Allan Mustard wrote:


Not really dropping. More like reorganizing.



Errr.

By combining Embassy with High Commission there is a decrease in 
information.


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).


The VCDR does not mention embassy. It has 'mission' and 'consular' but 
no 'embassy', nor 'high commission' etc.


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]




The above 'consolidations' ... loose information.

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.


They can combine Embassies and High Commission etc if that information 
is there.



You can see I favour keeping the longer diversified values.

--

I don't really care if the key diplomatic becomes a top level tag or not.

But the tag amenity=embassy is wrong ... so needs to be depreciated with 
something else, possibly the key diplomatic=* at the top level ...or 
amenity=diplomatic and then the sub tag diplomatic=*




Probably a vote on this subject alone is worthwhile.


Keeping it simple is a good thing.

--

Using the name values of amenity=embassy can work to determine what 
value the key diplomatic=* should have, provided the name/language has 
that information.


-

Tagging and mapping of the services offered .. I'd advise getting one 
thing done at a time, don't get distracted on the 'extras'.


Add this on that large 'todo list'  :)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Joseph Eisenberg]

Re: “To make this work, projects like osm carto would either have to add a
column for this key to their dbs”

I don’t think this is a big problem. This year we added “advertising” as a
top-level key that is rendered for advertising=column.

It does make the code a little more complex, but so does every new feature
and subtag.

I can’t say if a new main tag would affect performance of the rendering
servers, but I don’t think it would be significant.
On Wed, Oct 31, 2018 at 3:49 AM Martin Koppenhoefer 
wrote:

>
>
> Am Di., 30. Okt. 2018 um 18:48 Uhr schrieb Allan Mustard <
> al...@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
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

Am Di., 30. Okt. 2018 um 18:48 Uhr schrieb Allan Mustard :

> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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?)*

*dele**gation* 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. 

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Johnparis]

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





On Tue, Oct 30, 2018 at 10:09 AM Warin <61sundow...@gmail.com> wrote:

> On 29/10/18 21:23, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> On 29. Oct 2018, at 11:18, Martin Koppenhoefer 
> 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
>
>
> Just to make it clear.
>
> I am only using things already tagged amenity=embassy, but missing a
> diplomatic tag and then using the associated name value to determine what
> diplomatic value to add.
>
> Not simply every name tag in the data base... that could lead to some
> interesting results.
>
> There are some things miss-tagged as amenity=embassy .. one is a school (I
> have re-tagged that), I think 3 others are brothels... fixmes in place now.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

On 29/10/18 21:23, Martin Koppenhoefer wrote:



sent from a phone

On 29. Oct 2018, at 11:18, Martin Koppenhoefer > 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



Just to make it clear.

I am only using things already tagged amenity=embassy, but missing a 
diplomatic tag and then using the associated name value to determine 
what diplomatic value to add.


Not simply every name tag in the data base... that could lead to some 
interesting results.


There are some things miss-tagged as amenity=embassy .. one is a school 
(I have re-tagged that), I think 3 others are brothels... fixmes in 
place now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

It would not get the diplomatic=* tag so still would not show up in an
overpass turbo search based on that tag plus the name.  Same goes for an
hotel tagged name=Embassy Suites.

On 10/30/2018 3:57 AM, Graeme Fitzpatrick wrote:
>
> Thanks - that makes sense now!
>
> On Tue, 30 Oct 2018 at 08:42, Steve Doerr  > wrote:
>
> Thanks, but you still haven't told us what's wrong with it.
>
>
> They've effectively called the pub / bar "The German Embassy"!
>
> Thanks
>
> Graeme
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Steve Doerr]

No they haven't. They've called it 'Ständige Vertretung'. It doesn't 
contain the word 'German' or 'Embassy', plus it's explicitly a 
restaurant, so what's wrong with it?



Steve


On 29/10/2018 22:57, Graeme Fitzpatrick wrote:


Thanks - that makes sense now!

On Tue, 30 Oct 2018 at 08:42, Steve Doerr > wrote:


Thanks, but you still haven't told us what's wrong with it.


They've effectively called the pub / bar "The German Embassy"!

Thanks

Graeme

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

Thanks - that makes sense now!

On Tue, 30 Oct 2018 at 08:42, Steve Doerr  wrote:

> Thanks, but you still haven't told us what's wrong with it.
>

They've effectively called the pub / bar "The German Embassy"!

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Steve Doerr]

On 29/10/2018 22:27, Martin Koppenhoefer wrote:



sent from a phone

On 29. Oct 2018, at 21:39, Graeme Fitzpatrick > wrote:



https://www.openstreetmap.org/node/332554285


Sorry, Martin, but what's wrong with it? (or am I missing something 
in translation?)



it is a pub which is called like the FRG representation in the GDR
https://en.m.wikipedia.org/wiki/Permanent_Representatives_of_Federal_Republic_of_Germany_and_the_German_Democratic_Republic



Thanks, but you still haven't told us what's wrong with it.


--

Steve



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

On 29/10/18 21:32, Mateusz Konieczny wrote:
29. Oct 2018 11:10 by 61sundow...@gmail.com 
:


At the moment mappers can simply tag by using the name


Noone proposed to stop using name tag.



My intent was

Mappers can use the name tag to obtain the diplomatic tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

On 30/10/18 07:39, Graeme Fitzpatrick wrote:



On Mon, 29 Oct 2018 at 20:26, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:



here’s an example for a misleading name tag:
https://www.openstreetmap.org/node/332554285


Sorry, Martin, but what's wrong with it? (or am I missing something in 
translation?)


The name translated is "Permanent Representation" ... but it is a 
restaurant.



--

Yes, Martin there are exceptions to every rule.
But as a general guide - diplomatic posts have names that indicate there 
functions.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

sent from a phone

On 29. Oct 2018, at 21:39, Graeme Fitzpatrick  wrote:

>> https://www.openstreetmap.org/node/332554285
> 
> 
> Sorry, Martin, but what's wrong with it? (or am I missing something in 
> translation?)


it is a pub which is called like the FRG representation in the GDR
https://en.m.wikipedia.org/wiki/Permanent_Representatives_of_Federal_Republic_of_Germany_and_the_German_Democratic_Republic

Ciao, Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

On Mon, 29 Oct 2018 at 20:26, Martin Koppenhoefer 
wrote:

>
> here’s an example for a misleading name tag:
> https://www.openstreetmap.org/node/332554285
>

Sorry, Martin, but what's wrong with it? (or am I missing something in
translation?)

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Mateusz Konieczny]

29. Oct 2018 11:10 by 61sundow...@gmail.com :


> > At the moment mappers can simply tag by  using the name 




Noone proposed to stop using name tag. 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

sent from a phone

> On 29. Oct 2018, at 11:18, Martin Koppenhoefer  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 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

sent from a phone

> On 29. Oct 2018, at 11:10, Warin <61sundow...@gmail.com> 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.


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 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

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.


On 29/10/18 12:45, Allan Mustard wrote:


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 

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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 

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Paul Allen]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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 suggestion modifications to the main proposal page.

Many thanks to one and all again,
cheers,
apm-wa
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

No response to date to my requests.  No approval, no response, just
silence, and widespread utilization of MAPS.ME on smartphones.

On 10/28/2018 10:07 AM, Graeme Fitzpatrick wrote:
>
>
> On Sun, 28 Oct 2018 at 15:02, Allan Mustard  > wrote:
>
> Old news.  I've been accused of that for years.  But numerous
> Turkmen government officials have MAPS.ME  on
> their smartphones, and the mayor of Ashgabat has a copy of the
> wall map we produce in his office.
>
> So can we take it that you don't have much trouble getting approval to
> use Govt data? :-)
>
> Thanks
>
> Graeme 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

On Sun, 28 Oct 2018 at 15:02, Allan Mustard  wrote:

> Old news.  I've been accused of that for years.  But numerous Turkmen
> government officials have MAPS.ME on their smartphones, and the mayor of
> Ashgabat has a copy of the wall map we produce in his office.
>
So can we take it that you don't have much trouble getting approval to use
Govt data? :-)

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

Old news.  I've been accused of that for years.  But numerous Turkmen
government officials have MAPS.ME on their smartphones, and the mayor of
Ashgabat has a copy of the wall map we produce in his office.

On 10/28/2018 7:24 AM, Graeme Fitzpatrick wrote:
> On Sat, 27 Oct 2018 at 20:00, Eugene Alvin Villar  > wrote:
>
> I can already see the BuzzFeed headline: "U.S. envoy to
> Turkmenistan admits Americans have diplomatic relations with Taiwan".
>
>
> 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
>
>  
> *"Breaking News"*
>
> U.S. ambassador to Turkmenistan accused of spying under guise of
> surveying for OSM
>
> :-)
>
> Thanks
>
> Graeme
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

On Sat, 27 Oct 2018 at 20:00, Eugene Alvin Villar  wrote:

> I can already see the BuzzFeed headline: "U.S. envoy to Turkmenistan
> admits Americans have diplomatic relations with Taiwan".
>

> 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
>

*"Breaking News"*

U.S. ambassador to Turkmenistan accused of spying under guise of surveying
for OSM

:-)

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

On Sun, 28 Oct 2018 at 03:12, Paul Allen  wrote:

>  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.
>

But, seeing that amenity=embassy already renders, that shouldn't really be
a problem should it?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Paul Allen]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[marc marc]

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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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
>

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Frederik Ramm]

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

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Philip Barnes]

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) 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Johnparis]

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 Sat, Oct 27, 2018 at 4:57 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 27. Oct 2018, at 06:50, Allan Mustard  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
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

sent from a phone

> On 27. Oct 2018, at 06:50, Allan Mustard  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 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Mateusz Konieczny]

26. Oct 2018 21:53 by dan...@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




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Paul Allen]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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 

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Eugene Alvin Villar]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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 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] 

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Eugene Alvin Villar]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging