You are not logged in.

Announcement

*** NOTICE: forum.openstreetmap.org is being retired. Please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators.
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***

#26 2014-12-17 08:24:03

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

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Im Schienenverkehr (im Busverkehr nur auf Busbahnhöfen mit einer langen Bussteigkante) spielen Haltepositionen eine wichtige Rolle.
Ob meine kurze Regionalbahn in Köln Hbf (Gleis 4/5 486 m) [1], Essen Hbf (Gleis 7, ca. 685 m = ca. 27 Wagen [2]) oder Gößnitz (588 m)) vorn oder hinten am Bahnsteig steht, macht für das Routing beim Umsteigen einen großen Unterschied (1,5 Min./100m bei 4 km/h!). Daher möchte man im Bahnverkehr die Halteposition mit erfassen und in die Route aufnehmen, wenn sie konstant ist bzw. konstant von der selben Routenvariante genutzt wird.

Wenn man die Haltepositionen wirklich nutzen wollte, dann bräuchte man aber noch ein Tag "diese_stop_position_ist_ausnahmsweise_ernst_zu_nehmen" :-)

Und wir haben auch noch solche Sachen wie die "Untersteignummern" in Mainz Hbf, jwd-Steige in Essen Hbf, ungenutzte(?) lange Steigteile, die eigentlich nur einen Ausgang anbinden sollen in Duisburg Hbf oder die zentrale Steiginsel vieler Busbahnhöfe, die eigentlich 6 oder 8 Steige haben müsste, aber als ein Steig gemappt wird. Ich hab da mal was eingebaut, was ohne große Änderungen rein ging.

bis dann
Weide

Offline

#27 2014-12-17 11:16:43

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Hallo Weide, hallo viw,

Weide wrote:
Nakaner wrote:

Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal.

Nein. Es geht in PTv2 gar nicht, weil es mehrere Haltestellen wären. Zwei Halte an verschiedenen Steigen einer Haltestelle kommen bei Bussen sogar ziemlich oft vor. Nur das Päärchen stop mit direkt darauf folgendem platform bildet einen Halt. Egal was man danach dran hängt -- es ist ein neuer Halt.

Kannst du das mal bitte mit einem Zitat aus dem Proposal belegen? Der Proposal-Text trifft dazu keine Aussage. Meiner Meinung nach wäre stop1–platform1–stop2–platform2a–platform2b–platform2c–stop3–platform3–… erlaubt und platform2a, platform2b und platform2c würden zu stop2 gehören.

Solltest du doch recht haben, so kann man immer noch in einem PTv2.1 eine Rolle "+platform" einfügen.

viw wrote:
Nakaner wrote:

(4)In deinem Schema müssen nicht mehr sowohl stop als auch platform in die Routenrelation. Stattdessen kommen nur noch Bahnsteige/Wartebereiche mit der Rolle halt hinein. Wenn eine Station einen mehrteiligen Bahnsteig hat (z.B. ein Teil des Bahnsteigs liegt auf einer Brücke), dann bekommt der zweite/dritte Bahnsteigteil die Rolle +halt. Bahnsteige der Spanischen Lösung bekommen die Rolle halt#. Wenn man die Plattform nicht kennt (z.B. weil Grasbahnsteig im hohen Gras oder von Bäumen verdeckter Bahnsteig), dann fügt man bei PTv2 nur die stop_position ein. Bei dir muss man dann die stop_position einfügen und ihr die Rolle halt_fixme zuweisen.
[...]
Meine Meinung

(4) Mir gefällt das nicht. Derzeit kann der Relationseditor in JOSM (bzw. auch jeder andere Editor könnte es, wenn er es könnte) anhand der Tags des einzufügenden Objekts entscheiden, ob er ihm automatisch die Rolle stop oder platform zuweist. Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal. Mit deinem Schema kann der Editor nicht automatisch eine Rolle vorschlagen. Was die Zerbrechlichkeit angeht, gibt sich das mit PTv2 aber nichts. Wenn ich von einem dreigeteilten Bahnsteig (Damm–Brücke–Damm), den ersten Teil entferne, dann werden mit deinem Schema die beiden übrigen Teile der vorherigen Station zugeordnet. Bei PTv2 muss man hingegen eine stop_position aus der Route entfernen und schon hat man eine Fehlzuordnung. Für mich rechtfertigt das kein neues Schema.

Stattdessen handelst du dir durch den Verzicht auf die stop_positions weitere Probleme ein. Eine stop_position im Straßenway signalisiert dem Pkw-Router, dass da ein Bus anhalten und den Autofahrer zum Halten zwingen könnte (ich kenne noch kein Tag wie bus_passing_place=yes). Im Schienenverkehr (im Busverkehr nur auf Busbahnhöfen mit einer langen Bussteigkante) spielen Haltepositionen eine wichtige Rolle.
Ob meine kurze Regionalbahn in Köln Hbf (Gleis 4/5 486 m) [1], Essen Hbf (Gleis 7, ca. 685 m = ca. 27 Wagen [2]) oder Gößnitz (588 m)) vorn oder hinten am Bahnsteig steht, macht für das Routing beim Umsteigen einen großen Unterschied (1,5 Min./100m bei 4 km/h!). Daher möchte man im Bahnverkehr die Halteposition mit erfassen und in die Route aufnehmen, wenn sie konstant ist bzw. konstant von der selben Routenvariante genutzt wird.

Ich kann deine Auffassung sehr gut verstehen! Aber es ist eben nicht möglich einer Route immer eine eindeutige Halteposition zuzuweisen!
Hier bei der S und Straßenbahn in Berlin verkehren Züge unterschiedlicher Länge auf der gleichen Route. Und allein diese Zuglänge entscheidet wo der Zug halten wird.

Wir sind uns aber einig, dass unterschiedliche Zuglängen zu unterschiedlichen Tageszeiten keine Duplikation von Routen rechtfertigen, oder? Die Haltepositionen von Schnellbahnen orientieren sich oft an den Bahnsteigzugängen. Wenn der Bahnsteigzugang hinten ist, wird mit Haltetafeln (bei EBO-Bahnen das Signal Ne5 [1]) gekennzeichnet, wo die Züge welcher Länge halten sollen. Nur Züge voller Länge (in Berlin 4/4-Züge) halten auf der ganzen Länge.

Da ist Intelligenz vom Auswerter und Fahrgast (Nutzer) gefragt, sodass er erkennt: "Ah! Langer Zug, da muss ich für's schnelle Umsteigen am nächsten Bahnhof hinten einsteigen."

Weide wrote:

Und wir haben auch noch solche Sachen wie die "Untersteignummern" in Mainz Hbf, jwd-Steige in Essen Hbf, ungenutzte(?) lange Steigteile, die eigentlich nur einen Ausgang anbinden sollen in Duisburg Hbf oder die zentrale Steiginsel vieler Busbahnhöfe, die eigentlich 6 oder 8 Steige haben müsste, aber als ein Steig gemappt wird. Ich hab da mal was eingebaut, was ohne große Änderungen rein ging.

Hast du dir mal das Mapping der Bahnsteige in Euskirchen angeschaut? Diese Konzept wäre mein Vorschlag. Bahnsteige mit Unternummern (eigentlich auch Bahnsteige mit mehr als einer Kante, d.h. die meisten Inselbahnsteige [2]) sind Multipolygone. Alle Tags außer die Gleisnummer hängen am Multipolygon. Das Multipolygon hat mehrere outer-Ways (Rolle outer) – die Bahnsteigkanten und die "kurzen Seiten", an denen keine Züge halten. Die Bahnsteigkanten-Ways erhalten ref=<Gleisnummer>. Bahnsteigabschnitte (A, B, C,), wie es sie in Deutschland, der Schweiz und anderen Ländern gibt, können als Node auf die Kante gemappt werden, wenn nur die Position des Schilds [3], aber nicht dessen Gültigkeit genau bekannt ist. Diese Konzept ist auf dem Mappingwochenende in Köln im Juli entstanden.

Viele Grüße

Michael



[1] https://github.com/Nakaner/railway-sign … _DS301.svg und https://github.com/Nakaner/railway-sign … _DV301.svg
[2] Manche Inselbahnsteige haben nur eine Kante, z.B. Möckmühl Gleis 2 und 3.
[3] Die Schilder werden häufig dort montiert, wo es gerade geschickt ist, z.B. an Trägern der Bahnsteigüberdachung. Daher ist ihre Lage nicht die genaue Mitte des Abschnitts.


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#28 2014-12-17 12:07:23

TobWen
Member
From: Ruhrgebiet
Registered: 2009-03-31
Posts: 1,112

Re: Diskussion über Public Transport Version 2.1

viw wrote:

Hier bei der S und Straßenbahn in Berlin verkehren Züge unterschiedlicher Länge auf der gleichen Route. Und allein diese Zuglänge entscheidet wo der Zug halten wird.

Wie willst du das bei Bahnsteigen ohne H-Tafel machen? In Dortmund-Hörde hält die Eurobahn, wo sie will. Mal zu weit vorne, mal zu weit hinten und bei Doppeltraktion gaaanz weit hinten.


Was macht der RVR mit OpenStreetMap? https://forum.openstreetmap.org/viewtopic.php?id=63052
Aktuelle Luftbilder des RVRs (Ruhrgebiet) http://forum.openstreetmap.org/viewtopic.php?id=28511

Offline

#29 2014-12-17 15:03:03

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

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Hallo Weide, hallo viw,
Wir sind uns aber einig, dass unterschiedliche Zuglängen zu unterschiedlichen Tageszeiten keine Duplikation von Routen rechtfertigen, oder? Die Haltepositionen von Schnellbahnen orientieren sich oft an den Bahnsteigzugängen. Wenn der Bahnsteigzugang hinten ist, wird mit Haltetafeln (bei EBO-Bahnen das Signal Ne5 [1]) gekennzeichnet, wo die Züge welcher Länge halten sollen. Nur Züge voller Länge (in Berlin 4/4-Züge) halten auf der ganzen Länge.

Da ist Intelligenz vom Auswerter und Fahrgast (Nutzer) gefragt, sodass er erkennt: "Ah! Langer Zug, da muss ich für's schnelle Umsteigen am nächsten Bahnhof hinten einsteigen."

Ähm genau das habe ich jetzt aus deinem Vorschlag nicht so richtig entnehmen können. Welchen Vorteil hat die Stopposition, wenn Sie doch nicht genau bestimmt werden kann? Du hast recht das es für die Umsteigewege von Vorteil ist hinten oder vorne einsteigen zu können, aber wo ist denn jetzt bei einen 2/4 Zug vorne und noch schlimmer wo ist denn hinten?

Offline

#30 2014-12-17 16:50:18

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

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Kannst du das mal bitte mit einem Zitat aus dem Proposal belegen?

Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform.

bis dann
Weide

Offline

#31 2014-12-17 17:29:46

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Weide wrote:

Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform.

Ok, danke. Du hast deine Aussage belegt.


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#32 2014-12-17 17:55:19

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

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Hast du dir mal das Mapping der Bahnsteige in Euskirchen angeschaut?

Äh, ja, gefällt mir nicht. Wenn die Routen auf die outer-Stücke zeigen, dann zeigen sie nicht auf platforms und das sollte Fehlermeldungen triggern. Man sollte auch den Namen eintragen können und wenn der mal dargestellt wird, dann sollte er auch im Stil von Platforms dargestellt werden. Taggt man sowohl die Stücke als auch das MP als platform, dann sind zuviele Platforms in dem Bahnhof. Da würde ich schon eher die Bahnsteigfläche als highway=pedestrian machen (wo möglich ohne MP) und an den passenden Stücken über dieselben Nodes oder etwas nach innen versetzt die Platforms als Linien. Das wäre auch auf die Bahnsteiginseln der Busse anwendbar, die gewöhnlich keine MPs sind.

bis dann
Weide

PS: area=yes an den MPs ist falsch (steht so im PTv2, aber PTv2 zählt da nicht)
PPS: Es sollten zwei stop_areas sein, da die Namen verschieden sind.

Offline

#33 2014-12-17 18:24:55

Jojo4u
Member
Registered: 2014-08-03
Posts: 1,090

Re: Diskussion über Public Transport Version 2.1

Es wird sich aber allermeist eine Stelle am Bahnsteig finden lassen wo sich garantiert ein Zug befindet, oder? So Regel: "der Mittelpunkt der kürzesten Zugvariante"?

Offline

#34 2014-12-17 18:33:17

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Hallo Weide,

Weide wrote:
Nakaner wrote:

Hast du dir mal das Mapping der Bahnsteige in Euskirchen angeschaut?

Äh, ja, gefällt mir nicht. Wenn die Routen auf die outer-Stücke zeigen, dann zeigen sie nicht auf platforms und das sollte Fehlermeldungen triggern.

Ja, klar. In so einem Fall sollten die platform-Member-Einträge in den Routenrelationen auf das Multipolygon zeigen. In Euskirchen ist kein Bahnsteig Teil einer Routenrelation. (habe gerade eben extra nachgeschaut)

Weide wrote:

Man sollte auch den Namen eintragen können und wenn der mal dargestellt wird, dann sollte er auch im Stil von Platforms dargestellt werden.

Du meinst also, dass man den Bahnhofsnamen an das Bahnsteig-Multipolygon taggen können sollte? Das ist doch möglich. Das wird dir im JOSM-Routeneditor dann als "Multipolygon (Euskirchen)" angezeigt.

Das Taggen von Gleisnummern an die Bahnsteigkante ist auch kein Problem für Renderer, die die Gleisnummer mitten in der Bahnsteigfläche rendern wollen. Die müssen einfach nur schauen, welche Gleisnummern auf die Mitglieder des Multipolygons getaggt sind (ref=* [1]) und diese sortieren und zu einem Label-String verketten.

Weide wrote:

Taggt man sowohl die Stücke als auch das MP als platform, dann sind zuviele Platforms in dem Bahnhof.

Ja, genauso wie ich bei einem Wald-Multipolygon mit zwei Outer-Mitgliedern (jeweils nicht geschlossene Ways, die zusammen einen Ring ergeben) nicht die beiden Ways zusätzlich zum Multipolygon mit landuse=forest tagge.

Weide wrote:

Da würde ich schon eher die Bahnsteigfläche als highway=pedestrian machen (wo möglich ohne MP) und an den passenden Stücken über dieselben Nodes oder etwas nach innen versetzt die Platforms als Linien. Das wäre auch auf die Bahnsteiginseln der Busse anwendbar, die gewöhnlich keine MPs sind..

Ich bin keine Freund von highway=pedestrian auf Eisenbahnsteigen. Bei der DB sind wir es gewohnt, dass man Bahnsteige einfach so betreten kann. In anderen Ländern gibt es jedoch Bahnsteigsperren (AFAIK gibt es im Hamburger Verkehrsverbund sogar noch "Bahnsteigkarten"). highway=pedestrian sollte von einem Mappingschema nur vorsichtig empfohlen werden, da es von Routern gegenüber railway/public_transport=platform bevorzugt wird.

Das Taggen der Gleisnummer an die Bahnsteigkante erleichtert das Blindenrouting in Bahnhöfen. In den Fahrplandaten ist vermerkt, auf welchem Gleis der Zug hält. Bei einem Inselbahnsteig gibt es jedoch meistens zwei Bahnsteigkanten. In welche Richtung soll nun der Blinde gehen, wenn der den Treppenaufgang hochkommt? Mit Gleisnummern auf der Bahnsteigkante kann das Smartphone sagen: "Benutzen Sie den Aufzug zur Gleisebene hoch und halten Sie sich dann nach links." Außerdem erleichtert es die Kartenanzeige eines Indoor-Routingergebnisses für sehende Nutzer.

Weide wrote:

PS: area=yes an den MPs ist falsch (steht so im PTv2, aber PTv2 zählt da nicht)

area=yes ist entweder Mapping for the Renderer oder Mapping for Osm2pgsql. Ich habe beobachtet, dass Multipolygonbahnsteige ohne area=yes als Linie statt als Fläche gerendert werden. Du hast aber trotzdem recht.

Viele Grüße

Michael

[1] local_ref=* wäre vielleicht besser, da ref=* durch eine netzweit einheitliche Bahnsteigkanten-ID belegt sein könnte.


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#35 2014-12-17 19:45:51

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

Re: Diskussion über Public Transport Version 2.1

Schade das Segmente nicht in dieser Version aufgenommen werden. Muss ich noch mal etwa 10 Jahre warten um das reifen zu lassen, oder doch einmal selber ein Vorschlag machen.

Ich habe Begriff dafür das Relationen in Relationen einige zusätzliche Komplexität bringen, andererseits würde es die Wartung ungeheuer viel vereinfachen. Ich habe versucht eine MapCSS zu erstellen die mit Segmente arbeiten kann, aber ich kann keine tags von Grosseltern betrachten.


Nah gut. Ich bin damit beschäftigt ein Skript zu bauen das v2 Routerelationen erfassen kann:

https://github.com/PolyglotOpenstreetma … 06ab4d581f

Es benutzt der scripting-plugin und Jython. Es läuft im JOSM.

Ich weiss nicht ob ihr in Deutschland angriff habt auf der Daten des Operators?

Das Skript fängt an mit eine geordnete Reihenfolge von Haltestellen. Es geht davon aus das alle Haltestellen auf Nodes gemappt sind. Ist das noch so in ihren Vorschlag?

* Es versucht zuerst eine Relation zu finden die eine gleiche Reihenfolge von HS hat. Wenn es die findet, benutzt es die Ways von der mit der längste Reihenfolge.

Das skript geht auch davon aus das alle Ways zusammen stehen, und alle HS auch. Das ist wie JOSM solche Routerelationen automatisch sortiert, deswegen schien mir das eine gute Konvention. Irgendwie wäre es natürlich einfacher HS mit ways zu verknupfen wenn die HS dazwischen stehen. Dan kann man aber nicht mehr visuell nachschauen ob die Ways eine ununterbrochen Sequenz sind.

*Wenn keine vergleichbare Route gefunden werd, dann versucht es mit dem letzten Way die nächste HS zu bereichen anhand irgendeine andere v2 Route. Die Büsse haben jedenfalls tendenz alle dieselbe "Korridors" zu benutzen.

*Wenn das nichts aufbringt, noch mal neu von alle Seitstrassen.

*Als letzte Lösung wird versucht einen gültigen Way zu finden neben die HS. Entweder mit Hilfe von Stop_area Relation, oder der näheste stop_position. So war ich etwa 2 Jahre her angefangen und es hilf, nur ist es sehr langweilig alle Variante so hinzuzufügen.

Das andere Problem ist natürlich die Wartung. Diese Variationen von Routen änderen sich ziemlich oft und die Relationen werden von andere benutzer ständig kaputtgemacht. Auch dafur (ver)suche ich eine halbautomatisierte oder so weit wie möglich automatisierte Lösung (zu entwickeln).

Könnt ihr mich befestigen ob meinen Ahnnahmen stimmen?
*HS nur auf Nodes
*Alle Wege zusammen im Route. Wenn der bus zwei mal über demselben Weg fährt, kommt er 2x vor im Relation
*Dann eine sortierte Reihenfolge des HSs? Wenn der bus zwei mal an dieselbe HS vorbeifährt, kommt sie 2x vor im Relation

Polyglot

Offline

#36 2014-12-17 22:28:57

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

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Ja, klar. In so einem Fall sollten die platform-Member-Einträge in den Routenrelationen auf das Multipolygon zeigen. In Euskirchen ist kein Bahnsteig Teil einer Routenrelation. (habe gerade eben extra nachgeschaut)

Dann hab ich das total missverstanden. Ich dachte, die Routen sollen auf die Teile zeigen.

Die müssen einfach nur schauen, welche Gleisnummern auf die Mitglieder des Multipolygons getaggt sind

Da bin ich Fundamentalist. MPs sollten nichts mit dem Inhalt ihrer Member zu tun haben. Nur die Geometrie der Linien zählt. Irgendwann beim nächsten API müssen wir die MPs automatisch durch Flächenobjekte ersetzen und das beisst sich damit.

Offline

#37 2014-12-17 22:34:23

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

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Schade das Segmente nicht in dieser Version aufgenommen werden. Muss ich noch mal etwa 10 Jahre warten um das reifen zu lassen, oder doch einmal selber ein Vorschlag machen.

Technisch ist es sehr einfach: Man definiert einen Segmentrelationstyp ohne eigene Eigenschaften und eine "include_halts"- und eine "include_tour"-Rolle innerhalb der p3=variant - Relationen.

Offline

#38 2014-12-19 09:54:11

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

Re: Diskussion über Public Transport Version 2.1

Jojo4u wrote:

Es wird sich aber allermeist eine Stelle am Bahnsteig finden lassen wo sich garantiert ein Zug befindet, oder? So Regel: "der Mittelpunkt der kürzesten Zugvariante"?

Ähm ja es gibt eine Stelle Am Bahnsteig wo garantiert ein Wagen eines S-Bahnzuges halten wird. Aber das ist eben nicht die zwangsläufig die Mitte. Und bei Straßenbahnen ist es ohnehin sehr fraglich. Dort gibt es das Phänomen der Doppelhaltestellen.

Offline

#39 2014-12-19 20:21:05

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

Re: Diskussion über Public Transport Version 2.1

Weide wrote:
Polyglot wrote:

Schade das Segmente nicht in dieser Version aufgenommen werden. Muss ich noch mal etwa 10 Jahre warten um das reifen zu lassen, oder doch einmal selber ein Vorschlag machen.

Technisch ist es sehr einfach: Man definiert einen Segmentrelationstyp ohne eigene Eigenschaften und eine "include_halts"- und eine "include_tour"-Rolle innerhalb der p3=variant - Relationen.

Ich weiss, nur wenn die Möglichkeit nicht im Vorschlag aufgenommen wird, wird überhaupt keiner Datennutzer das auch benutzen/auf der Karte darstellen. Mit dem Skript das ich jetzt entwickle wird die Wartung schon etwas niedriger. Nicht mit Routesegmente arbeiten hat das Vorteil dass man sofort visuell beobachten kann, ob die Linie nicht unterbrochen würde. Das kann ich aber viel schneller automatisiert entscheiden.

*Segmente könnten aber (langweiliger) Mapperarbeit sparen
*Es wäre auch möglich um Spiderdiagramme ab zu bilden, wenn auf die Segmente einige zusätzliche tags gesetzt werden wie route_ref und colour. Sogar in JOSM mit MapCSS. Das ist etwas das wir bis jetzt noch nicht machen konnten.


Ist es bitte möglich erst die ways und danach die HS in Routerelationen auf zu nehmen? Das ist wie JOSM die sortieren würde. (Oder die JOSM-entwickler davon überzeugen es umgekehrt zu tun.) Ich mag es aber das ich sofort aur die Ways arbeiten kann. Die HS werden hier automatisiert hinzugefügt.

Offline

#40 2014-12-20 10:39:19

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

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Ist es bitte möglich erst die ways und danach die HS in Routerelationen auf zu nehmen? Das ist wie JOSM die sortieren würde.

Es ist doch gut wenn man sehen kann, dass jemand die Relation kaputt gemacht hat. Die JOSM-Sortierung auf die Haltestellen anzuwenden ist immer Quatsch. Bei den Wegen funktioniert es nur bei einfachen Routen. Und ich kenne viele Routen bei denen es richtig viel Arbeit ist, sie nach einer automatischen Sortierung wieder zu berichtigen.

Oder die JOSM-entwickler davon überzeugen es umgekehrt zu tun.

Ich würde die JOSM-Leute eher fragen, ob man die Sortierung nicht abschalten kann, wenn Haltestellen mit sortiert würden und ob sie nicht die Sortierung total verweigern könnten, wenn es keine eindeutige Lösung gibt.

Weide

Last edited by Weide (2014-12-20 10:40:26)

Offline

#41 2014-12-20 13:01:45

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

Re: Diskussion über Public Transport Version 2.1

Ich benutze die Sortierung innerhalb Relation Editor nicht mehr für eine ganze Route. Für Teile ist sie aber wohl praktisch. Also Klik, Shift-Klik etwas weiter, dann sortieren. Die HS werden normalerweise nicht berurt. Die Reihenfolge sollte gleich bleiben. Üblicherweise selektiere ich aber nur Ways.

Mein Skript fügt Sequenznummer ein für Ways die es hinzufügt. Das macht es auch etwas einfacher.

Vielleicht möchtest du es mal ausprobieren. Hast du irgendwo eine Route von welche alle HS auf Nodes gemappt sind?

https://github.com/PolyglotOpenstreetma … omStops.jy

Wenn du Lust hast, will ich es auch mal demonstrieren in eine Google Hangout. Es fängt an recht praktisch zu funktionieren... Findet Ways in andere Routen wenn die schon auf Version 2 stehen und ihre Wege nicht unterbrochen sind. Wenn keine andere Routen vorhanden sind, fügt es nur die anliegende Ways zu. Wenigstens hat man dann schon diese Ways in richtige Reihenfolge und versehen von Sequenznummer. Wenn man damit anfängt, muss man dan diese Ways noch verbinden, aber einmal eine Gegend gute Referenzrouten hat, kann das Skript stehts mehr selber zusammenstellen.



Jo

Last edited by Polyglot (2014-12-20 13:55:31)

Offline

#42 2014-12-20 19:51:07

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

Re: Diskussion über Public Transport Version 2.1

Mal deine letzte changeset angeguckt:

https://www.openstreetmap.org/changeset … 864/6.3710

Jetzt verstehe ich wieso es kein Reaktion kommt auf meinem Skript. Ihr mappt PT grundsätzlich anders als wir/ich. Ich habe es in Belgien alles konsistent auf ein System umgewandelt. (In Brüssel bin ich noch nicht ganz fertig) Ein System das aber wohl funkzioniert. Wenn ich mir das so ansehe, seit ihr noch halbwegs zwischen PT v2 und PT v1. Ich habe natürlich nur ein Beispiel gesehen. Hast du vielleicht irgendwo bessere Beispiele? Damit meine ich, die HS neben der Weg gemappt, am liebsten auf Nodes.

Hier in Belgien sind wir so angefangen, weil jede HS ein Referenznummer hat, das auf die Schilder angedeutet steht (wenigstens in Flandern). Deswegen hat es für uns nie Sinn gemacht HS als Node auf dem Weg zu mappen. Und deswegen sind alle Details auch auf diesen Nodes neben dem Weg.

Vielleicht müsste ich mal in England gucken gehen. Sehen wie die es machen.

Grüsse,

Jo

Offline

#43 2014-12-20 22:16:35

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

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Wenn ich mir das so ansehe, seit ihr noch halbwegs zwischen PT v2 und PT v1.

:-) So schlecht liegen wir garnicht im Rennen. Mein Programm liefert jetzt für den Regierungsbezirk Düsseldorf in Nordrhein-Westfalen noch 6408 Fehlermeldungen und für Belgien 16231 :-) Aber Belgien ist ja auch deutlich größer. :-)

bis dann
Weide

Edit: falsche Zahl korrigiert

Last edited by Weide (2014-12-21 07:12:01)

Offline

#44 2014-12-20 22:48:00

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

Re: Diskussion über Public Transport Version 2.1

Kann ich die Fehlermeldungen irgendwo mal sehen? Oder das Programm?

Ich komm mal in Düsseldorf schauen, wenn ich fertig bin mit dem korrigieren von Linien 1-9 in Brugge.

Jo

Offline

#45 2014-12-20 23:09:22

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

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Kann ich die Fehlermeldungen irgendwo mal sehen? Oder das Programm?

Wenn Du mir eine Nachricht schickst, dann kann ich per E-Mail-Antwort mit Attachment die Liste schicken. Das Programm kannst Du auch haben; ich habe aber nur Executables für Linux (x86-64). Für die Quellen bräuchte man einen Ada-Compiler.

bis dann
Wilhelm

Offline

#46 2014-12-21 16:51:42

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

Re: Diskussion über Public Transport Version 2.1

Ich habe mal dokumentiert wie wir das hier in Belgien mappen, basiert auf dem Artikel im Wochenaufgabe:

http://osm.be/nl/content/mapping-public … t-belgium#

Offline

#47 2014-12-21 18:16:44

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Hallo Polyglot,

Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen, basiert auf dem Artikel im Wochenaufgabe:

http://osm.be/nl/content/mapping-public … t-belgium#

Was das Tagging der Routen betrifft, finde ich bloß zwei Unterschiede. Ihr habt die Haltestellen am Ende der Relation eingereiht, wir am Anfang. Bei euch gibt es keine stop_positions (mit der Rolle stop) in der Route, bei uns schon.

Sehe ich es richtig, dass ihr keine stop_positions mappt?

Kennst du schon das Tag fee_zone=*? Im Gebiet des Verkehrs- und Tarifverbunds Stuttgart (VVS) wird mit diesem Tag (an Bahnhof-Nodes, Haltepositionen, Bushaltestellen, stop_area-Relationen) die Tarifzone(n)/Tarifwabe(n), in denen die Station liegt angegeben. Es scheint das Stuttgarter Äquivalent zu zone:De_Lijn=85 zu sein, oder?

Im Karlsruher Verkehrsverbund (KVV) wird das Verbundsgebiet als (Multi-)Polygon erfasst:
abbreviation=KVV
boundary=public_transport
name=Karlsruher Verkehrsverbund
type=boundary
wikidata=Q1733986
https://www.openstreetmap.org/relation/3157173/history

Viele Grüße

Michael


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#48 2014-12-21 19:00:30

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

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen...

Das ist kein PTv2. Es wäre gut, wenn ihr es irgendwie markieren könntet.

Weide

Offline

#49 2014-12-21 21:09:18

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

Re: Diskussion über Public Transport Version 2.1

Weide wrote:
Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen...

Das ist kein PTv2. Es wäre gut, wenn ihr es irgendwie markieren könntet.

Weide

Ich möchte gerne wissen was nicht v2 dran ist. Eine Routerelation pro Variante, check, Platforme sind gemapt mit public_transport=platform/bus=yes. check. Der Validator von JOSM ist froh damit. Und ich kann die alle verwalten mit ein Pythonprogramm, weil es ausreichend konsistent ist für automatische Verwaltung.

Jo

Last edited by Polyglot (2014-12-21 22:32:47)

Offline

#50 2014-12-21 21:23:31

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

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Hallo Polyglot,

Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen, basiert auf dem Artikel im Wochenaufgabe:

http://osm.be/nl/content/mapping-public … t-belgium#

Was das Tagging der Routen betrifft, finde ich bloß zwei Unterschiede. Ihr habt die Haltestellen am Ende der Relation eingereiht, wir am Anfang. Bei euch gibt es keine stop_positions (mit der Rolle stop) in der Route, bei uns schon.

Sehe ich es richtig, dass ihr keine stop_positions mappt?

Kennst du schon das Tag fee_zone=*? Im Gebiet des Verkehrs- und Tarifverbunds Stuttgart (VVS) wird mit diesem Tag (an Bahnhof-Nodes, Haltepositionen, Bushaltestellen, stop_area-Relationen) die Tarifzone(n)/Tarifwabe(n), in denen die Station liegt angegeben. Es scheint das Stuttgarter Äquivalent zu zone:De_Lijn=85 zu sein, oder?

Im Karlsruher Verkehrsverbund (KVV) wird das Verbundsgebiet als (Multi-)Polygon erfasst:
abbreviation=KVV
boundary=public_transport
name=Karlsruher Verkehrsverbund
type=boundary
wikidata=Q1733986
https://www.openstreetmap.org/relation/3157173/history

Viele Grüße

Michael

Es werden sicher auch stop_position gemappt. Das wichtigste sind aber die highway=bus_stop/public_transport=platform/bus=yes. Die sind jetzt alle da.

Wenn public_transport=stop_area gemacht werden, werden auch die stop_position erfasst. Wenn etwas anderes am highway gemappt werden muss, werden die auch gemappt. In die Routerelationen sind die aber nicht notwendig. Sie machen es nur schwieriger und als die jedenfalls nicht alle da sind...

Als es eine stop_area pro highway=bus_stop/public_transport=platform/bus=yes gibt, ist es einfach zu ermitteln welche stop_position(en) dazu gehört/en.

Grüsse,

Jo

Offline

Board footer

Powered by FluxBB