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:
- (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.
- 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.
- 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.
- 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