OpenStreetMap Forum

Kontinentalverschieber

Member

Registered: 2015-08-19

Posts: 191

Re: network und operator bei öffentlichen Verkehrmitteln

Versuch doch mal alle Haltestellen zu einer Masterelation herauszufinden.

Kein Problem. Es gibt ja bereits so ähnliche Strukturen und zwar in Form der route_master-Relation, die wiederum als Mitglieder die verschiedenen Routen-Relationen einer Linie hat. Wenn man nun beispielsweise wissen will, welche Haltestellen insgesamt durch eine solche mit route_master definierte Linie angesteuert werden, muss man zunächst von der route_master-Relation in die einzelnen Routen-Relationen gehen und dort dann wiederum nachschauen, wie es bezüglich der Mitglieder mit der rolle "platform" aussieht. Ich habe das einmal am Beispiel der S31 in Hamburg gemacht, die pro Richtung 3 Teile hat: Von Altona zum Hauptbahnhof und von dort alternativ entweder zum Berliner Tor oder nach Neugraben. In der Gegenrichtung dann vom Berliner Tor oder Neugraben zum Hauptbahnhof und vom Hauptbahnhof nach Altona.

Overpass-Turbo-Beispiel:

[out:json][timeout:25];
relation["type"="route_master"]["name"="HVV-S-Bahnlinie S31"]({{bbox}});rel(r);way(r:"platform");
out body;
>;
out skel qt;

Zunächst wird die gewünschte route_master-Relation herausgesucht, dann lässt man sich mittels rel(r) sämtliche Kindrelationen davon geben und dann lässt man sich wiederum mittels way(r:"platform") alle Wege daraus geben, die mit der Rolle platform getaggt sind.

bzw. zu welche(r/n) Masterrelation gehört die Haltestelle.

Das geht natürlich entsprechend analog.

Overpass-Turbo-Beispiel:

[out:json][timeout:25];
way(152813951);rel(bw:"platform");rel(br);relation._["type"="route_master"];
out tags;

Zunächst wird der Bahnsteig 3/4 des Hamburger Hauptbahnhofs ausgewählt way(152813951), dann lässt man sich mit rel(bw:"platform") alle Relationen geben, in denen dieser Weg mit der Rolle "platform" eingetragen ist. Dann lässt man sich wiederum mit rel(br) alle Elternrelationen davon geben und schließlich filtert man diese mit relation._["type"="route_master"] auf die gewünschten Relationen vom Typ route_master. Das Ergebnis ist nur im Daten-Fenster sichtbar - es sind die route_master-Relationen der Linien S1, S21 und S31. Die anderen S-Bahn-Linien (S2, S3, S11), die ebenfalls an diesen Bahnsteigen halten, verwenden keine route_master-Relation, sondern bestehen nur aus einfachen route-Relationen und sind demzufolge im Ergebnis absichtlich nicht enthalten.

Und wenn das zu einfach gelöst ist, dann denke ich können wir wieder über solche Relationsmonster nachdenken.

OK, dann mal los!

Sammelrelationen erleichtern die Arbeit, werden aber von einigen Technikfreaks und Abfrageverliebten als altmodisch und somit unnötig abgetan.

Ganz im Gegenteil: Sie erleichtern auch Abfragen ungemein, weil man sich nicht mehr mit Strings herumschlagen muss und hoffen, dass alle auch wirklich den String 1:1 übernommen haben bzw. irgendwelche Semikolon-Lösungen zu beachten sind, weil jemand mehrere Strings zusammen in ein Feld pressen wollte und lauter weitere Fälle. Wenn man mit Relationen umzugehen weiß, sind die total simpel und das Mittel der Wahl für viele Abfragen.

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Schade ich würde es zu gern testen wollen, aber bekomme immer eine Fehlermeldung.

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Jetzt geht es. Sieht auf jeden Fall interessant aus. Ob das für einen Gesamten Verbund wie den VBB klappen würde wage ich noch zu bezweifeln, aber für Teilbereiche ist es auf jeden Fall möglich.
Meinst du man könnte die Relation dann nachher mit Josm runterladen? Network VBB?

Bei der S31 ist mir ein ungewöhnliches Tagging aufgefallen, was wahrscheinlich so nicht sein sollte. Denn es gibt nur Relationen zwischen Hbf-Altona, Hbf-Neugraben und Hbf-Berliner Tor. Damit gibt es eigentlich keine durchgehende Verbindung von Altona nach Neugraben bzw. Altona nach Berliner Tor. In einen Proposal dazu wurden mal Segmente in Erwägung gezogen. Diese Segmente werden dann wieder zusammengefasst in einer Relation für die bestimmte Linienvariante und diese Linienvariante dann wieder in die Masterrelation.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

... wage ich noch zu bezweifeln, aber für Teilbereiche ist es auf jeden Fall möglich.

Ja. Wenn es allgemeingültig sein soll, dann muss man außer der Rolle "platform" auch noch die Rolle "stop" berücksichtigen und bei der Rolle "platform" auch Nodes und Multipolygone berücksichtigen. Die Rollen können außerdem auch noch in der Form "*_entry_only" und "*_exit_only" auftreten. Als beliebten Fehler könnte man auch noch die leere Rolle an Nodes berücksichtigen (war in PTv1 gleichwertig zu "stop", aber PTv1-Relationen können eigentlich nicht Mitglieder von Masterrelationen sein)

Weide

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

... wage ich noch zu bezweifeln, aber für Teilbereiche ist es auf jeden Fall möglich.

Ja. Wenn es allgemeingültig sein soll, dann muss man außer der Rolle "platform" auch noch die Rolle "stop" berücksichtigen und bei der Rolle "platform" auch Nodes und Multipolygone berücksichtigen. Die Rollen können außerdem auch noch in der Form "*_entry_only" und "*_exit_only" auftreten. Als beliebten Fehler könnte man auch noch die leere Rolle an Nodes berücksichtigen (war in PTv1 gleichwertig zu "stop", aber PTv1-Relationen können eigentlich nicht Mitglieder von Masterrelationen sein)

Weide

Das was du dort beschreibst, ist kein Beweis, das ein Server in der Lage ist zuverlässig alle Haltestellenmasten mit Network=Verkehrsverbund Berlin-Brandenburg auszugeben.
Denn ich glaube solche Zwischen Abfragen wie hier sind eher was für Programme wie OSMUpdate oder OSM2pgsql, da wenn die Datenmenge größer wird schnell der Arbeitsspeicher abnimmt. Im Prinzip muss die Datenbank dafür eigentlich eine neue Tabelle erstellen in der alle Relation sind die das Kriterium erfüllen und die wiederum müssen dann wiederum in einem Join alle Member herausfinden und in einem weiteren Join dann die Koordinaten. Bei Ways gibts noch einen weiteren Zwischenschritt.
Und wenn es blöd läuft fügt einer die Punkte direkt hinzu und die fallen dann unter den Tisch. In der Masterrelation der S31 war auch noch ein Way drin.

Kontinentalverschieber

Member

Registered: 2015-08-19

Posts: 191

Re: network und operator bei öffentlichen Verkehrmitteln

Ob das für einen Gesamten Verbund wie den VBB klappen würde wage ich noch zu bezweifeln, aber für Teilbereiche ist es auf jeden Fall möglich.

Schlimmer, als wenn man versuchen würde, mit einer Network-Key-Suche heranzukommen, wird es definitiv nicht. Für die Datenbank dürften die Relationen sogar ein Vorteil sein, allerspätestens dann, wenn man beim Network-Key auch noch anfangen muss, unscharf zu suchen oder mehrere Suchanfragen zu stellen (beispielsweise sind Bushaltestellen in Ludwigsfelde vielfach mit network="VBB" statt network="Verkehrsverbund Berlin-Brandenburg" getaggt).

Was natürlich, insbesondere bei Visualisierung (bei reiner Datenanforderung eher nicht) problematisch werden kann, ist der reine Umfang an Haltestellen bei großen Gebieten. Aber das Problem hat man so oder so.

Meinst du man könnte die Relation dann nachher mit Josm runterladen? Network VBB?

Da gibt es keinen Unterschied zum jetzigen Zustand. Man kann die Elemente einer Relation per Rechtsklick herunterladen oder im Relations-Editor unter dem Tab Kind-Relationen auch die Kind-Relationen inklusive ihrer Elemente.

Schade ich würde es zu gern testen wollen, aber bekomme immer eine Fehlermeldung.

Das lag daran, dass der Server overpass-api.de ausgefallen ist (unter anderem funktionierte auch die Objektabfrage auf der OSM-Karte deshalb nicht mehr). Man kann bei Overpass-Turbo unter Einstellungen den Server wechseln. Die anderen beiden dort angebotenen Server haben noch funktioniert. Allerdings wirkt diese Einstellung nur lokal und wird nicht in die Links zum Teilen übernommen.

Wenn es allgemeingültig sein soll, dann muss man außer der Rolle "platform" auch noch die Rolle "stop"...

Es ging hier nicht darum, eine allgemeingültige Abfrage für alle möglichen Rollen in Route-Relationen zu formulieren, sondern darzustellen, wie man sehr problemlos aufsteigend oder absteigend innerhalb von Relationen suchen kann. Dass diese ganze public_transport-Geschichte ein System mit zu vielen Freiheitsgraden und zu wenig Verbindlichkeit ist, lässt sich leider nicht leugnen und macht viele Auswertungen unnötig kompliziert, wenn man sie dann wirklich mal entwerfen muss.

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Ob das für einen Gesamten Verbund wie den VBB klappen würde wage ich noch zu bezweifeln, aber für Teilbereiche ist es auf jeden Fall möglich.

Schlimmer, als wenn man versuchen würde, mit einer Network-Key-Suche heranzukommen, wird es definitiv nicht. Für die Datenbank dürften die Relationen sogar ein Vorteil sein, allerspätestens dann, wenn man beim Network-Key auch noch anfangen muss, unscharf zu suchen oder mehrere Suchanfragen zu stellen (beispielsweise sind Bushaltestellen in Ludwigsfelde vielfach mit network="VBB" statt network="Verkehrsverbund Berlin-Brandenburg" getaggt).

Es ist schon ein drastischer Unterschied!
Die Daten stehen in Tabellen. Und wenn man jetzt in der Tabelle nodes alle sucht die ein bestimmten Key-Value aufweisen egal ob unscharf oder nicht, dann reicht es dem Datenbanksystem einmal durch die Tabelle durch zu laufen. Das Problem ist höchstens ein zu großes Ergebnis, welches man dann mit limit auf eine bestimmte Datensatzzahl begrenzen kann.

Wenn aber dein Fall eintritt, dann muss das Datenbanksystem zu erste eine Zwischentabelle anlegen in dem alle Relationen die in der Ursprungsrealtion aufgeführt waren zwischengespeichert werden. In dem Beispiel mit der S31 waren das 6 Stück. Als nächstes muss in alle Relationen wiederum nach den Nodes geschaut werden und als Zwischentabelle abgelegt werden. Dann kommt ein Join mit der Ursprungstabelle nodes in dem alle Knoten dann ihre Koordinaten erhalten.
Es scheint also nur das selbe zu sein. In wirklichkeit ist der Aufwand aber deutlich höher. Jedenfalls für das Datenbanksystem.
Ich glaube das ist auch ein Grund dafür warum es bisher keine Karte geschafft hat die Information forward backward in einer Karte umzusetzen.
Der Unterschied ist einfach ob ich einen Weg nehme und abfrage welche Rollen der in allen Relationen hat in denen er vorkommt, oder ob ich in allen Relationen erstmal diese Rollen berechnen muss um zu sehen welche Rollen dann für diesen Weg am Ende rauskommen.

Kontinentalverschieber

Member

Registered: 2015-08-19

Posts: 191

Re: network und operator bei öffentlichen Verkehrmitteln

Das ist ziemlich viel Spekulation und hängt üblicherweise auch von der konkreten Implementierung der Datenbank ab. Bei einer unscharfen Suche ist aber beispielsweise der Aufwand um Größenordnungen höher. Dort müssen nämlich tatsächlich komplette Tabellen durchlaufen und für jede Zeile eine Vergleichsoperation ausgeführt werden, was teuer ist (bei einer scharfen Suche könnte eventuell dagegen ein Index die Sache deutlich beschleunigen). Relationen dürften dagegen komplett auf dem Index arbeiten. Die Elemente der Relation sind also nur Verweise auf Einträge in den jeweiligen Tabellen. Demzufolge braucht es da keine Zwischentabellen und erst recht keine aufwändigen Join-Operationen, sondern man hat schon direkt den Verweis auf den eigentlichen Eintrag in der Hand (man weiß also, wo im Speicher das referenzierte Objekt steht und braucht es in der Zieltabelle nicht suchen).

Ich bezweifle auch, dass backward und forward gerade für Karten wegen des Datenbankaufwandes nicht ausgewertet werden. Bei Karten sind doch eher die Darstellungsoperationen bei der Generierung der Flaschenhals. Es dürfte, wie bei allen Tags, vor allem eine Frage des Programmieraufwandes und des daraus resultierenden Nutzen sein und dass noch x andere Anforderungen auf Implementierung warten. So oft, wie sich bei OSM neue Tagging-Schemas ausgedacht werden, kann ohnehin kein Programmierer nachkommen, so dass man da stets auswählen muss, was man alles unterstützt. Und forward und backward ist dann meist auch bei der Darstellung nicht trivial - da muss man sich teils auch erst einmal geeignete Formen einfallen lassen, so dass man das lieber rausschiebt.

Last edited by Kontinentalverschieber (2015-08-25 18:42:29)

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

Ich glaube das ist auch ein Grund dafür warum es bisher keine Karte geschafft hat die Information forward backward in einer Karte umzusetzen.
Der Unterschied ist einfach ob ich einen Weg nehme und abfrage welche Rollen der in allen Relationen hat in denen er vorkommt, oder ob ich in allen Relationen erstmal diese Rollen berechnen muss um zu sehen welche Rollen dann für diesen Weg am Ende rauskommen.

Ja, so isses. Es ist ganz sicher kompliziert ... ich hab es gemacht. Dabei berechne ich für ein Gebiet aus OSM-PBFs neue OSM-Daten, die die erforderlichen ÖPNV-Angaben in "leicht verdaulicher Form" enthalten. Auf diese Daten kann man dann z.B. mkgmap loslassen.

Da wird dann z.B. aus:

<way id="120032728"
 ...
<tag k="cycleway" v="lane"/>
<tag k="highway" v="tertiary"/>
<tag k="lanes" v="2"/>
<tag k="maxspeed" v="50"/>
<tag k="name" v="Hochdahler Straße"/>
</way>

der folgende Datensatz zur Generierung von ÖPNV-Overlays:

<way id='120032728'
...
<tag k='kind' v='tourway'/>
<tag k='class' v='3'/>
<tag k='lines_forward' v='O3'/>
<tag k='vehicles_forward' v='+bus+'/>
<tag k='lines_bidirectional' v='741,DL4'/>
<tag k='vehicles_bidirectional' v='+bus+'/>
<tag k='lines' v='741,DL4,O3'/>
<tag k='vehicles' v='+bus+'/>

Die Haltestellen enthalten entsprechende Angaben zu den Linien und aus den Stopareas und Stop-Area-Groups werden Flächen mit entsprechenden Linienangaben.

Die Software liegt auf http://www.gafte.de. Es ist freie Software für Linux und Windows sowie die Quellen.

Weide

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

Das was du dort beschreibst, ist kein Beweis, das ein Server in der Lage ist zuverlässig alle Haltestellenmasten mit Network=Verkehrsverbund Berlin-Brandenburg auszugeben.

Nö. Ich war aber auch garnicht auf die Idee gekommen, sowas beweisen oder behaupten zu wollen. Es ging mir nur darum, ein paar Lücken der Abfrage zu zeigen.

Weide

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Ich glaube das ist auch ein Grund dafür warum es bisher keine Karte geschafft hat die Information forward backward in einer Karte umzusetzen.
Der Unterschied ist einfach ob ich einen Weg nehme und abfrage welche Rollen der in allen Relationen hat in denen er vorkommt, oder ob ich in allen Relationen erstmal diese Rollen berechnen muss um zu sehen welche Rollen dann für diesen Weg am Ende rauskommen.

Ja, so isses. Es ist ganz sicher kompliziert ... ich hab es gemacht. Dabei berechne ich für ein Gebiet aus OSM-PBFs neue OSM-Daten, die die erforderlichen ÖPNV-Angaben in "leicht verdaulicher Form" enthalten. Auf diese Daten kann man dann z.B. mkgmap loslassen.

Da wird dann z.B. aus:

<way id="120032728"
 ...
<tag k="cycleway" v="lane"/>
<tag k="highway" v="tertiary"/>
<tag k="lanes" v="2"/>
<tag k="maxspeed" v="50"/>
<tag k="name" v="Hochdahler Straße"/>
</way>

der folgende Datensatz zur Generierung von ÖPNV-Overlays:

<way id='120032728'
...
<tag k='kind' v='tourway'/>
<tag k='class' v='3'/>
<tag k='lines_forward' v='O3'/>
<tag k='vehicles_forward' v='+bus+'/>
<tag k='lines_bidirectional' v='741,DL4'/>
<tag k='vehicles_bidirectional' v='+bus+'/>
<tag k='lines' v='741,DL4,O3'/>
<tag k='vehicles' v='+bus+'/>

Die Haltestellen enthalten entsprechende Angaben zu den Linien und aus den Stopareas und Stop-Area-Groups werden Flächen mit entsprechenden Linienangaben.

Die Software liegt auf http://www.gafte.de. Es ist freie Software für Linux und Windows sowie die Quellen.

Weide

Also du hast eine Lösung für die einmalige Aufbereitung geschaffen. Wie du dabei vorgehst, kann ich leider nicth sehen, da im Programm nur das Ergebnis steht.
Wie sieht es aber mit Diffs aus? Das ist ja der Knackpunkt auf der ÖPNVKarte. Insbesondere was die Stopareas angeht und welche Linien an welchen Haltestellen halten.

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Ja, so isses. Es ist ganz sicher kompliziert ... ich hab es gemacht. Dabei berechne ich für ein Gebiet aus OSM-PBFs neue OSM-Daten, die die erforderlichen ÖPNV-Angaben in "leicht verdaulicher Form" enthalten. Auf diese Daten kann man dann z.B. mkgmap loslassen.

Da wird dann z.B. aus:

<way id="120032728"
 ...
<tag k="cycleway" v="lane"/>
<tag k="highway" v="tertiary"/>
<tag k="lanes" v="2"/>
<tag k="maxspeed" v="50"/>
<tag k="name" v="Hochdahler Straße"/>
</way>

der folgende Datensatz zur Generierung von ÖPNV-Overlays:

<way id='120032728'
...
<tag k='kind' v='tourway'/>
<tag k='class' v='3'/>
<tag k='lines_forward' v='O3'/>
<tag k='vehicles_forward' v='+bus+'/>
<tag k='lines_bidirectional' v='741,DL4'/>
<tag k='vehicles_bidirectional' v='+bus+'/>
<tag k='lines' v='741,DL4,O3'/>
<tag k='vehicles' v='+bus+'/>

Kannst du das Ergebnis vielleicht einmal erläutern? Ich habe das Programm jetzt einfach mal auf Brandenburg von heute losgelassen.
Dabei finde ich dann:

<way id='254552421' visible='true' version='1'>
<nd ref='2603515639'/>
<nd ref='212906195'/>
<nd ref='212905599'/>
<tag k='kind' v='tourway'/>
<tag k='class' v='3'/>
<tag k='lines_backward' v='893'/>
<tag k='vehicles_backward' v='+bus+'/>
<tag k='lines' v='893'/>
<tag k='vehicles' v='+bus+'/>
<tag k='pt_oneway' v='-1'/>
</way>

Wenn ich mich nicht irre, dann ist auf diesem Weg die Linie 893 in beiden Richtungen unterwegs. Die Linie 256 ist mit zwei Routen in einer Richtung unterwegs.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

Wie sieht es aber mit Diffs aus?

Schlecht. Da hab ich nichts.

Bei kleinen Gebieten ist das nicht so schlimm ... da dauert es nicht so lang. Aber germany.pbf brauchte beim letzten Test 41Min (Athlon II X2 250 3GHz, 58% von 8GB) und Europa wird auf meinem Rechner wohl nicht gehen.

Weide

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

Wenn ich mich nicht irre, dann ist auf diesem Weg die Linie 893 in beiden Richtungen unterwegs. Die Linie 256 ist mit zwei Routen in einer Richtung unterwegs.

Da müsste in der "err"-Datei einiges zu diesen Linien stehen. Wenn eine Masterroute da ist, dann müssten die enthaltenen Routen PTv2 sein. Eine 893 hat aber stops ohne Rolle ... das gab es nur bei PTv1. Eine der 256 hat "forward" und "backward", die nur bei PTv1 vorkommen können, sowie "platform", das nur in PTv2-Routen vorkommen kann. Vermutlich steht in der "err"-Datei, dass einige Routen deshalb ignoriert wurden.

Weide

PS: Es könnte helfen, "public_transport:version=1 oder 2" ausdrücklich reinzuschreiben. Dann muss das Programm nicht raten und kann sich nicht mit "wat weis ich wat dat sein soll" beklagen.

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Dann schauen wir mal wie das Ganze morgen aussieht.

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Kannst du noch etwas zu der Programmierung sagen? adb ads werden zwar als AccessProjektdatei erkannt, aber lassen sich mit Access nicht öffnen.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

Kannst du noch etwas zu der Programmierung sagen? adb ads werden zwar als AccessProjektdatei erkannt, aber lassen sich mit Access nicht öffnen.

Das hat mit Access nichts zu tun. Es sind Programme in der Programmiersprache Ada (https://de.wikipedia.org/wiki/Ada_%28Pr … sprache%29). Die Dateien kann man mit jedem Texteditor lesen.

Weide

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Wenn ich mich nicht irre, dann ist auf diesem Weg die Linie 893 in beiden Richtungen unterwegs. Die Linie 256 ist mit zwei Routen in einer Richtung unterwegs.

Da müsste in der "err"-Datei einiges zu diesen Linien stehen. Wenn eine Masterroute da ist, dann müssten die enthaltenen Routen PTv2 sein. Eine 893 hat aber stops ohne Rolle ... das gab es nur bei PTv1. Eine der 256 hat "forward" und "backward", die nur bei PTv1 vorkommen können, sowie "platform", das nur in PTv2-Routen vorkommen kann. Vermutlich steht in der "err"-Datei, dass einige Routen deshalb ignoriert wurden.

Weide

PS: Es könnte helfen, "public_transport:version=1 oder 2" ausdrücklich reinzuschreiben. Dann muss das Programm nicht raten und kann sich nicht mit "wat weis ich wat dat sein soll" beklagen.

Ich finde es etwas unglücklich, das ein Programm nur wegen der forward und backwardrollen die Relation nicht verarbeiten kann. Denn das eigentlich der einzige Fehler den ich zum validen PTV2 finden konnte. Das würde die Route aber wiederum abwärtskompatibel machen.
Das gleiche gilt natürlich auch für leere Rollen bei Stop oder Platform.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

Dann schauen wir mal wie das Ganze morgen aussieht.

Da kommt dann

<tag k='lines_forward' v='256'/>
<tag k='vehicles_forward' v='+bus+'/>
<tag k='lines_bidirectional' v='893'/>
<tag k='vehicles_bidirectional' v='+bus+'/>
<tag k='lines' v='893,256'/>
<tag k='vehicles' v='+bus+'/>

Wenn man im JOSM genug geladen hat, dann kann man das als osm-Datei speichern und die mit

osmosis  --read-xml file="josmsave.osm"  enableDateParsing=no --write-pbf file="josmsave.pbf"  omitmetadata=true

in pbf umwandeln. Die Fehlermeldungen sind dann aber schlechter, weil der Kontext fehlt.

Weide

Seoman

Member

Registered: 2011-07-14

Posts: 61

Re: network und operator bei öffentlichen Verkehrmitteln

Persönlich wäre ich dafür, ausgeschriebene Namen vorzuschreiben (deshalb wäre eine Liste vermutlich noch wichtiger, weil sonst die Einheitlichkeit kaum herzustellen ist). Denn die Abkürzungen haben das Problem, dass sie schon innerhalb der Bundesrepublik nicht kollisionsresistent sind. Eine "MVG" gibt es beispielsweise laut Wikipedia schon sechs Mal in Deutschland. Das würde also Auswertungen sehr kompliziert machen, weil man dann immer noch das Betriebsgebiet der einzelnen Gesellschaften wissen muss, um dort die gleichen Tags aufzulösen.

Ich sehe es ebenso. Ausgeschriebene Namen sind für mich die "richtige" Information, während die Abkürzungen die "komfortable" Information darstellen. Ich bin daher dafür, auf ein einheitliches Schema hinzuarbeiten, bei dem

1. die ausgeschriebenen Namen als bessere Variante empfohlen werden und
2. die Abkürzungen als abgeleiteter Tag empfohlen werden.

Als Beispiel würde das dann so aussehen:

"operator"="Langer Name der Betreibergesellschaft"
"operator:short"="LNB"
"network"="Langer Name des Verkehrsverbunds"
"network:short"="LNV"

Außerdem kam hier die Frage auf, wie mit unterschiedlichen Werten an einer Haltestelle umgegangen werden soll. Ich sehe hier zwei Fälle:

a) Verschiedene Transportmittel, z.B. am Bahnhof. Hier ließe sich das durch ein Subtag lösen:

"operator:train"="Bahnunternehmen AG"
"operator:train:short"="BU"
"operator:bus"="Busunternehmen A-Stadt"
"operator:bus:short"="BUA"

b) Mehrere Anbieter für dasselbe Transportmittel. Hier sollte es bei der Lösung mit Semikolon bleiben:

"operator:train"="Bahnunternehmen AG;Eisenbahnunternehmen AG"
"operator:train:short"="BU;EBU"

Jeweils analog für network.

Zusätzliche Anregung: Um die Durchsetzung und Akzeptanz seitens der Betreiber zu erhalten, ließe sich vielleicht so etwas wie ein Workshop auf einer Fachtagung der ÖPNV-Anbieter organisieren.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: network und operator bei öffentlichen Verkehrmitteln

a) Verschiedene Transportmittel, z.B. am Bahnhof. Hier ließe sich das durch ein Subtag lösen:

"operator:train"="Bahnunternehmen AG"
"operator:train:short"="BU"
"operator:bus"="Busunternehmen A-Stadt"
"operator:bus:short"="BUA"

Es geht aber um die Zuständigkeit für die Haltestelle. Also etwa den Ansprechpartner, wenn die Scheiben des Wartehäuschens kaputt sind. Aber auch da können mehrere Zuständigkeiten existieren. Ich kenne einen Fall, bei dem die Stadt für die Wartehäuschen und ein ÖPNV-Betreiber für die Pflasterung zuständig ist.

Das mit dem ":short" finde ich gut.

Weide

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

Ausgeschriebene Namen sind für mich die "richtige" Information, während die Abkürzungen die "komfortable" Information darstellen. Ich bin daher dafür, auf ein einheitliches Schema hinzuarbeiten, bei dem

1. die ausgeschriebenen Namen als bessere Variante empfohlen werden und
2. die Abkürzungen als abgeleiteter Tag empfohlen werden.

Als Beispiel würde das dann so aussehen:

"operator"="Langer Name der Betreibergesellschaft"
"operator:short"="LNB"
"network"="Langer Name des Verkehrsverbunds"
"network:short"="LNV"

Dieser Streit ist alles nicht neu. Es geht vor allem darum was die Menschen sagen. Ich höre nirgendwo in Berlin jemanden sagen "die Berliner Verkehrsbetriebe". Man spricht einfach von der BVG!
Gleiches gilt auch für andere Unternehmen. Die treten einfach als BOGESTRA oder DVB auf. Das ist nicht nur ein shortname, den jemand einträgt weil er zu faul ist.(aber auch)

Seoman

Member

Registered: 2011-07-14

Posts: 61

Re: network und operator bei öffentlichen Verkehrmitteln

Dieser Streit ist alles nicht neu. Es geht vor allem darum was die Menschen sagen. Ich höre nirgendwo in Berlin jemanden sagen "die Berliner Verkehrsbetriebe". Man spricht einfach von der BVG!
Gleiches gilt auch für andere Unternehmen. Die treten einfach als BOGESTRA oder DVB auf. Das ist nicht nur ein shortname, den jemand einträgt weil er zu faul ist.(aber auch)

Aber genau das spricht doch dafür, es z.B. so zu handhaben wie ich vorgeschlagen habe: Beide Parteien können ihre Variante unterbringen.

Man könnte auch so etwas verwenden wie

a)
"operator"="BOGESTRA" +
"operator:short"="BOGESTRA" +
"operator:long"="Bochum-Gelsenkirchener Straßenbahnen AG"

Beide Varianten stehen drin, aber das Tag ohne Subkey kennzeichnet den üblichen Gebrauch.

Oder b)
"operator:usage"="BOGESTRA" +
"operator:short"="BOGESTRA" +
"operator:long"="Bochum-Gelsenkirchener Straßenbahnen AG"

Das ":usage" würde dann den üblichen Gebrauch kennzeichnen.

Solange die Unternehmen sich nicht umbennen und der lange Name existiert, dann gehört der auch in die Datenbank.

Seoman

Thoschi

Member

Registered: 2013-07-19

Posts: 767

Re: network und operator bei öffentlichen Verkehrmitteln

Es gab mal abbr:operator oder abbr:name ... das wurde dann wieder rausgeworfen.
Problem mit Abkürzungen ist doch eher der alte Streit mit "wir mappen was man sieht" (was dann auch noch häufig fehlerhaft als unverrückbare Regel dargestellt wird).
Ich habe nicht dagegen, den Langnamen anzugeben, finde es eigentlich sogar richtig. Ich habe nur etwas dagegen, die Abkürzung als falsch zu verdammen.
Ich finde die Lösung a) gut, mit :usage kann kaum jemand etwas anfangen. Und wer auswertet kann sich dann auf :short oder :long beschränken.

viw

Member

Registered: 2010-05-15

Posts: 2,623

Re: network und operator bei öffentlichen Verkehrmitteln

je mehr tags das werden, desto mehr bin ich dafür Relationen zu verwenden. Denn ich mag nicht an jedem Pups 3 Tags für ein und das selbe pflegen. nachher kommt noch der Streit mit der Rechtsform. Also Deutsche Post oder Deutsche Post AG usw.