Neues aus der Rubrik Multipolygonwahnsinn...

Hallo zusammen,

in der Folge z.B. des Beitrags Multipolygonwahnsinn - oder: Durchblick war gestern!

mal ein neuer Aufguss…

Seit einiger Zeit beobachte ich diese beiden MP-Fehler: http://tools.geofabrik.de/osmi/?view=areas&lon=12.56585&lat=52.40032&zoom=18&opacity=1.00 mutmaßlich hervorgerufen durch die CS https://www.openstreetmap.org/changeset/113316880#map=18/52.40025/12.56620 und https://www.openstreetmap.org/changeset/113316893#map=18/52.39999/12.56451 Beide CS habe ich entsprechend kommentiert…

Ich frage mich und euch:

  1. was soll das…
  2. Warum werden bei diesen Bahnsteigdingen sklavisch komplizierte MP-Relationen eingesetzt.
  3. Warum ist den Erstellern offensichtlich eine OSM-konforme geometrische Korrektheit ein stückweit egal?
  4. Was ich “osmlab osm-request”
  5. Was ist “created_by:library=OSM Request 1.2.9”

Ich persönlich halte alle diese railway=plattform-Pseudo-MP’s für total unnötig… Hier mal die Auswertung für Brandenburg: https://overpass-turbo.eu/s/1ehQ Meiner Meinung nach lässt sich das entweder relationsfrei oder als MP ohne mehre outer abbilden…

Sicherlich, Relationen/ Multipolygone im weiteren Sinne sind elegante Dinge, diese müssen aber bitte nach bestem Wissen und Gewissen äußerst sparsam eingesetzt werden. Das hier ist leider etwas zu sehr inflationär… :frowning:

Sven

Der User arbeitet nicht mit JOSM.
OSMI wird er sich auch nicht anschauen.
Er wird es schlicht nicht merken.
Ich beseitige normalerweise MP-Fehler vor meiner Haustür.
Aber dieses “Konstrukt” dort verstehe ich nicht.

Er arbeitet auch mit iD, aber nicht nur… aber das oben genannte ist mir fragwürdig und nicht von iD… Das iD bei sowas gerne mal Schrott produziert ist ja hinlänglich bekannt…

Das ist schlecht!

… hast wohl einen guten Lehrer gehabt was … :smiley:

Ich auch nicht, das ist ja mein Problem…

Viele Grüße,

Sven

https://wiki.openstreetmap.org/wiki/DE:Tag:railway=platform%20edge?uselang=de

Allerdings ist dieses MP irgendwie nicht nachvollziehbar in sich verschachtelt. Eigentlich dürfte es bei Gleis 4 nur ein MP geben mit 2 outer (1 Bahnsteigkante Gleis 4, 1 weiteres outer, wo keine Züge halten) und ein inner für die Öffnung der Treppe.

Das ganze ließe sich auch ohne Relation lösen, wenn man Bahnsteigfläche und Bahnsteigkante als verschiedene Objekte betrachtet und die Kante einfach als zusätzliche Linie deckungsgleich an die entsprechende Seite der Fläche zeichne. So wie ich einen Zaun an einer Weide ebenfalls separat zeichnen würde anstatt die Weide als MP zu verhackstücken

Hallo,

das eine Multipolygon für Bahnsteig 4 ist ok, es besteht aus äußerem und innerem Ring und stammt von einer Mentz-Mitarbeiterin von 2016. Das sah auf den ersten Blick in der History auch gültig aus (1 Ring außen, 1 Ring innen für den Treppenabgang; den Aufzugsschacht hat sie wohl vergessen).

Der von streckenkundler verlinkte Änderungssatz hat die Mitgliedschaft des äußeren Ways gelöscht und stattdessen eine Relation (type=multipolygon) mit der Rolle “outer” eingefügt. Dieses hat wiederum zwei Mitglieder, nämlich die gleisseitige Bahnsteigkante und den Rest des Bahnsteigs. Das ist falsch.

Ins Auge springt mir auch das created_by=*-Tag am =https://www.openstreetmap.org/changeset/113316880Änderungssatz, das klar einen Bot kennzeichnet und somit unter den Automated Edits Code of Conduct fällt. Der Benutzer hat noch ein paar weitere Änderungssätze mit dem Bot hochgeladen. Ich habe den Änderungssatz kommentiert und bin mal gespannt, was ich als Antwort auf meine Frage nach Dokumentation und Diskussion erhalte.

Ich vermute entweder einen Bug im Bot, den man im Rahmen der Diskussion und Dokumentation schon auf die Schliche hätte kommen können (z.B. indem ein Diskussionsteilnehmer einen Testlauf fordert) oder Wissenslücken des Benutzers/Programmierers in Bezug auf Multipolygone (was ein No-Go für einen Bot-Programmierer ist, wenn es um Relationen geht).

Allgemein zu Bahnsteigkanten:

Bei Bahnsteigen, die zwischen zwei Gleisen liegen, ergibt die Erfassung von railway=platform_edge + ref= Sinn. Bei Außenbahnsteigen ist es Unsinn. Es gibt dort nur ein Gleis, das in Bahnsteignähe liegt. Die anderen sind weiter als eine Schrittlänge des Normalfahrgasts + halbes Fahrzeugumgrenzung + Toleranz entfernt.

Ich habe lange Zeit Bahnsteigkanten bei Insel-/Zwischenbahnsteigen mittels Multipolygonen gemappt. Das ist aber unnötig, wenn es keine Löcher im Bahnsteig für Treppenaufgänge o.ä. gibt (z.B. Bahnsteige, die nur am Ende per Treppe/Aufzug angebunden sind, oder solche, die nur über höhengleiche Reisendenübergänge erreicht werden). Wenn man ein Multipolygon nicht aus anderen Gründen benötigt, kann man auch einfach überlappende Ways erfassen, die sich die Nodes mit dem Bahnsteig-Polygon teilen.

Eine Diskussion des Bots im Vorfeld hätte solche Probleme wie jetzt sicherlich vermeiden können.

Ob ich den mechanischen Edit revertiere oder wie ich da aufräume, weiß ich derzeit noch nicht.

Viele Grüße

Michael

Hallo allerseits,

die Edits kamen von mir, daher auch nochmal meinerseits ein paar Zeilen zur Erklärung. Zunächst mal zum Sinn von platform_edges allgemein: Um einige Features moderner ÖPNV-Auskunften auf Basis von OSM implementieren zu können, ist es wichtig, eine Bahnsteigkante sowohl über ihre Nummer (also z.B. Gleis 3) als auch ihre ID(s), also in der Regel IFOPT identifizieren zu können. Grundsätzlich ließe sich das zwar auch über die Kombination einer platform und einer nummerierten stop_position auf dem zugehörigen Gleis erreichen, mit diesem Ansatz gibt es jedoch ein paar Probleme:

  1. (Alleine genommen ist das Folgende nicht zwingend ein ausschlaggebendes Argument, es ist m.E. trotzdem wichtig, daher liste ich es hier auf) Die Ableitung von Informationen über Bahnsteigkanten ohne das Mapping von platform_edges (also nur aus stop_positions und platforms) ist zwar in vielen Fällen möglich, jedoch absolut kein triviales Problem, insbesondere im Falle von Bahnsteigen in Kurven oder Weichen im Bahnsteigbereich.
  2. Bahnsteige sind oft länger als die tatsächlich zugänglichen Bahnsteigkanten, häufig ist der letzte Teil des Bahnsteiges mit einem Zaun abgegrenzt, ein Ein- oder Ausstieg ist dort nicht möglich. Natürlich ließe sich auch diese Information ableiten, falls der entsprechende Zaun o.Ä. eingetragen ist, allerdings ist eine solche Berechnung vergleichsweise umständlich.
  3. Es gibt Bahnsteige, die an einer Kante mehrere Gleisbezeichnungen haben (z.B. heißt die erste Hälfte des Bahnsteiges “Gleis 1” und die andere Hälfte “Gleis 1a”). Dies lässt sich nicht über stop_positions abbilden.
  4. An Bahnsteigen mit Stummelgleisen ist die Ableitung der Bahnsteigkante aus der stop_position oft auch nicht eindeutig.

Aus diesem Grund habe ich vor etwa einem Jahr zunächst alle Bahnsteige der S-Bahn Berlin mit platform_edges gemapped, und vor einem Monat auch einige Bahnsteige in Brandenburg. Grundsätzlich habe ich bei den meisten Bahnsteigen zunächst die platform_edges in der vollen Bahnsteiglänge gemapped, allerdings trifft der o.g. Punkt 1 auf sehr viele davon zu, und das veränderte Mapping ermöglicht in Zukunft eine einfache Anpassung der Länge der platform_edge. Bei der Verwendung von Multipolygonen bin ich dem Mapping existierender platform_edges gefolgt, d.h. für “normale” Inselbahnsteige ergibt sich 1 Multipolygon mit vier “outer”-Wegen, nämlich den zwei Bahnsteigkanten und den zwei kurzen Seiten. Die Bahnsteigkanten separat als neuen Weg anzulegen, wäre inkonsistent zu bestehenden Mappings gewesen, außerdem ergibt dies m.E. nicht allzu viel Sinn, da Bahnsteig und Bahnsteigkante untrennbar zusammengehören. Wenn beispielsweise der Verlauf des Bahnsteigs korrigiert wird, ändert sich logischerweise auch der Verlauf der Kante. Eine separate Kartierung könnte dies nicht garantieren. Zudem gehören Bahnsteig und Bahnsteigkante hierarchisch zusammen, im Fall der separaten Kartierung müsste also eine andere Lösung gefunden sein, dieses Verhältnis zu kennzeichnen. (Aber vielleicht ist das trotzdem der bessere Ansatz, ich weiß es nicht.)

Im Bezug auf das konkrete Problem: Es tut mir Leid, dass da etwas kaputt gegangen zu sein scheint, ich schaue mir das in den nächsten Tagen gerne nochmal an und korrigiere, falls ich verstehe wie das Mapping korrigiert werden müsste.

Bezüglich des “Bot”-Edits: Ich habe im von @Nakaner verlinkten Changeset schon kurz beschrieben, wie dieser User-Agent zu stande kam: Ich wollte Ways in Relations umwandeln, habe dafür jedoch keine Funktion in iD gefunden, und das JOSM-UI ist eine Sache für sich, also habe ich die Changesets dafür manuell erstellt und reviewed, und dann via osm-request (node.js) an die OSM-API geschickt. Um einen Bot handelt es sich dabei aber nicht.

Long story short: Ich hoffe, das konnte einige eurer Fragen beantworten, es tut mir in jedem Fall leid, falls ich euch irgendwelche Umstände bereitet habe, auf der positiven Seite möchte ich aber auch noch erwähnen, dass ich bei DB-nahen Veranstaltungen schon von zwei Personen Feedback bekommen habe, dass ihnen die platform_edges in Berlin bei der Entwicklung von ÖPNV-Anwendungen sehr helfen (das alleine ist natürlich kein Totschlagargument, aber zeigt vielleicht, dass ich das nicht nur mache, weil mir langweilig ist :D)

In dem Sinne viele Grüße
Julius

Als erstes +1 dafür nicht beides als ein Objekt zu Taggen.
Während ein Zaun nicht unbedingt mit der Weide verbunden und auch nicht gerade geometrisch exakt identisch ist, ist dieses bei einem Bahn-/Bussteig und seiner Kante aber gegeben. Daher sehe ich eine Relation hier eigentlich als das korrekte Objekt. Bevor ich jetzt Linien übereinander zeichne wäre eventuell eine Lösung mit Linienknoten für den Anfang bzw das Ende der einzelnen Abschnitte eine mögliche Alternative. Überzeugt mich aber auch nicht wirklich.

Kenne iD nicht, aber auch da sollte es eine Funktion für geben. In JOSM ist das Multipolygon erstellen (Strg+B). Etliche Bahnsteige sind aber schon als MP eingetragen, dann sollten diese entsprechend angepasst werden. Dabei kann gerne auch noch das ein oder andere bisher vergesssene “inner” (z.B. Treppenschacht oder Aufzug) mit eingepflegt werden.
Wie kann ich mir so einen “Review” vorstellen? Ich hätte dafür JOSM benutzt, aber dann hätte ich es ja auch damit gleich hochladen können. :smiley:

Von iD weiß ich, dass es mit Relationen viel Müll baut, daher rate ich Dir einen anderen Editor zu verwenden. JOSM hätte Dich auf jeden Fall bei einigen Konstrukten auf Fehler hingewiesen. :slight_smile:

Kannst Du das mal bitte ausführlicher erläutern, ich verstehe nicht, was Du meinst.

Hallo,

sucht du vielleicht das?

Neue Relation auswählen, dann kommt das

Gruß
Danfost

1 Like

Nee, kann ich nicht, da ich mir selbst noch nicht viele Gedanke dazu gemacht habe und wohl auch nicht machen werde. Was ich meine ist dass, anstatt übereinander liegenden Linien jeweils für die Steigkante bzw auch die Abschnitte nur ein Knoten an den beiden Enden gebraucht wird, mit entsprechenden Tags, aber Richtungen und Knoten ist ja auch nicht ohne und eigentlich habe ich nichts gegen die Relationen.

Wenn, dann Frage ich mich eher, warum wir nicht bei Haltepunkten auf beiden Seiten die Steige nicht auch als zwei aneinandergrenzende Flächen eintragen. Bei nur einer Fläche für mehrere Steignummer brauche ich immer ein zusätzliche Objekt, um die Seite der Nummer zuordnen zu können.

Stimmt, das habe ich manchmal sogar schon gesehen. Kommt auch vollkommen ohne MP aus, nicht einmal das Loch für Aufzug und Treppe müssen ausgestanzt werden.

Auch die A - B - C - E Abschnitte ließen sich mit Teilflächen abbilden. Wobei ich mich - egal ob Kante oder Fläche - hierbei frage, ob wir hier mit diesen klar abgrenzbaren Teillinien/Teilflächen nicht eine Genauigkeit suggerieren, die in der Realität gar nicht existiert. Da existieren diese Abschnitte nur als Schilder (irgendwo in der Mitte des jeweiligen Abschnittes*) und als Markierung auf dem Wagenstandsanzeiger am Bahnsteig, aber selbst auf denen nur als Symbol/Buchstabe ohne konkrete Angabe von…bis…

  • genaugenommen wären diese Abschnitte in OSM sinnvollerweise nur als Punkt abzubilden, da dies nur eine ungefähre Angabe bedeutet. Und zwar als Punkt an der Stelle, wo sich am Bahnsteig das entsprechende Schild befindet.

Da habe ich jetzt schon alles gesehen, von nur abgeschätzten Sektoren, zu markierten Sektorgrenzen bis hin zu Absperrungen an der Kante mit nur kleinen Einlässen mit automatischen Barrieren.

Wenn ich das alles jetzt in einzelne Flächen zerlege wird es recht schwierig. Ich habe jetzt schon Probleme, bei denen das Objekt Bahnsteig aus mehreren Flächen besteht, da z.B. ein Teil aus einer Brücke besteht oder sich das tacticle_paving und surface sich ändert. Wir haben bisher keinen Objekttypen der aneinandergrenzende Flächen zur einer Fläche zusammenfasst. Eventuell sollte ich mal über die Trennung von highway/railway=platform und public_transport=platform nachdenken.

Solche Importe produzieren auch völlig unsinnige MPs:
https://www.openstreetmap.org/relation/7925344

Mal abgesehen von vielen weiteren Fehlern: die outer gehen schräg über Straßen, quer durch Gebäude und kommen sich mit Wohngebieten ins Gehege.

Das benachbarte Moor ist mit knapp 350 Mitgliedern allerdings noch grausiger:
https://www.openstreetmap.org/relation/7928654#map=13/69.1126/15.7064

Ei Lecker… https://overpass-turbo.eu/s/1ess :frowning:

Soviel meiner “Lieblinge”

Sven

mal wieder was aus dieser Rubrik:

Heute: der Grunewald:

  1. https://www.openstreetmap.org/relation/9600988

Öhm, was denn nun:

  1. https://www.openstreetmap.org/relation/3410 oder…

  2. https://www.openstreetmap.org/relation/6425259

zu mindestens die dritte Relation scheint vollständig eigene Geometrien zu haben…

Die anderen beiden aber teilen sich in verschiedener Art- und Weise Geometrien: Forst mit LSG… Wie weit dann noch, da sehe ich noch nicht ganz durch.

Vermutlich hat User questmarker u.a. mit CS https://www.openstreetmap.org/changeset/118298481 unwissentlich da einiges kaputt gemacht, was ich aber nicht ihm, sondern (mal wieder) iD ankreide… seine Intention war richtig: er wollte Teilflächen, die LSG sind, zu diesem hinzufügen. Nach https://wiki.openstreetmap.org/wiki/Geoportal_Berlin ist der WMS-Dienst

https://fbinter.stadt-berlin.de/fb/wms/senstadt/nsg_lsg? 

eine verwendbare Quelle. Danach wäre die Grundintention korrekt!

Jetzt dachte ich, daß es einfach wäre, ist es aber nicht. Für mich muß das nach verschiedenen Bereichen getrennt werden: z.B. 1. Schutzgebiete, 2. Waldbereiche, 3. Umgrenzung, was alles “Grunewald” ist…

Meinungen und Hilfsangebote werden gerne entgegengenommen.

Sven

Meiner Meinung nach machen die 3 Relationen Sinn:

  1. Ist das Landschaftsschutzgebiet, die Löcher sind andere Schutzklassen (Naturschutzgebiet)
  2. Ist landuse “Wald”, Löcher sind andere Nutzungen. Nur das protection_title - Geschützte Grünanlage sollte raus
  3. Ist das Hundeauslaufgebiet, auch hier sollte das protection_title - Geschützte Grünanlage raus