Fragen zum ÖPNV-Schema

errt · 2010-07-13T15:45:28.000Z

Highway=bus_stop wird ersetzt durch public_transport=stop_position oder public_transport=platform, je nachdem wo der Node lag.
Meines Wissens sind keine Rollen für die Relationsmitglieder vorgesehen, die Strecke lässt sich von Haltestellen durch die Tags unterscheiden, außerdem sollen ja die Wege, die die Strecke bilden, in geordneter Reihenfolge in der Relation enthalten sein.
Highway=platform ist offensichtlich veraltet und sollte ersetzt werden, wenn eine Route nach neuem Schema eingetragen wird.
Würde ich so machen, dass es der Realität am Nähesten kommt: Wenn der Bus wirklich nur am Straßenrand hält, dann ein Node, der das Bushaltestellenschild repräsentiert. Gibt es einen erkennbaren Ansatz einer Platform (z.B. einen erhöhten Bordstein), kann man auch einen Way verwenden.

Ist allerdings alles etwas spekulativ und der Interpretationsspielraum ist groß, auch wenn ich die eigentliche Seite http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema informativer finde als die von dir verlinkte.

Weide · 2010-07-13T20:30:55.000Z

Hi,

brogo:

In dem Text wird nicht erwähnt, was mit den ‘highway=bus_stop’-Nodes passiert. Werden auch in die Relation aufgenommen oder ist dieser Tag veraltet?

Erhalten die Relations-Member, die den eigentlichen Weg darstellen, eine besondere Rolle? Ansonsten die der platform? Wie kann man ansonsten unterscheiden, welches der Weg und welches der Bussteig ist?

Ist ‘highway=platform’ veraltet und soll nun durch ‘public_transport=platform’ ersetzt werden?

Oft gibt es ja Haltestellen, bei denen keine separate Haltebucht, geschweige den einen speziellen Bussteig gibt. Der Bus hält einfach am Straßenrand. Soll man jetzt eine ‘public_transport=platform’ künstlich anlegen? Node oder Way?

Ich würde “platforms” nicht künstlich anlegen.

Ansonsten mache ich es wie folgt:

Die Halte bleiben wie sie sind. Ich habe irgendwo eine Stelle gefunden, nach der dies als Übergang vorgesehen ist. Sie erhalten die Rolle “forward_platform” (neben der Straße) oder “forward_stop” (auf der Straße). Wenn beides vorhanden ist, dann kommt beides rein. Das “forward_” ist deshalb mit drin, weil die Relation zwar nur eine Variante einer Richtung angibt, man dies aber nicht so ohne Weiteres an den Tags erkennen kann – es könnte ja auch eine klassisch getagte Buslinie sein. Bezüglich dieser Variante sind natürlich alle Stops “forward”.
Aus demselben Grunde bekommen die Straßenabschnitte die Role “forward” bzw. “backward”, je nachdem, ob sie in OSM-Richtung oder gegen OSM-Richtung befahren werden. Das gibt dann im Grunde genommen nur die im JOSM sichtbaren Pfeilrichtungen wieder und wäre überflüssig, wenn man der Relation die Absicht des Mappers ansehen könnte. Alle Relationen der Buslinie werden dann in einer Superrelation zusammengefasst. Alle Einzelrelationen erhalten ein Tag der Art"note:relations=part of bus line 111 (Relation 11111)". Da fiel mir nichts Besseres ein, aber irgendwie muss man ja deutlich machen, dass dies nur ein Teil der gesamten Buslinie ist und aus den Tags kann man es ja wie gesagt nicht schließen.

Weide

EvanE · 2010-07-13T23:02:51.000Z

Weide:

…
Die Halte bleiben wie sie sind. Ich habe irgendwo eine Stelle gefunden, nach der dies als Übergang vorgesehen ist. Sie erhalten die Rolle “forward_platform” (neben der Straße) oder “forward_stop” (auf der Straße). Wenn beides vorhanden ist, dann kommt beides rein. Das “forward_” ist deshalb mit drin, weil die Relation zwar nur eine Variante einer Richtung angibt, man dies aber nicht so ohne Weiteres an den Tags erkennen kann – es könnte ja auch eine klassisch getagte Buslinie sein. Bezüglich dieser Variante sind natürlich alle Stops “forward”.
Aus demselben Grunde bekommen die Straßenabschnitte die Role “forward” bzw. “backward”, je nachdem, ob sie in OSM-Richtung oder gegen OSM-Richtung befahren werden. Das gibt dann im Grunde genommen nur die im JOSM sichtbaren Pfeilrichtungen wieder und wäre überflüssig, wenn man der Relation die Absicht des Mappers ansehen könnte. Alle Relationen der Buslinie werden dann in einer Superrelation zusammengefasst. Alle Einzelrelationen erhalten ein Tag der Art"note:relations=part of bus line 111 (Relation 11111)". Da fiel mir nichts Besseres ein, aber irgendwie muss man ja deutlich machen, dass dies nur ein Teil der gesamten Buslinie ist und aus den Tags kann man es ja wie gesagt nicht schließen.

Hallo Weide

Alle Buslinien, die ich in Dortmund getroffen habe, sind als Relationen
nach dem neuen ÖPNV-Schema erfasst. Da steht keine einzige Rolle drin.
Es ist ja eines der Ziele dieses Schemas je Relation nur eine Richtung
zusammenzufassen. Von daher sind alle Wege und alle Haltestellen immer
in Fahrtrichtung.

Die Richtung eines Weges hat in einer Relation meiner Meinung nach
nichts verloren, da die Wegrichtung geändert werden kann, ohne dass
diese Änderung in der Rolle entsprechend angepasst würde.

Edit:
In die Fahrtrichtungs-Relation kommt nur die stop_position rein.
Die Haltestelle (=Zugang zum Bus) liegt ja ausserhalb der Fahrtroute.

Übrigens gibt es einen schweren Fehler in der Definition der Haltestellen-
und Richtungs-Relationen. Es wurde kein Reationstyp dafür definiert.
Lediglich für die zusammenfassende Relation ist type=route festgeschrieben.

type=* ist aber ein für Relationen zwingend vorgeschriebene Parameter.

Also sollte das ‘neue’ ÖPNV-Schema (zumindest bezüglich Relationstyp)
mal dringend überarbeitet werden.

Die Sache mit den einzelnen Relationen je Fahrtrichtung und Alternative
hat noch eine andere unangenehme Auswirkung: Kreisverkehre müssen
leider in mehre Stücke aufgedrösselt werden, da die Rückrichtung ja in
einer anderen Relation erfasst wird.

Edbert (EvanE)

Weide · 2010-07-14T04:12:42.000Z

EvanE:

Alle Buslinien, die ich in Dortmund getroffen habe, sind als Relationen
nach dem neuen ÖPNV-Schema erfasst. Da steht keine einzige Rolle drin.
Es ist ja eines der Ziele dieses Schemas je Relation nur eine Richtung
zusammenzufassen. Von daher sind alle Wege und alle Haltestellen immer
in Fahrtrichtung.

Ja. Alle diese von mir benutzten Rollen sind redundant und überflüssig, sobald man davon ausgeht, dass es das neue ÖPNV-Schema ist. Um davon ausgehen zu können, müsste man aber eine eindeutige Typ-Kennzeichnung haben(s.u.). Als OSM-Objekt ist die Linienvariante des neuen Schemas eine Buslinie des alten Schemas. Das ist ein Konstruktionsfehler des neuen Schemas. Da man nun kompatibel mit dem alten Schema taggen muss, bedeutet eine leere Role, dass ein Stück Weges in beiden Richtungen benutzt wird und das ist in der Linienvariante praktisch nie der Fall. Also braucht man dort aufgrund des Konstruktionsfehlers praktisch überall Roles.

Die Richtung eines Weges hat in einer Relation meiner Meinung nach
nichts verloren, da die Wegrichtung geändert werden kann, ohne dass
diese Änderung in der Rolle entsprechend angepasst würde.

Das muss der Editor hinbekommen. Genauso muss er auch beim Splitten eines Weges diesen richtig in die Relation einbauen.

Edit:
In die Fahrtrichtungs-Relation kommt nur die stop_position rein.
Die Haltestelle (=Zugang zum Bus) liegt ja ausserhalb der Fahrtroute.

In
http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema steht:
"Für Hin- und Rückweg einer Linie wird jeweils eine eigene Relation verwendet: Dabei werden alle Haltepositionen, Zugangsstellen und Verkehrswege als Mitglieder aufgenommen. Deren Reihenfolge in der geordneten Mitgliederliste gibt dabei genau die reale Verbindung zwischen Quell- und Zielort wieder.

Zugangsstellen werden aus den folgenden beiden Gründen mitaufgenommen: Zum einen ermöglicht dies Routinganwendungen FußgängerInnen direkt auf die richtigen Zugangsstellen zu verweisen. Zum anderen sichert dies die Abwärtskompatibilität des Modells, da somit auch all jene Map Features nach wie vor gültige Relationsmitglieder sind, die als Halte getaggt sind, sich aber neben Verkehrswegen befinden und nicht auf solchen."

und im Wiki http://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema steht:
“Hier bei werden beide Nodes also die Stopposition und die Platform hinzugefügt.”

Übrigens gibt es einen schweren Fehler in der Definition der Haltestellen-
und Richtungs-Relationen. Es wurde kein Reationstyp dafür definiert.
Lediglich für die zusammenfassende Relation ist type=route festgeschrieben.

type=* ist aber ein für Relationen zwingend vorgeschriebene Parameter.

Das Wort “type” kommt im gesamten Oxomoa-Dokument nicht vor. Warum daraus im Wiki “type=route” für die Metarelation geworden ist, ist mir unklar.

Wie ich dazu gekommen bin, fällt mir nicht mehr ein, aber ich habe es mir definitiv nicht ausgedacht, dass ich die Metarelation mit “type=line” tagge.

Also sollte das ‘neue’ ÖPNV-Schema (zumindest bezüglich Relationstyp)
mal dringend überarbeitet werden.

Ja! Und nicht nur das neue ÖPNV-Schema. Hätte man der neuen Art von Multipolygonen von Anfang an einen anderen Typ verpasst (“type=area”), dann wären uns massenweise Probleme erspart worden. Und hätte die Linienvariante einen eigenen Typ statt des gewohnten “type=route”,“route=bus”, dann wären alle Roles überflüssig, da sie sich dann klar aus dem Kontext ergeben würden.(s.o.)

Die Sache mit den einzelnen Relationen je Fahrtrichtung und Alternative
hat noch eine andere unangenehme Auswirkung: Kreisverkehre müssen
leider in mehre Stücke aufgedrösselt werden, da die Rückrichtung ja in
einer anderen Relation erfasst wird.

Ja, das sollte man vielleicht tun – andererseits sollte man auch den Kreisverkehr als ganzes reinnehmen können, ohne dass Programme die Wegabfolge dann als nicht mehr zusammenhängend kennzeichnen … JOSM macht das z.B. richtig.

Weide

ajoessen · 2010-07-14T05:32:17.000Z

Weide:

Das Wort “type” kommt im gesamten Oxomoa-Dokument nicht vor. Warum daraus im Wiki “type=route” für die Metarelation geworden ist, ist mir unklar.

Wie ich dazu gekommen bin, fällt mir nicht mehr ein, aber ich habe es mir definitiv nicht ausgedacht, dass ich die Metarelation mit “type=line” tagge.

aber wunder dich nicht, wenn in josm dann eine Starkstrom-Freileitungs-Relation draus wird. Ist aber nur ein Übersetzungsfehler.

Ja, das sollte man vielleicht tun – andererseits sollte man auch den Kreisverkehr als ganzes reinnehmen können, ohne dass Programme die Wegabfolge dann als nicht mehr zusammenhängend kennzeichnen … JOSM macht das z.B. richtig.

Dann sollten bitteschön auch alle anderen Programme das können, oder man ignoriert die Fehlermeldungen einfach. Wir mappen doch nicht für die Editoren

Gruß,
ajoessen

EvanE · 2010-07-14T06:42:31.000Z

Hallo Weide

Weide:

EvanE:

Alle Buslinien, die ich in Dortmund getroffen habe, sind als Relationen nach
dem neuen ÖPNV-Schema erfasst. Da steht keine einzige Rolle drin. …

Ja. Alle diese von mir benutzten Rollen sind redundant und überflüssig, sobald man davon ausgeht, dass es das neue ÖPNV-Schema ist. Um davon ausgehen zu können, müsste man aber eine eindeutige Typ-Kennzeichnung haben(s.u.). Als OSM-Objekt ist die Linienvariante des neuen Schemas eine Buslinie des alten Schemas. Das ist ein Konstruktionsfehler des neuen Schemas. Da man nun kompatibel mit dem alten Schema taggen muss, … Also braucht man dort aufgrund des Konstruktionsfehlers praktisch überall Roles.

Könnte man so sehen, halte ich aber für unnötig und wird (zumindest in
Dortmund) nicht so gehandhabt.

Was die mehrdeutige Klassifizierung mit type=route angeht muss ich dir
allerdings zustimmen: Das ist ein Mangel des neuen Schemas.

Weide:

EvanE:

Die Richtung eines Weges hat in einer Relation meiner Meinung nach
nichts verloren, da die Wegrichtung geändert werden kann, ohne dass
diese Änderung in der Rolle entsprechend angepasst würde.

Das muss der Editor hinbekommen. Genauso muss er auch beim Splitten eines Weges diesen richtig in die Relation einbauen.

Das mit dem Splitten (und auch Joinen) klappt bei JOSM.
Ob die Rolle forward/backward eines Relationsmitgliedes allerdings
automatisch mitgedreht wird, da habe ich meine Zweifel.
(forward/backword als Tagg an einen Weg funktioniert in JOSM)

Weide:

EvanE:

In die Fahrtrichtungs-Relation kommt nur die stop_position rein.
Die Haltestelle (=Zugang zum Bus) liegt ja ausserhalb der Fahrtroute.

…
und im Wiki http://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema steht:
“Hier bei werden beide Nodes also die Stopposition und die Platform hinzugefügt.”

Sorry, du hast Recht.
Ich hatte das nicht sorgfältig genug kontrolliert.
(Wird in Dortmund wie von dir zitiert angewendet.)

Weide:

EvanE:

Übrigens gibt es einen schweren Fehler in der Definition der Haltestellen-
und Richtungs-Relationen. Es wurde kein Reationstyp dafür definiert.
Lediglich für die zusammenfassende Relation ist type=route festgeschrieben.

type=* ist aber ein für Relationen zwingend vorgeschriebene Parameter.

Das Wort “type” kommt im gesamten Oxomoa-Dokument nicht vor. Warum daraus im Wiki “type=route” für die Metarelation geworden ist, ist mir unklar.

Wie ich dazu gekommen bin, fällt mir nicht mehr ein, aber ich habe es mir definitiv nicht ausgedacht, dass ich die Metarelation mit “type=line” tagge.

Ich wollte wie ajoessen “Starkstrom-Freileitungs-Relation” einwerfen.
Aber wenn type=line für die Sammel-Relation in Ordnung ist, werde ich diese
entsprechend anpassen. Bleibt nur die Frage welchen Typ die Richtungs-Relationen
bekommen sollen. type=route fände ich durchaus passend aber führt zu
Fehlinterpretationen altes/neues ÖPNV-Schema.

Weide:

EvanE:

Also sollte das ‘neue’ ÖPNV-Schema (zumindest bezüglich Relationstyp)
mal dringend überarbeitet werden.

Ja! Und nicht nur das neue ÖPNV-Schema. Hätte man der neuen Art von Multipolygonen von Anfang an einen anderen Typ verpasst (“type=area”), dann wären uns massenweise Probleme erspart worden. Und hätte die Linienvariante einen eigenen Typ statt des gewohnten “type=route”,“route=bus”, dann wären alle Roles überflüssig, da sie sich dann klar aus dem Kontext ergeben würden.(s.o.)

Da kann ich dir nur zustimmen.
type=area statt type=multipolygon hätte uns viele hitzige Diskussionen erspart.
Für die Linienvarianten ginge eigentlich type=route. Es ist ja im Grunde eine Route.
Nur die Member-Rollen wären im alten/neuen ÖPNV-Schema leider unterschiedlich.

…

Edbert (EvanE)

EvanE · 2010-07-14T06:56:31.000Z

ajoessen:

Weide:

Das Wort “type” kommt im gesamten Oxomoa-Dokument nicht vor. Warum
daraus im Wiki “type=route” für die Metarelation geworden ist, ist mir unklar.

Wie ich dazu gekommen bin, fällt mir nicht mehr ein, aber ich habe es mir
definitiv nicht ausgedacht, dass ich die Metarelation mit “type=line” tagge.

aber wunder dich nicht, wenn in josm dann eine Starkstrom-Freileitungs-
Relation draus wird. Ist aber nur ein Übersetzungsfehler.

Gut zu wissen. type=line für die Sammelrelation aus Hin-/Rück-Richtung

Alternativen scheint soweit klar zu sein.
Aber welchen Typ sollen dann die Relationen für die einzelnen Richtungen
bzw. die Alternativen bekommen?

ajoessen:

Weide:

… andererseits sollte man auch den Kreisverkehr als ganzes reinnehmen können,
ohne dass Programme die Wegabfolge dann als nicht mehr zusammenhängend
kennzeichnen … JOSM macht das z.B. richtig.

Dann sollten bitteschön auch alle anderen Programme das können, oder man ignoriert die Fehlermeldungen einfach. Wir mappen doch nicht für die Editoren

Was meinst du genau damit?

Kreisverkehre für Linien-Relationen splitten,
Kreisverkehre dürfen also aus mehreren Teilstücken bestehen.
Kreisverkehre zusammen lassen, die Routen müssen damit klarkommen.
(Bei Hin- und Rückrichtung in einer Relation war das ja kein Problem.)

Edbert (EvanE)

ajoessen · 2010-07-14T07:09:43.000Z

ajoessen:

Weide:

… andererseits sollte man auch den Kreisverkehr als ganzes reinnehmen können,
ohne dass Programme die Wegabfolge dann als nicht mehr zusammenhängend
kennzeichnen … JOSM macht das z.B. richtig.

Dann sollten bitteschön auch alle anderen Programme das können, oder man ignoriert die Fehlermeldungen einfach. Wir mappen doch nicht für die Editoren

Was meinst du genau damit?

Kreisverkehre für Linien-Relationen splitten,
Kreisverkehre dürfen also aus mehreren Teilstücken bestehen.

Kreisverkehre zusammen lassen, die Routen müssen damit klarkommen.
(Bei Hin- und Rückrichtung in einer Relation war das ja kein Problem.)

Edbert (EvanE)

Zusammenlassen natürlich. Sonst hätte man sich den Konstrukt roundabout ja gleich sparen können. Fürs Routing muss der Kreisverkehr eben wie ein Knoten (bzw der “kleine Kreisverkehr”) behandelt werden:
“Nehmen sie die dritte Ausfahrt” funktioniert nicht mehr, wenn alles zerstückelt ist.
Die Kreisverkehre dafür wieder mit Relationen zusammenbauen zu müssen, ist mir irgendwie zu blöd.

Gruß,
ajoessen

ajoessen · 2010-07-14T07:14:53.000Z

EvanE:

ajoessen:

Weide:

Das Wort “type” kommt im gesamten Oxomoa-Dokument nicht vor. Warum
daraus im Wiki “type=route” für die Metarelation geworden ist, ist mir unklar.

Wie ich dazu gekommen bin, fällt mir nicht mehr ein, aber ich habe es mir
definitiv nicht ausgedacht, dass ich die Metarelation mit “type=line” tagge.

aber wunder dich nicht, wenn in josm dann eine Starkstrom-Freileitungs-
Relation draus wird. Ist aber nur ein Übersetzungsfehler.

Gut zu wissen. type=line für die Sammelrelation aus Hin-/Rück-Richtung

Alternativen scheint soweit klar zu sein.
Aber welchen Typ sollen dann die Relationen für die einzelnen Richtungen
bzw. die Alternativen bekommen?

Da würde ich mich hieran halten:
http://wiki.openstreetmap.org/wiki/Aachen_Editing#Taggen_von_Buslinien_in_Aachen_und_Umgebung

Also Route für die Relationen mit den Wegelementen, und line für die Metarelation.

Gruß,
ajoessen

Weide · 2010-07-15T09:55:36.000Z

EvanE:

Weide:

EvanE:

Die Richtung eines Weges hat in einer Relation meiner Meinung nach
nichts verloren, da die Wegrichtung geändert werden kann, ohne dass
diese Änderung in der Rolle entsprechend angepasst würde.

Das muss der Editor hinbekommen. Genauso muss er auch beim Splitten eines Weges diesen richtig in die Relation einbauen.

Das mit dem Splitten (und auch Joinen) klappt bei JOSM.
Ob die Rolle forward/backward eines Relationsmitgliedes allerdings
automatisch mitgedreht wird, da habe ich meine Zweifel.
(forward/backword als Tagg an einen Weg funktioniert in JOSM)

Ja, das muss ich einschränken: Beim Splitten und Umdrehen hatte ich schon mal Probleme. Seit ich da aber vorher das Gebiet um die zu ändernden Objekte explizit lade, geht es. Ob es wichtig ist, die Relation vorher komplett geladen zu haben, kann ich nicht sagen, denn das mache ich sowieso immer.

Weide

EvanE · 2010-07-15T10:48:12.000Z

ajoessen:

EvanE:

Gut zu wissen. type=line für die Sammelrelation aus Hin-/Rück-Richtung …
Aber welchen Typ sollen dann die Relationen für die einzelnen Richtungen
bzw. die Alternativen bekommen?

Da würde ich mich hieran halten:
http://wiki.openstreetmap.org/wiki/Aachen_Editing#Taggen_von_Buslinien_in_Aachen_und_Umgebung

Also Route für die Relationen mit den Wegelementen, und line für die Metarelation.

Danke für die Informationen.
Dann habe ich es ja weitgehend sinnvoll gemacht.

Bleibt noch die Frage der Haltestellen-Relationen:
Bisher habe ich mangels besserer Alternativen type=site dafür verwendet.

Im Aachener Dokument wird dafür type=public_transport +
public_transport=stop_area vorgeschlagen.
Das habe ich so auch schon mehrfach in Dortmund gesehen.
(Das habe ich dann natürlich nicht geändert.)

Ist das gängige Praxis, so dass ich das in Zukunft verwenden kann?

Edbert (EvanE)

EvanE · 2010-07-15T10:59:05.000Z

Weide:

EvanE:

Das mit dem Splitten (und auch Joinen) klappt bei JOSM.
Ob die Rolle forward/backward eines Relationsmitgliedes allerdings
automatisch mitgedreht wird, da habe ich meine Zweifel.
(forward/backword als Tagg an einen Weg funktioniert in JOSM)

Ja, das muss ich einschränken: Beim Splitten und Umdrehen hatte ich schon mal Probleme. Seit ich da aber vorher das Gebiet um die zu ändernden Objekte explizit lade, geht es. Ob es wichtig ist, die Relation vorher komplett geladen zu haben, kann ich nicht sagen, denn das mache ich sowieso immer.

Hallo Weide

Ja, man sollte möglichst nur dort Änderungen vornehmen,
wo man auch alle Daten hat.

Bei Relationen ist es sicher hilfreich, die Wegstücke vor/hinter dem
zu trennenden/verbindenden Wegstück(en) geladen zu haben.

Im JOSM-Relations-Editor kann man auch einzelne Member gezielt
laden, indem sie markiert und sich per Button “ausgewählte Elemente
laden” holt.

So kann man prüfen, ob der Weg an dieser Stelle vor/nach der
Änderung kontinuierlich ist.

“Unvollständige Elemente Laden” erfüllt natürlich diese Bedingung, kann
aber ziemlich große Bereiche laden (Autobahnen, IC/ICE-Linien, …)

Edbert (EvanE)

ajoessen · 2010-07-15T11:01:37.000Z

EvanE:

Bleibt noch die Frage der Haltestellen-Relationen:
Bisher habe ich mangels besserer Alternativen type=site dafür verwendet.

Im Aachener Dokument wird dafür type=public_transport +
public_transport=stop_area vorgeschlagen.
Das habe ich so auch schon mehrfach in Dortmund gesehen.
(Das habe ich dann natürlich nicht geändert.)

Ist das gängige Praxis, so dass ich das in Zukunft verwenden kann?

Wenn das in Aachen und Dortmund schon so gemacht wird, spricht doch nichts dagegen, oder?

Gruß,
ajoessen

Weide · 2010-07-15T12:16:40.000Z

Hi,

wir sind in dieser Diskussion auf ein paar Probleme mit Datenstrukturen in OSM gestoßen, die sich auch an ganz anderen Stellen in OSM zeigen. Ich habe da die Idee, dass man mit Hilfe von Normen Dinge klarer machen kann, ohne die Freiheit der Mapper irgendwie einzuschränken. Ich mache dazu mal einen getrennten Thread “Normdiskussion” auf.

Weide

EvanE · 2010-07-15T12:51:38.000Z

ajoessen:

EvanE:

… type=public_transport + public_transport=stop_area …
Ist das gängige Praxis, so dass ich das in Zukunft verwenden kann?

Wenn das in Aachen und Dortmund schon so gemacht wird, spricht doch nichts dagegen, oder?

Es könnte woanders andere gleich gute oder bessere Lösungen geben.
Daher frage ich lieber nach.

Wenn keine Einwände mehr kommen, werde ich die Verwendung von
type=line (Sammelrelation),
type=route (eine Richtung) und
type=public_transport (Haltestellen)
für das neue ÖPNV-Schema durch ausgiebige Anwendung pushen.

Das sollte noch auf den entsprechenden Seiten ergänzt werden.

Edbert (EvanE)

TobWen · 2010-07-16T10:17:00.000Z

Wir (bzw. Martin ganz alleine) haben das in Dortmund durchgeführt, als das ÖPNV-Schema noch ganz neu war.
Es mag also durchaus sein, dass es in anderen Kommunen Probleme gibt, über die sich hier niemand Gedanken machen musste.

Notfalls mal beim öpnvkarten.de-Macher anfragen, der wird vermutlich die Beste Übersicht haben

EvanE · 2010-07-16T12:46:06.000Z

Hallo Tobias

TobWen:

Wir (bzw. Martin ganz alleine) haben das in Dortmund durchgeführt, als das ÖPNV-Schema noch ganz neu war.
Es mag also durchaus sein, dass es in anderen Kommunen Probleme gibt, über die sich hier niemand Gedanken machen musste.

Notfalls mal beim öpnvkarten.de-Macher anfragen, der wird vermutlich die Beste Übersicht haben

Konkret ging es natürlich um die Situation in Dortmund.
Von daher reicht mir das erst mal aus.

Genau wie in Dortmund werde ich mir in anderen Städten erst einmal
ansehen wie die Dinge vor Ort gehandhabt werden und nur die Dinge
ändern, in denen ich eine Verbesserung oder Fehlerbehebung sehe.

Edbert (EvanE)

kellerma · 2010-07-18T13:34:35.000Z

EvanE:

Wenn keine Einwände mehr kommen, werde ich die Verwendung von
type=line (Sammelrelation),
type=route (eine Richtung) und
type=public_transport (Haltestellen)
für das neue ÖPNV-Schema durch ausgiebige Anwendung pushen.

Das sollte noch auf den entsprechenden Seiten ergänzt werden.

Edbert (EvanE)

Doch, es bestehen Einwaende.
Lt. zwei native speakern ist line im englischen keine Entsprechung der deutschen Linie (Sammlung von Routen). Kam vielleicht daher, dass beim damaligen workshop nur vertreter mit muttersprache Deutsch anwesend waren?

Warum man jetzt die bushaltestellen wieder in einer extra relation verpackt, versteh’ich auch nicht.

Den groessten Gewinn haette man, wenn mensch Abfahrtszeiten haette. …
(ohne den Fahrplan abzutippen {was bei unseren fraenkischen VGN sogar erlaubt waere})

Ciao,
Frank

EvanE · 2010-07-18T14:37:58.000Z

kellerma:

EvanE:

Wenn keine Einwände mehr kommen, werde ich die Verwendung von
type=line (Sammelrelation),
type=route (eine Richtung) und
type=public_transport (Haltestellen)
für das neue ÖPNV-Schema durch ausgiebige Anwendung pushen.

Das sollte noch auf den entsprechenden Seiten ergänzt werden.

Doch, es bestehen Einwaende.
Lt. zwei native speakern ist line im englischen keine Entsprechung der deutschen Linie (Sammlung von Routen). Kam vielleicht daher, dass beim damaligen workshop nur vertreter mit muttersprache Deutsch anwesend waren?

Warum man jetzt die bushaltestellen wieder in einer extra relation verpackt, versteh’ich auch nicht.

Den groessten Gewinn haette man, wenn mensch Abfahrtszeiten haette. …
(ohne den Fahrplan abzutippen {was bei unseren fraenkischen VGN sogar erlaubt waere})

Hallo Frank

Erst mal herzlich willkommen im OSM-Forum.

Laut http://dict.leo.org sind die Übersetzung von Buslinie/(Straßen)Bahnlinie:
‘bus line’ / tramline / ‘railway line’.

Es geht ja auch nicht um eine Sammlung von Routen sondern im Grunde um die
Zusammenfassung einer Route, die um überhaupt einen Fahrplan sinnvoll
abbilden zu können, in eine Hin- und Rückrichtung getrennt werden.

Auf diese Weise bräuchte man - solange man im Takt fährt - nur die Abfahrtszeiten
einer z.B. zentralen Haltestelle plus die Differenzen der anderen Haltestellen.

Im Übrigen sind die englischen Begriffe ähnlich unscharf bei der Unterscheidung
zwische Infrastruktur und den sie benutzenden Linien wie die deutschen Begriffe.

Hast du bzw. deine Bekannten einen besseren Begriff für die Gesamtheit der Routen
einer Linie? Noch könnte man eine Alternative einführen.

Edbert (EvanE)

chris66 · 2010-07-18T14:41:12.000Z

kellerma:

Doch, es bestehen Einwaende.
Lt. zwei native speakern ist line im englischen keine Entsprechung der deutschen Linie (Sammlung von Routen).

Wenn ich den Stromleitungsspezi User Bahnpirat richtig verstanden habe, dann ist dieser type (line) auch
bei Stromleitungsrelationen geplant.

Chris