[Tagging] Feature Proposal - RFC - (consulate)

Joseph Eisenberg joseph.eisenberg at gmail.com
Tue Oct 30 22:11:19 UTC 2018


Re: “To make this work, projects like osm carto would either have to add a
column for this key to their dbs”

I don’t think this is a big problem. This year we added “advertising” as a
top-level key that is rendered for advertising=column.

It does make the code a little more complex, but so does every new feature
and subtag.

I can’t say if a new main tag would affect performance of the rendering
servers, but I don’t think it would be significant.
On Wed, Oct 31, 2018 at 3:49 AM Martin Koppenhoefer <dieterdreist at gmail.com>
wrote:

>
>
> Am Di., 30. Okt. 2018 um 18:48 Uhr schrieb Allan Mustard <
> allan at mustard.net>:
>
>> Not really dropping.  More like reorganizing.  As someone who has spent
>> hours puzzling over Maperitive's rendering rules, deciding how to build
>> them so that particular categories of POIs will be rendered in specific
>> ways, I am quite sensitive to the need for consistency and a finite number
>> of possible permutations while also accommodating the need to cover every
>> eventuality.  Hierarchies are designed for exactly that purpose.  After
>> much back and forth at this point I am proposing a hierarchy that I believe
>> meets all needs without being overly complex, and which will accommodate
>> the novice mapper (diplomatic=embassy, period) and the advanced mapper
>> (diplomatic=embassy, embassy=interests_section, etc.).
>>
>> diplomatic=* would become a top-level, primary tag.  It would have three
>> categories: embassy, consulate, other.
>>
>
> to make this work, projects like osm carto would either have to add a
> column for this key to their dbs or mappers would have to add something
> like amenity=diplomatic on top of all tags (and likely it will lead to the
> second way of doing it). It would make sense, if amenity=diplomatic was
> sufficient information for a significant number of people, it doesn't make
> sense if amenity=diplomatic does not convey the required information.
>
>
>> If the consensus is that "other" sucks as an option I'm certainly open to
>> other suggestions, but we need something for diplomatic missions headed by
>> neither an ambassador/charge d'affaires (i.e., subject to the VCDR) nor a
>> consul (i.e., subject to the VCCR).
>>
>
> diplomatic=minor_mission? If there's neither a consul nor an ambassador,
> it must be somehow minor ;-)
>
>
>
>> Then the real fun begins.  As I have read through the various comments
>> and suggestions, it has occurred to me that the following hierarchy of tags
>> would potentially fill the bill:
>>
>> The three values/categories (embassy, consulate, other) would have
>> specific subcategories.  If you wanted to do a key search in overpass
>> turbo, it would still be possible. The subcategories would be
>>
>> * embassy=[embassy/yes, nunciature, high_commission, interests_section,
>> mission, delegation, branch_embassy]
>>
>> * consulate=[consulate/yes, consulate_general, consular_agency,
>> consular_office, honorary_consul]
>>
>> * other=[liaison_office, representative_office, subnational]
>>
>
> if these are all exclusive, it could also be:
>
> amenity=[embassy, consulate, minor_mission]
> diplomatic=[(embassy/yes), nunciature, high_commission,
> interests_section, mission, delegation, branch_embassy, (consulate/yes),
> consulate_general, consular_agency, consular_office, honorary_consul, liaison_office,
> representative_office, subnational]
>
> we would save on keys and the main level (most mappers interested) would
> be in the amenity space and have just 3 different, simple tags with
> reasonable level of detail.
>
>
> or amenity=[embassy, consulate, minor_mission]
> embassy=[embassy/yes, nunciature, high_commission, interests_section,
> mission, delegation, branch_embassy]
> consulate=[consulate/yes, consulate_general, consular_agency,
> consular_office, honorary_consul]
> minor_mission =[liaison_office, representative_office, subnational]
>
> diplomatic=[trade_office, assistance_office, cultural_center,
> user_defined]
>
> (integrating your diplomatic:type)
>
>
> Cheers,
> Martin
> _______________________________________________
> 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/20181031/fe66a0d7/attachment.html>


More information about the Tagging mailing list