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 [email protected] https://lists.openstreetmap.org/listinfo/talk-de
