Proposed_features/Metro_Mapping

Nakaner · 2017-10-04 23:16:45

Hallo,

auf der Mailingliste Tagging wurde in den vergangenen Tagen ein Tagging-Proposal namens Metro Mapping von Ilya Zverev diskutiert, dessen Abstimmung nächste Woche starten soll.

Ich weiß bis heute nicht, was außer der stop_area_group-Relation daran neu [1] sein soll. Wenn es nur um die stop_area_group-Relation geht, halte ich das ganze Drumherum für unnötig, was mich zu einer Nein-Stimme motivieren würde. Für eine Übersichtsseite im Stil von Public_Transport braucht es in meinen Augen kein Proposal, im Zweifelsfall kann man bestimmte Inhalte zur Diskussion stellen und fasst im Wiki dann den Diskussionsinhalt zusammen.

Darüber hinaus halte ich das Mappen von Umsteigeempfehlungen des Verkehrsbetriebs/Verkehrsunternehmens für unnötig und nicht mehr zeitgemäß, weil das bloß für Routing-Engines benötigt wird, die noch nicht im intermodalen Zeitalter angekommen sind.

Kommentare sind erwünscht. Bitte hinterlasst sie auf der Diskussionsseite im Wiki oder auf der Talk-Mailingliste oder auf der Tagging-Mailingliste.

Viele Grüße

Michael

PS Das Ganze ist von seinem Arbeitgeber, der Firma hinter MAPS.ME motiviert, welche ihre App um U-Bahn-Routing ergänzen möchte.

[1] neu heißt hier "über ein Proposal eingebracht"

Weide · 2017-10-05 06:59:27

Nakaner wrote:

Ich weiß bis heute nicht, was außer der stop_area_group-Relation daran neu [1] sein soll.

public_transport=station ist inkompatibel zu PTv2.

"light_rail" ist in PTv2 nur als Gleistyp aber nicht als Routentyp zulässig. In PTv2 bekommt man sämtliche Schienenrouten durch Suchen nach "train", "subway" und "monorail".

In PTv2 enthält eine Route alle "stop"s und "platform"s und niemals "station"s. Da steht aber: "Minimal mapped route: route=subway relation that contains just station=subway nodes"

Soweit PTv2 nicht schon tot ist wird es dadurch noch weiter gekillt.

Weide

Nakaner · 2017-11-11 12:22:57

Hallo,

die Abstimmungsphase hat begonnen und geht noch bis zum 24. November 2017. Ich habe mich deutlich gegen das Proposal ausgesprochen.

Hier mal die deutsche Übersetzung meiner Begründung, warum ich mit Nein gestimmt habe:

Dieses Proposal mag recht gut auf regionale Ebene funktionieren, es wird jedoch viel Verwirrung und Probleme mit sich bringen, wenn man es auf andere Länder anwendet oder gar versucht, es in Mitteleuropa anzuwenden. Außerdem widerspricht es der gelebten Mappingpraxis in einigen Punkten:
- Wie Martin Koppenhoefer bereits auf der Maillingliste [Tagging] ausgeführt hat, sind derzeit zahlreiche Stationen als Flächen erfasst. Ich sehe keinen Nutzen darin, diese Erfassungsweise für veraltet zu erklären. (Wer meine bisherige Meinung in der Frage kennt, möge beachten, dass sich diese in den letzten zwei Jahren geändert hat)
- Routenrelationen müssen die Gleise enthalten. Dieses Proposal versucht, das bestehende Schema zu ändern, ohne eine neue Versionsnummer einzuführen. Grob eingezeichnete Gleise sind besser als keine Gleise.
- Es ist üblich, Bushaltestellen und Bahnstationen, die denselben Namen haben oder nahe beieinander liegen (die Bahnstation heißt "A-Stadt Hauptbahnhof", die Bushaltestelle "Bahnhofsvorplatz"). Stop-Area-Groups führen eine neue Abstraktionsschicht ein. Ich vermute, dass sie nicht hilfreich sein werden, die Motivation unter den "normalen" Mappern für dieses Thema zu erhöhen.
- "Das Hinzufügen der Bahnsteige einer Station [zur Routenrelation] ist empfohlen." – Das widerspricht dem akzeptierten Proposal [(PTv2 aus dem Jahr 2011)], welches vorschreibt, dass Haltepositionen und Bahnsteige der Routenrelation hinzugefügt werden müssen, wenn sie erfasst sind.
- Das Tag area=yes ist nicht für Multipolygone erforderlich, aber dein Proposal schreibt vor, dass man das Tag allen flächenhaften Bahnsteigen hinzufügen muss.
- Das Proposal erwähnt mit keinem Word das Tag railway=halt, welches für kleine Stationen (in Deutschland für Stationen ohne Weichen) verwendet wird. Man kann, wenn man deinem Proposal folgt, keine validen Stop-Area-Relationen bilden, wenn die Station als railway=halt erfasst ist. Es gibt zahlreiche Stadtbahnhaltestellen [(lassen wir die Frage nach der Definition von light_rail mal bitte außen vor)], für die railway=station nicht angemessen ist.
- Das Proposal erlaubt nur ein Objekt mit railway=station pro Stop-Area-Relation, aber es gibt Stationen, die aus zwei oder drei Stationen bestehen, aber wie eine aussehen: diverse Stationen zwischen Berlin Westkreuz und Berlin Ostkreuz, diverse Stationen zwischen Hamburg-Altona und Hamburg Hbf, Köln Messe/Deutz.
- Im öffentliche Personennahverkehr wimmelt es an Ausnahmen. Ich habe es dir, Ilya, neulich erklärt. Man kann nicht erwarten, dass alle Routenrelationen, die in einer Masterroute zusammengefasst werden, dieselbe Liniennummer haben. Es kann Gründe geben, Linien mit unterschiedlichen Nummern zusammenzufassen. Mir fällt spontan nur ein Straßenbahnbeispiel ein: In Bremen gibt es Straßenbahnlinien mit einem S-Suffix. S bedeutet "schnell", weil sie nicht an allen Haltestellen halten. Daher schlage ich vor, diesen Satz umzuformulieren, sodass er Abweichungen erlaubt, wenn die örtlichen Umstände es vernünftig erscheinen lassen.
- Das Proposal schlägt ein network=*-Tag vor, beschreibt dessen Bedeutung aber nicht. Falls die Bedeutung unklar ist, so erwähne es doch bitte. Zumindest deutsche Mapper erfassen damit den Verkehrsverbund (Erklärung auf Wikivoyage), zu denen eine Linie gehört. Eine Linie kann zu mehreren Verkehrsverbünden gehören, wenn sie über die Grenzen eines Verkehrsverbunds hinweg reicht oder in einem Übergangsgebiet liegt. Das network=*-Tag gibt an Fahrkartenautomaten an, welche Verkehrsverbünde dort ihre Fahrkarten verkaufen.
Das Proposal basiert darauf, was legal gemappt werden kann. [Der Satz ist Quatsch, gemeint war eigentlich, was man in manchen Gegenden mappen kann] Es gibt bereits Betreiber von U-Bahnen und U-Straßenbahnen (z.B. die Rheinbahn in Düsseldorf), die ihre Gleise in OSM importiert haben. Man sollte nicht vergessen, dass es in OSM clevere/seltsame Leute gibt, die entweder Laserentfernungsmesser, Messbänder, Kameras, Laserscanner mit in die Stationen nehemn oder einfach mit offenen Augen durch die Station gehen. Ich habe beispielsweise während der SotM 2016 in Brüssel versucht, die Gleislage der U-Bahn zu verbessern. Zudem gibt es zahlreiche Stationen, die sehr einfach sind, weil sie flach unter der Straßenoberfläche liegen. Und selbst tiefere Stationen können einfach zu mappen sein, z.B. Wilhelm-Leuschner-Platz in Leipzig.

In dieser Begründung sind weitere Mängel nicht erwähnt:
- Das Proposal ist nur zu einem Teil ein Proposal und zu großen Teilen eine Anleitung wie U-Bahn-Stationen zu erfassen sind. Das lenkt von den Änderungen ab.

Anmerkungen (ganz und gar nicht neutral):

- Die französische Firma Carto'Cité, die im Auftrag der SNCF Bahnstationen mappt, hat in der Abstimmung schon gegen das Proposal gestimmt.
- Ilya Zverev, der Autor des Proposals, arbeitet bei MAPS.ME. Weil deren App ein ÖPNV-Routing ohne Fahrplandaten für Stadtschnellbahnsysteme bekommen soll, hat er das Taggingproposal geschrieben.

Viele Grüße

Michael

EDIT: Carto'Cité ist Auftragnehmer, meine Vermutung war richtig.

Last edited by Nakaner (2017-11-11 12:24:18)

Nakaner · 2017-12-13 14:56:38

Hallo,

Ilya hat einen neuen Versuch gestartet. Er sieht erheblich besser aus. Eine Reihe kleinerer Anmerkungen habe ich auf der Tagging-Liste veröffentlicht.

Viele Grüße

Michael

Announcement

#1 2017-10-04 23:16:45

Proposed_features/Metro_Mapping

#2 2017-10-05 06:59:27

Re: Proposed_features/Metro_Mapping

#3 2017-11-11 12:22:57

Re: Proposed_features/Metro_Mapping

#4 2017-12-13 14:56:38

Re: Proposed_features/Metro_Mapping

Board footer