Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 14.01.2014 08:54, André Riedel wrote: Ich sehe schon, es ist noch komplizierter als ich dachte. 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 mein Gedanke war, dass der Set ein Datentyp ist. also so in etwa das um das amenity=hotel;restaurant zu ersetzen set key=amenity valuehotel/value valuerestaurant/value /set Das was du machst finde ich vom Bauchgefühl her unglücklich. Ich würde das doch trennen wollen. Es ist ja auch geographisch nicht der gleiche Ort. Eventuell die gleiche Adresse, aber die Leute übernachten bestimmt nicht im Restaurant. Das ist also schon räumlich getrennt. Eventuell ist das Hotel ja in Wirklichkeit ein Stockwerk drüber oder so. Es ging mir mehr um die Sachen bei denen es sich nicht trennen lässt. Wie eben das Stück Autobahn von Stuttgart Richtung Karlsruhe: set key=ref valueA 8/value valueA 81/value /set Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On Di, Jan 14, 2014 at 08:33:18 +0100, Peter Wendorff wrote: 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. Das ist ein ganz wichtiger Punkt. Bevor man sich Gedanken darüber macht, wie die Daten in OSM besser modelliert werden könnten, sollte man schauen, mit welchen Daten die Anwendungen umgehen können. Die Hürde ist in sehr vielen Fällen im Moment nicht das OSM-Datenmodell. Das ist zwar umständlich in der Handhabung, aber es ist mächtiger als das, was üblicherweise in der späteren Verarbeitung verwendet wird. Konkret ist unsere Rendering-Toolchain zu begrenzt. Mit osm2pgsql und Mapnik kann man einfach diese Multivalued-ref-Tags und dergl. nicht ohne Tricks umsetzen. Deshalb sind alle Versuche, dieses Problem anzugehen, immer auf halber Strecke hängen geblieben. Das Ergebnis waren komplexe Script-Verhaue und gigantische Mapnik-Config-Files. Wenn wir soweit wären, dass die Rendering-Toolchain ganz selbstverständlich mit solchen refs umgehen kann, dann würde sich daraus auch ergeben, wie wir das bei OSM richtig taggen müssen bzw. ob wir eine Ergänzung des OSM-Datenmodells brauchen. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Ich meinte das eher so, wie Stephan es auch in seiner Antwort durchklingen lässt. Mir geht es um Datentypen innerhalb von Tag-Values, nicht um neue Datentypen generell. So wie du es vorschlägst, ist das ein massiver Umbau der API, und ob der wirklich glücklich ist, lässt sich diskutieren. Mein Vorschlag wäre eher in Richtung einer zentralen Dokumentation zu sehen; also: 1) Das Semikolon kann als Sonderzeichen in values betrachtet werden. 2) Der Typ der Values eines Tags ist im wiki per Template definierbar. 3) Ist nichts anderes definiert, ist der Wert als atomar zu betrachten. Im Wiki kann dann für amenity stehen: amenity [typ: set] Wenn im amenity-key ein Semikolon auftaucht, dann enthält dieses Tag mehrere Werte, deren Reihenfolge aber keine Bedeutung hat. highway:lanes [typ: array] Wenn im highway:lanes-Tag ein Semikolon auftaucht, dann enthält dieses Tag mehrere Werte als geordnete Liste, die Reihenfolge hat also eine Bedeutung. seamark:colors [typ: array] s. lanes. ref [typ: set] s. amenity name [typ: atomic] Wenn hier ein Semikolon auftaucht, hat dieses keine besondere Bedeutung, der Wert ist trotzdem als ein einzelnes Element zu interpretieren. Diesen Typ kann man jeweils in die Tag-Templates im Wiki mit aufnehmen und taginfo, Editoren etc. können diese Info nutzen, um die GUI anzupassen, Vergleiche/Suche anzupassen: wenn ich nach amenity=bar suche, finde ich dann auch bar;restaurant; wenn ich nach amenity=bar;restaurant suche, finde ich auch restaurant;bar Wenn ich nach amenity=bar+ suche, finde ich amenity=bar;restaurant nicht, aber amenity=barn wenn ich nach seamark:colors=white suche, finde ich red;white aber nicht, weil das ein anderer Wert ist, wenn ich nach name=foo suche, finde ich nicht name=foo;bar, bei name=foo* aber schon. Bei deinem Vorschlag hingegen lässt sich zumindest Restaurant/Cafe von Hotel trennen, falls Restaurant und Cafe dieselben Räumlichkeiten verwenden, sind die Öffnungszeiten auch in dieser Form falsch, denn ich kann dann ja auch Samstags um 13:30 ins Cafe gehen - schlimmstenfalls krieg ich den Kuchen erst später, aber mit dem Kaffee kann ich schon anfangen. Dieser Unterschied ist aber nicht ersichtlich, was hier wie zusammenhängt oder auch nicht. Und: Willst Du sets dann auch noch verschachteln (z.B. weil restaurant und cafe gemeinsam einen anderen operator haben als das Hotel)? Gruß Peter Am 14.01.2014 08:54, schrieb André Riedel: 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,
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Stephan Knauss o...@stephans-server.de wrote: Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Jepp. Ehrlich gesagt finde ich das sauberer als diese Pseudo-Listen mit ;. Sven -- Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 22:35, Stephan Knauss wrote: Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Mittlerweile bin ich der Meinung, dass JOSM dies (alle Werte des Tags als strichpunkt-separierte Liste) gar nicht mehr bzw nicht mehr als default anbieten und/oder beim Upload deutlich davor warnen sollte. Nur konnte ich mich noch nicht aufraffen, einen entsprechenden Eintrag im Bugtracker zu schreiben. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 22:12, Peter Wendorff wrote: jetzt fängst du aber mit Ausweichtaktiken an. Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf Highway Shields ausgerichtet. Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die Lösung des Problems nicht. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Dass das Problem nicht trivial ist, ist mir klar. Die automatisch erzeugten Werte von JOSM beim verbinden von Wegen sind da ein Problem, ja. Aber die von mir angesprochenen Kombinationen sind eben durchaus auch üblich und tatsächlich ein Grenzfall. Was Jochen unter But of course in this case it only means that somebody couldn’t make up their mind whether to use lake or pond and chose the worst: both. beschreibt. Nur ist das nur das Schlechteste, solange es nicht genutzt und interpretiert wird. Was mache ich denn mit dem erwähnten Restaurant/Cafe oder Hotel/Restaurant, Begriffen, die ja sogar fast in die allgemeine Sprache aufgenommen ist so als Doppelworte? Was mache ich mit einem Autohaus mit Werkstatt (shop=car, shop=car_repair), bei dem beides nicht sinnvoll voneinander trennbar ist? Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel machen deutlich dass das Semikolon auch anderes meinen kann. Aber es gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist meines Erachtens auch ein gutes Beispiel. Immer wieder beschweren sich gerade neue Mapper, das Mappen sei so komplex, man könne eigentlich keinen Weg mehr unterteilen, ohne zig Relationen kaputtzumachen bzw. reparieren zu müssen; und das zum Teil zu Recht, wie ich finde. Bisher sind es nur Buslinien und große Rad/Wanderrouten, die großflächig als Relationen eingetragen sind; bei Autobahnen, Bundesstraßen etc. ist das meines Erachtens viel zu häufig, aber das hält sich in Grenzen. Wenn wir jetzt bei Kreisstraßen, Landstraßen etc. weitermachen, alles in Relationen zu verpacken, nur weil es eine zusammenfassende Nummer hat, wächst sich das wieder zu einem Ungetüm aus. Dann können wir demnächst auch nur noch ungetaggte Ways nutzen, und alle Tags auf Relationen übertragen, wie das tendentiell schon bei Multipolygonen passiert. Aber wer sich hinterher über untagged-ways beschwert, ist dann selbst Schuld, wenn jetzt das Gegenteil gefordert wird. Ob ich die A30 als Relation zusammenfasse oder die E27, die Buslinie 7 oder die Goethestraße, das ist im Prinzip alles das gleiche, und wenn wir ref=7;10, ref=B55;E27 etc. nicht haben wollen, wird uns nichts anderes übrigbleiben, als eben wirklich alles in die Relationen zu verschieben. Ob das die bessere Lösung ist, bezweifle ich aber erstmal. Gruß Peter Am 13.01.2014 22:35, schrieb Stephan Knauss: On 13.01.2014 22:12, Peter Wendorff wrote: jetzt fängst du aber mit Ausweichtaktiken an. Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf Highway Shields ausgerichtet. Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die Lösung des Problems nicht. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Stephan ___ 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
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Hi, On 13.01.2014 23:10, Peter Wendorff wrote: Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel machen deutlich dass das Semikolon auch anderes meinen kann. Aber es gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist meines Erachtens auch ein gutes Beispiel. Allerdings eins, bei dem Relationen eine ganz gute oder zumindest funktionierende Loesung sind; bei Hotel-Restaurants hingegen wird man damit nicht weit kommen. Bis zu API 0.3 uebrigens (oder wars sogar 0.4) konnte ein Objekt in OSM uebrigens tatsaechlich mehrere Tags desselben Keys haben. Wir haben das dann abgeschafft, weil fast keine damals gaengige Software das auch unterstuetzt hat - einmal ein Objekt mit so einem Doppeltag mit JOSM bearbeitet, schon wurde zufaellig einer der beiden Tags gewaehlt... 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 * alle Tags ausser die in einer bestimmten Negativliste (note, comment, ...) am Semikolon aufsplitten? * nur Tags aus einer bestimmten Positivliste (amenity, ref, ...) am Semikolon aufsplitten? Wenn ja - wie verteilen wir diese Listen zwischen allen Programmen? * Tags nur dann aufsplitten, wenn sie einer bestimmten Form genuegen (z.B.: wenn der Value mit einem Semikolon *beginnt*)? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
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. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
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
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
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
