[Tagging] Feature Proposal - RFC - (consulate)

Eugene Alvin Villar seav80 at gmail.com
Thu Nov 1 19:19:15 UTC 2018

On Fri, Nov 2, 2018 at 3:12 AM Eugene Alvin Villar <seav80 at gmail.com> wrote:

> On Thu, Nov 1, 2018 at 11:14 AM Allan Mustard <allan at mustard.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181102/2b04e142/attachment.html>

More information about the Tagging mailing list