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.sm...@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 "10t". >> * 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 structures"... 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 http://wiki.openstreetmap.org/wiki/Seamarks/Sectored_and_Directional_Lights) >> * 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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
