Feature Proposal - RFC - (consulate)

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

dieterdreist


sent from a phone

> On 10. Nov 2018, at 06:23, Allan Mustard <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Eugene Alvin Villar
In reply to this post by Allan Mustard
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Graeme Fitzpatrick
In reply to this post by Eugene Alvin Villar


On Sun, 11 Nov 2018 at 12:34, Eugene Alvin Villar <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Colin Smale
In reply to this post by Graeme Fitzpatrick

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Allan Mustard
In reply to this post by Graeme Fitzpatrick

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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Allan Mustard
In reply to this post by Colin Smale

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Allan Mustard
In reply to this post by Colin Smale

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:
    • 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:
      • 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 the two-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 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.

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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:
    • 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:
      • 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 the two-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 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.

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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:
    • 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:
      • 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 the two-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 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.

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Graeme Fitzpatrick
In reply to this post by Allan Mustard


On Sun, 11 Nov 2018 at 21:42, Allan Mustard <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Colin Smale
In reply to this post by Graeme Fitzpatrick

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Allan Mustard
In reply to this post by Colin Smale
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Allan Mustard
In reply to this post by Warin

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
123