[Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Warin 61sundowner at gmail.com
Tue Nov 13 02:34:39 UTC 2018

What I am suggesting;

Stage 1 - Vote on office=diplomatic as a replacement for amenity=embassy

Once that is past
Stage 2 - vote on diplomatic=embassy/consulate/?
with embassy=embassy/high_commission/?

Stage 3 .. if you have further things.

That way each vote is on one issue only not the lot bundled together.

Once that is past On 13/11/18 12:22, Allan Mustard wrote:
> Warin, may I please remind you that in your message of 31 October you 
> were the mapper who expressed great concern about loss of data?
> On 11/13/2018 2:37 AM, Colin Smale wrote:
>> On 2018-11-12 22:00, Warin wrote:
>>> On 13/11/18 01:07, Allan Mustard wrote:
>>>> Not contrived at all in these days of tight budgets. I see no 
>>>> reason the inverse would not work. I'll add it.
>>> I think there are too many things in the proposal. Keep it simple. 
>>> Yes the 'extras' might sound nice but they add complexity and each 
>>> one is a point that can lead to someone objecting to that specific 
>>> thing and leading to enough no votes that it fails.
>> At moments like this I like to invoke one of my heroes: Albert 
>> Einstein. One famous saying attributed to him is: As simple as 
>> possible, but no simpler.
>> If you simplify complex realities too much, you lose valuable detail. 
>> If it's complex, it's complex. If you want to leave out a level of 
>> detail, such as being able to distinguish between the different types 
>> of services provided on behalf of multiple "tenant" countries in a 
>> diplomatic mission, then so be it, but let's discuss whether it is 
>> desirable to leave that out, and whether the resultant ambiguity is 
>> acceptable. Data modelling means constructing an approximation to 
>> reality, and is all about what details to keep in and what to leave 
>> out. Once it is left out, it cannot be reconstructed from the rest of 
>> the data. (If it can, your data model is not properly normalised.)
>> If OSM is being limited to being suboptimal because of politics and 
>> the inability to reach consensus, I would rather the system was fixed 
>> instead of condemning the whole business to eternal mediocrity.
> _______________________________________________
> 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/20181113/7f804790/attachment.html>

More information about the Tagging mailing list