[Tagging] Removing name_1 and alt_name_1 from Wiki

[Martin Koppenhoefer]

2016-01-21 11:03 GMT+01:00 Colin Smale <colin.smale at xs4all.nl>:

> A few candidates I can think of for incorporation in to the OSM
> (meta)model:
>
> * date/time format
>

+1, the opening_hours syntax is IMHO the defacto standard, it is also used
in other context, e.g. service_times or conditional tagging.


> * number format
>

what do you mean? "." or "," as decimal separator ? In Italy we often have
dates (or nobles, popes, ...) in street names, and those are written
differently in different documents / signs, sometimes as words, or arabian
or latin numbers, e.g. Quattro Novembre can also be "4 Novembre" or "IV
Novembre". or Pio Quinto can also be Pio V
Currently we either do nothing or we write the alternatives in alt_name etc.



> * units of measurement and their abbreviations
>
* support for polygon/area as primitive type
>

+1


> * multi-valued attributes (semicolons vs. _1, [1] etc)
>

+1, maybe also different syntax for ordered lists and not?


> * data structures (related attributes) possibly as a formalisation of the
> ":" syntax (so-called namespaces)
>

this one I would see a bit different: don't mix up different things, and
you don't need to mark "related attributes": all attributes on an object
relate to that object. All the times I have found OSM objects with
different values for common keys, they actually had been a mix of different
objects and as soon as you split them into different objects you don't need
these any more (stuff like bridge:name for instance, resulting from bridge
objects missing for a long time). You might still need namespaces to say
which kind of attribute is meant (e.g. (hypothetical) maxspeed:wet /
maxspeed:snow / maxspeed:dry ... or historic:civilization), but these are
just different keys that are "visually" grouped for convenience (a logical
system that helps finding consistent syntax for new keys) and to allow
easier interpretation/avoid misinterpretation of the key by giving a
context (similar attributes get similar key names).



* use of "curated lists" for certain keys (i.e. an enumeration where only
> certain defined values are allowed)
>

what do you think about here? Instinctively I'm inclined to reject this
idea, because it is against our open tagging model? As soon as you start
introducing exceptions, (some) people will try to extend this and go around
telling others that their way of mapping is "wrong".


> * reference datum for heights/elevations
>

something that could be agreed upon. Actually I'd guees the very most ele
indications are likely either unprecise (coming from "amateur measurements"
with cellphones or consumer gps devices and are based on GPS, i.e. they
have a higher error level than a wrong reference datum assumption would
produce) or are in the system locally (nationally) used (read off a sign,
copied from a book, etc.).

Cheers,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20160121/8f7370fc/attachment.html>