Detailmapping in Heidelberg

@tudacs: Genau das (Osmose) wollte ich auch gerade schreiben.

Ohne jetzt alles hier im Detail verfolgt zu haben, kommt mir die folgende “Regel” in den Sinn: Nur separat mappen, was auch baulich getrennt ist. In Heidelberg sieht es nun so aus, als wenn die Bürgersteige immer baulich getrennt von den Straßen angelegt sind. Aus meiner Sicht eine routingtechnische Katastrophe.

https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=49.41690%2C8.68537%3B49.42042%2C8.68463#map=17/49.41874/8.68581
:roll_eyes:

Ja, das ist diese Art von Mapping fast überall.

Nachdem es sich aber de Fakto nicht verhindern lässt, gäbe es aus meiner Sicht zwei Hilfslösungen:

  1. highway=footway bei Gehsteigen zwingend mit footway=sidewalk ergänzen
  2. für solche “unechten” Wege ein highway=sidewalk etablieren.
    Damit könnten Router und Renderer diese Wege gezielt ignorieren bzw. spezialisierte Anwendungen diese gezielt bevorzugt nutzen.
    Gegen 1. spricht, dass es komplizierter ist und der Zusatz viel zu gern vergessen wird.

Ein wahres Füllhorn an Fehlroutings …

https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=49.41904%2C8.68140%3B49.41907%2C8.68106
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=49.41927%2C8.68288%3B49.41830%2C8.68203
ganz zauberhaft: https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=49.41393%2C8.68461%3B49.41411%2C8.68628

Die ausführliche Darlegung der Nachteile des Separatmappings haben die Verantwortlichen offenbar nicht überzeugt. Wenn jetzt auch noch handwerklich miserable Arbeit dazukommt (keine shared Nodes an Kreuzungen), finde ich die Verschlechterung des Datenbestandes schwerwiegend genug, um da eine Bremse reinzuhauen. Der Datenbestand ist im gegenwärtigen Zustand nicht gut benutzbar!

–ks

Die getrennten Wege auch noch durch Haeuser durch zu zeichnen finde ich lieblos. Offensichtlich ist es doch relativ kompliziert, die extra Geometrien konsistent einzutragen. Waere ich dort lokaler Mapper, waere ich wirklich enttaeuscht.

Als Kerb height habe ich drei diskrete Werte gefunden (ohne alles runterzuladen): 0cm, 3cm und >3cm. Was hat es damit auf sich? (Edit: Das waere auch fuer mich interessant, weil ich grenzwertige Faelle aus mangelndem Wissen derzeit nicht eintragen kann)

Lg, Gppes

Höhe der Bordsteinkante? Ich denke das ist für mobilitätseingeschränkte Menschen eine wichtige Information. Ein normaler Fußgänger bemerkt einen Bordstein nichtmal, ein Radfahrer flucht kurz, ein Opi mit Gehwagen kriegt’s irgendwie hin, ein Rollifahrer muss umdrehen.

Mich interessieren die konkreten Werte. Ich habe schon wheelchair access getaggt. Bis jetzt waren meine Regeln:

  1. Ueberwinden mit dem Rennrad ohne den Arsch zu heben: Muss mit dem Rollstuhl auch gehen
  2. Gar nicht abgesenkt: Wird mit dem Rollstuhl nicht gehen
  3. Alles dazwischen: Nicht eingetragen, weil ich es nicht weiss.

Kann jemand was konkret zu den Zahlen sagen?

Lg, Gppes

zu den 3cm:

https://nullbarriere.de/din32984-querungsanlagen.htm

Das ist auch im wiki zu “kerb” erläutert:
https://wiki.openstreetmap.org/wiki/Key:kerb

Oh Gott, hier auch:
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=50.94120%2C6.95678%3B50.94126%2C6.95821

Bei dem “Router” scheint wirklich handwerklich supoptimale Arbeit vorzuliegen, sollte man das wirklich zum Maßstab des Mappings machen …
Jo

Moin,

die Router sind nicht optimal – aber das Köln Beispiel geht etwas an Heidelberg vorbei und droht ein bisschen eine Nebelkerze und Entschuldigung für fehlgeleitetes Mapping, wie es gerade in Heidelberg praktiziert wird, zu wirken.

Ich zitiere mal aus dem Ausgangspost:

Ich warte auf die Anleitung/Beschreibung. Seit dem 23.4. wird da ‘etwas’ getestet und führt zu quasi unbrauchbaren Kartenteilen.

Meine Nachfrage zur Präzisierung

blieb unbeantwortet.

Wenn es um (Barrierefreies) Routing geht, aber bloß kein Router angefasst werden soll, ist das Mapping “handwerklich miserabel” (danke, ks, für die Formulierung). Wenn ein ein neuer Router entstehen soll (mal hypothetisch gedacht), der mit dieser Art mapping arbeitet, dann ist das aktuelle Vorgehen und der Ausgangspost miserabel und zudem ein Bruch mit “don’t map for the router”.

Ich würde mir wünschen, dass die Verantwortlichen des Geographischen Instituts sich hier einklinken würden. Es nutzt ja nichts, mit den Studenten des Instituts hier zu diskutieren, wenn diese auf der anderen Seite durch fachliche ‘Vorgesetzte’ irgendwas diktiert bekommen.

Hat jemand Kontakt zur Orga-Ebene der SotM Heidelberg Konferenz? Das Mapping gerade droht ja gerade eher ein unfassbares Negativbeispiel für “the state of the map” (den Zustand, nicht (unbeding) die Konferenz) zu werden…

+1

Wurde hier nicht schon oefter diskutiert, dass das gezeigte Beispiel des Kollegen (Routing ueber Flaechen) generell schwierig ist?

Mannomann… Angesichts der schlechten Kommunikation und des schlechten Mappings wäre ich dringend für eine Bremse, und evtl. sollte man auch eine Zeitmaschine in Erwägung ziehen…

Die OSM Datenbank ist nicht dafür gemacht, Testfeld für bestimmte Projekte zu sein, und die Teilnehmenden sollten sich an bestehende Regeln (die es ja nicht aus Spaß gibt) halten. Das passiert hier offensichtlich nicht.

Das liegt nicht am Mapping, sondern wirklich am Router – der routet noch nicht frei über Flächen.

Die Heidelberger Umwege (und nur um die geht es hierzuthread) sind eine andere Baustelle, die liegen eindeutig am unvollständigen Mapping.

–ks

Hallo,

ich habe mich bislang aus der Diskussion herausgehalten und sie auch nicht wirklich verfolgt. Ich habe sie mir jetzt durchgesehen und auch ein Auge auf den Status quo in OSM in Heidelberg geworfen. Ach du liebe Güte ist das schrottig. War Namo in Bad Nauheim und Frankfurt auch so schlimm (ist schon ein paar Jahre her)?

Ich habe soeben eine Beschwerde bei der DWG eingereicht und gebeten, Dokkan eine blockierende Nachricht mit Lesebestätigung zu senden.

Ich bin Mitglied der State of the Map Working Group der OSM Foundation, aber nicht aus Heidelberg. Diese Mappingaktivität geht allein auf das örtliche Organisationsteam zurück, das auch in den zwei Tagen vor der SotM den HOT-Gipfel organisiert. Die Mappingaktivität ist AFAIK nicht Thema in den Sitzungen gewesen und auch in unserem internen (nicht öffentlichen) Projekt auf GitHub wurde darüber AFAIR nicht diskutiert. Ich habe der gesamten Working Group soeben eine Mail geschrieben.

Sollten die Mängel bis Mittwoch nicht ausgeräumt sein, wird es Zeit, sie mit dem einfachsten Mittel zu beseitigen, d.h. eines Reverts oder einer systematischen Löschung der Bürgersteige.

Viele Grüße

Michael

EDIT: Ich möchte noch anmerken, dass trotz der negativ überraschenden Qualität zu meinem aktuellen Negativbeispiel für organisiertes Mapping, das ich auf der FOSSGIS 2019 vorgestellt habe, noch ordentlich Platz ist.
EDIT 2: Geschlecht korrigiert

Soeben über diese Kreuzung gestolpert:
https://www.openstreetmap.org/edit?node=2640742303#map=20/49.97769/8.43670
Da können sich die Heidelberg-Detailmapper noch etwas abschauen, zumindest die Kreuzungspunkte scheinen alle verbunden zu sein :wink:

Aber etwas ernsthafter, die Kreuzung passt wohl eher als Beispiel in diesen Faden:
“Für die Kreuzungsfahrspurentwirrer (Spurmapping vs. Spurtagging)”
https://forum.openstreetmap.org/viewtopic.php?id=65554

Hallo,

ich bin gebeten worden, klarzustellen, dass die Aktion nicht von dem örtlichen Teils des SotM-Organisationsteams ausgeht. Im Speziellen ist die folgende Aussage nicht richtig:

Die Aktivität stammt von Angehörigen der Universität Heidelberg, die aber nicht Mitglieder des SotM-Organisationsteams sind.

Viele Grüße

Michael

Es war ja nicht näher spezifiziert, welcher Mittwoch… :confused:

Also hier nun der Versuch eines “Nachrufs”:

Nach dem 2. Juli 2019 war die Mappingaktivität zum “Detailmapping Heidelberg” abrupt verstummt, die Daten in dem Bereich lagen nun etwa ein Jahr an manchen Stellen etwas hilflos in der Gegend herum (offene Weg-enden, fehlende Verbindungswege, Wege durch Gebäude hindurch, “doppelte” Gehwege (getrennt+tags) …). Letzte Woche habe ich mich bemüht, die Übergänge zwischen dem Detailgemappe dort und “dem Rest” einigermaßen sauber zu gestalten und die aus dem Boden sprießenden Notizen (ala “Weg endet hier?!”) zu schließen.

Ich denke der Thread spricht in Summe für sich und wünsche der OSM mehr Mapper, die im Kleinen kontinuierlich zur Karte beitragen und die Daten verbessern.

[EDIT P.S:] Der Wikiseite zum Projekt habe ich einen Absatz zum offensichtlichen(?) Ende des “Projektes” voran gestellt. Kann da jemand mal drauf schauen, ob das neutral aber deutlich genug ist? Ich fände es gut, wenn dort a) sichtbar ist, dass da nix mehr passiert, b) darf dort mMn durchaus auch sichtbar sein, dass es kein rühmlicher Abschluss ist, c) wäre es eigentlich an den Projektteilnehmern gewesen, die Wikiseite bei Beendigung upzudaten und im Zweifelsfall Hinweise zu hinterlassen, wieso manche Enden offen sind.

Vielen Dank für Deine Arbeit! Ich weiß, wie mühsam solche „Aufräum“-Aktivitäten sind und dass sie leider meist wenig Dank einbringen, aber solche Arbeiten sind wirklich wichtig, um die Karte ordentlich und die Daten bearbeitbar zu halten.

Ja, es ist sehr schade, aber leider nicht das erste Mal, dass eine solche mit viel Elan und eigentlich besten Absichten begonnene Aktion (ich meine jetzt nicht tudacs’ Aufräumarbeit, sondern das Projekt „Detailmapping in Heidelberg“) recht durchwachsene bis problematische Ergebnisse hat. Ebenso schade finde ich es, dass die Mitwirkenden dann ihr Projekt einfach abbrechen und nicht selbst versuchen, die gröbsten entstandenen Probleme zu bereinigen. Wir machen alle Fehler, aber „man“ könnte wenigstens versuchen, sie zu beheben, wenn man auf sie aufmerksam gemacht wird …

Meine Hauptbedenken beim Mappen von Gehwegen als getrennte Ways sind, dass das mit viel Disziplin und Sorgfalt gemacht werden muss, wenn nicht massenweise Mappingschrott erzeugt werden soll. Hier ist das wohl leider ein Paradebeispiel dafür.

Das Geografische Institut hat sich hier mMn nicht gerade mit Ruhm bekleckert. Das war vermutlich ein studentisches Projekt, bei dem üblicherweise die Studenten nach der Abschlusspräsentation auf Nimmerwiedersehen (für OSM) in die Semesterferien entschwinden. So etwas ist vorauszusehen und deshalb sollten Daten erst nach Überprüfung durch die Projektleitung schrittweise in OSM eingetragen werden. Bis dahin können die Studenten sehr gut mit einem lokalen Abzug der OSM-Daten arbeiten. Für das Ausbildungsziel müssen die Studenten nicht notwendig live in OSM arbeiten.

Aber “d’ Katz isch scho da Boom nuff” und für die Zukunft würde ich allen Projektverantwortlichen in spe ins Stammbuch schreiben, schon bei Projektbeginn an das Projektende zu denken.