[Tagging] Removing name_1 and alt_name_1 from Wiki

Colin Smale colin.smale at xs4all.nl
Thu Jan 21 12:33:46 UTC 2016

Thanks for your comments Martin! 

On 2016-01-21 12:21, Martin Koppenhoefer wrote:

> 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.

The opening_hours syntax goes way beyond the definition of a date/time.
I was thinking more about ISO8601, which on the one hand allows full
specification including fractions of seconds and timezones, and on the
other hand allows a degenerate partial syntax where all that detail is
not required. In opening_hours the time is specified as hh:mm, and this
is compatible with ISO8601. 

We also have values representing a date - such as start_date. The wiki
page already refers to ISO8601, but the point I would like to make is
that this reference should be at an "OSM" level, and not at the level of
an individual tag. 

>> * 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.

I mean numerical values of keys, not as part of a string. For example
population which can have values into the millions, or maxweight which
has smaller values but may include decimals. Let's agree at a high
level, OSM-wide, that "numbers use . as a decimal separator and no
thousands groupings". Anywhere a key has a value which is a number, the
wiki page for that key should refer to the central definition of
"number". Same for date, time, etc - promote the definition from
key-local to OSM-wide. 

>> * units of measurement and their abbreviations

Not as straightforward as you might expect - look at all the different
"tons" there are in the world. Metric, Long Ton, Short Ton... all
different, and all used within OSM. In my work in the financial sector I
learnt that it is basically "extremely bad practice" to have an amount
(of money) without an explicit currency code in the same record - sooner
or later errors will occur. A 10 ton weight limit in the US is not the
same as a 10 ton limit elsewhere, but they are both written as "10" or

>> * support for polygon/area as primitive type
> +1

.. and then redefine a multipolygon in terms of this... 

>> * multi-valued attributes (semicolons vs. _1, [1] etc)
> +1, maybe also different syntax for ordered lists and not?

Indeed. Let's sort this out for once and for all. Re: ordered vs.
unordered: I think they can share a basic syntax, and the specific key's
definition can make it clear to what extent the order is significant. 
Note that the lanes stuff essentially has a syntax for a 2-dimensional
array, using a combination of ";" and "|", give or take some semantic
differences about missing values... 

>> * 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).

I think your comment illustrates why we need to tidy up the definition.
I was thinking of examples like lanes and seamark, where there is
clearly a grouping of tags based on the prefix. You don't need to be
Einstein to extrapolate this into a kind of object/class type of
structure which will open the door to reuse of definitions of "data

I see your example with maxspeed more as a qualification of the key. We
achieve the same effect with maxspeed:conditional, where the effective
value depends on certain conditions, usually time-of-day but I bet there
are some really creative expressions out there. 

It would be nice if the syntax for the data structures can be combined
with the syntax for multiple values, so an object can have a list of
data structures. Cf. the way seamark handles lighthouse sectors, where a
lighthouse appears different depending on where you are. One lighthouse
has 1+ sector, and each sector has attributes like start angle, colour,
and flash pattern. In a typical programming language you would define a
"sector" with its attributes, and define a "lighthouse" as having a list
of "sectors" so you could refer to lighthouse.sectors[1].colour for
example. In OSM/seamark it would be "seamark:light:1:colour". Maybe we
can promote the structures defined by the seamark people to be a generic
model for the whole of OSM? 

(more info on

>> * 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".

I don't intend to limit the creative freedom of mappers, but only to
allow certain keys to only have certain values. For example, oneway only
needs yes and no, and possibly reverse. Any other value is simply wrong.
By normalising this kind of construction we allow and instruct editors
etc. to validate this key against the allowed values, and to stop any
other values getting into the database. It would also catch spelling
mistakes of course! I think there is a case to be made for this to be
introduced with landuse as well - in all the discussions about this tag,
my impression is that there seems to be an underlying agreement that the
list of types of landuse is finite and that not all values make sense.
The list of allowed values doesn't have to be totally fixed for ever,
but it must have a proper change process. 

Later, more complex constraints may be possible, looking at combinations
of keys, but that is definitely for the future.... 

>> * 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.).

So let's define that a vertical measurement must state its datum? If we
have just a collection of numbers without knowing which datum was used
for which number, we will have a collection of unreliable numbers (on
top of the error in the number itself!) and no way of
correcting/rebasing/reliably interpreting the numbers. May as well not
have them at all... 

> 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/20160121/ec8b5863/attachment.html>

More information about the Tagging mailing list