You are not logged in.

#51 2014-12-21 23:08:29

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Ich möchte gerne wissen was nicht v2 dran ist.

Each route relation has all the stops at the end.

Ist im direkten Gegensatz zu dem im PTv2 angegebenen.

To keep the number of variants limited we only have a variant for the longest...

Nach PTv2 sollen alle Varianten gemappt werden.

Stop-Areas sind völlig anders. Die im PTv2 haben mehr Ähnlichkeit mit Euern stop_area_groups, nur ohne die zweite Relationsebene dazwischen.

To keep things simple and manageable all bus and tram stops in Belgium are mapped on nodes.

In case a platform is present, this can be entered as a way or an area.

Dann sind die Platforms doppelt vorhanden.

These nodes don't get extra information like name...
Dann kann man sie nicht in die Routen stecken, was ausdrücklich von PTv2 gefordert wird. Würde man sie dann doch dort erfassen, dann hätten sie daher einen anderen Namen und wären getrennte Haltestellen. Die Haltestellenliste wäre dann falsch.

Es wird auf die Beschreibung des Bus- und Tram-Linien-Mappings für Belgien verwiesen. Dort steht:
Stops don't need roles.

Das ist ein direktes Verbot der Aufnahme von Way-Platforms. Die könnte man dann nicht mehr von Fahrwegen unterscheiden.

Weide

Offline

#52 2014-12-22 00:25:07

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 243

Re: Diskussion über Public Transport Version 2.1

Weide wrote:
Polyglot wrote:

Ich möchte gerne wissen was nicht v2 dran ist.

Each route relation has all the stops at the end.

Ist im direkten Gegensatz zu dem im PTv2 angegebenen.

To keep the number of variants limited we only have a variant for the longest...

Nach PTv2 sollen alle Varianten gemappt werden.

Stop-Areas sind völlig anders. Die im PTv2 haben mehr Ähnlichkeit mit Euern stop_area_groups, nur ohne die zweite Relationsebene dazwischen.

To keep things simple and manageable all bus and tram stops in Belgium are mapped on nodes.

In case a platform is present, this can be entered as a way or an area.

Dann sind die Platforms doppelt vorhanden.

These nodes don't get extra information like name...
Dann kann man sie nicht in die Routen stecken, was ausdrücklich von PTv2 gefordert wird. Würde man sie dann doch dort erfassen, dann hätten sie daher einen anderen Namen und wären getrennte Haltestellen. Die Haltestellenliste wäre dann falsch.

Es wird auf die Beschreibung des Bus- und Tram-Linien-Mappings für Belgien verwiesen. Dort steht:
Stops don't need roles.

Das ist ein direktes Verbot der Aufnahme von Way-Platforms. Die könnte man dann nicht mehr von Fahrwegen unterscheiden.

Weide

Bin mal auf wiki gucken gegangen, sogar die Historie angesehen und es steht da tatsächlich. Erst Stops, dann Ways.  Damals habe ich das nicht gesehen. Schade es gefällt mir wie wir es jetzt machen. Die Haltestellen werden automatisch erfasst. Die Ways manuell, es ist praktisch die erst zu haben.

Was alle Varianten angeht. Ich bin ein Minimalist der auch den Aufwand für die Wartung zu ein minimum zurückbringen will. Deswegen diese Entscheidung. Es gibt etwa 1000 Linien für das Norten des Landes alleine. 2-50 Variante für jede Linie (wie ich die zähle). Es gibt nicht soviele Leute die sich mit ÖPNV beschäftigen wollen, also jede gesparte Aufwand ist eine  gute Sache.

Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.

Ich habe die andere Seite nicht mehr nachgelesen. HS bekommen jetzt alle die Rolle platform, weil alle umgewandelt sind auf highway=bus_stop,public_transport=platform, bus/tram=yes.

Vielleicht wäre es besser wenn die Nodes die jetzt public_transport=platform bekommen, public_transport=pole bekommen würden, wenigstens wäre das deutlicher. Mir macht es kein Unterschied dass zwei mal platform vorhanden sind. Wenn gemappt auf way, area oder MP ist das ein Steig. Wenn gemappt auf ein Node ist das der Node der alle Details enthalt für diese HS.

Welche Version sollte ich drauf kleben? 1.5, 2.5, 3.5, BE3.14? Ich benutze jetzt 2. Mein Skript considers alle Routes mit Version über 2 wo die Ways nicht unterbrochen sind als golden, und kopiert Wege davon wenn die Reihenfolge des HS übereinstimmt. Ich habe endlich eine Hilfe um die Wartung zu ermöchlichen.

Jetzt werde ich mal eine Relation in Aachen 'verbessern'. Auch dort sind die Ways erst, dann die HS, und ich hatte die noch nicht vorher bearbeitet.

Manche HS waren neben der Weg gemappt, andere als Node auf dem Weg im Route 21. Es wird noch nicht einfach sein diese 2 Schemata zu einigen für Routes die über die Grenze gehen.

Offline

#53 2014-12-22 07:58:54

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Bin mal auf wiki gucken gegangen, sogar die Historie angesehen und es steht da tatsächlich. Erst Stops, dann Ways.  Damals habe ich das nicht gesehen. Schade es gefällt mir wie wir es jetzt machen. Die Haltestellen werden automatisch erfasst. Die Ways manuell, es ist praktisch die erst zu haben.

Ja, es wäre genauso gut gewesen, wenn es im PTv2 anders herum gestanden hätte. Aber jetzt ist es so und das hat Folgen.

Jetzt darf z.B. ein Programm zum Extrahieren der Haltestellen den Rest der Relation überspringen wenn der erste Fahrweg-Eintrag kommt. Das zu tun ist sogar sinnvoll, denn in PBF-Dateien ist das Überspringen sehr zeitsparend. Viele Programme bei OSM laufen täglich und da ist es ein riesiger Unterschied, oft sie 2 Stunden oder 20 Stunden brauchen.

Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.

Was alle Varianten angeht. Ich bin ein Minimalist der auch den Aufwand für die Wartung zu ein minimum zurückbringen will. Deswegen diese Entscheidung.

Wenn ein Mapper entscheidet, dass er abgekürzte Varianten nicht eintragen will, dann ist das völlig OK. Auch wenn viele Mapper das tun, ist es völlig OK.

Ein Problem ist es aber, das zu verbieten. Nach PTv2 darf und soll man es. Wenn ein Mapper sieht, dass eine Variante fehlt und sie einträgt (richtig nach PTv2) und ein anderer löscht sie, weil es so in dem Papier steht, dann haben wir einen Edit-War. Und da muss man klar sagen: solange PTv2 dran steht ist das Eintragen des ersten Mappers richtig und das Löschen durch den zweiten falsch.

Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.

Nein. Beispiel: Ein Bahnhof "Pusemuckel" hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof "Pusemuckel Bahnhof" mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof "Pusemuckel Bahnhof/Westseite" mit 3 Bussteigen (1 bis 3).

-Nach PTv2BE sind es 15 Stop-Areas und ? stop_area_groups.
-Nach PTv2 sind es 3 Stop_Areas.
-Nach meinem Vorschlag sind es drei Stop-Areas und eine Stop_Area-Group.

Mir macht es kein Unterschied dass zwei mal platform vorhanden sind.

Wenn eine zweite Platform da ist, dann darf ein Mapper sie auch in einer Route benutzen. (Er darf nicht beide Platforms benutzen, das wären dann zwei Halte und falsch.) Jetzt kann man aber an der einzelnen Platform eventuell nicht mehr alle Routen erkennen, weil einige auf der anderen Platform liegen.

Man kann nicht vorhersehen wie die Datenbank benutzt wird. Deshalb sollten die Sachen stimmen -- egal ob man einem ein Problem mit falschen Einträgen einfällt oder nicht.

Weide

Last edited by Weide (2014-12-22 07:59:46)

Offline

#54 2014-12-24 11:18:06

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 243

Re: Diskussion über Public Transport Version 2.1

Weide wrote:
Polyglot wrote:

Bin mal auf wiki gucken gegangen, sogar die Historie angesehen und es steht da tatsächlich. Erst Stops, dann Ways.  Damals habe ich das nicht gesehen. Schade es gefällt mir wie wir es jetzt machen. Die Haltestellen werden automatisch erfasst. Die Ways manuell, es ist praktisch die erst zu haben.

Ja, es wäre genauso gut gewesen, wenn es im PTv2 anders herum gestanden hätte. Aber jetzt ist es so und das hat Folgen.

Jetzt darf z.B. ein Programm zum Extrahieren der Haltestellen den Rest der Relation überspringen wenn der erste Fahrweg-Eintrag kommt. Das zu tun ist sogar sinnvoll, denn in PBF-Dateien ist das Überspringen sehr zeitsparend. Viele Programme bei OSM laufen täglich und da ist es ein riesiger Unterschied, oft sie 2 Stunden oder 20 Stunden brauchen.

M.E. ist das meist wichtige dass es bequem ist für Mapper um die zu überarbeiten. Es gibt nicht viele Mapper die sich am PT interessieren, für die Wenige die es gibt muss es so angenähm wie möglich sein. Ein Komputerprogramma würde ich nie so schreiben dass es aufhört mit dem Processing in der Mitte von eine Relation. Es gibt immer die Möglichkeit das ein iD-Benutzer eine HS am Ende hinzugefügt hat, meistens ohne es sich zu realisieren. Die Optimalisazion für Programme sollte darin bestehen die Datenmenge so klein wie möglich zu halten. Das machen wir aber sowieso nicht mit unsere lange Tagnamen und vielfalt duplizierte Daten.

Weide wrote:

Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.

Da hast du Recht. Das ist ein Problem. Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?

Was alle Varianten angeht. Ich bin ein Minimalist der auch den Aufwand für die Wartung zu ein minimum zurückbringen will. Deswegen diese Entscheidung.

Weide wrote:

Wenn ein Mapper entscheidet, dass er abgekürzte Varianten nicht eintragen will, dann ist das völlig OK. Auch wenn viele Mapper das tun, ist es völlig OK.

Ein Problem ist es aber, das zu verbieten. Nach PTv2 darf und soll man es. Wenn ein Mapper sieht, dass eine Variante fehlt und sie einträgt (richtig nach PTv2) und ein anderer löscht sie, weil es so in dem Papier steht, dann haben wir einen Edit-War. Und da muss man klar sagen: solange PTv2 dran steht ist das Eintragen des ersten Mappers richtig und das Löschen durch den zweiten falsch.

Verboten habe ich es ja nicht. Das Skript das die Daten umwandelt, stellt die kurzere Variante von "Teleskoplinien" aber nicht zur Verfügung. Dieses Skript spart Mapper soviel Zeit (weil es nicht mehr notwendig ist, stundenlang Fahrpläne zu bestudieren um aus zu finden welche Variante es gibt. Es wäre wenig sinnvoll nicht gebrauchzumachen von die praktische Lösung. Ich kenne genau 1 Mapper der das vor einige Jahren für 2 Linien gemacht hat. Er hat das aber zeitdem nicht mehr neu gemacht und De Lijn ändert das ständige kleinere oder grossere sachen dran. Desto mehr Varianten wir beschreiben, desto mehr Arbeit der oft nicht gemacht wird.

Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.

Nein. Beispiel: Ein Bahnhof "Pusemuckel" hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof "Pusemuckel Bahnhof" mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof "Pusemuckel Bahnhof/Westseite" mit 3 Bussteigen (1 bis 3).

Weide wrote:

-Nach PTv2BE sind es 15 Stop-Areas und ? stop_area_groups.
-Nach PTv2 sind es 3 Stop_Areas.
-Nach meinem Vorschlag sind es drei Stop-Areas und eine Stop_Area-Group.

Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.

Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.

In Oostende gibt es 3 Bahnhofe

* Eine für die Büsse von De Lijn:
https://www.openstreetmap.org/relation/4299252
* Eine für die Trams von De Lijn:
https://www.openstreetmap.org/relation/4299241
* Und das Bahnhof von NMBS:
https://www.openstreetmap.org/relation/4299253

Die sind dann wieder zusammgefasst in:
https://www.openstreetmap.org/relation/4299254

Es gibt auch ein Ferryterminal. Darüber fehlen mir aber die Daten, sonnst würde der auch ein Eintrag bekommen in die letzte Relation.

Gent Zuid hat Gleise für Tram und viele Steige für Büse.

Die sind durchnumeriert, also reicht eine Relation um die zu grupieren:

https://www.openstreetmap.org/relation/4307993

(In Oostende ist es eine Ausnahme dass die Gleise vom Tram ihre eigene Sequenz für Numerierung haben. Das ist historisch so gekommen und es wird warscheinlich nicht mehr so sein nachdem das ganze in welche Jahren umgebaut wird zu einem völlig integrierten Bahnhof.)

Weide wrote:

Wenn eine zweite Platform da ist, dann darf ein Mapper sie auch in einer Route benutzen. (Er darf nicht beide Platforms benutzen, das wären dann zwei Halte und falsch.) Jetzt kann man aber an der einzelnen Platform eventuell nicht mehr alle Routen erkennen, weil einige auf der anderen Platform liegen.

Man kann nicht vorhersehen wie die Datenbank benutzt wird. Deshalb sollten die Sachen stimmen -- egal ob man einem ein Problem mit falschen Einträgen einfällt oder nicht.

Weide

Wenn man in ein ganzes Land der Regel hat um die Platforme die auf Ways un MPs gemappt sind nicht in die Routerelationen auf zu nehmen, dann ist da keine Verwirrung möglich. Wir sind hier angefangen HS nur auf Nodes zu mappen und es wäre sehr schwierig um das jetzt noch zu ändern. Ich bleibe dabei dass es besser gewesen wäre um diese Nodes nicht public_transport=platform zu vergeben.

Jetzt haben wir Nodes getaggt mit highway=bus_stop, public_transport=platform, bus/tram=yes welche alle Details enthalten.
Und Ways und MPs getaggt mit public_transport=platform, bus/tram=yes, highway/railway=platform, die angeben wo es in der Wirklichkeit Steige (Platforms) gibt.
Etwas verwirrend dass 2x public_transport=platform dafür benutzt wird, aber es ist unproblematisch um die 2 auseinander zu halten.

Das einzige Problem ist denn aber wo Routes über die Grenzen gehen, sowie in Aachen, Breda, Dunkerque. Da wird eine stop_area benötigt um die zu verbinden. Das funkzioniert natürlich nur, wenn es genau 1 stop_area pro HS gibt. Ist es möglich um das so vor zu schlagen für V3?

Die Segmentrouten habe ich jetzt selber auch aufgegeben. Ich entwickle einen Skript dass die Arbeit um die zu Warten/Unterhalten (maintenance) ungeheuer leichter macht. Es ist noch nicht völlig fertig, aber es spart schon viel Zeit.

Der nächsten Schritt ist dann eine Art webservice der angibt wo Wartung benötigt ist.

Frohe Weihnachten,

Jo

Offline

#55 2014-12-24 12:14:57

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:
Weide wrote:

Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.

Da hast du Recht. Das ist ein Problem. Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?

ausgeschlossen ist bei OSM nichts. Aber die Frage ist ob man die "abwärtskompatibilität" einfach so aufgeben möchte. Die Frage ist welchen Aufwand macht es dein Programm anzupassen? vielleicht kann man mit Version 3 einfach die Position der Haltestellen am "anderen Ende" einfach zu lassen, ohne es explizit zu fordern.

Offline

#56 2014-12-24 13:52:10

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.

Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.

In Oostende gibt es 3 Bahnhofe...

Weihnachten ruft ... deshalb nur ganz kurz...

Beim Bus gäbe es nach PTv2 nur eine stop_area mit allen 28 Platforms und allen 14 stop_positions. Alle 42 Elemente und die stop_area hätten "name=Oostende Station". Der Busbahnhof wäre also eine stop_area und nicht eine stop_area_group mit 14 stop_areas.

frohe Weihnacht und guten Rutsch
Weide

Offline

#57 2014-12-26 01:28:42

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 243

Re: Diskussion über Public Transport Version 2.1

Weide wrote:
Polyglot wrote:

Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.

Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.

In Oostende gibt es 3 Bahnhofe...

Weihnachten ruft ... deshalb nur ganz kurz...

Beim Bus gäbe es nach PTv2 nur eine stop_area mit allen 28 Platforms und allen 14 stop_positions. Alle 42 Elemente und die stop_area hätten "name=Oostende Station". Der Busbahnhof wäre also eine stop_area und nicht eine stop_area_group mit 14 stop_areas.

frohe Weihnacht und guten Rutsch
Weide

Ich weiss. Wenn das aber alles so auf einem Häufen geschmissen wird, kann nicht mehr daraus abgeleitet werden was zueinander gehört. Dann kann man auch einfach keinen stop_area machen und alles geometrisch ableiten (versuchen).

Jo

Offline

#58 2014-12-26 16:55:19

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?

Da ist nichts ausgeschlossen, wir bestimmen das ja alle zusammen.

In meinem Vorschlag ist aber zentral, dass die alten Relationen bleiben bis zumindest die wichtigsten Renderer beides können. Das Problem mit der Reihenfolge bleibt also -- egal ob ich das in meinem Vorschlag ändere oder nicht.

Weide

Offline

#59 2014-12-26 17:09:08

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Ich weiss. Wenn das aber alles so auf einem Häufen geschmissen wird, kann nicht mehr daraus abgeleitet werden was zueinander gehört. Dann kann man auch einfach keinen stop_area machen und alles geometrisch ableiten (versuchen).

Wir können gern darüber diskutieren, was bei PTv2 alles schlecht ist. Aber wenn wir etwas anderes wollen, dann sollten wir es nicht PTv2 nennen. Wenn erstmal viele Mapper die Maße von Objekten in Meter angegeben haben, dann sollte man nicht mehr darüber nachdenken, welche Länge für so einen Meter denn am praktischsten wäre. Man kann über neue und bessere Einheiten reden -- aber den Meter darf man nicht alle paar Wochen ändern.

Weide

Offline

#60 2014-12-29 15:11:14

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 436

Re: Diskussion über Public Transport Version 2.1

Im Public Transport Schema V2 wird für Routen ein "name"-Tag vorgeschlagen:

name = <vehicle type> <reference number>: <initial stop> => <terminal stop>    
Example: Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi

Dies ist unpassend und sollte verbessert werden, denn
- ein solcher Name existiert in der realen Welt nicht und widerspricht somit der Namenskonvention in OSM:
"The names should be restricted to the name of the item in question only and should not include categories, types, descriptions, addresses or notes."
- kollidiert mit dem realen Namen einer Verbindung, sofern dieser existiert

Wie die Comment-Spalte nahelegt ("Prose description of route variant.") sollte der Text in "description" statt "name" stehen.
V2.1 sollte diesen Designfehler korrigieren.

Offline

#61 2014-12-29 16:39:30

Maskulinum
Member
Registered: 2012-11-20
Posts: 91

Re: Diskussion über Public Transport Version 2.1

seawolff wrote:

Wie die Comment-Spalte nahelegt ("Prose description of route variant.") sollte der Text in "description" statt "name" stehen.
V2.1 sollte diesen Designfehler korrigieren.

Sollte dieses "Ungetüm" irgendwo stehen?
Bus => kommt aus dem route
201 => aus dem ref
initial stop => aus dem from
terminal stop => aus dem to
Varianten stecken im via

Offline

#62 2014-12-29 16:46:47

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,391

Re: Diskussion über Public Transport Version 2.1

Also sollen jetzt statt dem Namen der Buslinie nur noch Zahlen in OSM stehen?

Na vielen Dank. Dadurch wird die Übersichtlichkeit und die Benutzerfreundlichkeit stark gefördert.

Offline

#63 2014-12-29 17:02:31

Maskulinum
Member
Registered: 2012-11-20
Posts: 91

Re: Diskussion über Public Transport Version 2.1

Prince Kassad wrote:

Also sollen jetzt statt dem Namen der Buslinie nur noch Zahlen in OSM stehen?

Ich meinte dieses Ungetüm:
name = <vehicle type> <reference number>: <initial stop> => <terminal stop>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.

name wäre für mich z.B. statt "Bus 564 Hanau ⇒ Langen-Bergheim" "Linie 564 Langen-Bergheim", was wahrscheinlich auch auf dem Bus stehen könnte.
Don't panic. smile

Offline

#64 2014-12-29 20:02:35

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Maskulinum wrote:

Ich meinte dieses Ungetüm:
name = <vehicle type> <reference number>: <initial stop> => <terminal stop>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.

name wäre für mich z.B. statt "Bus 564 Hanau ⇒ Langen-Bergheim" "Linie 564 Langen-Bergheim", was wahrscheinlich auch auf dem Bus stehen könnte.

Da ist PTv2 noch kürzer: die Linie heißt dort "Bus 564". Die Linie insgesamt findet man in der route_master-Relation und nicht in den route-Relationen.

Bei den route-Relationen geht es um die Varianten und da ist der Startort genauso ein Unterscheidungsmerkmal wie der Zielort und manchmal müssen sogar Zwischenziele genannt werden. Auf dem Bus muss der Startort natürlich nicht stehen, denn den an einer bestimmten Haltestelle wartenden Passagieren ist die Vergangenheit des Busses ja völlig egal.

Statt "Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi" würde man auch vermutlich auch eher "Bus 201: Waldegg=>Wängi" schreiben.

Weide

Offline

#65 2014-12-29 22:29:20

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 436

Re: Diskussion über Public Transport Version 2.1

Weide wrote:
Maskulinum wrote:

Ich meinte dieses Ungetüm:
name = <vehicle type> <reference number>: <initial stop> => <terminal stop>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.

name wäre für mich z.B. statt "Bus 564 Hanau ⇒ Langen-Bergheim" "Linie 564 Langen-Bergheim", was wahrscheinlich auch auf dem Bus stehen könnte.

Da ist PTv2 noch kürzer: die Linie heißt dort "Bus 564". [...]
Statt "Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi" würde man auch vermutlich auch eher "Bus 201: Waldegg=>Wängi" schreiben.

Hier werden Busrouten meist als "Linie 201" oder evtl. "Linie 201 Start-Ziel" genannt (sowohl umgangssprachlich wie auch vom Betreiber).
Züge heißen "RB 84" oder vielleicht "RB 84 Lübeck – Kiel".
Die Konstuktionen  "<vehicle type> <reference number>: <initial stop> => <terminal stop>" sind keine Namen und gehören nicht ins name-Tag.
Als "description" oder "note" sind sie vermutlich unkritisch. Ob man sie überhaupt braucht ist eine andere Frage.

Offline

#66 2014-12-29 23:03:44

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

seawolff wrote:

Die Konstuktionen  "<vehicle type> <reference number>: <initial stop> => <terminal stop>" sind keine Namen und gehören nicht ins name-Tag.
Als "description" oder "note" sind sie vermutlich unkritisch. Ob man sie überhaupt braucht ist eine andere Frage.

Es sind von Mappern vergebene Varianten-Namen (nicht Liniennamen) und sie werden gebraucht. Sollen wir wirklich die drei Relationen der S2 von Essen, Duisburg und Recklinghausen nach Dortmund alle "S2 Dortmund" nennen? Dann sind die Master-Relationen unlesbar.
Um es nochmal klar zu sagen: es geht nicht um den Namen der Linie. Der ist in PTv2 "Train S2" oder "S2".

Weide

Offline

#67 2014-12-29 23:13:43

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 5,079
Website

Re: Diskussion über Public Transport Version 2.1

Zu Linienvarianten...

Da ich mich gerade mit Buslinien in meiner Umgebung beschäftige:

Hier mal das, was wir in der Pampa haben:

http://www.openstreetmap.org/relation/4435760 Hier der Fahrplan dazu: http://www.rvs-lds.de/tl_files/fahrplaene/509.pdf

Offiziell heißt sie: 509 Glietz < > Briesensee < > Lübben wobei lediglich die wenigsten der Linien die genannte Verbindung befahren. Das ist aber Standard hier... Die Linien sind so gestrickt, daß ein regelrechter Umlauf eines Busses und Fahrers über mehrere Linien entsteht...
Die Relation enthält alle Varianten des Fahrplans... wenn ich nichts übersehen hab...

Vom Einpflegen in OSM her ein riesen Aufwand...

Ach ja, die Angabe im name-Tag der einzelnen Routen-Variante hilft mir einigermaßen bei den vielen Varianten durchzusehen... sie sind für mich unerläßlich.


Sven

Last edited by streckenkundler (2014-12-29 23:15:30)

Online

#68 2014-12-29 23:33:37

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 243

Re: Diskussion über Public Transport Version 2.1

Gibt es eigentlich in Deutschland auch Geselschafte die ihre Daten offenbar machen unter Lizenz die in OSM übernommen werden kann, oder die damit einstimmen das die Daten in OSM aufgenommen werden?

Wenn man das von Fahrpläne ableiten muss, ist das tatsächlich ein ungeheuer Aufwand. Speziell weil das alles jetzt von unten aus zerbrochen wird von Mappern und von 'oben' aus wird das auch hier und dort manchmal angepasst.

Jo

Offline

#69 2014-12-29 23:34:57

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,391

Re: Diskussion über Public Transport Version 2.1

Ich wusste noch nicht mal dass es überhaupt erlaubt ist von Fahrplänen abzukupfern... es machen aber scheinbar viele.

Offline

#70 2014-12-29 23:52:30

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 243

Re: Diskussion über Public Transport Version 2.1

Wenn nicht von die Fahrplänen und nicht von die Quelldaten, wie kann man dann sicher sein alle Varianten sind eingeschlossen? Dann muss man diese Linien allen mal benutzen, mal auf Wochentag, mal am Samstag, mal am Sonntag, Freitagabends, Sonntagabends, Mittwoch zwischen 12 und 2. Mal die erste und die letzte Fahrt, weil die auch manchmal abweichen.

Und wie weiss man denn wenn etwas geändert würde and die Fahrplänen. Oder man musste es jede 3 Monate noch mal neu machen und vergleichen ob es noch stimmt.

Kein Problem mit 1000 Mappern, sondern wir sind froh wenn 1 pro Gegend sich daran interessiert.

Ich habe 2 Jahren mails geschickt an Gesellschaft De Lijn (Flandern) (Nicht jede Woche). Und auf einem Tag haben die dann Zustimmung gegeben um ihre Daten in OSM zu übernehmen. TEC (Wallonien) haben ihre Daten dann nochmal 2 Jahre später völlig freigegeben unter freie Lizenz.

Nur die Gesellschaft in Brüssel antwortet nicht. Vielleicht müsste ich mal auf Französisch versuchen... Man kann die Daten bekommen, aber die sagen: nicht für kommerzielle Benutzung. An Google haben die die schon langst vergeben. Und Google macht da auch eine Art kommerzielle Benutzung.

Jo

Offline

#71 2014-12-30 00:46:24

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 5,079
Website

Re: Diskussion über Public Transport Version 2.1

Prince Kassad wrote:

Ich wusste noch nicht mal dass es überhaupt erlaubt ist von Fahrplänen abzukupfern... es machen aber scheinbar viele.

ich verweise mal auf:
http://forum.openstreetmap.org/viewtopic.php?id=19209 und auf http://daten.berlin.de/datensaetze/vbb- … ember-2015

Online

#72 2014-12-30 09:17:53

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Gibt es eigentlich in Deutschland auch Geselschafte die ihre Daten offenbar machen unter Lizenz die in OSM übernommen werden kann, oder die damit einstimmen das die Daten in OSM aufgenommen werden?

Wenn man das von Fahrpläne ableiten muss, ist das tatsächlich ein ungeheuer Aufwand. Speziell weil das alles jetzt von unten aus zerbrochen wird von Mappern und von 'oben' aus wird das auch hier und dort manchmal angepasst.

Jo

Es sind mir derzeit keine Unternehmen bekannt, welche das tun. Aber es gibt Verbünde die dies tun bzw. getan haben. Einer der ersten war der VRS welcher die Mapper eingeladen hat und dort GPX Routen bereitgestellt hatte um die Linien zu übernehmen.
Später folgte der VBB, welcher regelmäßig aktualsierte GTFS Daten zur Verfügung stellt. Dabei gibt es die ausdrückliche Genehmigung der Übernahme in OSM. Es fehlt lediglich ein Konzept, wie dies geschehen kann.
Ich hatte einmal begonnen für ein automatisches Einlesen vorzuarbeiten: http://www.openstreetmap.org/relation/3 … 94/13.5257
Allerdings macht es als Einzelkämpfer nur wenig Spaß. Dazu kommt das die Daten leider nur Haltestellenbereichsscharf sind und man so diverse Spezialfälle leider nicht abdecken kann.
Wenn es dazu neue Ideen gibt, würde ich mich sehr freuen.

Inzwischen gibt es auch weitere Verbünde, die Ihre Daten anbieten. Darunter ist Ulm und der VRN (http://www.vrn.de/vrn/einfach-ankommen/ … index.html) Hier als VDV Format. Auch dabei kann ich gerne bei der Umwandlung behilflich sein. Leider hat es nur mit dem Zuschicken der Daten nicht geklappt.

Offline

#73 2014-12-30 11:14:17

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 436

Re: Diskussion über Public Transport Version 2.1

Weide wrote:

Es sind von Mappern vergebene Varianten-Namen (nicht Liniennamen) und sie werden gebraucht. Sollen wir wirklich die drei Relationen der S2 von Essen, Duisburg und Recklinghausen nach Dortmund alle "S2 Dortmund" nennen? Dann sind die Master-Relationen unlesbar.

Mapper vergeben keine Namen sondern erfassen existierende Namen (siehe Wiki:Names).
Mapper dürfen natürlich Bezeichnungen generieren, aber die gehören nicht nach "name" sondern in einen dafür vorgesehenen Key  oder evtl. in "note" oder "description".

Um es nochmal klar zu sagen: es geht nicht um den Namen der Linie. Der ist in PTv2 "Train S2" oder "S2".

Auch "Train S2" ist in Deutschland höchstwahrscheinlich nicht der übliche Name und gehört nicht ins "name"-Tag.

Offline

#74 2014-12-30 11:24:02

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 5,079
Website

Re: Diskussion über Public Transport Version 2.1

Ich weiß nicht, ob wir jetzt hier OT werden...

viw wrote:

Dazu kommt das die Daten leider nur Haltestellenbereichsscharf sind und man so diverse Spezialfälle leider nicht abdecken kann.

Mit der derzeitigen Datenlage kann die Haltestellen-ID lediglich in die Haltestellen-Relation geschrieben werden, da punktscharfe Daten wie bei einigen Stationen Berlins http://daten.berlin.de/datensaetze/%C3% … estationen fehlen. Hier sollte aber auch eindeutig festgelegt werden, was an welchen Tag kommt, ob Abkürzungen verwendet werden oder nicht. letzeres wäre besser.

In dem Datensatz stop_times der aktuellen Fahrplandaten wird nur von Haltestellenbereich zu Haltestellenbereich geroutet... Dort ist nicht aufgeschlüsselt, wenn es mehrere Haltepunkte gibt. Den Haltestellen-ID also in die Stop-Position zu schreiben bringt also nichts...

... und wenn man in die Bus-Relation anstelle Platform und Stop-Position die Haltestellen-Relation schreibt? ...ist aber auch Blöd...



Sven

Online

#75 2014-12-30 11:50:57

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 243

Re: Diskussion über Public Transport Version 2.1

Es ist in JOSM möglich Namen zusamenstellen zu lassen anhand tags und sogar tags von parent relations.

Das lässt dann aber iD und Potlatchbenutzer ohne Namen, wenn wir die in description oder note verschieben. Keine ahnung ob diese Editors mittlerweile zurückfallen können auf andere tags wenn name nicht vorhanden ist. Vor einige Jahren wollte der Entwickler von Potlatch das nicht unterstutzen.

Man muss dazu sowas:

    <item name="De Lijn" type="relation"
        name_template="route(!{parent() type=route_master'?{'{operator} {ref:De_Lijn} ' | '{ref} '}'}{ref} ?{'{from} - {via} - {to} ' | '{from} - {to} ' | '{from} ' | '{to} '}?{'{note} '})"
        name_template_filter="type=route route=bus">
    </item>
    
    <item name="De Lijn" type="relation"
        name_template="route_master(?{'{operator} {ref:De_Lijn} {ref} {name}'})"
        name_template_filter="type=route_master route_master=bus">
    </item>

    <item name="De Lijn" type="relation"
        name_template="route(!{parent() type=route_master'?{'{operator} {ref:De_Lijn} ' | '{ref} '}'}{ref} ?{'{from} - {via} - {to} ' | '{from} - {to} ' | '{from} ' | '{to} '}?{'{note} '})"
        name_template_filter="type=route route=tram">
    </item>
    
    <item name="De Lijn" type="relation"
        name_template="route_master(?{'{operator} {ref:De_Lijn} {ref} {name}'})"
        name_template_filter="type=route_master route_master=tram">
    </item>

an ein Presets file hinzufügen. Das muss natürlich erst mehr generell gemacht werden. Jetzt funktioniert es nur gut für route und route_master von De Lijn. Was mich daran gefällt ist das die schön zusammen geordnet werden im Relations pane.

Jo

Offline

Board footer

Powered by FluxBB