Forschungsprojekt zum Mapping von Parkplätzen im öffentlichen Raum in Wien

Communities Österreich (Austria)
, , ,
1

Liebe Community in Österreich und insbesondere Wien,

im Rahmen einer Masterarbeit an der TU Wien wollen wir uns gerade die Zuverlässigkeit von unterschiedlichen Methoden zur Erfassung von Parkplätzen im öffentlichen Straßenraum anschauen. Wir planen, dabei folgende Methoden zu vergleichen:

  • Exaktes Zählen/Abmessen vor Ort (Ground Truth)
  • Erfassung mit der App “StreetComplete” vor Ort (Layer “Street parking”)
  • Zählen/Schätzen am Luftbild
  • Ableitung aus den GIS-Daten der Flächenmehrzweckkarte der Stadt Wien

Für den zweiten Punkt haben wir vor, mehrere ProbandInnen mit der App die Parksituation für einige Straßenzüge in Wien, in denen derzeit noch keine Tags zur Erfassung der Parksituation in OSM vorliegen, erfassen zu lassen. Die zu erfassenden Straßenzüge sollen sich dabei überlappen, so dass wir auch das “Intercoder Agreement” auswerten können, d.h. in welchem Ausmaß sich die von unterschiedlichen Menschen mit der App getaggten Daten gleichen bzw. unterscheiden.

Unser aktueller Plan ist, dafür einige Straßenzüge ohne Parkraum-Tagging im 8., 9., 18. und 19. Bezirk auszuwählen und wie folgt vorzugehen:

  • Für die Auswahl der Straßenzüge ohne Parkraum-Tagging verwenden wir die Visualisierung auf https://zlant.github.io/parking-lanes/
  • Die erste Testperson tagged mit StreetComplete die Parksituation für die (noch ungetaggeden) Straßenzüge
  • Das Changeset wird anschließend lokal gespeichert und in OSM reverted, damit die 2. Testperson wieder ungetaggede Straßenzüge vorfindet.
  • Innerhalb weniger Tage tagged die 2. Testperson mit StreetComplete die selben Straßenzüge noch einmal.
  • Dieses Changeset wird lokal gespeichert und verbleibt in OSM.
  • Nach Abschluss der Evaluierung wird das Tagging ggf. noch einmal mit Hilfe der Ground Truth Daten verbessert.

Am Ende des Projekts sollte sich in jedem Fall eine ausschließliche Verbesserung für den OSM-Datenbestand ergeben, sowie eine Fehler-/Genauigkeits-Abschätzung der o.A. Methoden vorliegen, die für die Mapping und OSM Community für dieses spezielle Thema vielleicht auch interessant ist. Der einzige vielleicht etwas sensible Schritt dabei ist, dass wir Daten, die wir selbst in OSM contributen, noch einmal reverten und für wenige Tage wieder den ungetaggeden Ausgangszustand herstellen. (Idealerweise würden wir z.B. mit einem Fork der StreetComplete App und einer lokalen Datenbank arbeiten, für so ein Setup fehlen aber im aktuellen Projekt leider die Ressourcen.)

Gibt es gegen diese Vorgehensweise schwerwiegende Einwände bzw. Ideen, es besser zu machen?

Wir können die für die Studie ausgewählten Straßenzüge auch vorab hier posten bzw. euch generell über den Projektfortschritt und die Ergebnisse am Laufenden halten.

Rückfragen/Kommentare gerne hier oder per Email an mich (florian.ledermann@tuwien.ac.at – ich betreue diese Masterarbeit an der TU Wien / Kartographie).

Beste Grüße, Florian

1 Like
2

Das wird schwierig, sobald jemand anderes in der Zwischenzeit an Daten Änderungen vorgenommen hat. Dann ist es nur schwer sicherzustellen das dessen Änderungen bei der Aktion nicht verloren gehen.

Meine Meinung: Was einmal richtig eingetragen wurde sollte nicht wieder aus irgendwelchen externen Gründen wieder entfernt werden. OSM ist keine Experimentierdatenbank sondern ein live-System.
Ich würde empfehlen die Änderungen vorerst nicht in der OSM-Datenbank abzulegen sondern extern zu speichern. Dazu müsste dann natürlich das Datenhandling in der verwendeten App (mehr oder weniger aufwendig) angepasst werden.

3 Likes
3

Spannendes Projekt!

Wisst ihr, was passiert, wenn ihr den automatischen Upload in SC abdreht, zuerst beide Erheber:innen durchschickt und anschließend beides (hintereinander) hochladet?

2 Likes
4

Soweit ist das bisher beobachtet habe verwirft SC anscheinend die eigenen Änderungen, wenn die zu ändernden Daten zwischenzeitlich in der Datenbank geändert wurden.

1 Like
5

Hm, das ist nicht optimal für euch. Wisst ihr schon, wie ihr den Vergleich der zwei Erheber:innen machen wollt? Würden da evtl Screenshots reichen? (Ich weiß nicht wie groß das Gebiet ist und wie gut SC auf Tablets funktioniert). So könntet ihr den SC-Vergleich ohne das genannte Upload-Revert-Upload Problem schaffen.

6

SC funktioniert super auf Tablet.

7

OpenStreetMap ist keine Forschungs-, sondern eine Mappingplattform.
Jemand Daten in OSM eintragen zu lassen und diese Edits dann zu
revertieren, damit das Experiment wiederholt werden kann, widerspricht
den Nutzungsbedingungen von OSM und wird zu Beschwerden - im Extremfall
auch an Eure Profs an der TU - führen. Ich rate deswegen dringend davon ab.

Wenn ihr vergleichend auswerten wollt, dann müsst ihr euch die Mühe
machen, zuvor ein paar “sehr ähnliche” Gebiete zu finden und diese mit
verschiedenen Methoden mappen zu lassen.

Alternativ käme die Nutzung der Developer-API unter
“master.apis.dev.openstreetmap.org” in Frage. Die dahinter stehende
Datenbank ist größtenteils leer; ihr könntet dort die Daten von einem
Testgebiet in Wien einspielen und Mapper dann darauf loslassen, und ohne
Probleme nachher alles wieder löschen und den Ursprungszustand
wiederherstellen. Allerdings müsst ihr dann dafür sorgen, dass z.B.
StreetComplete eben auch dieses Developer-API nutzt, ich weiss nicht, ob
man das einstellen kann oder ob man dazu den Code ändern und die App
selber bauen muss.

6 Likes
8

Daten hochladen und sie danach wieder zurückzusetzen halte ich für keine Gute Idee aber geht das eventuell auch lokal? So viel ich weiß, können StreetComplete Änderungen auch in .osc Dateien gespeichert werden ohne sie auf dem Server zu speichern (Offline-Modus). Dadurch können mehrere Personen die Straßen zeitgleich ablaufen und danach können die lokalen Änderungen miteinander verglichen werden. Zeitgleich, damit es keinen Unterschied zwischen den Ursprungsdaten gibt.

9

Vielen Dank für eure Antworten bisher!

Ehrlich gesagt finde ich die zum Ausdruck gebrachten Meinungen schon etwas enttäuschend. Nur um noch einmal klarzustellen:

  • Zu keinem Zeitpunkt berühren wir Daten von Dritten, oder solche, die vor Beginn unseres Projekts schon in OSM waren.
  • Zu keinem Zeitpunkt würden wir falsche, synthetische oder verfälschte Daten in OSM eintragen! Die Teilnehmenden werden instruiert, jederzeit nach bestem Wissen und Gewissen und den Richtlinien aus dem OSM-Wiki zu taggen.
  • Das ganze Projekt betrifft nur das Tagging von “Streetside Parking”, einem relativen Nischenthema, zu dem die Daten in Wien höchst unvollständig sind, in den von uns bearbeiteten Gebieten gar nicht existieren. Direkt nach dem 2. Durchgang wäre der Datenbestand hier in den genannten Bezirken deutlich erweitert.
  • Die gesamte Studie betreffend StreetComplete wird innerhalb weniger Tage abgeschlossen. Der “Revert” des ersten Durchgangs würde unmittelbar danach erfolgen, und spätestens ein paar Tage danach (möglichst am nächsten Tag) erfolgt der zweite, ab dann in OSM verbleibende Durchgang. Sollte tatsächlich jemand in der Zwischenzeit auf Basis unserer Daten oder im Untersuchungsgebiet Änderungen vornehmen, können wir selbstverständlich darauf achten, dass diese nicht angetastet werden (Danke für diese Anregung @Langlaeufer ).

Klar kann man Argumente finden, warum man aus Prinzip trotzdem dagegen ist. In wie fern das OSM besser macht, sehe ich nicht. Im Gegenteil: wenn wir eine offline-Lösung implementieren, zieht das Ressourcen ab, die wir dann durch eine Verkleinerung der Untersuchungsgebiete kompensieren müssen, und die Daten würden OSM erst Monate später zur Verfügung stehen, falls wir dann noch daran denken, sie hochzuladen. (Habe ich leider schon oft erlebt, das nach Abschluss von Analysen der Fokus schnell woanders liegt und dann solche Sachen nicht mehr gemacht werden.)

OpenStreetMap ist keine Forschungs-, sondern eine Mappingplattform.

Ich will OSM auch nicht als “Forschungsplattform” nutzen, sondern als langjähriger User und Mitglied der Community hier Synergien zu meinem day job herstellen, von der beiden Seiten (mMn) profitieren. Ich habe schon zahlreiche Abschlussarbeiten betreut, im Rahmen derer Teils umfangreiche Verbesserungen des OSM-Datenbestandes entstanden sind. Für mich habe ich OSM auch immer als eng vernetzt mit der forschenden Community - ob universitär oder eigeninitiativ - kennen gelernt. Z.B. das weithin bekannte Projekt “Parkraumanalyse Neukölln” hat sicher auch mit Tagging-Varianten experimentiert. Ob es im Zuge dieses Projekts auch zu Reverts gekommen ist, weiss ich nicht, aber warum auch nicht? Oder wäre das dann auch verboten gewesen? Ich selbst habe im Zuge der Recherchen für das gegenständliche Projekt weite Teile des 4. Bezirks mit StreetComplete vervollständigt, teilweise in von der Uni bezahlten Arbeitszeit. Also Forschungsaktivitäten in Zusammenhang mit OSM rundheraus abzulehnen oder eine starke Verbindung zu leugnen, halte ich für eine bedauerliche Sichtweise. Alles an Daten zu nehmen, die in Uni-Kontexten entstehen, aber eine Anfrage, die vielleicht einen Edge-Case darstellt und daher guten Willen der Community bedarf, aus Prinzip abzulehnen, ohne dass dadurch für OSM etwas besser wird, finde ich wie gesagt eine enttäuschende Position.

Jemand Daten in OSM eintragen zu lassen und diese Edits dann zu
revertieren, damit das Experiment wiederholt werden kann, widerspricht
den Nutzungsbedingungen von OSM

@woodpeck Wenn das die Position hier ist, werden wir das natürlich akzeptieren und einen anderen Weg finden. Ich zweifle auch deine Einschätzung nicht an, sie kommt ja von kompetenter Stelle. Dennoch würde mich interessieren, auf welchen Passus du dich hier beziehst? Ich habe jetzt folgende Dokumente überflogen:

Terms of Use - OpenStreetMap Foundation
Ban Policy - OpenStreetMap Foundation
API Usage policy
Etiquette - OpenStreetMap Foundation
Licence/Contributor Terms - OpenStreetMap Foundation
Organised Editing Guidelines - OpenStreetMap Foundation

und mir ist kein Passus aufgefallen, den ich so wie du interpretiere. Eher im Gegenteil, in den “Organised Editing Guidelines” lese ich: “Organised mapping efforts are an integral part of today’s OSM contribution landscape” sowie die Forderung nach “plans for a ‘post-event clean up’ to validate edits, especially if the activity introduces new contributors to OpenStreetMap” – als solche könnte man unsere geplante Vorgehensweise ja auch interpretieren, wenn man denn wollen würde. (Gut, da steht auch, dass wir für unser Projekt eine Wiki-Seite anlegen hätten sollen, das wusste ich bisher nicht und kann ich sehr gerne machen.)

Also, klar ist für mich, dass falls die geäußerten Einwände hier bestehen bleiben, wir nach einem anderen (technischen) Weg suchen werden, aber ich würde doch darum ersuchen, das noch einmal zu überdenken. Für die konkreten Einwände (z.B. Edits von anderen im Zeitfenster zwischen unseren Edits) würden wir Lösungen finden, die in jedem Fall der Integrität der OSM-Daten Vorrang vor den Bedürfnissen unseres Projekts geben. Wenn es hier aber um abstrakte Prinzipien geht, die im konkreten Fall zu keinem Zeitpunkt zu einer Verbesserung der OSM Daten durch Verhinderung unseres Projekts führen, dann kann ich in dieser Debatte wohl keine rationalen Argumente beisteuern.

Mit besten Grüßen, Florian

1 Like
10

Bisher haben hier nur sehr wenige Leute mitgeschrieben und zB ich habe zwar auch geschrieben, aber gar nicht meine Meinung gesagt. Es ist glaube ich noch zu früh um das als Stimmungsbild zu nehmen.

Meine Meinung ist: Euer Projekt ist gut für OSM. Sowohl weil danach mehr (korrekte) Daten vorhanden sind und nie neue falsche, als auch weil Forschung über Unwege einen Nutzen bringt.

Bevor ihr mühsam irgendwelche Sachen programmieren müsst, würde ich euch raten: Macht es einfach! Aber falls es eine technisch einfache Möglichkeit gäbe, das ohne Revert zu schaffen, dann wäre ich für diesen Weg.

Meine Meinung begründe ich nicht mit eurem Impact (das Projekt ist echt harmlos und wird quasi niemand mitbekommen), sondern weil das ein Präzedenzfall sein könnte, wonach andere Forscher:innen vielleicht mal etwas deutlich größeres oder weitreichenderes “kurz in OSM probieren” könnten, wo die Nachteile (für OSM) überwiegen würden.

PS: Und ja, bitte die Forschungsergebnisse hier posten, wenn es dann mal fertig ist.

3 Likes
11

Danke @skyper guter Vorschlag.

@Flo_Ledermann bevor Du gleich die Flinte in Korn wirfst, setzt Dich doch mal mit @westnordost in Verbindung, welche Möglichkeiten es da mit StreetComplete gibt. Ich kann mir schwer vorstellen, dass man da keine Offline-Lösung für Euch findet. Ich gehe davon aus, dass auch StreetComplete von den Ergebnissen Eurer Untersuchungen profitiert.
Und nach Eurer Auswertung der verglichenen Daten könnt Ihr sicher immer noch die besten der so gewonnen Daten in die Datenbank hochladen. So haben alle Beteiligte was davon: Ihr, SC und OSM.

Übrigens ist genau das der Grund, warum solche Aktionen am besten vorher mit der Community besprochen werden sollten - so wie Du es ja vorbildlich getan hast. Selten ist die erste und naheliegendste Lösung auch die beste und optimalste. Ich würde daher auch Dich bitten, Deine Position noch einmal zu überdenken. Es geht hier nicht darum, auf Prinzipien zu bestehen, Euch zu ärgern oder Euer Projekt zu torpedieren. Es geht darum, Euer Bewusstsein zu schärfen, dass OSM keine Spielwiese ist, sondern eine Datenbank, die quasi in Echtzeit geografische Daten bereitstellt.

1 Like
12

Wenn ihr die OSM-Datenbank benutzt könnte es während der Laufzeit eures Experimentes Änderungen an den betreffenden OSM-Daten geben. Wie würdet ihr damit umgehen? Würdet ihr diese Änderungen auch zeitweilig entfernen wollen? Was, wenn Änderungen eurer Testmapper von denen anderen Mapper überschrieben werden, bzw. wegen Bearbeitungskonflikten gar nicht erst gespeichert werden? Was macht ihr mit Änderungen die zwischen euren beiden Testmappern auftreten? Wie wollt ihr sicherstellen, dass am Ende die besseren Daten (eure oder die von zwischenzeitlich anderen Mappern) in OSM gespeichert werden?

Ich würde auch vermuten, dass das Projekt am Ende im Saldo ein Gewinn für die OSM-Datenbank ist. Die Frage ist ob ggf. auch Arbeit von andern Mappern zerstört werden könnte und wie man versucht, das zu vermeiden.

13

Wenn ihr die OSM-Datenbank benutzt könnte es während der Laufzeit eures Experimentes Änderungen an den betreffenden OSM-Daten geben. Wie würdet ihr damit umgehen? […]

@Langlaeufer Wie oben geschrieben habe ich diese Einwände bereits ernst genommen. Wir würden als interne Richtlinie jedenfalls postulieren, dass zu keinem Zeitpunkt Daten die andere erstellt, erweitert oder verändert haben, von uns gelöscht oder verändert werden. Falls tatsächlich in dem kleinen “kritischen” Zeitfenster ein Edit Dritter stattfindet, würden wir in Kauf nehmen, dass unsere Studie halt nicht “perfekt” ist, die Daten belassen, und das einfach in den Limitations anführen (jede Studie hat Limitations, das ist ja kein Problem). Die Wahrscheinlichkeit dafür schätze ich als äußerst gering ein, Parkplatzmapping hat in Wien eigentlich bisher noch kaum jemanden interessiert, nur jetzt schein es plötzlich ein höchst brisantes Thema zu sein.

So viel ich weiß, können StreetComplete Änderungen auch in .osc Dateien gespeichert werden

@skyper @Mammi71 Was SC betrifft, seid ihr leider falsch informiert. SC unterstützt den lokalen Download der Edits nicht, und ein diesbezüglicher Feature Request von mir wurde als “out of scope” von @westnordost geschlossen. Die Alternativen sind mit Root-Rechten in der SC-Datenbank rumzupuhlen, oder einen Fork zu machen und es selbst zu implementieren. Beides schätze ich als mehrere Tage Arbeit ein (bin in der Codebase und Android-Programmierung nicht drinnen), die in diesem (nicht finanzierten) Projekt wahrscheinlich einfach nicht möglich sind (die Uni gesteht mir pro Masterarbeiten glaube ich 12 Stunden Arbeitszeit zu, inklusive Lesen und Begutachtung der fertigen Arbeit, andere am Projekt beteiligte Personen sind keine Programmierer*innen).

Macht es einfach!

@Nielkrokodil Sorry, aber wenn @woodpeck hier postet dass wir damit gegen die Nutzungsbedingungen von OSM verstoßen, und in Aussicht stellt, und “bei unseren Professoren” anzuschwärzen (lustig, das würde dann wieder auf meinem Schreibtisch landen? :rofl:), dann kommt das ja nicht von irgendwem, sondern von einem DWG Mitglied. Das ist also schon ein klare Ansage, auch wenn mir nach wie vor nicht klar ist, welche Nutzungsbedingung genau damit gemeint ist.

Übrigens ist genau das der Grund, warum solche Aktionen am besten vorher mit der Community besprochen werden sollten - so wie Du es ja vorbildlich getan hast.

Das ist auch das, was ich auf der Meta-Ebene an der Debatte traurig finde – wir predigen immer, sich mit der Community vor Ort abzusprechen, und ich versuche das zeitgerecht zu machen und auf konkrete Bedenken einzugehen. Der generelle Vibe ist aber für mich, dass hier Leute reinspringen, die einfach das Haar in der Suppe finden wollen, anstatt zu überlegen, wie das Projekt für alle beteiligten sinnvoll ablaufen kann. Andere, die hier mitlesen, werden sich in Zukunft wohl eher hüten, Projekte im voraus mit der Community abzusprechen, und “einfach machen” – was ich nach wie vor für den falschen Weg halte.

Weiters frage ich mich, wie es mit dem vielgepredigten Grundsatz “die lokale Community entscheidet” hier ausschaut. Ich habe nicht den Eindruck, dass jene, die hier kritisch kommentieren und um die Datenintegrität von noch gar nicht existierenden Daten besorgt sind, sich mit dem mappen von Parkplätzen im öffentlichen Raum beschäftigen, geschweige denn in Wien? Aber das ist natürlich nur eine Hypothese, schriebt also bitte gerne dazu was euer Background zu dem Thema und regional ist.

Also ich bin jetzt auch überfragt, wie wir jetzt weitermachen – für mich steht fest, so lange der Vorwurf eines DWG Mitglieds im Raum steht, dass wir mit unserem skizzierten Vorgehen gegen die Nutzungsbedingungen von OSM verstoßen, werden wir das Projekt so nicht machen. Da die Alternativen nicht realistisch mit den kurzfristig vorhanden Ressourcen umsetzbar sind, würden wir dann OSM wahrscheinlich überhaupt rauslassen, es z.B. auf Papier machen und nachher wegschmeissen – ein schlechteres Ergebnis für alle. Falls ein Nutzungsbedingungs-kompatibler Weg gefunden wird oder dieser Vorwurf ausgeräumt werden kann, würde ich es tatsächlich gerne mit der lokalen Community abklären, wie wir vorgehen können.

14

Das Problem sehe ich darin, dass schon bei der Planung Reverts fest
vorgesehen sind. Das geht dann über “ups, unsere Studenten haben einen
Fehler gemacht, den müssen wir korrigieren” hinaus, sondern macht OSM zu
einem Vehikel für Experimente.

Du willst ja nicht Edits “validieren”, sondern Du willst absichtlich
gute Edits wieder löschen, damit Du die gleichen Daten von anderen
Leuten auf andere Weise noch einmal eintragen und einen Vergleich machen
kannst.

Vielleicht kannst Du einen Weg finden, die erste Testgruppe “echte”
Edits machen zu lassen und der zweiten Testgruppe dann einen alten
Datenauszug vorsetzen und sie in die dev-API oder eine andere Sandbox
laufen zu lassen. Dann müsstest Du nichts revertieren - ausser natürlich
wenn es fehlerhaft ist, aber das wäre ja wieder ein normales Revertieren
und kein im-Rahmen-eines-Versuchs.

15

Du vermischst da zwei Features von StreetComplete:

  1. Offline-Modus / „automatische Uploads deaktiviert“: Dann werden die Edits lokal in der SQLite-Datenbank gespeichert, jedoch nicht als .osc-Datei oder irgendetwas anderes leicht exportierbares.
  2. Team-Modus, bei dem mehrere Mapper:innen gleichzeitig im selben Gebiet mappen können. Dabei werden die Aufgaben lokal je nach OSM-Element-ID aufgeteilt. D.h. wenn man zu dritt mapped, bekommt Person A die Quests für alle OSM-Nodes/-Ways/-Relations mit IDs, die direkt durch 3 teilbar sind. Person B bekommt die durch 3 teilbaren mit Rest 1 und Person C die durch 3 teilbaren mit Rest 2. Es werden also zwischen den Geräten keine Daten ausgetauscht.
16

Mir ist das auch nicht klar.

Ich mappe oft in Wien und habe bereits in Wien mit dem SC Parking Overlay gemappt. Und ich verwende verkehrsbezogene OSM Daten beruflich.

1 Like
17

Soweit ich das verstehe ist das in etwa wie folgt: Es wird im JOSM eingetragen, nur lokal gespeichert und diese Dateien werden dann verglichen. Einmal Ground-Truth, einmal per Luftbild, einmal aus anderer Datenbank heraus. Nur StreetComplete lädt eben direkt hoch, deswegen der Umweg über hochladen und dann das CS lokal speichern.

Habe ich das soweit korrekt verstanden?

Warum wird StreetComplete zwei mal gemacht? Geht es da darum, wie unterschiedliche Personen das vor Ort dann mappen/erfassen würden?
Vielleicht könnte man statt der zweiten Partie StreetComplete mit https://fieldpapers.org/ arbeiten? Es werden die Fieldpapers für das Gebiet gedruckt, danach geht die Person mit StreetComplete und danach die Person mit den Fieldpapers durch.
Das kann dann in JOSM übertragen und wieder lokal gespeichert werden.

Vielleicht ist das eine gangbare Option, mit der ihr arbeiten könntet?

Wenn das nicht möglich ist, wäre es für mich (wenn auch aus Salzburg) durchaus im Rahmen, dass ihr das das mit dem Revert macht - wenn hier eben Zustimmung herrscht und niemand aus der lokalen Community da schwere Einwände dagegen hat. Dass ihr Parkplätze, die zwischenzeitlich bearbeitet werden dann weglässt und nicht revertiert, hast du ja geschrieben.

Ich habe nicht den Eindruck, dass jene, die hier kritisch kommentieren und um die Datenintegrität von noch gar nicht existierenden Daten besorgt sind, sich mit dem mappen von Parkplätzen im öffentlichen Raum beschäftigen, geschweige denn in Wien?

Und weiter? Irrelevant, meiner Meinung nach. Vielleicht interessieren sich welche dafür. Vielleicht haben welche jetzt das Interesse entwickelt. Vielleicht finden andere einfach dein Projekt cool und möchten, dass in OSM alles passt. :person_shrugging: Gibt viele Gründe, warum jemand hier mitschreibt. Wenns danach ginge, hätten wir in Tirol noch viele lustige Landuse-Lücken.

Ich sehe hier sehr viele Versuche konstruktiv zu arbeiten und dir/euch zu helfen, wie man das umsetzen könnte.

3 Likes
18

@woodpeck: Die Nutzung von api.openstreetmap.org ist in SC hardkodiert, also auch für das Ausweichen auf die dev-API müsste SC abgeändert werden, wenn auch nur eine Zeile im Code.

@Flo_Ledermann: Nachdem ich diesen Thread gelesen habe, hört es sich so an, als sei der aufwandärmste Weg mit dem alle glücklich wären, folgender:

  1. Geänderte version von SC erstellen damit es mit der dev API statt mit der production API kommunizert. Ich könnte dafür eine Version zur Verfügung stellen. Im Gegenzug wäre es cool wenn die Forschungsergebnisse zumindest uns OSM-Interessierten zugänglich gemacht würden, da diese durchaus interessant für Verbesserungen an Tagging und Softwareimplementierung sein könnten.

  2. Den Ausschnitt Wiens der Teil des Forschungsprojektes sein soll per JOSM herunterladen und abspeichern. Dann diese Daten auf der dev API wiederum importieren. Also:

    2.1 Vorher die Daten in dem Abschnitt auf der Dev API am besten alle löschen damit es keine Duplikate gibt

    2.2 Ich glaube es ist notwendig, die IDs der aus OSM exportierten Daten alle ein “-” voranzustellen (also aus id=123 wird id=-123) weil sich positive IDs auf Elemente beziehen, die schon existieren. Aber auf der Dev-Instanz existieren sie ja noch nicht. Oder, @woodpeck? Sollte jedenfalls möglich sein per einfachen Regex-Search&Replace mit Hilfe eines Texteditors. Um generell die Daten zu reduzieren, könntet ihr statt quasi ganz Wien nur die Straßen per Overpass-API aus Wien exportieren, was den Datensatz auch übersichtlicher macht. (Ich hoffe die neulich eingeführten quotas für neu-User betreffen nicht die Dev-Instanz??)

  3. Forfahren wie geplant. Pro Durchlauf eines Testlaufes die Daten wieder alle aus der Dev API löschen und neu importieren. Kein komplizierter Revert nötig, einfach alles löschen und neu raufspielen. (es sei denn die IDs der Elemente sollen für die Auswertung die gleichen bleiben. In dem Fall dann eben nur die parking-taggings wieder entfernen)

Der Nachteil dieses Weges, übrigens, ist natürlich, dass die von den an der Studie teilnehmenden Personen beigetragenen Daten am Ende nicht in OSM landen. (Es wäre recht aufwändig die zur Dev-API beigetragenen Änderungen auf OSM zu replizieren, weil ja die Element-IDs unterschiedlich sind). Aber gut, so ist das dann eben.

5 Likes
19

Die Overpass-API ist im Wiki dokumentiert. Bei Interesse finden sich sicherlich genug Leute hier im Forum die euch dabei helfen könnten, eine geeignete Query zu schreiben, aber ansonsten ist es als Forscher generell vorteilhaft, die Overpass-API zu kennen um OSM-Daten statistisch auszuwerten.

Ihr wollt wahrscheinlich eine Query, die alle Straßen plus alle Flächen die mit amenity=parking getaggt sind und natürlich die zu den Wegen zugehörigen Nodes zurückliefert.

20

Wenn hier OSM profitiert sehe ich kein Problem dabei, wenn die Untersuchung so durchgeführt wird. Und wenn ihr wenige Stunden nach der Bearbeitung revertet und bei jedem Objekt darauf achtet, dass ihr der letzte Bearbeiter wart werden ja nur eure Einträge revertiert.

Der generelle Vibe ist aber für mich, dass hier Leute reinspringen, die einfach das Haar in der Suppe finden wollen, anstatt zu überlegen, wie das Projekt für alle beteiligten sinnvoll ablaufen kann.

Das sehe ich auch so. Zumal wenn man beachtet, dass die Opponenten hier ohnehin nicht die lokale Community darstellen sondern aus Deutschland herein funken.
In OSM wird so viel Schindluder getrieben. Heute waren z.B. noch immer Kacheln zu sehen mit Straßen, welche mit Hassbotschaften und Flüchen benannt waren (laut Forum fand der Vandalenakt gestern statt!). Die Entscheidungsträger in OSM täten also gut daran, auch bei diesen wirklich ernsten Angelegenheiten die gleiche penible Verve an den Tag zu legen. Ansonsten wirkt dieses bürokratische Gebaren hier einfach nur unglaubwürdig. Sorry so viel Kritik muss sein.