Feature Proposal - RFC - (consulate)

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

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

Re: 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 <[hidden email]> 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
[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)

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 <[hidden email]> 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
[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)

dieterdreist
In reply to this post by Johnparis


sent from a phone

> On 1. Nov 2018, at 07:20, Johnparis <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)

SelfishSeahorse
On Thu, 1 Nov 2018 at 09:41, Martin Koppenhoefer <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
On Thu, 1 Nov 2018 at 09:41, Martin Koppenhoefer <[hidden email]> 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
[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)

Daniel Koć
In reply to this post by Warin
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Feature Proposal - RFC - (consulate)

Allan Mustard
In reply to this post by Johnparis

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 <[hidden email]> wrote:
On Thu, 1 Nov 2018 at 09:41, Martin Koppenhoefer <[hidden email]> 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
[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)

dieterdreist


sent from a phone

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

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

Re: Feature Proposal - RFC - (consulate)

Eugene Alvin Villar
In reply to this post by Allan Mustard
On Thu, Nov 1, 2018 at 11:14 AM Allan Mustard <[hidden email]> wrote:
* shift to office=diplomatic and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate and other as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.

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

My second preferred option is amenity=diplomatic + subtags if people are really not too keen on office=diplomatic.


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

Re: Feature Proposal - RFC - (consulate)

Eugene Alvin Villar
On Fri, Nov 2, 2018 at 3:12 AM Eugene Alvin Villar <[hidden email]> wrote:
On Thu, Nov 1, 2018 at 11:14 AM Allan Mustard <[hidden email]> wrote:
* shift to office=diplomatic and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate and other as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.

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

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

Re: Feature Proposal - RFC - (consulate)

egil
In reply to this post by Eugene Alvin Villar


On 2018-11-01 20:12, Eugene Alvin Villar wrote:
On Thu, Nov 1, 2018 at 11:14 AM Allan Mustard <[hidden email]> wrote:
* shift to office=diplomatic and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate and other as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.

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

+1 


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

Re: 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 <[hidden email]> wrote:
* shift to office=diplomatic and use the existing diplomatic=* additional (secondary) tag to specify whether embassy, consulate, or other, then use embassy, consulate and other as additional (tertiary) tags to specify further the type of diplomatic or non-diplomatic mission as needed.

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

+1В 



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

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

Allan Mustard
In reply to this post by egil
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
Reply | Threaded
Open this post in threaded view
|

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

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

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 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
[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
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 <[hidden email]> 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
> [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)

Paul Allen
In reply to this post by Allan Mustard
On Sat, Nov 10, 2018 at 5:25 AM Allan Mustard <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
123