Das "leidige" Thema Public_transport...

Keichi · 2012-09-20 17:54:26

Hallo,

ich beschäftige mich gerade im Kreis Recklinghausen mit den ÖPNV Verbindungen und den dazugehörigen Routen Relationen für die Busse, dabei muss ich natürlich auch einige Haltestellen bzw. Busbahnhöfe an das neue public_transport Schema anpassen.

Ich sehe auch zum Teil immer wieder einige Leute die es bereits versucht haben, nur stelle ich dann oft fest das es für den selben Bahnhof 3+ public_transport=stop_area Relationen gibt und dann nochmal eine public_transport=stop_area_group Relationen, alle mit genau den selben Namen und ohne irgend einen Hinweis darauf das es sich dabei auf ein bestimmtes Verkehrsmittel bezieht.

Nur frage ich mich wirklich schon die ganze Zeit, MUSS man wirklich für ein Haltestelle die den selben Namen hat, tausend Relationen anlegen, nur weil die eine für die Busse ist, die andere für die Trams und nochmal eine für die Züge?

Generell ist es doch eh so das zu 99% alle Bussteige, Bahnsteige whatever genau im selben Gebiet sind. Wieso schmeißt man dann nicht einfach alle platformen, stop_positions und die Amenties in eine einzige Relation rein? Das sieht nicht nur ordentlicher aus es ist auch deutlich Praktischer.

Gut für den Enduser ist es im Grunde ja egal wieviele Relationen es gibt, aber als Mapper der die Relationen alle sieht kriege ich da echt nen Kotzreiz. Vorallem wenn man die ganzen public_transport Relationen dann hinterher noch in die Network Relationen für die einzelnen Verkehrsverbünde einpflegen will, wo es schon zig tausend einträge drin sind.

Sowas muss doch wirklich nicht sein und ist doch bestimmt auch nicht so gewollt oder irre ich mich da?

Hobby Navigator · 2012-09-20 20:19:22

Hallo Keichi, zu deinen Fragen kann ich zwar nicht wirklich viel beitragen, ist nicht so mein Thema.
Was ich allerdings machen kann ist dich herzlich im Forum willkommen zu heißen. Das geht ja gar nicht das dies noch niemand gemacht hat.

Zu deinen Fragen wird es sicher noch Meinungen geben, hier findet(/n) sich für (fast) jeden Bereich ein oder auch mehrere Spezialist(en).
Georg

HostedDinner · 2012-09-20 20:27:38

stop_area_group? Noch nie gehört... Im Proposal http://wiki.openstreetmap.org/wiki/Prop … _Transport gibt es nur stop_area und ich pack da alles rein, warum auch nicht? Man muss nur aufpassen, wegen operator, denn evt. haben die verschiedenen Stops verschiedene Operator...
Und auch hier http://wiki.openstreetmap.org/wiki/Tag: … Dstop_area steht, dass alles in eine Relation reinkommt...

Lg HostedDinner

Fabi2 · 2012-09-20 21:01:33

Keichi wrote:

Nur frage ich mich wirklich schon die ganze Zeit, MUSS man wirklich für ein Haltestelle die den selben Namen hat, tausend Relationen anlegen, nur weil die eine für die Busse ist, die andere für die Trams und nochmal eine für die Züge?

Nein, muß man nicht, zumindest dachte ich das bis jetzt, denn wenn man das alte Oxomoa-Schema (https://wiki.openstreetmap.org/wiki/Use … PNV-Schema) kennt und benutzt hat, auf dem ja putlic_transport-Schema basiert und es quasi nur ein offizielles Wiedergekäue des Schemas per Proposal-Prozess war, um es auch außerhalb Europas formal abnicken zu lassen. Es sind ein paar kleinere Änderungen eingeflossen und außer diesen habe ich mir leider den Rest des neuen Proposals auch nicht angesehen, hätte ich aber lieber mal machen sollen.

Da haben offenbar Leute das offizelle Proposal geschrieben, die das Schema nicht ganz bis ins Letzte verstanden haben. Wie man auch unter https://wiki.openstreetmap.org/wiki/Fil … modell.png sehen kann, gibt es keinerlei Einschränkungen für die Art und Anzahl der Platformen und Haltepunkte in der stop_area-Relation. Da frag ich mich echt, wie man dann im offiziellen Proposal ( https://wiki.openstreetmap.org/wiki/Pro … _Transport ) auf die Idee gekommen ist, das die Zuordnung einer stop_area-Realtion nur für eine Transportmittelart gelten soll?

Das Oxomoa-Schema hat ja mindestens einen fehler und ist auch an manchen stellen leider uneindeutig, so daß ich auch erst mal überlegen mußte, was denn z.B. jetzt die Unterscheidung von stop_area zu stop_area_group ausmachte, weil bei gleichem Namen ist das sinnvollerweise 1 stop_area-Relation (das steht nicht drin, das durfte man sich damals überlegen). Dann beinhaltet das alte und neue Schema noch einen Fehler, welcher aber nicht sofort offensichtlich ist und somit bei der Konstruktion übersehen wurde. Ich habe auch erst vor eine Weile festgestellt, das da konsequentenweise eine Relation fehlt, die die Haltepunkte an einer Platform, der betreffenden Platform selbst zuordnet. Also eine Bahnsteigrelation der Art: die Haltepunkte 1, 2 und 3 auf Gleis 4 liegen an Bahnsteig B.

Für dieses Problem wurde dann ersatzweise der Workaround gefunden, das man die Platformen und stop_positions mit den Verkehrsmitteln taggen soll, was aber unötige Redundanz ist, denn wenn man den Haltepunkt mit dem Verkehrmittel getaggt hat, dann braucht man das Verkehrsmittel nicht noch mal an den Bahnsteig zu taggen, weil schließlich ist ja, zumindest in der Realität, klar, wo die Platform für die jeweiligen Haltepunkte ist, nur das wurde eben leider nicht für den Rechner abgebildet.

Keichi wrote:

Generell ist es doch eh so das zu 99% alle Bussteige, Bahnsteige whatever genau im selben Gebiet sind. Wieso schmeißt man dann nicht einfach alle platformen, stop_positions und die Amenties in eine einzige Relation rein? Das sieht nicht nur ordentlicher aus es ist auch deutlich Praktischer.

Mach es so, es wurde bei den alten vor dem offizeillem Beschluß ja auch so gemacht! Ja, und der Kotzreiz kommt da nicht nur dir...

Weide · 2012-09-20 21:17:07

Hi,

also gewöhnlich kommt man mit einer dieser stop_area-Relationen aus, oft sogar ganz ohne.

Die stop_area_group stammt aus einem älteren Vorschlag und gehört nicht zum PT-Schema.

Man "muss" übrigens nicht umstellen.

Manches kann man auch garnicht umstellen. Ein Punkt mit highway=bus_stop neben der Fahrbahn bedeutet, dass man dort auf den Bus warten kann. Es sagt nichts darüber, ob da ein markierter Wartebereich ist oder Häuschen stehen. Ein Punkt mit public_transport=platform besagt dagegen, das dort nichts bis auf ein Haltestellenschild ist. Ohne Ortskenntnis kann man sowas nicht umstellen.

Falls man die Routen des PT-Schemas praktisch findet, dann kann man sie übrigens auch anwenden, ohne irgendwelche Haltestellen zu ändern. Das führt nicht zu Problemen!

frohes Mappen
Weide

Weide · 2012-09-20 21:21:27

Hi,

Fabi2 wrote:

Da frag ich mich echt, wie man dann im offiziellen Proposal ( https://wiki.openstreetmap.org/wiki/Pro … _Transport ) auf die Idee gekommen ist, das die Zuordnung einer stop_area-Realtion nur für eine Transportmittelart gelten soll?

Wo steht das denn?

Weide

Fabi2 · 2012-09-20 21:27:48

HostedDinner wrote:

stop_area_group? Noch nie gehört... Im Proposal http://wiki.openstreetmap.org/wiki/Prop … _Transport gibt es nur stop_area und ich pack da alles rein, warum auch nicht? Man muss nur aufpassen, wegen operator, denn evt. haben die verschiedenen Stops verschiedene Operator...

Die wesentlichen Änderungen des offiziellen Proposals (wenn man die vermurksten Sachen jetzt mal herausläßt) sind:
1. type=linie wurde zu type=route_master
2. Die stop_area_group wurde mangels genauer Definierbarkeit auf meine Initative hin in die Tonne getreten.
3. public_transport=station sollte besser landuse=station bzw. building=station sein --> überflüssige Schemaverkomplizierung.

geokyf · 2012-09-20 21:29:53

In manchen Fällen kann es sich auch ganz sparen. Hier hat man es mittlerweile so weit gebracht, dass außerhalb des Schülerverkehrs die meisten Verbindungen nur noch Rufbusse sind, bei denen man 2 Stunden vorher anrufen muss. Da reicht der gute alte bus_stop mit Telefonnummer dran, Fahrpläne und Routen sind sowieso nur noch kann und ohne Anruf hinfällig.

HostedDinner · 2012-09-20 21:32:29

Fabi2 wrote:

Da frag ich mich echt, wie man dann im offiziellen Proposal ( https://wiki.openstreetmap.org/wiki/Pro … _Transport ) auf die Idee gekommen ist, das die Zuordnung einer stop_area-Realtion nur für eine Transportmittelart gelten soll?

Ich glaub, das es einfach nur ungünstig formuliert ist Auf der Seite https://wiki.openstreetmap.org/wiki/Tag … Dstop_area (zumindest in der Englischen Version) steht, dass es für mehrere Verkehrsmittel ist...

wambacher · 2012-09-20 21:35:22

geokyf wrote:

Da reicht der gute alte bus_stop mit Telefonnummer dran, Fahrpläne und Routen sind sowieso nur noch kann und ohne Anruf hinfällig.

Rufbusse gibt es bei uns auch immer mehr - macht aber kein Problem, wenn man ein wenig planen kann.
Allerdings: Die Rufbusse fahren immer noch feste Routen zu festen Zeiten - also nach Fahrplan. Nur nicht immer, sondern nur nach Bedarf. Daher ist eine "normale" Erfassung durchaus sinnvoll.

Gruss
walter

HostedDinner · 2012-09-20 21:42:13

Mir fällt gerade auf: Warum ist eigentlich der Part über Haltestellen (und deren Realtionen) nicht auf der Seite https://wiki.openstreetmap.org/wiki/Public_Transport sondern nur im Proposal? Ich denke viele werden nicht auch noch das Proposal lesen, wenn sie die "Einstiegsseite" vom Public Transport gelesen haben...
Man sollte evtl. einen Abschnitt dazu schreiben, um die einzelenen Hinweise bei den Verkehrsmitteln zusammenzufassen.

Lg HostedDinner

Weide · 2012-09-20 21:44:16

Hi,

wambacher wrote:

Allerdings: Die Rufbusse fahren immer noch feste Routen zu festen Zeiten - also nach Fahrplan. Nur nicht immer, sondern nur nach Bedarf. Daher ist eine "normale" Erfassung durchaus sinnvoll.

Sowas gibt es aber auch anders. Z.B. am Tag vorher anrufen, dann erfährt man die Uhrzeit, wird am nächsten Tag zuhause abgeholt und in die nächste Stadt gefahren.

Weide

Fabi2 · 2012-09-20 21:48:02

Weide wrote:

Fabi2 wrote:
Da frag ich mich echt, wie man dann im offiziellen Proposal ( https://wiki.openstreetmap.org/wiki/Pro … _Transport ) auf die Idee gekommen ist, das die Zuordnung einer stop_area-Realtion nur für eine Transportmittelart gelten soll?
Wo steht das denn?

"The stop area is a relation that contains all elements of a train/subway/monorail/tram/bus/trolleybus/aerialway/ferry stop." im Proposal läßt sich sehr leicht in diese Richtung interpretieren ("von einer ...-Haltestelle ..."), da ja extra noch die Verkehrmittel aufgezählt werden und daraus nicht eindeutig hervorgeht, das damit im Prinzip die Elemente aller Platformen/Hlatepositionen mit dem gleichen Namen gemeint sind.

Weide wrote:

Ein Punkt mit public_transport=platform besagt dagegen, das dort nichts bis auf ein Haltestellenschild ist.

Das sagt formal aus, das die Stelle ist, wo man wartet und in das Verkehrsmittel ein- oder aussteigt. Ich habe schon Fußwege zur Platform gemacht. Das Mindestkennzeichen ist natürlich bei der Nutzung des Fußweges als Busplatform, das diese als solche zu erkennen ist, egal ob am Schild, am Wartehäuschen oder am aufgehängten Fahrplan.

geokyf · 2012-09-20 21:50:16

wambacher wrote:

Allerdings: Die Rufbusse fahren immer noch feste Routen zu festen Zeiten - also nach Fahrplan. Nur nicht immer, sondern nur nach Bedarf. Daher ist eine "normale" Erfassung durchaus sinnvoll.

Wenn die Auslastung stimmt ja, ansonsten fällt das ganze aus oder man lässt einer Haltestelle aus, wenn sich der Umweg nicht lohnt. Mit der Folge, dass so ein ÖPNV immer unattraktiver wird und noch weniger Fahren. So hat man hier auch schon die Bahn zur Stilllegung getrieben. Ein positives hat es dennoch, wo keine Bushaltestelle mehr ist, muss auch keiner erfasst werden und so hat man weniger Arbeit.

Weide · 2012-09-20 21:54:28

Hi,

Fabi2 wrote:

Weide wrote:
Fabi2 wrote:
Da frag ich mich echt, wie man dann im offiziellen Proposal ( https://wiki.openstreetmap.org/wiki/Pro … _Transport ) auf die Idee gekommen ist, das die Zuordnung einer stop_area-Realtion nur für eine Transportmittelart gelten soll?
Wo steht das denn?
"The stop area is a relation that contains all elements of a train/subway/monorail/tram/bus/trolleybus/aerialway/ferry stop." im Proposal läßt sich sehr leicht in diese Richtung interpretieren ("von einer ...-Haltestelle ..."), da ja extra noch die Verkehrmittel aufgezählt werden und daraus nicht eindeutig hervorgeht, das damit im Prinzip die Elemente aller Platformen/Hlatepositionen mit dem gleichen Namen gemeint sind.

Ach so ... ich bin nie auf die Idee gekommen, dass man das falsch verstehen könnte.

Fabi2 wrote:

Weide wrote:
Ein Punkt mit public_transport=platform besagt dagegen, das dort nichts bis auf ein Haltestellenschild ist.
Das sagt formal aus, das die Stelle ist, wo man wartet und in das Verkehrsmittel ein- oder aussteigt. Ich habe schon Fußwege zur Platform gemacht. Das Mindestkennzeichen ist natürlich bei der Nutzung des Fußweges als Busplatform, das diese als solche zu erkennen ist, egal ob am Schild, am Wartehäuschen oder am aufgehängten Fahrplan.

Wenn es ein Punkt ist, dann besagt es definitiv das dort kein Bussteig ist. Ich würde mich aber nicht darauf verlassen.

Weide

wambacher · 2012-09-20 21:57:48

Weide wrote:

Sowas gibt es aber auch anders. Z.B. am Tag vorher anrufen, dann erfährt man die Uhrzeit, wird am nächsten Tag zuhause abgeholt und in die nächste Stadt gefahren.

Jo, sowas hatten wir auch, aber das wurde leider aus Kostengründen eingestellt. Für so einen Dienst ist die OSM-Erfassung wirklich nicht sinnvoll (und auch garnicht möglich).
Aber die Rufbusse, mit denen die gesetzlich vorgeschriebene Grundversorgung der Bevölkerung gewährleistet wird, sind eine kostengünstige Art von "Linienverkehr" und gehören mMn in OSM rein.
Sehr oft benutzen sie sogar die alten Linien-Nummern und etablierten Routen.

Gruss
Walter

wambacher · 2012-09-20 22:05:39

geokyf wrote:

Wenn die Auslastung stimmt ja, ansonsten fällt das ganze aus oder man lässt einer Haltestelle aus, wenn sich der Umweg nicht lohnt. Mit der Folge, dass so ein ÖPNV immer unattraktiver wird und noch weniger Fahren. So hat man hier auch schon die Bahn zur Stilllegung getrieben. Ein positives hat es dennoch, wo keine Bushaltestelle mehr ist, muss auch keiner erfasst werden und so hat man weniger Arbeit.

Ja, da hast du leider Recht. Dass der Umfang der Dienstleistung bedarfsgerecht angepasst wird, ist ja in Ordnung (*). Dazu gibt es die -bei uns jährlich erfolgenden- Fahrplanänderungen. Danach ist aber für ein Jahr Ruhe und der Status Quo kann in OSM angepasst werden.

Gruss
Walter

*) aber wehe, die bauen "meine" Haltestelle ab, dann werd' ich sauer

Geogast · 2012-09-20 22:17:52

Irgendwie habe ich ein Déjà-vu. Vor einem guten Jahr haben wir das schon mal diskutiert. "Leidig", eben.

Keichi · 2012-09-20 22:24:52

HostedDinner wrote:

stop_area_group? Noch nie gehört... Im Proposal http://wiki.openstreetmap.org/wiki/Prop … _Transport gibt es nur stop_area und ich pack da alles rein, warum auch nicht? Man muss nur aufpassen, wegen operator, denn evt. haben die verschiedenen Stops verschiedene Operator...
Und auch hier http://wiki.openstreetmap.org/wiki/Tag: … Dstop_area steht, dass alles in eine Relation reinkommt...
Lg HostedDinner

Ja gut aber dafür kann man ja notfalls den Operator von der jeweiligen Relationen dann mit : (oder was ;?) trennen, so das alle rein kommen.

Fabi2 wrote:

Keichi wrote:
Nur frage ich mich wirklich schon die ganze Zeit, MUSS man wirklich für ein Haltestelle die den selben Namen hat, tausend Relationen anlegen, nur weil die eine für die Busse ist, die andere für die Trams und nochmal eine für die Züge?
Nein, muß man nicht, zumindest dachte ich das bis jetzt, denn wenn man das alte Oxomoa-Schema (https://wiki.openstreetmap.org/wiki/Use … PNV-Schema) kennt und benutzt hat, auf dem ja putlic_transport-Schema basiert und es quasi nur ein offizielles Wiedergekäue des Schemas per Proposal-Prozess war, um es auch außerhalb Europas formal abnicken zu lassen. Es sind ein paar kleinere Änderungen eingeflossen und außer diesen habe ich mir leider den Rest des neuen Proposals auch nicht angesehen, hätte ich aber lieber mal machen sollen.
Da haben offenbar Leute das offizelle Proposal geschrieben, die das Schema nicht ganz bis ins Letzte verstanden haben. Wie man auch unter https://wiki.openstreetmap.org/wiki/Fil … modell.png sehen kann, gibt es keinerlei Einschränkungen für die Art und Anzahl der Platformen und Haltepunkte in der stop_area-Relation. Da frag ich mich echt, wie man dann im offiziellen Proposal ( https://wiki.openstreetmap.org/wiki/Pro … _Transport ) auf die Idee gekommen ist, das die Zuordnung einer stop_area-Realtion nur für eine Transportmittelart gelten soll?
Das Oxomoa-Schema hat ja mindestens einen fehler und ist auch an manchen stellen leider uneindeutig, so daß ich auch erst mal überlegen mußte, was denn z.B. jetzt die Unterscheidung von stop_area zu stop_area_group ausmachte, weil bei gleichem Namen ist das sinnvollerweise 1 stop_area-Relation (das steht nicht drin, das durfte man sich damals überlegen). Dann beinhaltet das alte und neue Schema noch einen Fehler, welcher aber nicht sofort offensichtlich ist und somit bei der Konstruktion übersehen wurde. Ich habe auch erst vor eine Weile festgestellt, das da konsequentenweise eine Relation fehlt, die die Haltepunkte an einer Platform, der betreffenden Platform selbst zuordnet. Also eine Bahnsteigrelation der Art: die Haltepunkte 1, 2 und 3 auf Gleis 4 liegen an Bahnsteig B.
Für dieses Problem wurde dann ersatzweise der Workaround gefunden, das man die Platformen und stop_positions mit den Verkehrsmitteln taggen soll, was aber unötige Redundanz ist, denn wenn man den Haltepunkt mit dem Verkehrmittel getaggt hat, dann braucht man das Verkehrsmittel nicht noch mal an den Bahnsteig zu taggen, weil schließlich ist ja, zumindest in der Realität, klar, wo die Platform für die jeweiligen Haltepunkte ist, nur das wurde eben leider nicht für den Rechner abgebildet.

Stimmt im Proposal war es wirklich drin, nur ist es trotzdem einfach nur Lächerlich und macht alles nur noch komplizierter als es momentan schon ist. Ich durfte mich zbs. grad auch schon wieder mit JOSM rumschlagen, weil er eine dieser doppel Relationen nicht richtig aus der Network Relation gelöscht hat und mir jedes mal nen Conflict gemeldet hat, so das ich meine Changes alle nicht hochladen konnte.. Nach ner halben Stunde fummelei habe ich es dann endlich geschafft das er es mal uppt und konnte das Changeset endlich schließen...

Für uns Mapper ist das also wirklich nen Horror mit den Zig Relations Ebenen.

Allerdings hast du recht, das ne Relation fehlt ist mir auch schon aufgefallen, ich habe mir darüber nur nie wirklich gedanken gemacht gehabt. Allerdings sehe ich da dann wieder das Problem das es die public_transport Liste noch weiter zumüllt, das ist jetzt schon nicht gerade einfach die Richtige Relation zufinden, wenn man die Routen anlegt und da mal plötzlich 600 Relationen drin hat, weil josm alles nachlädt. Also entweder müsste man dafür ne komplett neue Type Relation machen, oder man belässt es so wie jetzt, und packt einfach Platform und stop_position in die stop_area Relation mit rein.

Wobei sich mir da dann aber die Frage stellt.. Wofür ist die Public_Transport Relation dann überhaupt noch Gut? Im Grunde doch dann nur noch dafür, das der Renderer die Haltestelle (wie in der ÖPNV Karte) gescheit markiert und für die ganzen Network Relationen.

Weide wrote:

Hi,
also gewöhnlich kommt man mit einer dieser stop_area-Relationen aus, oft sogar ganz ohne.
Die stop_area_group stammt aus einem älteren Vorschlag und gehört nicht zum PT-Schema.
Man "muss" übrigens nicht umstellen.
Manches kann man auch garnicht umstellen. Ein Punkt mit highway=bus_stop neben der Fahrbahn bedeutet, dass man dort auf den Bus warten kann. Es sagt nichts darüber, ob da ein markierter Wartebereich ist oder Häuschen stehen. Ein Punkt mit public_transport=platform besagt dagegen, das dort nichts bis auf ein Haltestellenschild ist. Ohne Ortskenntnis kann man sowas nicht umstellen.
Falls man die Routen des PT-Schemas praktisch findet, dann kann man sie übrigens auch anwenden, ohne irgendwelche Haltestellen zu ändern. Das führt nicht zu Problemen!
frohes Mappen
Weide

Ich muss dir da leider Versprechen. public_transport=platform kann zwar nicht alleine sagen ob dort ein Wartehaus steht aber dafür kann man die Node ja noch mit shelter=yes bench=yes und bin=yes erweitern. Außerdem bedeutet für mich der platform tag das man eben an dieser Stelle warten soll, weil dort ein Bus/Tram/Zug/Ubahn hält. Es stimmt allerdings manche Details kann man ohne Ortskenntnisse nicht eintragen, aber ab und zu ist es auf den Luftbildern ja offentsichlich das dort der Bereich ist wo eben besagtes Verkehrsmittel hält, sei es weil ein riesen BUS auf der Farhbahn gemalt wurde, oder weil man das Wartehaus auf der Luftaufnahme sehen kann.

Was mir an den PT Schema halt gefällt ist nunmal die Möglichkeit das man direkt sehen kann das die und die Linie dort hält und vorallem auf welcher Seite sie hält. Solche Dinge sind zwar momentan noch nicht Relevant, werden es aber hoffentlich irgendwann sein, weswegen ich schon meine, das man die alten Tags gegen das neue Schema austauschen sollte. Ich denke jedenfalls, das es irgendwann auch mal möglich sein wird, das man OSM dafür benutzen kann, auch mal Routen mit den ÖPNV zu planen und spätenstens dann sind solche Daten Goldwert. Wir haben ja jetzt schon den Vorteil gegenüber den offizellen Karten der Verkehrsunternehmen, das wir sagen können dort hält das und das in die Richtung und dort drüben in die andere.

Eins fällt mir gerade noch ein, wo wir ja auch bei den Route Relationen sind.. Ist es eigentlich irgendwie umsetzbar das man in der Route Relation einen Tag der Member Relation aus public_transport auszulesen?

Ich dachte mir das so:

Die Relation public_transport=stop_area hat 2 mal member Musterweg als stop_position und platform allerdings jede mit nen anderen ref= also 1,2,3,4 usw.

Könnte man dort nicht in der route relation als role angeben auf welche REF sich das ganze in der stop_area Relation bezieht?

Weil so könnte man die komplette stop_area Relation in die route relation schmeißen und müsste nur noch per role sagen an welcher Haltestelle (ref) der Bus nun hält, und damit wäre dieser Hässliche Woraround dann auch umgangen und man bräuchte keine zusätzliche Relation mehr anlegen.

Hobby Navigator wrote:

Hallo Keichi, zu deinen Fragen kann ich zwar nicht wirklich viel beitragen, ist nicht so mein Thema.
Was ich allerdings machen kann ist dich herzlich im Forum willkommen zu heißen. Das geht ja gar nicht das dies noch niemand gemacht hat.

Danke auch wenn ich schon seid 2008 an der Karte "rumwerkel"

Fabi2 · 2012-09-20 22:40:11

wambacher wrote:

. Dass der Umfang der Dienstleistung bedarfsgerecht angepasst wird, ist ja in Ordnung (*). Dazu gibt es die -bei uns jährlich erfolgenden- Fahrplanänderungen. Danach ist aber für ein Jahr Ruhe und der Status Quo kann in OSM angepasst werden.
[...]
*) aber wehe, die bauen "meine" Haltestelle ab, dann werd' ich sauer

Naja, wir in Berlin hatten ja mal mit das beste Nahverkehrsnetz in Europa, hatten, wohlgemerkt. Seit 2004 hat man dank Metrobus/-tram die Taktzeit von 95% der Linien von 10 auf 20 min erhöht, das ganze wurde dann auch noch als Servicezugewinnn gefeiert. Seither machen die BVG-Betriebswirtschafter jedes Jahr Bedarfsumfragen, mit dem Ergebnis von weiteren "Optimierungen" und Fahrteneinsparungen. Seit 2010 hat es dann eine nachtbusline in meiner Nähe erwischt: da gibt es jetzt den besonders grotesten "Halbe-Haltestelle-Einseitenbetrieb": der betreffende Nachtbus hält einseitig nur noch an ca. jeder 3. Haltestelle, an den anderen, die früher bedient wurden, fährt er vorbei (die betreffenden alten Haltestellen liegen als Bustaschen direkt an der Straße der betreffenden Linie). Nun muß man wissen, das es eine Randlinie ist und die potenziellen Verzögerungen durch zusätzliche ein und Ausstige auf 3/4 der betreffenden Linienrichtung bestenfalls 5 min, wenn überhaupt, ausmachen würden, da da meistens fast niemand einsteigen will. Naun ratet mal, was einem die Fahrplanauskunft rät: ja, klar, man soll mit der gleichen Linie in der anderen Richtung zurückfahren, weil da hält der Bus nämlich an den Haltestellen... Nur, laut Fahrplan hat man in meinem Fall 2 min Zeit zum Umsteigen, aber real ist der Bus schon weg, wenn man mit der gegenrichtung an der Umsteigehaltestelle ankommt. Das liegt daran, das die Leine von den größeren Knotenpunkten meist zwecks Umsteigerei, auf dier anderen Busse warten muß und so verspätet losfährt. Während der Fahrstrecke holt er aber, wegen der wenigen Zustiege, diese Zeit meist locker wieder heraus, was besonders für die gegenrichtung gilt, die ja nur noch ein paar Stationen von der Endhaltestelle entfernt ist. Ergebnis: Die BVG-BWLer erreichen ihre Sparvorgaben (spart ja immerhin vielleicht 50 m pro Fahrt... ), ohne ihr Großhirn zu benutzen, gerade in Hinblick auf den Service für den Kunden... Über den tollen Service der Berliner S-Bahn (ist ja schließlich 'ne Tochter der "Börsenbahn") muß ich bestinmt nicht mehr groß was schreiben, das kann man zur Genüge googeln.

Keichi · 2012-09-20 23:20:52

Geogast wrote:

Irgendwie habe ich ein Déjà-vu. Vor einem guten Jahr haben wir das schon mal diskutiert. "Leidig", eben.

Jepp und bis heute hat sich da nicht viel getan und alles ist immer noch so unklar wie letztes Jahr

HostedDinner wrote:

Mir fällt gerade auf: Warum ist eigentlich der Part über Haltestellen (und deren Realtionen) nicht auf der Seite https://wiki.openstreetmap.org/wiki/Public_Transport sondern nur im Proposal? Ich denke viele werden nicht auch noch das Proposal lesen, wenn sie die "Einstiegsseite" vom Public Transport gelesen haben...
Man sollte evtl. einen Abschnitt dazu schreiben, um die einzelenen Hinweise bei den Verkehrsmitteln zusammenzufassen.
Lg HostedDinner

Ich hatte mir die Info von hier https://wiki.openstreetmap.org/wiki/Buses geholt.. Wobei das auch nicht gerade super erklärt wurde und ichs mir dann einfach in JOSM bei schon vorhandenen public_transport Realtionen abgeschaut habe.

Was mir beim lesen der Diskusion vom Proposal noch aufgefallen ist, sind die Fußwege auf den man ja eigentlich die public_transport=platform Node setzen soll.. Nur mal ganz ehrlich ich Mappe seit 2008 an der Karte rum, nur das sind irgendwie die einzigen Wege die absolut kein Schwein in vollen Umfang mappen will.

Wie sieht das den da bei nen Router aus? Reicht den das wenn nen sidewalk=* auf dem Highway way liegt?

Last edited by Keichi (2012-09-20 23:30:17)

Fabi2 · 2012-09-21 00:42:34

Keichi wrote:

Stimmt im Proposal war es wirklich drin, nur ist es trotzdem einfach nur Lächerlich und macht alles nur noch komplizierter als es momentan schon ist. Ich durfte mich zbs. grad auch schon wieder mit JOSM rumschlagen, weil er eine dieser doppel Relationen nicht richtig aus der Network Relation gelöscht hat und mir jedes mal nen Conflict gemeldet hat, so das ich meine Changes alle nicht hochladen konnte.. Nach ner halben Stunde fummelei habe ich es dann endlich geschafft das er es mal uppt und konnte das Changeset endlich schließen...
Für uns Mapper ist das also wirklich nen Horror mit den Zig Relations Ebenen.

Aus Sicht des Datenmodells sind ja verschatelte Relationen im Moment meist die einzig saubere Lösung für viele Sachen, nur ist das Schema dann weder anfängerfreundlich im Sinne von leicht zu verstehen, noch ist es für Leute die es dann verstanden haben, hakbwegs praktikabel zu editieren. Zur schlechten Editierbarkeit trägt die mäßige Toolunterstützung bei und die wiederum zum Entstehen weiteren halbgarer Teil- und Frickellösungen. Ich denke da auch an die schlechte Relationsunterstützung von geschachtelten Relationen in JOSM, was ja noch mit der beste Editor in dieser Hinsicht ist (Relation anzeigen, zeigt nur die erste Ebene an. Von der Hauptrelation kann man nicht leicht die zugeordenten Kindrelationen auswählen, usw. Durch solche Sachen wird das Handling umstaändlich, obwohl am Ende iregndwie geht.).

Keichi wrote:

Allerdings hast du recht, das ne Relation fehlt ist mir auch schon aufgefallen, ich habe mir darüber nur nie wirklich gedanken gemacht gehabt. Allerdings sehe ich da dann wieder das Problem das es die public_transport Liste noch weiter zumüllt, das ist jetzt schon nicht gerade einfach die Richtige Relation zufinden, wenn man die Routen anlegt und da mal plötzlich 600 Relationen drin hat, weil josm alles nachlädt. Also entweder müsste man dafür ne komplett neue Type Relation machen, oder man belässt es so wie jetzt, und packt einfach Platform und stop_position in die stop_area Relation mit rein.

Gut, vielleicht läßt sich die Relationsflut über Filter eindämmen, habe ich noch nicht versucht, geht aber sicher, wobei da evtl. ein Suchfeld zum schnellen Filtern vielleicht noch besser wäre, man schreibt da einfach Tagteile rein und AND und key=value wird automatisch zum filtern angenommen. Aber geht sicher auch mit vorbelegten Filtern, die man dann an und aus klickt. Ich würde die entsprechende Ergänzung der Relation (als type=public_transport public_transport=*, um konsitent und kompatibel zum alten Schema zu bleiben) gerne sehen, zusammen mit einer kleinen optionalen Gut-genug-Fahrplanerweiterung. Zwar wurden die Fahrplandaten ja jetzt freigegeben und man kann in Zukunft evtl. auf weitere Freigaben hoffen, aber der dauerhafte Nutzen der angedachten Erweiterung ist aus meiner Sicht größer als der Aufwand der Erfassung, außerdem wird es nicht für alle Netze oder kleine Nischenlinien auf der Welt elektionische Daten geben, wenn überhaupt. Das Ganze wurde schon mal in Verbindung mit dem Entwurf von Netzwolfs erweiterten Öffnungszeiten diskutiert (als z.B. "Mo-Fr 08:00-16:00/20") und man müßte da nur ein paar Tags für die Betriebszeiten + Taktzeit, sowie den relativen Fahrzeitabstand zwischen den Stationen und die normale durchnittliche Aufenthaltsdauer an den Stationen pro Linienvariante erfassen, schon hat man eine Fahrplanauskunft für Notfälle. Zu den Betriebszeiten kann man alle x Minuten mit dem Verkehrsmittel fahren, im statistischen Mittel beträgt die Umsteigezeit an den Stationen 50% der Taktzeit des nachfolgenden Verkehrsmittels + die reine mittlere Fahrzeit, die ja mit erfaßt ist.
Ausnahmen, z.B. zum Betrieb an bestimmten Tagen, werden bewußt herausgelassen und es ist auch nicht das erklärte Ziel die offizielle Auskuft irgendwie ersetzen zu wollen, sondern nur, wenn man gerade mal am Ar... der Welt ist, herausfinden zu können, wie man jetzt noch weiter kommen kann. Da nur der Bereich der Betriebszeitenn und der ungefähre Takt an sich erfaßt sind, ist es nicht so schlimm bzw. aufwendig, wenn sich innerhalb des Betreibsintervalls mal etwas die Abfahrtszeiten ändern.

Keichi wrote:

Wobei sich mir da dann aber die Frage stellt.. Wofür ist die Public_Transport Relation dann überhaupt noch Gut? Im Grunde doch dann nur noch dafür, das der Renderer die Haltestelle (wie in der ÖPNV Karte) gescheit markiert und für die ganzen Network Relationen.

Ja, bei größeren und auch verstreuter liegenden Haltestellen, weiß man da im Moment sicher, welche Plattformen/Haltepunkte wirklich zur Hlatestelle gehören. Andernfalls müßte man eine Umkreissuche machen und läuft dann immer noch Gefahr evtl. Teile der Haltestelle zu vergessen.

Was mir an den PT Schema halt gefällt ist nunmal die Möglichkeit das man direkt sehen kann das die und die Linie dort hält und vorallem auf welcher Seite sie hält. Solche Dinge sind zwar momentan noch nicht Relevant, werden es aber hoffentlich irgendwann sein, weswegen ich schon meine, das man die alten Tags gegen das neue Schema austauschen sollte. Ich denke jedenfalls, das es irgendwann auch mal möglich sein wird, das man OSM dafür benutzen kann, auch mal Routen mit den ÖPNV zu planen und spätenstens dann sind solche Daten Goldwert. Wir haben ja jetzt schon den Vorteil gegenüber den offizellen Karten der Verkehrsunternehmen, das wir sagen können dort hält das und das in die Richtung und dort drüben in die andere.

Keichi wrote:

Eins fällt mir gerade noch ein, wo wir ja auch bei den Route Relationen sind.. Ist es eigentlich irgendwie umsetzbar das man in der Route Relation einen Tag der Member Relation aus public_transport auszulesen?
Ich dachte mir das so:
Die Relation public_transport=stop_area hat 2 mal member Musterweg als stop_position und platform allerdings jede mit nen anderen ref= also 1,2,3,4 usw.
Könnte man dort nicht in der route relation als role angeben auf welche REF sich das ganze in der stop_area Relation bezieht?
Weil so könnte man die komplette stop_area Relation in die route relation schmeißen und müsste nur noch per role sagen an welcher Haltestelle (ref) der Bus nun hält, und damit wäre dieser Hässliche Woraround dann auch umgangen und man bräuchte keine zusätzliche Relation mehr anlegen.

Klar geht das und das wäre auch sehr sinnvoll, der saubere Weg wurde aber leider wie so oft bei OSM, aus Kompatibilitäts- oder Gründen des Verständnisses durch die Mapper, mal wieder geopfert:

1. In die Relation der Linienvariante kommt nur noch die Strecke und jeweilige die stop_position, was an der stop_position hält ergibt sich implizit durch die Linienvariantenrelationen.
2. Über die stop_position und die, leider fehlende Bahnsteig-Relation, kann man dann z.B. für den Router, den zugehörigen Bahnsteig/Platform für das weitere Routing ermitteln.
3. Von der emittelten Platform, kommt man dann über die die stop_area-Relation (wo nur noch die Platformen drin sind) zum Namen,Operator,Network,etc. der Gesamthaltestelle.

Ja, es nervt einfach, wenn man zusehen darf, wie halbe Lösungen gebastelt werden, nur damit die Community, die ja sehr wichtig ist bei Crowdsourcing-Projekten, das Mappingschema noch versteht.
Damit bekommt man dann entweder gar keine Daten oder aber unflektsible Teillösungen, bei der man für die nächste Anwendung dann wieder fast alles neu erfassen/umändern darf.

Keichi · 2012-09-21 03:34:09

Fabi2 wrote:

Klar geht das und das wäre auch sehr sinnvoll, der saubere Weg wurde aber leider wie so oft bei OSM, aus Kompatibilitäts- oder Gründen des Verständnisses durch die Mapper, mal wieder geopfert:
1. In die Relation der Linienvariante kommt nur noch die Strecke und jeweilige die stop_position, was an der stop_position hält ergibt sich implizit durch die Linienvariantenrelationen.
2. Über die stop_position und die, leider fehlende Bahnsteig-Relation, kann man dann z.B. für den Router, den zugehörigen Bahnsteig/Platform für das weitere Routing ermitteln.
3. Von der emittelten Platform, kommt man dann über die die stop_area-Relation (wo nur noch die Platformen drin sind) zum Namen,Operator,Network,etc. der Gesamthaltestelle.
Ja, es nervt einfach, wenn man zusehen darf, wie halbe Lösungen gebastelt werden, nur damit die Community, die ja sehr wichtig ist bei Crowdsourcing-Projekten, das Mappingschema noch versteht.
Damit bekommt man dann entweder gar keine Daten oder aber unflektsible Teillösungen, bei der man für die nächste Anwendung dann wieder fast alles neu erfassen/umändern darf.

Das stimmt allerdings, wobei ich die Lösung nun ehrlich gesagt sogar leichter finde

Auch das mit den Segmentieren was im Proposal diskutiert wirde verstehe ich nicht so ganz.. Wieso nimmt man dafür nicht einfach AssociatedStreet? Ich meine wir haben schließlich schon die möglichkeit auf die komplette Straße in einer Relation zuzugreifen, wieso macht man sich da dann noch mehr aufwand?

Im Grunde würde die Relation fürs Routing reichen, der Renderer müsste dann halt nur noch Berechnen wie der Bus fährt eben aus den Daten die er durch die route Relation dann bekommt, indem die ganze AssociatedStreet Relationen + die Public_transport Relationen drin stehen.

Irgendwie denken die Leute die das Proposal geschrieben haben viel zu Kompliziert oder haben einfach nie überhaupt was an der Karte gemacht und wissen nicht was schon alles vorhanden ist.

Weide · 2012-09-21 05:51:58

Hi,

Keichi wrote:

...Ich muss dir da leider Versprechen...

"Wartehaus" ja, aber der Wartebereich selbst hat eine andere Bedeutung und ist nicht direkt übersetzbar. Das Proposal sagt:

A public_transport=platform is used to tag a Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole.

Wenn man nach dem PT-Schema dort einen Punkt setzt, dann sagt man damit, dass es dort keine Linie und keine Area einzuzeichnen gibt. Das ist beim highway=bus_stop anders. Daher kann man das eine nicht direkt in das andere übersetzen.

Keichi wrote:

Was mir an den PT Schema halt gefällt ist nunmal die Möglichkeit das man direkt sehen kann das die und die Linie dort hält und vorallem auf welcher Seite sie hält. Solche Dinge sind zwar momentan noch nicht Relevant, werden es aber hoffentlich irgendwann sein, weswegen ich schon meine, das man die alten Tags gegen das neue Schema austauschen sollte.

Das war auch schon vorher so. Das ist noch kein Grund irgendwas auszutauschen.

Keichi wrote:

Weil so könnte man die komplette stop_area Relation in die route relation schmeißen und müsste nur noch per role sagen an welcher Haltestelle (ref) der Bus nun hält, und damit wäre dieser Hässliche Woraround dann auch umgangen und man bräuchte keine zusätzliche Relation mehr anlegen.

Was soll die stop_area in der Route? Ich sehe keinen Grund, sowas zu wollen. Aber es hängt vermutlich mit dem Folgenden zusammen.

"ref" und "name" sind nicht Bahnsteignummern, sondern beziehen sich auf die gesamte Haltestelle. Das ergibt sich eindeutig aus der Formulierung der Recommendation im Proposal: "recommended if no public_transport=stop_area exists, else optional". Es gehört also dasselbe rein, wie bei name und ref der stop_area. Es wäre ja auch irre, wenn man beim zweiten Bussteig am Bahnhof das "name=Bahnhof" durch "name=2" ersetzen müsste, wenn man eine stop_area hinzufügt. Das Hinzufügen einer Relation kann doch nicht die Bedeutung eines Tags einer anderen Relation umschalten.

In das PT-Proposal hätten eigentlich Bus- und Bahnsteignummern rein gehört, aber es ist nun einmal nicht drin und man kann platform=2 oder ähnliches nehmen.

Weide

PS: Nicht das jetzt jemand denkt, ich wäre gegen das PT-Schema. Ich bin im Gegenteil dafür und benutze es intensiv.

Keichi · 2012-09-21 14:42:35

Weide wrote:

Hi,
Keichi wrote:
...Ich muss dir da leider Versprechen...
"Wartehaus" ja, aber der Wartebereich selbst hat eine andere Bedeutung und ist nicht direkt übersetzbar. Das Proposal sagt:
A public_transport=platform is used to tag a Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole.
Wenn man nach dem PT-Schema dort einen Punkt setzt, dann sagt man damit, dass es dort keine Linie und keine Area einzuzeichnen gibt. Das ist beim highway=bus_stop anders. Daher kann man das eine nicht direkt in das andere übersetzen.
Keichi wrote:
Was mir an den PT Schema halt gefällt ist nunmal die Möglichkeit das man direkt sehen kann das die und die Linie dort hält und vorallem auf welcher Seite sie hält. Solche Dinge sind zwar momentan noch nicht Relevant, werden es aber hoffentlich irgendwann sein, weswegen ich schon meine, das man die alten Tags gegen das neue Schema austauschen sollte.
Das war auch schon vorher so. Das ist noch kein Grund irgendwas auszutauschen.
Keichi wrote:
Weil so könnte man die komplette stop_area Relation in die route relation schmeißen und müsste nur noch per role sagen an welcher Haltestelle (ref) der Bus nun hält, und damit wäre dieser Hässliche Woraround dann auch umgangen und man bräuchte keine zusätzliche Relation mehr anlegen.
Was soll die stop_area in der Route? Ich sehe keinen Grund, sowas zu wollen. Aber es hängt vermutlich mit dem Folgenden zusammen.
"ref" und "name" sind nicht Bahnsteignummern, sondern beziehen sich auf die gesamte Haltestelle. Das ergibt sich eindeutig aus der Formulierung der Recommendation im Proposal: "recommended if no public_transport=stop_area exists, else optional". Es gehört also dasselbe rein, wie bei name und ref der stop_area. Es wäre ja auch irre, wenn man beim zweiten Bussteig am Bahnhof das "name=Bahnhof" durch "name=2" ersetzen müsste, wenn man eine stop_area hinzufügt. Das Hinzufügen einer Relation kann doch nicht die Bedeutung eines Tags einer anderen Relation umschalten.
In das PT-Proposal hätten eigentlich Bus- und Bahnsteignummern rein gehört, aber es ist nun einmal nicht drin und man kann platform=2 oder ähnliches nehmen.

Weide
PS: Nicht das jetzt jemand denkt, ich wäre gegen das PT-Schema. Ich bin im Gegenteil dafür und benutze es intensiv.

Die stop_area soll einfach nur zur besseren Übersicht rein, sonst hätten wir wohl auch keinen wirklichen Grund für die PT Relation. Außerdem vereinfacht es die ganze Sache, vorallem FALLS die Leuts sich mal irgendwann zur Segmentierung entschieden sollten.

Aber es stimmt, Platform wäre in dem Fall wirklich angebrachter und man würde das ref nicht verhunzen. Ich sehe auch gerade im Wiki Artikel der Route Relation http://wiki.openstreetmap.org/wiki/Relation:route das es stop:number und platform:number gibt, leider werden die Daten aber nicht vom Renderer ausgewertet. Aber das wäre in dem Fall dann eh Depracted weil man ja die stop_area Relation nutzt und dort nur per Role sagt 1,2,3.

Announcement

#1 2012-09-20 17:54:26

Das "leidige" Thema Public_transport...

#2 2012-09-20 20:19:22

Re: Das "leidige" Thema Public_transport...

#3 2012-09-20 20:27:38

Re: Das "leidige" Thema Public_transport...

#4 2012-09-20 21:01:33

Re: Das "leidige" Thema Public_transport...

#5 2012-09-20 21:17:07

Re: Das "leidige" Thema Public_transport...

#6 2012-09-20 21:21:27

Re: Das "leidige" Thema Public_transport...

#7 2012-09-20 21:27:48

Re: Das "leidige" Thema Public_transport...

#8 2012-09-20 21:29:53

Re: Das "leidige" Thema Public_transport...

#9 2012-09-20 21:32:29

Re: Das "leidige" Thema Public_transport...

#10 2012-09-20 21:35:22

Re: Das "leidige" Thema Public_transport...

#11 2012-09-20 21:42:13

Re: Das "leidige" Thema Public_transport...

#12 2012-09-20 21:44:16

Re: Das "leidige" Thema Public_transport...

#13 2012-09-20 21:48:02

Re: Das "leidige" Thema Public_transport...

#14 2012-09-20 21:50:16

Re: Das "leidige" Thema Public_transport...

#15 2012-09-20 21:54:28

Re: Das "leidige" Thema Public_transport...

#16 2012-09-20 21:57:48

Re: Das "leidige" Thema Public_transport...

#17 2012-09-20 22:05:39

Re: Das "leidige" Thema Public_transport...

#18 2012-09-20 22:17:52

Re: Das "leidige" Thema Public_transport...

#19 2012-09-20 22:24:52

Re: Das "leidige" Thema Public_transport...

#20 2012-09-20 22:40:11

Re: Das "leidige" Thema Public_transport...

#21 2012-09-20 23:20:52

Re: Das "leidige" Thema Public_transport...

#22 2012-09-21 00:42:34

Re: Das "leidige" Thema Public_transport...

#23 2012-09-21 03:34:09

Re: Das "leidige" Thema Public_transport...

#24 2012-09-21 05:51:58

Re: Das "leidige" Thema Public_transport...

#25 2012-09-21 14:42:35

Re: Das "leidige" Thema Public_transport...

Board footer