Eine Set würde ich in API 0.7 bevorzugen, denn so könnte man bspw. die Unterschiedlichen Öffnungszeiten kenntlich machen.
<key="name" value="Zum Goldenen Löwen" /> <set> <key="amenity" value="restaurant" /> <key="opening_hours" value="Mo-Su 11:00-21:00"> </set> <set> <key="tourism" value="hotel" /> <key="opening_hours" value="24/7"> </set> <set> <key="amenity" value="cafe" /> <key="opening_hours" value="Sa,Su 14:00-17:00"> </set> Am 14. Januar 2014 08:33 schrieb Peter Wendorff <wendo...@uni-paderborn.de>: > Am 14.01.2014 00:40, schrieb Stephan Knauss: >> On 13.01.2014 23:40, Frederik Ramm wrote: >>> Du hast schon recht, es waere wuenschenswert, wenn Software das >>> "automatisch richtig" machen wuerde, aber puh, das wird ein langer und >>> steiniger Weg. Am Anfang stuende die Frage: Sollen wir >> >> eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur >> key=value Paare, sondern noch etwas mehr. >> >> Eine Idee für Api 0.7 >> >> Geordnete Listen: >> Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge >> nacheinander kommen. Doppelte Values sind erlaubt. >> >> Sets: >> Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, >> doppelte Values sind verboten. >> >> Wäre eine größere Änderung, dürfte aber viele der bisherigen >> Verwendungen vom Semikolon abdecken. >> >> Bisherige Werte in der Datenbank blieben als value erhalten bis es >> jemand von Hand (oder script) konvertiert. >> >> ABER: Das ist eine recht große Änderung die eine Modifikation an jeder >> Software erfordern würde die die Daten verarbeiten will. Um kompatibel >> zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 >> output wieder zusammenmergen kann in einen einzelnen value mit Semikolon >> für nicht angepasste alte Software. > Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und > dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die > Bojen-Farben: > value-type: List > > Bei Lanes: List > Bei amenity: Set > Bei name: String > etc. > > Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation > entsprechend behandelt werden (als eine ungeordnete Menge), beim name > als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte. > > Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe > sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software, > die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen - > Renderer, Router, ... > > Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele > Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft > dafür, dass Mapper großflächig Daten beisteuern und vor allem > korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann > wieder funktioniert. > > Gruß > Peter > > _______________________________________________ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
