<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-01-21 11:03 GMT+01:00 Colin Smale <span dir="ltr"><<a href="mailto:colin.smale@xs4all.nl" target="_blank">colin.smale@xs4all.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A few candidates I can think of for incorporation in to the OSM (meta)model:
<p>* date/time format</p></blockquote><div><br></div><div>+1, the opening_hours syntax is IMHO the defacto standard, it is also used in other context, e.g. service_times or conditional tagging.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>* number format</p></blockquote><div><br></div><div>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<br></div><div>Currently we either do nothing or we write the alternatives in alt_name etc.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>* units of measurement and their abbreviations</p></blockquote><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>* support for polygon/area as primitive type</p></blockquote><div><br>+1<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>* multi-valued attributes (semicolons vs. _1, [1] etc)</p></blockquote><div><br></div><div>+1, maybe also different syntax for ordered lists and not?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>* data structures (related attributes) possibly as a formalisation of the ":" syntax (so-called namespaces)</p></blockquote><div><br></div><div>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).<br></div><div><br> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>* use of "curated lists" for certain keys (i.e. an enumeration where only certain defined values are allowed)</p></blockquote><div><br></div><div>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".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>* reference datum for heights/elevations</p></blockquote><div><br></div><div>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.).<br></div><div><br>Cheers,<br></div><div>Martin<br></div></div></div></div>