[Talk-at] Über Imports

[Kevin Kofler]

Andreas Labres wrote:
> Trotzdem ist der Effekt der, dass in Wien NIEMAND mehr Bäume auf
> öffentlichem Grund mappt.

Nicht wahr. ;-)
http://www.openstreetmap.org/changeset/15633204
http://www.openstreetmap.org/changeset/15641171
http://www.openstreetmap.org/changeset/16187576
:-)

> Es ist dies ein rein menschliches Problem. Du hast keinen Anreiz
> mehr, keine "Lust" dazu. Diese Funktion wird verstärkt durch die Anzahl.
> Beispiel dazu: in den Anfängen von "add a note" hatte ich mich drum
> gekümmert, die abzuarbeiten. Und da waren Dinge dabei, da hatte jemand für
> jede einzelne Hausnummer eine neue "note" gemacht. Das hat so lange gut
> funktioniert, bis jemand auf die Idee kam, die hunderten, teils /Jahre/
> alten, OpenStreetBugs in Notes zu importieren. Seither lese ich die Notes
> nicht mehr, mir fehlt jeder Spaß daran. 6587 ungelesene Notes...

Die Menge ist natürlich ein Problem. Aber gerade diese Menge ist es auch, 
warum die Daten nicht bereits in der OSM drinnen sind, und es bei manchen 
Imports wahrscheinlich Jahre dauern würde, um auch nur annähernd so weit zu 
kommen, wie durch den Import möglich.

> Also, lieber Abzeichnen (das funktioniert mit basemap.at + geoimage.at +
> local knowledge eigentlich sehr gut) oder irgendwas Halbautomatisches (das
> jedenfalls immer nur überschaubare "Häppchen" macht).
> 
> Und ich widerspreche mir hiermit sofort selbst: Sinn macht für mich in
> Wien ein Hydrantenimport. Aber gut gemacht. Und das oben erwähnte
> "Häppchen" besteht für mich darin, dass es relativ wenige Hydrantenorte
> gibt, wo in der Nähe schon sowas gemappt ist. Und genau dieses "Häppchen"
> muß man händisch durchgehen und entscheiden, wird der gemappte Hydrant
> unangetastet gelassen, wird er verschoben, wird der OGD Hydrant trotzdem
> importiert. -- Und auch da wird danach der Effekt sein, dass niemand mehr
> sich in Wien um Hydranten kümmert. Dessen muß man sich bewußt sein. Und
> eigentlich muß man eine (wieder manuell auszuführende/zu überprüfende)
> Update-Funktion implementieren, die die OGD-Updates (die's hoffentlich
> gibt; IMO hat das noch nie jemand untersucht wie diese OGD-Daten
> eigentlich veralten oder gewartet werden) einpflegen kann, dabei aber
> Rücksicht auf aktuelles Mapping nehmen muss. Hydrant für Hydrant (und Baum
> für Baum, weil das feht uns eigentlich auch noch!) durchgehend. Und sowas
> würde ich gern mal in einem Hackday implementieren, rein Javascript und
> Overpass, und heraus fällt eine OSM-Datei mit /meinen/ Änderungen: Ich
> habe überprüft und ich möchte, dass dieser Baum dorthin verschoben und mit
> diesen Tags ergänzt/korrigiert oder gelöscht oder neu hinzugefügt wird.
> Und wahrscheinlich sollte man das auch immer auf eine gewisse Bounding Box
> beschränken: ich korrigiere jetzt die Bäume in diesem Gebiet (bbox
> ziehend).
> 
> Auch dazu noch ein Beispiel: Ich hab vor der Kirche in Mariabrunn einen
> Baum gemappt. Ich weiß, dass der dort steht, aber ich hab keinen Tau,
> welche Art das ist und wie alt/groß. Aber weil der schon vor dem
> Baumkatasterimport dort gemappt war, wurde der ausgeklammert. Dh. obwohl
> es diese Infos in den OGD Daten vermutlich gibt, fehlen Sie in OSM. Und
> mir fehlt die Lust, da manuell zu forschen und das manuell zu
> aktualisieren. Aber wenn's ein Tool w.o. gäbe, würde mir das sagen
> - bei dem Baum fehlen diese und jene Tags
> - außerdem sollte er 1,5 m nach rechts verschoben sein
> und dann sage ich JA und er macht es. Und dann habe ich den gemappt. Und
> wenn der gefällt würde und durch einen neuen Baum ersetzt, würde ich das
> auch mappen. - Im Gegensatz dazu habe ich mir die zwei OGD-Bäume, die's in
> meiner Straße gibt, noch nie angesehen.

Da gebe ich dir natürlich recht, im Tooling-Bereich wären da Verbesserungen 
dringend nötig. Wobei sich die Katze da auch irgendwie in den Schwanz beißt: 
Wir machen (fast) alles händisch, weil wir keine guten Tools haben, aber 
niemand schreibt gute Import-Tools, weil die Community sowieso lieber 
händisch arbeitet. Ich weiß auch nicht, wie wir aus diesem Teufelskreis 
herauskommen. Ein weiteres Problem ist die schlechte Nachvollziehbarkeit von 
Änderungen seitens der OGD-Daten selbst. Es gibt meistens nicht einmal eine 
History von offizieller Seite (soweit ich weiß, importiert die Grazer 
Community jetzt alles regelmäßig in ein eigenes SCM, um die History zu 
bewahren, das wäre wohl überall sinnvoll), und auch von Version zu Version 
eindeutige Objekt-IDs sucht man oft vergeblich. Das erschwert auch die 
Arbeit von Tools, die die Änderungen importieren sollten.

> Und noch etwas: Die OGD Daten von Wien haben sich schon viel zu sehr
> verselbständigt (und schon gar nicht waren die "für uns freigegeben"),
> würde die Stadt da wieder redzuieren, wäre der Aufschrei groß. Und die
> Wiener OGD-Daten sind sowohl politisch gewünscht wie "bürokratisch"
> umgesetzt, da ist IMO keine Kursänderung in Sicht. Im Gegenteil, das ist
> eine europaweit anerkannte Vorreiterrolle.

Um Wien mache ich mir diesbezüglich eh keine Sorgen, sondern eher um 
Gegenden, die noch nicht so weit sind.

        Kevin Kofler