Neuer Mapper bearbeitet Busrelationen

GerdP · 2021-03-15 14:08:13

ToniE wrote:

GerdP wrote:
Welche Anwendung braucht das?
https://waymarkedtrails.org kann daraus Höhenprofile für die Rad-/Wander-/MTB-/...Routen erstellen.
Automatisches Sortieren in der Anwendung ist nur bedingt tauglich, da es nicht immer korrekte Ergebnisse liefert.

Liegt das daran, dass die Sortierung es falsch macht, oder daran, dass das Datenmodel es nicht erlaubt? Ich frage, weil es mir bei manchen Relationen einfach nicht klar ist, was die überhaupt darstellen sollen und wie eine korrekte Sortierung aussehen müsste. Wenn das nicht 100% klar ist, dann darf man sich über "kaputte" Relationen nach der Bearbeitung nicht wundern. Der Editor muss ja bei Aktionen, die Wege splitten oder vereinen, berechnen können, wo welche Teile nach der Aktion hingehören.

ToniE · 2021-03-15 14:20:50

GerdP wrote:

ToniE wrote:
GerdP wrote:
Welche Anwendung braucht das?
https://waymarkedtrails.org kann daraus Höhenprofile für die Rad-/Wander-/MTB-/...Routen erstellen.
Automatisches Sortieren in der Anwendung ist nur bedingt tauglich, da es nicht immer korrekte Ergebnisse liefert.
Liegt das daran, dass die Sortierung es falsch macht, oder daran, dass das Datenmodel es nicht erlaubt? Ich frage, weil es mir bei manchen Relationen einfach nicht klar ist, was die überhaupt darstellen sollen und wie eine korrekte Sortierung aussehen müsste. Wenn das nicht 100% klar ist, dann darf man sich über "kaputte" Relationen nach der Bearbeitung nicht wundern. Der Editor muss ja bei Aktionen, die Wege splitten oder vereinen, berechnen können, wo welche Teile nach der Aktion hingehören.

Manche Routen sind halt komplex, sie widersetzen sich schlichtweg einer Automatisierung.
Sie benutzen einige Wege doppelt - in der selben oder in der anderen Richtung - ...

Hier ein Beispiel, das nach einer automatischen Sortierung in der Regel "Inseln" enthält, die jeweils einen "roundtrip" darstellen.

https://ptna.openstreetmap.de/relation. … 20&lang=de

Das ist eh schon ein Rundkurs. Die Strecken oben links um Hanfeld herum oder unten am Starnberger See tauchen nach einer automatischen Sortierung gerne mal als isolierte Rundkurse auf.

Der Editor sollte nach dem Aufsplitten (was ja eine lokale Aktion auf einem einzelnen Way ist) die lokale Reihenfolge wieder herstellen ohne die gesamte Reihenfolge zu verändern.
Dazu reicht es in der Regel aus die beiden Anschluss-Ways zur lokale Sortierung heranzuziehen.
Schlimmer wird's natürlich, wenn der Way zwei mal in der Relation vor kommt.

Soweit zur Theorie.

"In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, in der Praxis schon!"

Last edited by ToniE (2021-03-15 14:31:31)

ToniE · 2021-03-15 14:29:38

GerdP wrote:

Ich frage, weil es mir bei manchen Relationen einfach nicht klar ist, was die überhaupt darstellen sollen und wie eine korrekte Sortierung aussehen müsste.

Rad-/Wander-/MTB-/ÖPNV-/...-Relationen definieren nicht nur, welche Wege dazu gehören, sondern auch in welcher Reihenfolge sie zu benutzen sind
- nur so komme ich vom Start zum Ziel
- nur so weiß ich was der 1. und was der letzte Way sind, was Start und Ziel überhaupt sind.

Auf einer Karte, die "lediglich" die roten, gelben, ... Linien "malt" ist die Reihenfolge völlig uninteressant - auch für den Leser.

Aber abstrahieren wir doch mal vom Begriff "Map" in "OpenStreetMap" und begeben wir uns auf die Datenebene in der DB.

Wenn's ums Navigieren geht, sieht's nämlich schon ganz anders aus - da spielt die Reihenfolge der Ways eine Rolle, und die Reihenfolge kann in der Regel nicht automatisch ermittelt werden.

Last edited by ToniE (2021-03-15 17:53:09)

AB-inf-x-chg-AB · 2021-03-15 16:01:07

skyper wrote:

... JOSM hatte da auch seine Problem und hat sie bei mehrfach befahrenen Abschnitten immer noch, allerdings hat sich auch einiges gebessert und bei komplett geladener Relation gibt es einen Validator-Test. ...

Also bei Relationen mit Schleifen, dann entstehen wahrscheinlich ähnliche Unstimmigkeiten wie bei iD, wenn involvierte ways geschnitten werden, siehe Github Besprechung: https://github.com/openstreetmap/iD/issues/4876

skyper · 2021-03-15 17:05:09

QA und das Auge der Personen beim Editieren profitieren auch stark von richtiger Sortierung.

AB-inf-x-chg-AB wrote:

skyper wrote:
... JOSM hatte da auch seine Problem und hat sie bei mehrfach befahrenen Abschnitten immer noch, allerdings hat sich auch einiges gebessert und bei komplett geladener Relation gibt es einen Validator-Test. ...
Also bei Relationen mit Schleifen, dann entstehen wahrscheinlich ähnliche Unstimmigkeiten wie bei iD, wenn involvierte ways geschnitten werden, siehe Github Besprechung: https://github.com/openstreetmap/iD/issues/4876

Bei den ganzen zusammengeführten Issues verliere ich den Überblick und das ursprünglich geschilderte Problem hat nichts mit mehrfach befahrenen Abschnitten zu tun.

Nein, einfache Schleifen sind bei JOSM kein Problem und im Moment finde ich nicht mal auf Anhieb ein Beispiel, wo es bei PTv2 Probleme gibt. Kann es sein, dass es nur noch bei neu angelegten (id=0) Relationen und Wegen ein Problem gibt? Werde wohl meine JOSM-Tickets überprüfen müssen. Bei Wanderwegen sieht es leider anders aus. Wie weit sind mehrfaches Auftreten von Wegen bei PTv1 und sonstigen Route-Relationen vorgesehen und dann wirklich ohne Rolle oder mit jeweils "back-/forward"? Jedenfalls beinhalten einfache Schleifen nicht zwangsläufig mehrfach benutzte Wegstücke und manch Mehrfachbenutzung fällt nicht so schnell als Schleife auf. Ein paar Beispiele zum Testen (erst einmal nur PTv2):

* https://www.openstreetmap.org/relation/2458059
* https://www.openstreetmap.org/relation/12422469 mit noch mehr Beispielen in route_master
* https://www.openstreetmap.org/relation/11242086 mit noch mehr Beispielen in route_master
* https://www.openstreetmap.org/relation/12384346 mit noch mehr Beispielen in route_master

Weide · 2021-03-16 07:16:13

GerdP wrote:

Liegt das daran, dass die Sortierung es falsch macht, oder daran, dass das Datenmodel es nicht erlaubt?

Letzteres. (Und es ist genau die richtige Frage um das Problem klar zu machen!)

Es gibt Relationen bei denen eine andere Reihenfolge der Member nichts an der Bedeutung ändert ... z.B. eine normale Abbiegerelation mit drei Elementen "from", "via" und "to". Die kann man automatisch sortieren.

Es gibt Relationen wie PTv2-Routen von denen jede eine Variante einer Richtung einer Buslinie angibt. In denen bedeutet die Reihenfolge der Haltestellen, dass diese in dieser Reihenfolge angefahren werden. Die Reihenfolge der Wege bedeutet, dass diese in dieser Reihenfolge benutzt werden. Daraus ergibt sich dann die Richtung in der die Wege benutzt werden und das ist wichtig für die Kartendarstellung. Es gibt aber auch unvollständige Buslinienvarianten und das ist völlig legitim. Automatische Sortierung ist da völlig unmöglich. Beispiel:

Nehmen wir mal 5 Punkte A, B, C, D, E von Süd nach Nord auf einer Hauptstraße. Die Wegstücke dazwischen nenne ich mal AB, BC, CD, DE. Jetzt fährt ein Bus wie folgt:
1.: A nach B (Weg AB nordwärts)
2.: B nach D durch das Dorf X (Wege noch nicht erfasst)
3.: D nach C (Weg CD südwärts)
4.: C nach B (Weg BC südwärts)
5.: B nach D durch das Dorf Y (Wege noch nicht erfasst)
6.: D nach E (Weg DE nordwärts)
Der Mapper gibt die korrekte Reihenfolge der Wege mit AB, CD, BC, DE an. Jede automatische Sortierung macht daraus die falsche Angabe AB, BC, CD, DE und die Auswertung ergibt dann fälschlicherweise, dass der Bus zwischen B und D nordwärts fährt während die Angabe des Mappers korrekt angibt, dass der Bus dort südwärts fährt. Diese Route sieht total sortierbar aus und ist es nicht ... das Datenmodell von PTv2-Routen erlaubt ganz einfach keine automatische Sortierung.

Das Beispiel ist zugegebenermaßen extrem und sieht konstruiert aus ... aber ich habe ziemlich genau das selbst vor Jahrzehnten in Schweden bei Kalmar Länstrafiken erlebt.

GerdP · 2021-03-16 10:20:04

skyper wrote:

Werde wohl meine JOSM-Tickets überprüfen müssen.

Ich denke, https://josm.openstreetmap.de/ticket/19217#comment:3 ist immer noch wahr. Ich habe damals versucht, den Code zu korrigieren, bin aber eben daran gescheitert, dass ich nicht verstehe, was wirklich passieren sollte. Mein Fazit damals: Wenn Leute so komplizierte Konstrukte zusammenbauen, dann sollen sie sich nicht wundern, wenn die regelmässig kaputt sind.
Oder anders rum: Es gibt in der Realität Zusammenhänge, die sich mit den OSM Datenstrukturen nur schlecht oder gar nicht darstellen lassen. Schleifen in Routen gehören dazu. Mein Ansatz wäre es, die Route in eindeutige Teile aufzuteilen oder eben einfach nicht zu erfassen.

SimonPoole · 2021-03-16 11:30:16

Nochmals, es gibt 2 verschiedene Aspekte:

- Wegaufspaltung

In diesem Fall werden durch die Änderung am Weg indirekt und ohne das der Mapper es weiss, Relationen in dem der Weg Mitglied ist geändert.

Dazu muss der neu ersteller Weg am richtigen Ort in allen beteiligten Relationen einfügt wird. D.h. über alle Relationen iterieren in den der Weg Mitglied war und dann jeweils über alle Mitgliedeinträge (role, element) iterieren und bestimmen ob der neue Weg vor oder nach dem bestehenden Mitglied eingefügt werden muss (oder gar nicht, im Fall von turn restrictions und ähnlichen Relationen *). Dies sollte eigentlich jeder Editor beherrschen, braucht auch keine zusätzlichen Informationen. Die Relation muss auch nicht sortiert werden.

- Relation sortieren

Dies sollte nur dann relevant sein wenn man direkt die Relation bearbeitet. Grundsätzlich finde ich sollte die Funktion vorhanden sein, aber bei problematischen Relationen eine Warnung anzeigen, dass man möglicherweise Information verliert.

Simon

* eins der echten Probleme ist, dass bei Konstrukten die unbekannte Semantik haben (z.B. weil das jemand gerade erfunden hat), man immer möglicherweise was falsch macht.

Last edited by SimonPoole (2021-03-16 13:20:51)

GerdP · 2021-03-16 12:57:12

Der oben beschriebene Fehler bei Wegaufspaltung betrifft den Fall, das der Anwender lieber mit unvollständigen Daten arbeitet und JOSM zunächst mal rausfinden muss, ob mit den vorhandenen Daten alles klar ist oder nicht und dabei dann mit Sonderfällen nicht zurechtkommt.
Keine Ahnung, ob das Problem in anderen Editoren überhaupt auftaucht. Der normale Benutzer lädt ja immer den Breich um den Weg, den er trennen will, dann gibt es - hoffentlich - kein Probllem.

SimonPoole · 2021-03-16 13:18:10

GerdP wrote:

Der oben beschriebene Fehler bei Wegaufspaltung betrifft den Fall, das der Anwender lieber mit unvollständigen Daten arbeitet und JOSM zunächst mal rausfinden muss, ob mit den vorhandenen Daten alles klar ist oder nicht und dabei dann mit Sonderfällen nicht zurechtkommt.

Das Problem ist ja das man ohne mindestens einer der Nachbarwege in der Relation nicht feststellen kann ob das neu erstellte Wegstück vor oder nach dem existierenden eingefügt werden muss (da die Wegrichtung selber in Routenrelationen keine Bedeutung hat).

Keine Ahnung, ob das Problem in anderen Editoren überhaupt auftaucht. Der normale Benutzer lädt ja immer den Breich um den Weg, den er trennen will, dann gibt es - hoffentlich - kein Probllem.

Das kann ausserhalb eines vollständig heruntergeladenes Gebietes im Prinzip in jedem Editor vorkommen, auch in iD wenn ein Weg über das sichtbare Gebiet (und nicht schon heruntergeladen) herausragt. Aber IMHO sind das Grenzfälle die nicht so häufig vorkommen sollten, dass sie als Erklärung für die geschilderten Probleme taugen.

Last edited by SimonPoole (2021-03-16 13:20:19)

skyper · 2021-03-16 14:41:57

Bei JOSM sind es beim Aufteilen von Wegen zwei Hürden:
1. Die Relationen erst einmal laden.
2. Die benachbarten Wege laden.

Andere Editor Software braucht auch diese Information, nur sollte bei iD zumindest die Relation schon geladen sein.

Weide wrote:

Der Mapper gibt die korrekte Reihenfolge der Wege mit AB, CD, BC, DE an. Jede automatische Sortierung macht daraus die falsche Angabe AB, BC, CD, DE und die Auswertung ergibt dann fälschlicherweise, dass der Bus zwischen B und D nordwärts fährt während die Angabe des Mappers korrekt angibt, dass der Bus dort südwärts fährt. Diese Route sieht total sortierbar aus und ist es nicht ... das Datenmodell von PTv2-Routen erlaubt ganz einfach keine automatische Sortierung.

Es gibt PTv2-Beispiele bei denen Autosortierung schier unmöglich ist, bei diesem einfachen Beispiel bin ich mir nicht sicher. Da ist es eher eine Frage auf was alles geachtet wird. Wenn die Stops in richtiger Reihenfolge und neben der Straße eingetragen sind und auch auf Tags wie `oneway=*` oder gar Abbiegeeinschränkungen geachtet wird, sollte es fast immer klappen.

GerdP wrote:

Ich denke, https://josm.openstreetmap.de/ticket/19217#comment:3 ist immer noch wahr.

Ja.

GerdP wrote:

Ich habe damals versucht, den Code zu korrigieren, bin aber eben daran gescheitert, dass ich nicht verstehe, was wirklich passieren sollte. Mein Fazit damals: Wenn Leute so komplizierte Konstrukte zusammenbauen, dann sollen sie sich nicht wundern, wenn die regelmässig kaputt sind.
Oder anders rum: Es gibt in der Realität Zusammenhänge, die sich mit den OSM Datenstrukturen nur schlecht oder gar nicht darstellen lassen. Schleifen in Routen gehören dazu. Mein Ansatz wäre es, die Route in eindeutige Teile aufzuteilen oder eben einfach nicht zu erfassen.

Was PTv1 angeht gebe ich Dir vollkommen Recht, allerdings wird es noch ewig dauern bis alles auf PTv2 umgestellt wird und für das teilweise Erfassen von Linien ist PTv2 nicht geeignet. Da braucht es schon einiges an Information.

Bei anderen Routen wie `foot`, `bicycle` oder `road` sollte es aber nicht so kompliziert sein. Da fehlen zum Teil ein/zwei definierte Rollen. Leider scheint https://josm.openstreetmap.de/ticket/19633 bei mir am Anfang der Liste immer noch nicht zu funktionieren, was dann auch https://josm.openstreetmap.de/ticket/6166 beeinflusst. Dachte ich hätte das schon gemeldet.

Generell sollte vielleicht eine andere Nachricht erscheinen, wenn JOSM auf einen unbekannten Relationstyp stößt.

axelr · 2021-03-16 16:51:44

Wir weichen vom Thema ab.
In josm haben wir eigentlich kein Problem.
In iD-Bearbeitungen fallen vermehrt Fehler auf.

Im iD-Editor werden beim Splitten von Wegen die neuen Wegstücke offensichtlich falsch herum eingesetzt.

Im iD-Editor wird vermutlich jede angefasste Relation neu durchgerechnet. Es lassen sich aber nicht alle Relationen automatisch berechnen.
Als Beispiel Bus711 http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=4731670 mit zwei Schlaufenenden. Man kann nur aus Kenntnis der Straßenseite der Haltestellen oder der Haltestellen-Reihenfolge den Fahrweg zusammenstellen.

miche101 · 2021-03-16 17:51:55

axelr wrote:

In josm haben wir eigentlich kein Problem.

doch.. da muss man beim Wegteilen die anschliessenden Wege laden sonst kann es in die Hose gehen... ID hab ich in Errinnerung nur teilt wenn diese Wege geladen sind..

Aber immer auf ID schimpfen... PTv2 ist eh "kacke" in der jetzigen Form.. viel zu viel arbeit bei kaum nutzen... und vieles veraltet, unvollständig oder kaputt

Mfg Miche

Last edited by miche101 (2021-03-16 17:55:36)

SimonPoole · 2021-03-16 18:13:16

skyper wrote:

Bei JOSM sind es beim Aufteilen von Wegen zwei Hürden:
1. Die Relationen erst einmal laden.
2. Die benachbarten Wege laden.
....

Nur, auch bei JOSM sollte das nicht die normale Arbeitsweise sein, sondern die absolute Ausnahme (die sichere Variante ist via https://wiki.openstreetmap.org/wiki/API … F0.6.2Fmap alles im zu bearbeitenden Bereich zu laden). Wenn man das verkackt, muss man sich auch nicht wundern wenn dabei Müll rauskommt, da kann auch JOSM nichts dafür.

Last edited by SimonPoole (2021-03-16 18:13:34)

FvGordon · 2021-03-16 19:10:58

Seit einigen Monaten erscheint in JOSM beim Teilen eines Weges, der z.B. zu einer Route-Relation gehört, ein neues Fenster, das fragt, ob einige zusätzliche Mitglieder der Relation heruntergeladen werden sollen. Bejaht man diese Frage (und beantwortet man auch die nächste, ob diese Entscheidung weiterhin angewendet werden soll), werden die beiden an diesen Weg auf beiden Seiten angrenzenden Relationsmitglieder geladen, um die Position zu bestimmen, wo in der Relation das neue Wegstück eingefügt werden soll.

miche101 · 2021-03-16 19:15:09

FvGordon wrote:

, ein neues Fenster, das fragt, ob einige zusätzliche Mitglieder der Relation heruntergeladen werden sollen.

Ja cool ich glaub muss gleich updaten

skyper · 2021-03-16 19:22:36

axelr wrote:

In iD-Bearbeitungen fallen vermehrt Fehler auf..

Richtig, sie fallen auf, ob es daran liegt das es bessere QA und mehr PTv2 gibt oder mehr Menschen sich um Routen kümmern oder ob es ein neues Problem ist, weiß ich nicht.

axelr wrote:

Im iD-Editor werden beim Splitten von Wegen die neuen Wegstücke offensichtlich falsch herum eingesetzt.

+1

axelr wrote:

Im iD-Editor wird vermutlich jede angefasste Relation neu durchgerechnet. Es lassen sich aber nicht alle Relationen automatisch berechnen.
Als Beispiel Bus711 http://www.roeltgen.com/gpx/ibro_ol4ptu … dt=4731670 mit zwei Schlaufenenden. Man kann nur aus Kenntnis der Straßenseite der Haltestellen oder der Haltestellen-Reihenfolge den Fahrweg zusammenstellen.

Uih, das klingt nach Aktionismus mit eher negativem Erfolg. Deckt sich aber zu meiner Beobachtung bei der eine Route mit Schleife komplett umsortiert wurde, obwohl nur ein Weg zerteilt wurde.

SimonPoole wrote:

skyper wrote:
Bei JOSM sind es beim Aufteilen von Wegen zwei Hürden:
1. Die Relationen erst einmal laden.
2. Die benachbarten Wege laden.
....
Nur, auch bei JOSM sollte das nicht die normale Arbeitsweise sein, sondern die absolute Ausnahme (die sichere Variante ist via https://wiki.openstreetmap.org/wiki/API … F0.6.2Fmap alles im zu bearbeitenden Bereich zu laden). Wenn man das verkackt, muss man sich auch nicht wundern wenn dabei Müll rauskommt, da kann auch JOSM nichts dafür.

Ja, sorry, das ist übertrieben und sollte auch nur das Problem von erfahrenen Benutzenden sein. Benachbarte Wege herunterzuladen funktioniert ja sehr zuverlässig, wenn es erlaubt wird. Insgesamt hat JOSM da einige Fortschritte in dem letztem Jahr gemacht. Mal sehen wann die andere Editor-Software nachzieht.

Wenn ich allerdings eine durchschnittliche Überland-Buslinie mit ihren 20-30 Varianten bearbeite, kann ich nicht alles Runterladen. Von einem Abschnitt langer Bundesstraßen, auch wenn es nur zwei bis drei TMC-Segmente sind, ganz zu Schweigen. Mit diesen Problem habt allerdings andere Editor-Software noch mehr zu kämpfen oder sind für solche Objekte nicht geeignet.

Last edited by skyper (2021-03-16 19:24:52)

GerdP · 2021-03-16 19:42:07

skyper wrote:

Wenn ich allerdings eine durchschnittliche Überland-Buslinie mit ihren 20-30 Varianten bearbeite, kann ich nicht alles Runterladen

Ich kann mir nicht so recht vorstellen, wie man z.B. einen Weg trennen kann, ohne sich die Daten im entsprechenden Abschintt komplett zu laden. Das es geht, ist mir klar. Ich würde das nur nicht machen wollen.

skyper · 2021-03-16 20:43:06

Ist Übung und das Verinnerlichen von `Ctrl+Alt+D` vor jedem Aufteilen bzw. Lösen von Linien und Verschieben von Punkten. Vor jeglichem Löschen/Verbinden sowieso. Ist mit dem ganzen Wegen und Haltestellen in einer PTv1 aber nicht weniger nur komplett unübersichtlich und ungenau.

Habe bisher keine Rückmeldungen auf Fehler in Bezug auf Relationen erhalten, aber das mag ja nichts heißen. Vielleicht wurden sie gar nicht entdeckt oder ohne Kommentar verbessert.

Weide · 2021-03-16 22:40:02

skyper wrote:

Es gibt PTv2-Beispiele bei denen Autosortierung schier unmöglich ist, bei diesem einfachen Beispiel bin ich mir nicht sicher. Da ist es eher eine Frage auf was alles geachtet wird. Wenn die Stops in richtiger Reihenfolge und neben der Straße eingetragen sind und auch auf Tags wie `oneway=*` oder gar Abbiegeeinschränkungen geachtet wird, sollte es fast immer klappen.

Ich denke, dass das Beispiel zeigt, dass die Autosortierung bei PTv2 nie gemacht werden sollte. Einen klareren Fall kann eine Autosortierung kaum bekommen und trotzdem war die Reihenfolge vor der Autosortierung richtig und ist danach falsch.

Und wenn wir bei der Autosortierung auch noch die Haltestellenreihenfolge, Oneway-Angaben usw. einbeziehen, dann werden die Fahrwege an die anderen Mappingfehler angepasst, so dass die Fehler nicht mehr auffallen.

Hungerburg · 2021-03-16 22:51:14

So eine Busrelation manuell sortieren, da braucht man einen 72 Zoll Bildschirm dafür.

Weide · 2021-03-17 06:45:03

Hungerburg wrote:

So eine Busrelation manuell sortieren, da braucht man einen 72 Zoll Bildschirm dafür.

Man kann die Relationsteile oder die Relationen bei denen man weiß dass es ein einfacher Fall ist, vom Editor sortieren lassen. Nur das automatische Sortieren ist falsch.

GerdP · 2021-03-17 11:35:48

Ich bin mal ganz ketzerisch: Sind Busrelationen nicht reine Spielerei? Mir kommt das ein bischen vor wie bei der Modeleisenbahn. Man braucht sie nicht, aber man kann sich über die Lösung von Problemen freuen, die man sonst nicht hätte.
Im Ernst: Ich kann mir keine Anwendung vorstellen, die über das Rendern hinausgeht, ohne andere Datenquellen wie Fahrpläne, Tarife etc. einzubinden. Wenn das aber eh nötig wäre, dann sehe ich keinen Bedarf, sich um Reihenfolgen in den OSM Daten zu scheren. Und das soll bitte keine Aufforderung sein, jetzt auch noch Fahrpläne und Tarife in eine PTv4.0 rein zu quetschen.

ToniE · 2021-03-17 12:07:24

GerdP wrote:

man kann sich über die Lösung von Problemen freuen, die man sonst nicht hätte.

Fast wie eine Ehe? Gemeinsam Probleme lösen, die man alleine nicht hat?

GerdP wrote:

Ich kann mir keine Anwendung vorstellen, die über das Rendern hinausgeht

Das scheint wohl für die meisten der Hauptzweck zu sein, aber dafür brauche ich kein PTv2, da reicht eine unsortierte aber vollständige Liste aller Haltestellen und Wege aus.

GerdP wrote:

Ich kann mir keine Anwendung vorstellen, die über das Rendern hinausgeht, ohne andere Datenquellen wie Fahrpläne, Tarife etc. einzubinden.

Wie in #25 dieses Thread schon gesagt: Trufi hat/macht eine App. In wie weit die noch andere Quellen (in Nouakchott, Mauretanien gibt es noch keine Quellen) hinzuziehen könnte ich mal erfragen.

GerdP wrote:

Und das soll bitte keine Aufforderung sein, jetzt auch noch Fahrpläne und Tarife in eine PTv4.0 rein zu quetschen.

Schau mal bei JungleBus vorbei, die machen sowas mit interval, duration, ...auf Basis von PTv2.

Last edited by ToniE (2021-03-17 12:08:33)

miche101 · 2021-03-17 13:21:13

...ja da muss man aber auch sagen das oft das Hauptziel dieser Aktionen ist mit Hilfe von OSM-Daten ein GTFS Datei zu erstellen... welche dann bei Google dann hochgeladen wird um ÖPNV-Routing auf Google Maps zu bekommen, weil der Lokale ÖPNV das nicht selbst macht.

Um dieses Ziel zu erreichen,... braucht es nicht umbedingt PTv2(machmal nur die platformen, highway=bus_stop).. bzw. nur eine Teilmenge, weil auf das Shape kann verzichtet werden.. bzw. lässt sich über routing erstellen

Gruß Miche

Announcement

#26 2021-03-15 14:08:13

Re: Neuer Mapper bearbeitet Busrelationen

#27 2021-03-15 14:20:50

Re: Neuer Mapper bearbeitet Busrelationen

#28 2021-03-15 14:29:38

Re: Neuer Mapper bearbeitet Busrelationen

#29 2021-03-15 16:01:07

Re: Neuer Mapper bearbeitet Busrelationen

#30 2021-03-15 17:05:09

Re: Neuer Mapper bearbeitet Busrelationen

#31 2021-03-16 07:16:13

Re: Neuer Mapper bearbeitet Busrelationen

#32 2021-03-16 10:20:04

Re: Neuer Mapper bearbeitet Busrelationen

#33 2021-03-16 11:30:16

Re: Neuer Mapper bearbeitet Busrelationen

#34 2021-03-16 12:57:12

Re: Neuer Mapper bearbeitet Busrelationen

#35 2021-03-16 13:18:10

Re: Neuer Mapper bearbeitet Busrelationen

#36 2021-03-16 14:41:57

Re: Neuer Mapper bearbeitet Busrelationen

#37 2021-03-16 16:51:44

Re: Neuer Mapper bearbeitet Busrelationen

#38 2021-03-16 17:51:55

Re: Neuer Mapper bearbeitet Busrelationen

#39 2021-03-16 18:13:16

Re: Neuer Mapper bearbeitet Busrelationen

#40 2021-03-16 19:10:58

Re: Neuer Mapper bearbeitet Busrelationen

#41 2021-03-16 19:15:09

Re: Neuer Mapper bearbeitet Busrelationen

#42 2021-03-16 19:22:36

Re: Neuer Mapper bearbeitet Busrelationen

#43 2021-03-16 19:42:07

Re: Neuer Mapper bearbeitet Busrelationen

#44 2021-03-16 20:43:06

Re: Neuer Mapper bearbeitet Busrelationen

#45 2021-03-16 22:40:02

Re: Neuer Mapper bearbeitet Busrelationen

#46 2021-03-16 22:51:14

Re: Neuer Mapper bearbeitet Busrelationen

#47 2021-03-17 06:45:03

Re: Neuer Mapper bearbeitet Busrelationen

#48 2021-03-17 11:35:48

Re: Neuer Mapper bearbeitet Busrelationen

#49 2021-03-17 12:07:24

Re: Neuer Mapper bearbeitet Busrelationen

#50 2021-03-17 13:21:13

Re: Neuer Mapper bearbeitet Busrelationen

Board footer