public_transport=station Konflikt

Weide · 2017-04-21 20:14:22

rurseekatze wrote:

Mal angenommen, es gibt einen Node mit public_transport=platform, aber ohne eines der "alten" Tags. Wie soll man dann wissen, ob da nun ein Bushaltestellen- oder ein Straßenbahnsymbol gerendert werden soll?

Da PTv2 vorschreibt, dass sowohl die stops als auch die platforms in die Routen müssen (soweit sie vorhanden sind), kann man die Routen nachsehen.

Was für ein Symbol kommt denn an Steige, die mehrere Verkehrsmittel haben? Anders gesagt: Lässt sich die Trennung überhaupt durchhalten?

miche101 · 2017-04-22 08:40:31

Weide wrote:

, kann man die Routen nachsehen.

Aber nur wenn überhaupt eine Route vorhanden ist. Und wenn nicht aus versehen die Route beschädigt bzw. gelöscht wurde..

geri-oc · 2017-04-22 09:14:38

Weide wrote:

as für ein Symbol kommt denn an Steige, die mehrere Verkehrsmittel haben? Anders gesagt: Lässt sich die Trennung überhaupt durchhalten?

Vielleicht das alte allgemeine Haltestellenschild zum Rendern (aller) Haltestellen verwenden?

Last edited by geri-oc (2017-04-22 09:15:09)

miche101 · 2017-04-22 13:00:54

geri-oc wrote:

Vielleicht das alte allgemeine Haltestellenschild zum Rendern (aller) Haltestellen verwenden?

Das wäre ein Rückschritt in die Steinzeit.

Normalweise, je nachdem was für eine Karte man machen möchte, das Ranghöchste Verkehrsmittel..

Man sollte schon noch das taggen dürfen was man vor Ort vorfindet... und wenn das ein Bushaltestellenschild ist, ist das eben ein Bushalteschild... egal was alles da noch hält. Da Bushaltestellen sich meist an Straßen befinden.. kann da alles halten was die Straße benutzen kann. Also ja zu highway=busstop, bus=yes oder wie auch immer..

Bei Busbahnhöfen finde ich immer noch den bus_routes=* wichtig... obwohl dieser leider abgesetzt wurde. Weil man kann nicht erwarten das wenn ein Busbahnhof umnummeriert wurde dass der Aufnehmende auch alle Relationen abändert. Das ist oft mit sehr viel Arbeit verbunden.

Weide · 2017-04-22 14:48:48

miche101 wrote:

Das wäre ein Rückschritt in die Steinzeit.

Finde ich nicht. Es erkennt einfach die Tatsache an, dass die harte Einteilung in Tramsteig, Bussteig, ... die Realität nicht so ganz trifft.

miche101 wrote:

Man sollte schon noch das taggen dürfen was man vor Ort vorfindet... und wenn das ein Bushaltestellenschild ist, ist das eben ein Bushalteschild... egal was alles da noch hält.

Natürlich sollte man taggen dürfen, was man so vorfindet. Aber wir haben kein Tag für Haltestellenschilder! highway=bus_stop ist kein Tag für Haltestellenschilder sondern für Haltestellen. Wenn da kein Schild steht aber eine Bushaltestelle da ist (z.B. in Spanien), dann kommt da highway=bus_stop hin. Und wenn (z.B. Düsseldorf-Benrath S) an jeder Haltestelle zwei Schilder stehen, dann kommen da keine zwei highway=bus_stop hin. Und wenn da Schild auf der falschen Straßenseite steht weil es auf der richtigen Seite zu spät sichtbar wäre (hab ich in Schweden gefunden), dann kommt das highway=bus_stop eben nicht auf die Seite mit dem Schild.

miche101 · 2017-04-22 17:59:39

Dann muss ich meine ganzen Bushaltestelleschilder wieder rauslöschen die ich die letzten 9 Jahre gemapt habe? Weil ich hab immer den Standpunkt des Schildes gemapt... Ja eigentlich das Schild.

Haltestellen hab ich da keine gesehen, vielleicht ein Häuschen und eine Bank wo man mutmaßen kann das des dazugehört.

Was ist eine Haltestelle? Wie definiert man das... Ist das physisch vor Ort auffindbar, oder vor Ort nachprüfbar durch erfragen vor Ort? Wenn nein dann gehört es nicht in OSM.

slhh · 2017-04-22 20:09:26

miche101 wrote:

Was ist eine Haltestelle? Wie definiert man das... Ist das physisch vor Ort auffindbar, oder vor Ort nachprüfbar durch erfragen vor Ort? Wenn nein dann gehört es nicht in OSM.

Als Haltestelle würde ich eine Stelle definieren, an der ein öffentliches Verkehrsmittel regelmäßig zum Fahrgastwechsel hält. Dies ist grundsätzlich vor Ort durch langfristige Beobachtung des Verkehrsmittels nachprüfbar, auch wenn es im Einzelfall praktikablere Möglichkeiten geben mag.

Mit Ausnahme des Verkehrsweges sehe ich nicht, dass irgendeine physikalische Haltestelleninfrastruktur dafür zwingend vorhanden sein muss.

Das Verkehrsunternehmen könnte statt eines Haltestellenschildes die Position der Haltestelle auch durch eine Fahrbahnmarkierung kennzeichnen lassen oder lediglich im Fahrplan festlegen (z.B. Angabe einer Hausnummer oder Kreuzung) oder sich einfach darauf verlassen, dass die Anlieger schon wissen werden, wo der Bus regelmäßig hält.

Ein Haltestellenschild mag hinreichend für die Annhme sein, dass sich dort eine Halltestelle befindet und in Deutschland mag es sogar eine notwendige Voraussetzung sein.

pyram · 2017-04-22 20:36:22

slhh wrote:

...Ein Haltestellenschild mag hinreichend für die Annhme sein, dass sich dort eine Halltestelle befindet...

Da kenne ich diverse Gegenbeispiele ;-)

Weide · 2017-04-23 08:23:14

miche101 wrote:

Dann muss ich meine ganzen Bushaltestelleschilder wieder rauslöschen die ich die letzten 9 Jahre gemapt habe? Weil ich hab immer den Standpunkt des Schildes gemapt... Ja eigentlich das Schild.

Ist doch völlig OK, wenn man die Position des Haltestellenschildes als Position der Bushaltestelle nimmt. Es gibt aber eben auch Ausnahmen wie z.B. zwei Schilder oder gar kein Schild an einer Haltestelle. Dann spielt es eben eine Rolle, dass es genau genommen nicht um das Schild sondern um seine Bedeutung geht.

miche101 · 2017-04-23 09:32:32

slhh wrote:

Dies ist grundsätzlich vor Ort durch langfristige Beobachtung des Verkehrsmittels nachprüfbar, auch wenn es im Einzelfall praktikablere Möglichkeiten geben mag.

Langfristige Beobachtung des Verkehrsmittels? Nicht dein ernst? Wer macht den sowas?

slhh wrote:

Das Verkehrsunternehmen könnte statt eines Haltestellenschildes die Position der Haltestelle auch durch eine Fahrbahnmarkierung kennzeichnen lassen oder lediglich im Fahrplan festlegen (z.B. Angabe einer Hausnummer oder Kreuzung) oder sich einfach darauf verlassen, dass die Anlieger schon wissen werden, wo der Bus regelmäßig hält.

Fahrbahnmarkierungen würden wieder physisch vor Ort aufzufinden sein. Des andere wäre vor Ort zu erfragen.
Was würde man dann machen wenn der Bus dort hält wo Leute stehen und warten, ohne festen Platz. Einfach irgendwo an der Straße an der dieser Bus fährt zu stehen um eine bestimmte Zeit.

slhh wrote:

Ein Haltestellenschild mag hinreichend für die Annhme sein, dass sich dort eine Halltestelle befindet und in Deutschland mag es sogar eine notwendige Voraussetzung sein.

Ja für mich als Benutzer und nicht nur als Mapper.. ja eigentlich das wichtigste, wo? muss ich hin, das ist mein Ziel auch optisch schon oft von weit zu sehen und für die eine Richtung müsste ich da hin für die andere müsste ich da hin.. Der Rest ist erst einmal egal.

Mir reden hier schon noch um so kleine Dinger oder, so Bushaltestellen... Da gibt es oft nur ein Schild mit Fahrplan sonst nichts Ja was soll man da auch Aufnahmen.

miche101 · 2017-04-23 09:47:08

Weide wrote:

Ist doch völlig OK, wenn man die Position des Haltestellenschildes als Position der Bushaltestelle nimmt. Es gibt aber eben auch Ausnahmen wie z.B. zwei Schilder oder gar kein Schild an einer Haltestelle. Dann spielt es eben eine Rolle, dass es genau genommen nicht um das Schild sondern um seine Bedeutung geht.

Ja zwei Schilder wird es schon kompliziert.. wo muss ich stehen wenn ich da mitfahren will? Je Fahrtrichtung können dieses weit voneinander entfernt sein... da ist es als Fußgänger schon interessant wo muss ich hin.. Wo genau muss ich am Bußbahnhof hin? usw.

Oder wie meinst du das, wie nimmst du eine Bushaltestelle auf? Kreierst du irgendeinen Mittelpunkt der "Haltestelle".. der sich vielleicht wenige Meter vom Schild unterscheidet und von der GPS Ungenauigkeit verschlungen wird?

Weide · 2017-04-23 12:09:57

miche101 wrote:

Ja zwei Schilder wird es schon kompliziert.. wo muss ich stehen wenn ich da mitfahren will? Je Fahrtrichtung können dieses weit voneinander entfernt sein... da ist es als Fußgänger schon interessant wo muss ich hin.. Wo genau muss ich am Bußbahnhof hin? usw.

Da hab ich mich unklar ausgedrückt. Ich meinte nicht verschiedene Haltestellen innerhalb der Gesamthaltestelle oder des Busbahnhofs. Ich meinte eine Einzelhaltestelle an die gerade mal ein einzelner Bus passt, also z.B. "Benrath S Steig 5". Die hat zwei gleichlautende Schilder ... eins mehr an dem einen Ende und das andere mehr an dem andern. Trotzdem gehört an jede der Einzelhaltestellen im Busbahnhof nur jeweils ein highway=bus_stop. Sich nach den Schildern zu richten ist eben eine gute Faustregel ... nicht mehr und nicht weniger.

miche101 · 2017-04-23 17:10:53

@Weide

ja es gibt keine Regel ohne Ausnahme. In dem Fall macht es Sinn.. Busbahnhöfe sind so ihr eigener Fall.. ganz schlimm wenn da herum geändert wird Solange das Ergebnis stimmt und der der die OSM-Karte verwendet richtig hin findet passt das

Mfg Miche

geri-oc · 2017-04-23 19:24:54

Da ich schon oft bei Bahnhöfen über MENTZ stolpere, sollte man sich vielleicht einmal an diese zu ÖPNV wenden. Sie verwenden ja auch Schlüssel und Werte die keiner im WIKI findet.

ES sind zwar z.B, highway, railway, platform alle an einem way als Fläche (was ich für falsch halte):

http://www.openstreetmap.org/relation/3 … 2/13.43389

Wären die beiden Bahnsteige hw=footway mit jeweiliger ref=2 oder ref=3 getaggt und diese als Bestandteil des Bahnsteiges in der Relation wäre auch ein Routing sinnvoller:

http://www.openstreetmap.org/directions … 5/13.43411

Dann kann der Bahnsteig (Fußweg) auch ein public_transport=platform für ÖPNV-Map tragen und die Fläche des Bahnsteiges railway=platform, public_transport=platform für die Railway-Map.

Diese Bahnsteige können dann zum Fernbahnhof Ostbahnhof - und in Verbindung mit anderen ÖPNV Verkehrsmitteln zum Knoten Ostbahnhof verbunden werden.

Nur müsste dann auch MENTZ auf Vorschläge, Hinweise reagieren und das im WIKI (ÖPNV) festschreiben.

slhh · 2017-04-23 23:53:46

miche101 wrote:

Langfristige Beobachtung des Verkehrsmittels? Nicht dein ernst? Wer macht den sowas?

Regelmäßige Nutzer, Fahrzeugführer des Verkehrsmittels, Regelmäßige andere Nutzer des Verkehrsweges und Anlieger der Haltestellen machen dies eigentlich ganz automatisch. Für Andere dürfte es praktischer sein, diese Personen zu befragen.

miche101 wrote:

Was würde man dann machen wenn der Bus dort hält wo Leute stehen und warten, ohne festen Platz. Einfach irgendwo an der Straße an der dieser Bus fährt zu stehen um eine bestimmte Zeit.

Diesen Fall werden die Entwickler des Taggingshemas wohl vergessen haben. Vermutlich sind die Verhältnisse in ihrer Heimatregion zu geregelt. Die sauberste Lösung wäre vermutlich in der Rolle des Fahrwegs zu kennzeichnen, dass ein Bedarfshalt erfolgen kann. EWnn es für den ganzen Linienverlauf gilt, würde natürlich auch ein Tag an der Linienrelation genügen.

slhh · 2017-04-24 00:17:37

geri-oc wrote:

ES sind zwar z.B, highway, railway, platform alle an einem way als Fläche (was ich für falsch halte):

Das halte ich auch für falsch.

geri-oc wrote:

Wären die beiden Bahnsteige hw=footway mit jeweiliger ref=2 oder ref=3 getaggt und diese als Bestandteil des Bahnsteiges in der Relation wäre auch ein Routing sinnvoller:

Zum Einen sollte der Router die Leute nicht auf der Bahnsteigkante balancieren lassen und zum Anderen wäre dies Tagging für den Rooter.
Ein guter Router sollte über die Bahnsteigfläche routen.
Auch die Querwege zur Verbindung mit der Platform sind eigentlich falsch. Hier wäre es wohl korrekt, die Treppenbereiche per Multipolygon-Inner aus dem Bahnsteig auszuschneiden und den Fussweg (die Treppe) dann mit dem Inner und damit der Bahnsteigfläche zu verbinden.

Weide · 2017-04-24 06:46:55

geri-oc wrote:

ES sind zwar z.B, highway, railway, platform alle an einem way als Fläche (was ich für falsch halte):
http://www.openstreetmap.org/relation/3 … 2/13.43389

"highway, railway, platform" sind nicht an einem way sondern an dem Multipolygon.

Das "highway=platform" ist Quatsch, denn das Ding ist klar nur für Züge. Das "area=yes" ist auch Quatsch, denn Multipolygone können nur Flächen sein und area=yes gehört nur an Objekte, die ohne das Tag Flächen oder Linien sein könnten.

geri-oc wrote:

Wären die beiden Bahnsteige hw=footway mit jeweiliger ref=2 oder ref=3 getaggt und diese als Bestandteil des Bahnsteiges in der Relation wäre auch ein Routing sinnvoller:

OK. Das Flächenrouting funktioniert nicht. Das ist ein Routing-Problem und es muss entweder gelöst werden oder wir müssen in OSM generell auf begehbare Flächen verzichten ... was nicht passieren wird.

Außerdem meinen die Routing-Engines augenscheinlich, dass man auf einem Bahnsteig nicht gehen kann. Das ist einfach ein Irrtum.

geri-oc wrote:

Dann kann der Bahnsteig (Fußweg) auch ein public_transport=platform für ÖPNV-Map tragen und die Fläche des Bahnsteiges railway=platform, public_transport=platform für die Railway-Map.

OK, dann hätten wir da an einem Bahnsteig drei Platforms -- falls ich das richtig verstanden habe.

Das kann PTv2 nicht. Jeder stop und jede platform, an der ein Verkehrsmittel hält, muss in die Route, sonst ist das Nachschlagen der Linien zu einer Haltestelle kaputt. Pro Anhalten des Fahrzeugs kann eine PTv2-Route aber nur maximal einen stop und eine platform aufnehmen, sonst geht die Haltestellenliste der Route kaputt. Ein Konzept mit solchen Platforms ist möglich, aber kann man es erst nach Ablösung von PTv2 realisieren. (In meinem PTv3-Vorschlag geht sowas)

geri-oc wrote:

Nur müsste dann auch MENTZ auf Vorschläge, Hinweise reagieren und das im WIKI (ÖPNV) festschreiben.

Mentz legt in OSM nichts fest! Nach unserem Anfangskonflikt mit Mentz hat sich da eigentlich auf dieser Basis ein gutes Verhältnis entwickelt.

Weide · 2017-04-24 07:03:19

slhh wrote:

Die sauberste Lösung wäre vermutlich in der Rolle des Fahrwegs zu kennzeichnen, dass ein Bedarfshalt erfolgen kann. EWnn es für den ganzen Linienverlauf gilt, würde natürlich auch ein Tag an der Linienrelation genügen.

In der Rolle geht es nicht. Sowas ging in PTv1, weil PTv1 eigentlich keine Rollen hatte und brauchte und man da dann einfach Zusatzangaben in der Rolle unterbringen konnte. In PTv2 hat man wie in Abbiegerelationen usw. aber echte Rollen, die für die Interpretation benötigt werden. Wenn man da was anderes reinschreibt oder was zusätzliches, dann ändert man die Auswerteregeln und macht korrekte Programme kaputt. Auswerteprogramme dürfen sich darauf verlassen, dass man in PTv2 mit einem Auszug der Relationsmember mit leerer Rolle die Liste der Fahrwege bekommt.

Tags an der Linie oder Variante wären sinnvoll. Da gibt es ja einige Varianten für "Zwischendurchstops": "Ein- und Aussteigen", "nur Aussteigen", "nur für Frauen", "erst ab 19:00". Da müssten wir mal überlegen, wie man die ganzen Kombinationen sinnvoll in ein oder mehrere Tags packen kann...

Trockennasenaffe · 2017-04-24 11:28:19

Weide wrote:

OK. Das Flächenrouting funktioniert nicht. Das ist ein Routing-Problem und es muss entweder gelöst werden oder wir müssen in OSM generell auf begehbare Flächen verzichten ... was nicht passieren wird.

Scheint prinzipiell ein lösbares Problem zu sein, wenn auch nicht ganz triviel: https://www.youtube.com/watch?v=6zzPzZg … Iffh6HfM7r

Weide wrote:

Außerdem meinen die Routing-Engines augenscheinlich, dass man auf einem Bahnsteig nicht gehen kann. Das ist einfach ein Irrtum.

Bahnsteige sind natürlich immer begehbar, aber eventuell nicht ohne rechtliche Einschränkungen. Meines Wissens nach sind Bahnsteige kein öffentlicher Raum, obwohl das gerade bei kleinen Haltepunkten nicht ersichtlich ist und Bahnsteige sogar hin und wieder im Hinblick als Zweitnutzung als Verbindungsweg angelegt werden.

Last edited by Trockennasenaffe (2017-04-24 11:28:50)

geri-oc · 2017-04-24 13:25:20

Weide wrote:

Mentz legt in OSM nichts fest! Nach unserem Anfangskonflikt mit Mentz hat sich da eigentlich auf dieser Basis ein gutes Verhältnis entwickelt.

Ich meinte auch nicht das Mentz etwas festlegen soll, sie sollten aber ihre eingeführten (z.B. sinnvollen Schlüssel = Anzeigetafel - destination_display) im WIKI - http://wiki.openstreetmap.org/wiki/DE:Public_transport - mit aufführen:

https://taginfo.openstreetmap.org/keys/ … ort#values

Damit wird schon etwas auf Vereinheitlichung eines Schlüssels hingearbeitet. Und da sie sich hauptsächlich mit ÖPNV beschäftigen und auch Daten nutzen, wäre eine Art "Moderator für ÖPNV" angebracht.

Weide · 2017-04-24 13:31:24

Trockennasenaffe wrote:

Scheint prinzipiell ein lösbares Problem zu sein, wenn auch nicht ganz triviel: https://www.youtube.com/watch?v=6zzPzZg … Iffh6HfM7r

Ja. Einige der Verfahren sind evtl. für OSM nicht so geeignet. Wir haben wegen unterschiedlicher Namen oder Bodenbeläge oder wat-weiss-ich ja auch Flächen, die an Flächen statt an Wege grenzen. Da kann man dann nicht mehr davon ausgehen, dass Anfang und Ende der optimalen Route auf vorhandenen Nodes liegen. Ein paar Algorithmen entfallen dann schon. Der Rest kann heftig in die Rechenzeit gehen.

Vielleicht sollten wir doch mal ganz offiziell unsichtbare Routing-Support-Wege zulassen. Wie in dem Vortrag gesagt wurde sind die jetzigen Lösungstricks ein wirklich störendes Problem für das echte Flächenrouting. Wenn man sowas dagegen offiziell zulässt, dann sind sie beim Rendern und beim Flächenrouting leicht zu ignorieren und das hätte auch noch einen großen Nutzen für den ÖPNV:

Wenn man als Fußgänger einfach einen Weg von A nach B sucht und stolpert dabei über eine querliegende Fußgängerzonenfläche, dann denkt man "wat n Blödsinn" und sucht sich selbst einen Weg. Wenn das bei Fahrplanauskünften passiert, dann bekommt man einfach eine schlechtere Verbindung mit Umsteigen in Düsseldorf statt in Köln. Dass das Ganze am Mapping des Bahnhofsvorplatzes in Köln liegt ist dann praktisch unsichtbar.

geri-oc · 2017-04-24 13:58:39

Weide wrote:

Dass das Ganze am Mapping des Bahnhofsvorplatzes in Köln liegt ist dann praktisch unsichtbar.

Funktioniert auch in Dresden gut: http://www.openstreetmap.org/#map=17/51.05974/13.74228

Dann würde es mit hw=footway an der Kante des Bahnsteiges auch besser funktionieren:

http://www.openstreetmap.org/directions … 63/6.95897

(Und so genau ist Routing (noch) nicht, das ich auf der Kante entlang balancieren muss.)

Trockennasenaffe · 2017-04-24 15:10:51

Weide wrote:

Ja. Einige der Verfahren sind evtl. für OSM nicht so geeignet. Wir haben wegen unterschiedlicher Namen oder Bodenbeläge oder wat-weiss-ich ja auch Flächen, die an Flächen statt an Wege grenzen. Da kann man dann nicht mehr davon ausgehen, dass Anfang und Ende der optimalen Route auf vorhandenen Nodes liegen. Ein paar Algorithmen entfallen dann schon. Der Rest kann heftig in die Rechenzeit gehen.

Wenn ich das richtig sehe, würde sich das lösen lassen in dem in der Vorverarbeitung der Daten zum Routing, benachbarte, begehbare Flächen zusammengefasst würden.

Weide wrote:

Vielleicht sollten wir doch mal ganz offiziell unsichtbare Routing-Support-Wege zulassen. Wie in dem Vortrag gesagt wurde sind die jetzigen Lösungstricks ein wirklich störendes Problem für das echte Flächenrouting. Wenn man sowas dagegen offiziell zulässt, dann sind sie beim Rendern und beim Flächenrouting leicht zu ignorieren und das hätte auch noch einen großen Nutzen für den ÖPNV:

Wenn solche Wege geduldet werden, sollte da in der Tat ein tag dran, dass sie vom rendern ausschließt. Ich bezweifle allerdings, dass solche Hilfswege generell die Lösung sind. Sobald man komplexere Flächen hat, wäre die Anzahl der Hilfswege um von jedem sinnvollen Startpunkt kürzt-möglich zu jeden sinnvollen Endpunkt zu kommen sehr groß. Die Bereitschaft, Diese konsequent anzulegen, zu warten und überhaupt das Konzept zu verstehen dürfte gering sein. Triviale Fälle sind auf der anderen Seite auch gut automatisiert zu behandeln.

Insgesamt würde ich sagen, dass ich stark anzweifle, dass Menschen im allgemeinen deutlich besser darin sind Wege über Flächen zu finden als Maschinen. Ich denke, dass bisher nur zu wenig Aufwand investiert wurde, brauchbare Algorithmen zu implementieren.

Last edited by Trockennasenaffe (2017-04-24 15:12:15)

slhh · 2017-04-25 00:19:35

Hier noch ein Video zum Flächenrouting von Roland Olbricht: https://www.youtube.com/watch?v=-ogblIKiN5M

Weide wrote:

Vielleicht sollten wir doch mal ganz offiziell unsichtbare Routing-Support-Wege zulassen.

Ein Tag zur Kennzeichnung solcher Wege halte ich für sinnvoll. Allerdings sehe ich bei begehbaren Flächen in der Regel keine Notwendigkeit solche Wege für Fussgänger anzulegen. Ein Fussgängerrouter routet über kurze Entfernungen und sollte dabei ein Flächenrouting beherschen. Wir sollten den Router-Entwicklern keinen Grund liefern, dieses niedrig zu priorisieren, zumal die Routing-Support-Wege hier im Allgemeinen auch keine guten Resultate ermöglichen dürften.

slhh · 2017-04-25 01:18:59

Weide wrote:

In der Rolle geht es nicht. Sowas ging in PTv1, weil PTv1 eigentlich keine Rollen hatte und brauchte und man da dann einfach Zusatzangaben in der Rolle unterbringen konnte. In PTv2 hat man wie in Abbiegerelationen usw. aber echte Rollen, die für die Interpretation benötigt werden. Wenn man da was anderes reinschreibt oder was zusätzliches, dann ändert man die Auswerteregeln und macht korrekte Programme kaputt. Auswerteprogramme dürfen sich darauf verlassen, dass man in PTv2 mit einem Auszug der Relationsmember mit leerer Rolle die Liste der Fahrwege bekommt.

Grundsätzlich dürfen sich Auswerteprogramme gar nicht darauf verlassen, dass OSM Tagging Schemas unveränderlich sind, sofern man von unangekündigten plötzlichen Massenedits absieht. Insbesondere bei Änderungen, auf die die Auswerter mit minimalen Code-Änderungen reagieren können, sollten wir uns absolut keine Gedanken über Inkompatibilitäten von Auswerteprogrammen machen.

Da PTv1 Rollen für die Fahrwege verwendet und PTv2 nicht, wäre die Ergänzung sogar einfacher in PTv2 zu integrieren. Aber natürlich können wir auch mehrere Eigenschaften durch geeignete Syntax in einer Rolle kodieren, falls nötig.

Da ich für die Erweiterung keine hohe Priorität sehe, würde ich sie eher in ein generell überarbeitetes PTv3 (oder PTv2.x) einfließen lassen, wenn wir die Erweiterung haben wollen.
Unnötig oft müssen wir die Auswerter auch nicht mit Inkompatibilitäten ärgern und PTv1 und PTv2 sehe ich ohnehin als gescheitert an.
Die allgemein nötigen Änderungen halte ich für umfangreich genug, dass es ein PTv3 geben muss, eventuell ist aber ein PTv2.x als Vorbereitung dazu sinnvoll.

Announcement

#26 2017-04-21 20:14:22

Re: public_transport=station Konflikt

#27 2017-04-22 08:40:31

Re: public_transport=station Konflikt

#28 2017-04-22 09:14:38

Re: public_transport=station Konflikt

#29 2017-04-22 13:00:54

Re: public_transport=station Konflikt

#30 2017-04-22 14:48:48

Re: public_transport=station Konflikt

#31 2017-04-22 17:59:39

Re: public_transport=station Konflikt

#32 2017-04-22 20:09:26

Re: public_transport=station Konflikt

#33 2017-04-22 20:36:22

Re: public_transport=station Konflikt

#34 2017-04-23 08:23:14

Re: public_transport=station Konflikt

#35 2017-04-23 09:32:32

Re: public_transport=station Konflikt

#36 2017-04-23 09:47:08

Re: public_transport=station Konflikt

#37 2017-04-23 12:09:57

Re: public_transport=station Konflikt

#38 2017-04-23 17:10:53

Re: public_transport=station Konflikt

#39 2017-04-23 19:24:54

Re: public_transport=station Konflikt

#40 2017-04-23 23:53:46

Re: public_transport=station Konflikt

#41 2017-04-24 00:17:37

Re: public_transport=station Konflikt

#42 2017-04-24 06:46:55

Re: public_transport=station Konflikt

#43 2017-04-24 07:03:19

Re: public_transport=station Konflikt

#44 2017-04-24 11:28:19

Re: public_transport=station Konflikt

#45 2017-04-24 13:25:20

Re: public_transport=station Konflikt

#46 2017-04-24 13:31:24

Re: public_transport=station Konflikt

#47 2017-04-24 13:58:39

Re: public_transport=station Konflikt

#48 2017-04-24 15:10:51

Re: public_transport=station Konflikt

#49 2017-04-25 00:19:35

Re: public_transport=station Konflikt

#50 2017-04-25 01:18:59

Re: public_transport=station Konflikt

Board footer