Detailmapping in Heidelberg

Ja, das stimmt, eigentlich sollte es nicht um Formulierungen gehen. Ich nehme meine penible Anmerkung zurueck! :wink:

Seit dem 6.6. und meiner Nachfrage sind nun einige Tage ohne Reaktion vergangen. Es war nicht die einzige Nachfrage, die beim “Detailmapping Heidelberg”-Team konkrete Problemstellungen, die ‘Getrennt Mapping’ von Gehwegen erfordert, erfragte.

Es hieß es sei ein Team, welche hier (auch) um Rat fragt. Das stelle ich nun doch auch stark in Frage.

Parallel geht das getrennt Mapping weiter und bestätigt mindestens meine Vorurteile, worüber ich ernsthaft erstaunt bin: fiktive Verbindungswege, die Überwege über die Straße schaffen sind Inkonsistent, Wege enden sehr unvermittelt – Work in Progress.

De facto ist der OSM Stand des Heidelberger Nordens also seit etwa 6.6. einigermaßen ‘unbrauchbar’, weil die Mappenden dem Anschein nach nicht darauf achten, mit Ihren Changesets stets eine funktionsfähige Karte zu hinterlassen, sondern sich vielmehr ihrem “großen Ziel” verschrieben haben. Soviel Missachtung für das Bestreben der OSM und der Community die Karte jederzeit in einem ‘akzeptable’ verwendbaren Zustand zu haben führt bei mir zu mehr als Irritation und stimmt mich traurig.

Wer mag: Die Goteinstraße ist gerade ein Paradebeispiel für Fragezeichen: Wenn ich von Hausnummer 3 zu 8 möchte, muss ich dann zur Kreuzung vor laufen? Von der Wielandstraße 1 kommt man scheinbar nicht zum Friedhof – jedenfalls nicht auf direktem Weg. Zwei Beispiele, die ich bei einfach nur draufzoomen gesehen habe, ohne länger zu suchen.

Wie mag die Community damit umgehen?

p.s. One more thing: https://www.openstreetmap.org/#map=19/49.41579/8.68893 – der Gehweg führt an der südlichen Seite der Schröderstraße wohl über die Häuser. Oder so.

http://osmose.openstreetmap.fr/en/map/#zoom=16&lat=49.41763&lon=8.68439&item=1070&level=1%2C2&tags=&fixable=

Es sind nur überlappende Objekte als Warnungen aktiviert. Quasi jede Überquerung der separat gemappten Wege über die Straße stellt eine Überlappung dar, weil keine Knoten gesetzt wurden.

Das ärgert mich nun tatsächlich, da ich Dokkan in einem Changeset Anfang Juni darauf hingewiesen hatte.

@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