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