[Tagging] Feature Proposal - RFC - (consulate)

Johnparis okosm at johnfreed.com
Sun Oct 21 23:15:57 UTC 2018

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

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

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

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

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

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

More information about the Tagging mailing list