Es währe einfacher, wenn alle Haltestellen eines Betreibers in einer der ungeliebten Sammelrelationen zusammengefasst wären. Dort bräuchte man nur einmal ändern, bzw könnten Blöckeweise raus und reinnehmen. Sammelrelationen erleichtern die Arbeit, werden aber von einigen Technikfreaks und Abfrageverliebten als altmodisch und somit unnötig abgetan. Ich sehe dies anders.
Blockweise heißt, dass die Relation auch sortiert ist. Ansonsten lassen sich 20 Elemente aus 1000 eben nicht mal schnell entfernen, weil du dann jedes einzeln suchen musst.
Desweiteren ist die Frage was in dieser Relation ist. Sind es die einzelnen Masten einer Haltestelle, ist das ganze noch recht übersichtlich. Aber wenn es wie vorgeschlagen Relationen sind, die ihrereseits wieder Elemente enthalten, so wird das ganze unübersichtlich.
Versuch doch mal alle Haltestellen zu einer Masterelation herauszufinden. bzw. zu welche(r/n) Masterrelation gehört die Haltestelle. Und wenn das zu einfach gelöst ist, dann denke ich können wir wieder über solche Relationsmonster nachdenken.
Ich glaube nicht, dass dieser Konflikt tatsächlich existiert.
Ich bin z.B. gegen Sammelrelationen und finde operator und network als Relationen praktischer als als Tags und sehe darin nicht den mindesten Widerspruch.
Sammelrelationen hat man doch nur dann, wenn ohnehin schon vorhandene Informationen nochmal in Relationsform gespeichert werden.
Wenn jemand network und operator beibehalten will und zusätzlich in Relationsform speichern will, dann bin ich dagegen. Das sind Sammelrelationen und die sind Mist.
Wenn jemand network und operator aber durch entsprechende Relationen ersetzen will (und dabei eine Übergangszeit mit beiden einkalkuliert), dann ist da keine Sammelrelation. Das ist ein anderes Konzept der Datenspeicherung über dessen Vor- und Nachteile man reden muss, gegen das aber im Prinzip nichts spricht.
Weide
stop_areas sind optional und das aus gutem Grund. Vermutlich ist es am Besten, die Objekte einzeln aufzunehmen.
Bei den Routen ist es schwieriger…
Weide
Es gab doch auch mal die Idee, network als Fläche darzustellen…
Weide
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.
[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.
Das geht natürlich entsprechend analog.
[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.
OK, dann mal los! 
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.
Schade ich würde es zu gern testen wollen, aber bekomme immer eine Fehlermeldung.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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
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.
Dann schauen wir mal wie das Ganze morgen aussieht.