[OSM-Dresden] Konflikte mit einem Mapper

[Michael Reichert]

Hallo Wolfgang, hallo Peter,

Am 2015-10-10 um 23:40 schrieb Wolle DD:
> ich habe in den letzten Wochen Probleme mit einem Mapper, der meine Arbeit
> an Bahnhöfen und Haltepunkten der S-Bahn Dresden verändert und auf meine
> Mails mit Lösungsvorschlägen nicht reagiert und zuletzt ein Changeset von
> mir revertet hat.

Ich habe mit dem Mapper auch Probleme (und auch den Verdacht, dass seine
Quellen nicht zulässig sind) – aber das ist eine andere Geschichte und
wäre hier größtenteils Off-Topic. ;-)

> Vor über einem Jahr habe ich alle Bahnhöfe und Haltepunkte unter anderem
> der S-Bahn Dresden nach dem public_Transport Schema einheitlich getaggt und
> dabei die Bahnsteigflächen als MP getaggt und die Kanten zu den Gleisen
> eindeutig benannt.
> Nun musste ich leider feststellen, dass dieser Mapper an einigen Bahnhöfen
> und Haltepunkte Änderungen vorgenommen hat, die falsch, überflüssig oder
> deren Informationsquellen höchstwahrscheinlich nicht für die Verwendung in
> OSM zugelassen sind. Dabei wurden auch Informationen, wie die Benennung der
> Bahnsteige, teilweise gelöscht. Dazu kommt noch, dass diese Änderungen an
> verschiedenen Bahnsteigen unterschiedlich waren: Mal war der Name noch
> vorhanden, mal nicht, mal wurde ein Fußweg für Blinde (!) eingezeichnet,
> mal die Bahnsteige als platform_edge bezeichnet, mal als platform (trotz
> dass der MP ja die Eigenschaften vererbt), usw.

Es gibt vier Methoden Plattformen zu erfassen:

(1) als Punkt – bloß bei Bussen gebräuchlich

(2) als Way ohne area=yes, wenn man die genaue Geometrie nicht kennt,
aber die Länge des Bahnsteigs kennt (bei Neubauten und durch
Laub/Schatten schlecht erkennbare Bahnsteige)

(3) als Fläche mit area=yes + ref=1;2 (wenn der Bahnsteig auf beiden
Seiten eine Kante zwecks Fahrgastwechsel hat). Ich verwendet diese
Methode, wenn es sich um einfache Bahnsteige ohne Abschnitte/Sektoren A,
B, C, D usw. (gibt's i.d.R. nur auf Fernverkehrsbahnhöfen). Wenn der
Bahnsteig mehr als zwei benannte Kanten hat oder ich die
Bahnsteigabschnitte erfasse, verwende ich Methode (4b). Wenn

(4a) Als Multipolygon. Diese Methode wurde von Mentz DV verbreitet und
war in der Prä-Mentz-Ära in Deutschland exotisch. Im Prinzip
funktioniert sie wie (3), aber die Tags hängen am Multipolygon und die
Fläche aus (3) ist dessen Outer-Way. Die Inner-Ways sind die Löcher, die
durch Treppenabgänge entstehen.

(4b) Als Multipolygon mit benannten Kanten. Diese Methode ist mit (4a)
kompatibel, funktioniert aber auch ohne Treppenabgänge. Auch hier trägt
das Multipolygon Tags wie railway=platform, public_transport=platform,
ref=1;2 Die gleisparallelen Ränder des Bahnsteigs werden mit
railway=platform_edge ref=1 getaggt. Das ist sinnvoll, wenn man der
Bahnsteig Abschnitte hat (A, B, C, D, …) oder mehr als zwei benannte
Kanten hat, z.B. 1a, 1b, 2a, 2b oder für so komplizierte Konstrukte wie
in Siegen, wo der Inselbahnsteig Zugang zu den Gleisen 3, 4, 54 und 55
bietet. (So ein Konstrukt gibt es auch in Essen Hbf und an anderen Orten)

Zum Thema Bahnsteigabschnitte siehe auch
https://lists.openstreetmap.de/pipermail/nahverkehr/2015-August/000016.html
https://lists.openstreetmap.de/pipermail/nahverkehr/2015-September/000017.html

Wenn man diese Bahnsteige in Routenrelationen aufnehmen will, muss man
das Multipolygon in die Routenrelation als platform-Member aufnehmen und
nicht den/die Outer-Ways. Das mag mit iD vielleicht nicht gehen, aber
dieser Editor ist auch nicht zum intensiven Editieren von Relationen
gedacht.

Es stimmt, dass railway=platform_edge von mir mal erfunden wurde. Erste
Diskussionen gab es dazu im Juli 2014 in Köln:
https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2014_1#Taggingdiskussionen
Es ist dazu vorgesehen, bei komplexen Bahnsteigflächen (wie Gleis
3/4/54/55 in Siegen) den Routern die Möglichkeit für sinnvolle Anweisen
zu geben.

@PeterDRS: Es ist nicht dazu gedacht, die Länge der Bahnsteigkante zu
ermitteln. Dazu braucht man dieses Tag nicht. Dazu legt man um die
Gleise in OSM einen Buffer (0,5 * Breite des Lichtraumprofils + ein paar
dm). Diese Buffer verschneidet man mit den Bahnsteigflächen. Die
resultierenden Flächen wandelt man mit Verfahren wie dem
Flächenbrandverfahren (oder andere Verfahren zur Gewinnung der
Mittellinie) in Linien um, deren Länge man dann messen kann. Ich habe
dir das am 19. August 2015 schon einmal gesagt.

train=yes an Plattformen ist legitim. Es gibt keinen Grund, zusätzliche
Tags zu verbieten, solange sie existierenden Tags widersprechen oder
deren Bedeutung umkehren.

Ich halte es für unnötig, Fußwege auf Bahnsteigen parallel zur
Bahnsteigkante zu erfassen, wenn der Fußweg nicht eine besonders
geschickte Abkürzung zwischen zwei Orten ist. Gescheite Fußgänger-Router
nehmen Bahnsteige in ihren Routing-Graphen auf (z.B. Graphhopper). Wir
mappen nicht für den Router.

In Dresden ist mir aufgefallen, dass Haltepositionen
(public_transport=stop_position) sich oft an der Stelle der Zugspitze
befinden. Ich finde das nicht richtig. Diese Punkte gehören IMHO an die
Mitte des kürzesten [1], dort eingesetzten Zuges, denn der
durchschnittliche Fahrgast will in den Zug einsteigen und nicht mit dem
Lokführer reden. Wer von euch beiden für die Lage der Haltepositionen
verantwortlich ist, habe ich nicht untersucht.

Viele Grüße

Michael aka Nakaner



[1] Das ist dann von Relevanz, wenn es sich um S-/Stadtbahnnetze
handelt, in denen zu unterschiedlichen Tageszeiten unterschiedlich lange
Züge verkehren (z.B. Karlsruhe, Heilbronn und Stuttgart).


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.openstreetmap.de/pipermail/dresden/attachments/20151011/7d3d811a/signature.asc>