erstmal herzlichen dank an alle Beteiligten. Heute nun wurde ich auf die Dokumentation aufmerksam gemacht.
Jetzt ergeben sich aber noch Fragen:
Wenn man Linien auf Oxomoa Shema umstellt, dann bekommt man für jede Linienvariante eine eigene Relation. Werden hierin für die Straßenabschnitte rollen wie forward und backward gepflegt?
Die Doku bearbeitet ausführlich wie Stoparea und stopareagroup getagt werden sollen. Mir erschließt sich aber nicht warum hier 5 Stopeareas gebraucht werden.
Am Beispiel in Dresden würde ich für den Bf Neustadt 2-3 Stopareas wählen. http://www.openstreetmap.org/?lat=51.065692&lon=13.740836&zoom=18&layers=M
Und zwar Straßenbahn nordwestlich name=Bahnhof Neustadt, Hansastraße
Straßenbahn südlich sowie Busse in der Mitte name=Bahnhof Neustadt
und alle Bahnsteige name=Dresden-Neustadt
Aber ich würde keinen Grund erkennen warum der Bus und die Straßenbahn voneinander getrennt werden müssten, obwohl sie an der anderen Seite des Schlesischen Platzes liegen.
Welchen Sinn ergeben spezielle Schulbusse in der Karte? Ich meine Schülerverkehre nach §42 sind für jedermann und sicher auch als Linienfahrten veröffentlicht. Freigestelte Schülerverkehre FVO sind nicht veröffentlicht und auch nur für Schüler daher stelle ich den Nutzen auf der Karte in Frage.
Außerdem bietet das Oxomoa Schema die Möglichkeit den Zweck in der Linienrelation zu hinterlegen. Bei den verschiedenen Rufbussen wird man sicher an den vielen Varianten in Deutschland scheitern.
Es gibt hier die Taxibusse/Anruflinientaxi/Rufbusse diese fahren auf einem festen Linienweg entweder nach Fahrplan oder komplett nach Bedarf
Dann gibt es Anrufsammeltaxis/Flächenrufbusse manche sind individuell wie ein Taxi auf einen bestimmten Bereich von Haustür zu Haustür bei anderen ist wenigstens Start oder Ziel eine Haltestelle
Dazu kommen dann noch Bürgerbusse oder Busse welche nach Fahrplanfahren und bei Bedarf Stichfahrten oder Sammelfahrten haben. Wie will man gerade letzteres darstellen?
Man möge mir bitte verzeihen, dass ich nicht explizit wiederholt habe, was an anderer Stelle im Forum bereits steht. Ich wollte thematisch an diesen Thread http://forum.openstreetmap.org/viewtopic.php?id=9652 anschließen. Allerdings wollte ich keinem zumuten bis zum Ende zu lesen.
Welche Art von Ergebnis erwartest du? In der Dokumentation wurde deutlich aufgeführt, was erreicht wurde. Auch steht dort zu lesen, das die GPX Daten nur von Ortskundigen übernommen werden sollten, da es offenbar Abweichungen gibt, welche einen automatischen Import unmöglich machen.
Auch habe ich über einzelne Linien gelesen welche in Angriff genommen wurden. Mehr Ergebnisse wird so ein Workshop kaum hergeben.
Diese Rollen waren für die Darstellung der Pfeile in der ÖPNVKarte verantwortlich. Warum sollen diese also jetzt komplett entfallen? Wie werden diese Richtungsinformationen dann dokumentiert?
Die Relation bekommt die Eigenschaften “from” und “to”. Hier sind Start- und Endhaltestelle der Route gemeint. Weiterhin sollten die Mitglieder der Relation in der Reihenfolge der Route eingetragen werden. Dies gilt sowohl für die Strecken als auch für die Haltepunkte und Platformen.
Soweit ist das alles klar. Aber zum Beispiel die ÖPNV Karte wird sich zum rendern nicht die From to tags anschauen und dann entlang der Linie wandern, sondern hier werden die Ways angeschaut. Welche Rolle sie in Relationen mit einem bestimmten tag besitzen. Bei der ÖPNV karte waren das route oder line = bus; tram; rail etc.
Das von dir vorgegebene Schema ist zwar konsistent und man kann die nötigen Informationen finden. Aber für die Aufbereitung würde das bedeuten zunächst zu jedem Way die Relationen anzuschauen und dann jede Relation von vorne bis hinten durchlaufen um jedem Weg den nötigen Tag zu geben. Ob derartiger Aufwand beim Import gemacht wird oder gemacht werden kann, denn man muss ja anhand der Reihenfolge erkennen ob ich in oder gegen die Wegrichtung fahre, ist aus meiner Sicht fraglich.
Sollte ich mich irren, bitte ich um Richtigstellung.
Mmmh, ich weiß jetzt zwar nicht, wie Melchior seine ÖPNV-Karte programmiert hat, jedenfalls wäre bzw. ist es für sein “Compi” “pipifax”, aus der oben angegebenen Darstellung jetzt noch “Hausdorffstraße” ein “forward”, “Dottendorfer Straße” ein forward (2x), “Kessenicher Straße” ein “backward” intern zu geben, damit seine Richtungspfeile wieder passen.
Noch verstärkend, ich bin froh, als Mensch nicht mehr diese “stumpfsinnigen” forward/backward’s eintragen zu müssen, die ein Proggie in Nullkommanix erstellt hat.
Und was das menschliche Erfassen anbelangt, hast Du ja (im josm) die “A-Z”-Sortierfunktion und falls dann die Reihenfolge verkehrt ist,
auch noch den “Sortierreihenfolge-Umdrehen”-Button.
im Gegensatz zu dir bin ich nicht der Meinung das es sich dabei um pipfax handelt.
Schließlich war es im Oxomoa Schema nicht vorgesehen das eine Linienvariante ein Tag route=* enthält. Vielmehr sollte eigentlich eine Linienvariante nur aus type=linevariant bestehen und dann noch Einsatzzeit und Zweck haben. Die restlichen Informationen stehen in der übergeordneten Relation type=line. Dort findet man Liniennummer und Verkehrsmittel. Damit wurden aber die Linien nicht abgebildet. Weil nicht dem Weg zugeordnet ist, dass er Mitglied einer Überrelation ist. Auch wenn du in Josm schaust wirst du dieses Verhalten feststellen. Inzwischen ist es aber möglich die Elternrelationen zu laden.
Für den Renderer zählen aber nur Eigenschaften des Weges um diesen Weg darzustellen. Und hier kommen wir zu dem Problem. Zuerst muss die datenbank zu jedem Weg alle Relationen und Überrelationen aufrufen um diese der Reihe nach abzuarbeiten. Dabei habe ich noch keine Idee wie man aus der Reihenfolge alleine die Richtung forward/backward heruasfinden möchte. Du kannst dies ja auch nicht einfach festlegen wenn du dir einfach nur die Wege in der Liste anschaust, oder?
Aus der Reihenfolge auf forward/backward schließen geht in etwa so:
Betrachte den ersten Weg in der Relation und finde seinen ersten und letzten Knoten
Betrachte den zweiten Weg in der Relation und finde ebenfalls ersten und letzten Knoten
Folgende Fälle sind möglich:
letzter Knoten des ersten Weges ist erster des zweiten Weges: beide forward
erster Knoten des ersten Weges ist letzter des zweiten Weges: beide backward
letzter Knoten des ersten Weges ist letzter des zweiten Weges: erster forward, zweiter backward
erster Knoten des ersten Weges ist erster des zweiten Weges: erster backward, zweiter forward
Für jeden weiteren Weg geht es entsprechend, wobei man bei Wegen, die schon als forward erkannt sind nurnoch den letzten Knoten prüfen muss, bei solchen die als backward feststehen nur den ersten. An Lücken kann man wieder bei Punkt eins anfangen.
Ansonsten könnte man sich mal anschauen, wie genau JOSM das Zusammenhängen von Wegen in Relationen auswertet.
Genau das wollte ich gerade jetzt viw anhand obiger Relation step-by-step erklären
Läuft daraus hinaus, das es sich um geordnete Listen handelt. Für ein Compi ist das pipifax
Ok verstehe. Und wie stellst du dir das als SQL abfrage vor? Nur so kurz gefragt.
Alleine der Import eines Europafiles in die Datenbank benötigt mit unter 3 Tage. Dabei werden den Wegen noch keine Attribute hinzugefügt, sondern lediglich Daten in Tabellen geschrieben.
Ja, genau so sehe ich das für alle Normalfälle auch, weil die Rolle ergibt sich eindeutig aus den Subreleationen bzw. den Elementtags. Die Frage ist natürlich was man macht, wenn der Bus die gleiche stop_position 2x in der gleichen Richtung anfährt, weil er laut Fahrplan zwischendurch ein Mal komplett im Kreis fährt umd dann nach der Runde normal weiter zu fahren.
Und nur weil die ÖPNV-Karte es nicht geschafft hat, bzw. aus Kompatibilitätsgründen die Tags der Elemente ignoriert, soll man jetzt weiterhin an jede Halteposition/Plattform ein forward/backward taggen?
Jedenfalls arbeite man gerade an einem offiziellem Oxomoa-Proposal (http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport), da das Schema eben nicht der Allgemeinheit bekannt ist. Die Frage ist auch was man mit der ja an sich überflüssigen stop_area_group macht etc…
dann erscheint der stop bzw. platform zweimal in der relation
stop // noch vor dem “Kreis”
stop // der “Kreis” beginnt
stop // der Haltepunkt im “Kreis” [können auch noch mehr sein]
stop // “der Kreis schliesst sich”
stop // und nun wieder “normal” weiter
die ways müssen natürlich entsprechend geordnet sein, evtl. schafft dies der “A-Z”-Button nicht mehr und die Wege müssen
manuell nachkorrigert werden.
String query5 = "select id "
+ " ,tags->'name' \"name\" "
+ " ,tags->'boundary' boundary"
+ " ,tags->'postal_code_level' postal_code_level"
+ " ,tags->'admin_level' admin_level"
+ " from relations"
+ " where (tags->'postal_code' = ?"
+ " or tags->'postcode' = ? ) "
+ " and tags->'boundary' in ('postal_code','postcode_area') "
+ "order by char_length(tags->'boundary'), name "
;
String SELECT_WAYS = "select id "
+ " from ways,relation_members "
+ " where relation_id = ? "
+ " and member_type = 'W' "
+ " and id=member_id "
+ " and bbox && "+bbox+" "
;
String GET_WAY_NODES = "select nodes[n] node_id "
+ " ,ST_y(geom) \"lat\" "
+ " ,ST_x(geom) \"lon\" "
+ " from (select nodes from ways "
+ " where ways.id = ? ) as foo, "
+ " generate_series(1,999) as g(n) ,nodes "
+ " where nodes[n] != 0 "
+ " and nodes[n] = nodes.id "
;
in etwa so macht man das: relation holen, wege besorgen, wege sortieren, nodes abrufen, ausgeben.
basiert allerding NICHT auf osm2psql.
hier mal mit den grenzem für plz-gebiete. geht aber auch für gemeindegrenzen oder routen.
gruss
walter
<snip>
/**
* direction is FORWARD if the first node of this way is connected to the previous way
* and / or the last node of this way is connected to the next way.
* direction is BACKWARD if it is the other way around.
* direction has a ROUNDABOUT value, if it is tagged as such and it is somehow
* connected to the previous / next member.
* If there is no connection to the previous or next member, then
* direction has the value NONE.
*/
<snap>
Du kannst Dir den entsprechenden Code selbst zur Gemüte führen und entscheiden,
ob dies “Hexenwerk” ist oder nicht.
