[Talk-at] Über Imports

[Andreas Labres]

On 14.04.14 20:40, Kevin Kofler wrote:
> PS: Bzgl. des Arguments, die Imports würden neue Mapper "verscheuchen"

Das Problem mit den Imports (wie schon oft gesagt, hör Dir die Podiumsdiskussion
auf der 2011.sotm-eu.org dazu an) ist NICHT:
* bezogen auf die Daten
* "verscheuchen" hat eigentlich auch das Problem nicht verstanden.

Konkretes Beispiel: Der Baumkatasterimport. Der war in Ordnung. Der war gut
gemacht (hat Rücksicht auf bereits gemappte Dinge genommen). Trotzdem ist der
Effekt der, dass in Wien NIEMAND mehr Bäume auf öffentlichem Grund mappt. 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...

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.

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.

BTW, heute(!):   https://open.wien.at/site/kalender/?mc_id=49

/al