Neuer Mapper bearbeitet Busrelationen

ToniE · 2021-03-18 13:10:29

GerdP wrote:

Bin ich der einzige, dem schlecht wird bei dem Gedanken, dass noch mehr kaum nachvollziebare PT Daten ins OSM Datenmodel reingequetscht werden soll? Gibt es nicht genau dafür dieses wikidata Tag?

Im Prinzip könnte man sich ja darauf reduzieren, nur die Haltestellen zu mappen ohne dass die Haltestellen in irgendeiner Beziehung zueinander stehen... denn nur die Haltestellen existieren ja. Die Route existiert ja nur "virtuell" durch Auswertung andere Informationen (Fahrpläne).

Dann kommen aber sicherlich einige Leute daher, die dann anmerken, dass man Buslinien nicht mehr auf Karten sehen kann.

Müsste man dann nicht auch so konsequent sein und Rad-/MTB-/Wander-/Ski/...-Routen auch auf deren Hinweisschilder/Wegweiser zu reduzieren?

Seien wir mal realistisch: das simple PTv1-Schema taugt nicht wirklich zu mehr als zum Malen von Buslinie auf Karten. Es taugt nicht einmal für eine einigermaßen brauchbare Qualitätssicherung.

Wenn wir also ernsthaft (im Sinne von "professionell") mit ÖPNV in OSM arbeiten wollen, müssen wir die Komplexität der Realität irgendwie in eine Datenmodell abbilden und deren Daten in eine Datenbank speichern - das "Malen von Karten" ist ab diesem Punkt nur noch Nebensache.

Die Herausforderung besteht darin, die komplexe Realität in ein möglichst einfaches Datenmodell zu packen, das Editieren einfach zu halten, eine einfache Auswertung und Qualitätssicherung zu ermöglichen, ... und den "Kartenmalern" das Leben nicht allzu schwer zu machen (immerhin sind Karten unser Aushängeschild).

PTv2 ist sicherlich nicht das Gelbe vom Ei - sonst hätten wir nicht andauernd solche Diskussionen.

Die Wege aus den Relationen rauszulassen und durch Navigation von Haltestelle zu Haltestelle (ggf. mit Hilfe von 'via'-Punkten) zu ersetzten ist ein guter Ansatz. Ich habe aber schon zwei negative Aspekte gehört: Kartenmaler brauchen eine Routing-Engine und eine Brückensperrung mag zu fehlerhaften Ergebnissen führen.

just my 2 (EUR) ct

Weide · 2021-03-18 13:14:42

GerdP wrote:

Bin ich der einzige, dem schlecht wird bei dem Gedanken, dass noch mehr kaum nachvollziebare PT Daten ins OSM Datenmodel reingequetscht werden soll? Gibt es nicht genau dafür dieses wikidata Tag?

Nö, sehe ich auch so.

Aber das Wikidata-Tag verweist auf Wikidata. Wir müssten was haben, mit dem Apps den dazu passenden Fahrplan im Internet finden können.

skyper · 2021-03-18 13:35:27

GerdP wrote:

Ist alles nur Spaß, oder? Ihr wollt nicht ernsthaft Fahrpläne in OSM abbilden, oder? Wahrscheinlich dann auch noch mit Gültigkeits-Perioden, damit auch irgendwer schauen kann, ob der Bus schon immer am Ostersonntag um 8:10 die Haltestelle in Pusemuckelsdorf ausgelassen hat. Ja klar. Das ist wichtig, aber der 1.4. ist noch ein paar Tage entfernt.

+1, sehr passend.

mmd wrote:

PTv2 ist wahrscheinlich so fragil, weil es zu sehr im Grenzbereich des aktuellen Datenmodells liegt.

Diese Aussage verstehe ich nicht. Eine Sortierung ist doch nicht Grenzgebiet.

Weide wrote:

mmd wrote:
Für PTv2 würde ich dort z.B. Eigenschaften wie "nur Einstieg" oder "nur Ausstieg" unterbringen, statt das irgendwie in die Rolle zu quetschen.
In PTv2 darf man nichts in die Rolle quetschen. Alle Rollen sind klar festgelegt.

+1, zudem funktioniert es doch mit den Rollen für nur Ein- oder Ausstieg.

Weide wrote:

mmd wrote:
wenn man z.B. den Zeitpunkt eines Stops durch Hinzufügen eines Zeitstempels eindeutig macht, also "Stop wird immer nach 00:37 Minuten gemessen ab Startzeitpunkt der Linie angefahren".
Dann bekommen wir zuviele Varianten. Viele Busse haben zu unterschiedlichen Uhrzeiten ein unterschiedliches Timing. Bei Zügen gibt es für eine Variante unterschiedliche Aufenthaltszeiten an wichtigen Umsteigebahnhöfen je nach Timing der anderen Züge.

+1, sehe ich genau so.

mmd wrote:

https://wiki.openstreetmap.org/wiki/API … not_enough

So wie ich dies verstehe geht es hier für PT-Relation nur um den Fahrplan und eine Modellanpassung an diesen.
Warum nicht endlich GTFS aufräumen/verbessern, damit da wenigstens mehr Konsistenz bei den Ids enthalten ist und sich nicht bei nur einer kleinen Änderung alle shape_id und trip_id änder können. Das gleiche trifft zu, wenn eine Variante mal aussetzt. Die alte Id wird nicht entsprechend wieder verwendet, wenn die Variante wieder aufgenommen wird. Das ist alles viel zu kurzlebig gedacht. Ganz zu Schweigen von einem Archiv der alten GTFS-Daten.

Eine Verlinkung mit dem Fahrplan sollte über die Ids jetzt schon möglich sein, nur passe ich die Ids doch nicht alle paar Wochen an, nur weil es eben einen Monat länger keinen Schulverkehr gibt.

Weide wrote:

mmd wrote:
Das war nur ein Beispiel, es geht mir um das Prinzip von der Sortierung der member wegzukommen.
Das ist ein wichtiges Ziel für das nächste PTv.

Verstehe ich nicht. Nur weil die Software die Api nicht richtig unterstützt und auf richtige Reihenfolge achtet.

Weide wrote:

Eine andere Möglichkeit wäre die folgende:
Man unterteilt die Gesamtstrecke durch Markierungsnodes in einzelne Stücke (meist nur eins), die selbstberührungsfrei und selbstkreuzungsfrei und lückenlos oder für Lücken ganz leer sind. Die Reihenfolge innerhalb der Stücke ist dann egal und die Stücke sind automatisch sortierbar. Splitten von Wegen ändert daran nichts. Ein sehr großer Anteil der weiteren heutigen "Kaputtänderungen" wäre so automatisch feststellbar. Fehlende Stücke am Anfang und Ende wären anders als jetzt erstmalig mappbar.

An so etwas habe ich auch schon mal gedacht. Eine Zwischenebene für die Strecke mit Segmenten und die Variante dann ähnlich einer Superroute mit den Haltestelle und den Segmenten. Würde allerdings pro Linie und Richtung jeweils Segmente erstellen und diese nicht für alle Linien auf einer Strecke verwenden, da sonst der Bezug zu den einzelnen Linien schnell verloren geht. An (Bus-)Bahnhöfen wird es etliche Segment-Relationen geben und insgesamt sind es auf jeden Fall noch mehr als bei PTv2.
Habe leider nicht ganz verstanden was Du mit diesen Lücken meinst, wobei ich mir nicht sicher bin, ob leere Relationen gut funktionieren. Ist gar nicht einfach die überhaupt zu finden.

Weide wrote:

miche101 wrote:
ja ich würde die Fahrstrecke ganz weg lassen... das kann man mit Routing machen... dafür bräuchte es machmal nur ein paar Via Punkte.
Man könnte auf die Fahrstrecke verzichten ... kann man auch jetzt schon. Von Routing -- auch mit via-Punkten -- halte ich nichts. Wenn da irgendwo eine Brücke gesperrt wird, dann würde nicht mehr angezeigt, dass die Buslinie nicht mehr stimmt. Statt dessen würde irgendwas plausibel aussehendes aber vermutlich falsches dargestellt, denn der Automat macht bestimmt nicht das, was das Verkehrsunternehmen unter Berücksichtigung möglicher Haltestellenverlegungen und Umsteigemöglichkeiten beschließen wird.
Kleine Mappingfehler bekommen so auch große Folgen wie man bei https://tracker.geops.ch/?z=14&s=1&x=77 … =transport alle paar Minuten an der Linie 5 sehen kann (rasender gelber Punkt).

Halte auch nicht viel von via Punkten und die sind noch anfälliger als Linien, weil hier der Bezug verlören geht. War schon bei TMC-Points ein Grund auch Wege mit in die Relationen aufzunehmen.

skyper · 2021-03-18 13:43:42

Weide wrote:

GerdP wrote:
Bin ich der einzige, dem schlecht wird bei dem Gedanken, dass noch mehr kaum nachvollziebare PT Daten ins OSM Datenmodel reingequetscht werden soll? Gibt es nicht genau dafür dieses wikidata Tag?
Nö, sehe ich auch so.

+1, vor allem dieser Ansatz.

Weide wrote:

Aber das Wikidata-Tag verweist auf Wikidata. Wir müssten was haben, mit dem Apps den dazu passenden Fahrplan im Internet finden können.

Ja, das ist wohl eher das Problem, möglichst langlebige Ids der einzelnen Varianten zu erzeugen, die sich nicht weil Fasnet ausfällt oder die Schulferien zwei Tage früher beginnen ändern. Bei der Wiederaufnahme nach Schienenersatzverkehr ist es häufig das gleiche. Das ist aber eher Aufgabe der Verkehrs-Unternehmen.

skyper · 2021-03-18 14:10:36

Mammi71 wrote:

Ganz ehrlich: seit PTv2 bin ich raus aus dem ÖPNV-Mapping. Außer Haltestellen trage ich in diesem Bereich nichts mehr bei, und die sind auch nicht in irgendwelche Relationen eingebunden, sondern maximal standalone. Und wenn ich diesen thread so lese fühle ich mich bestätigt.

Schade, das Du mit den Relationen nichts anfangen kannst. Wo ist das Problem. Ich empfinde PTv2 als einfacher, da es nicht eine Mammut-Relation ist, sondern jede Variante ersichtlich und klar strukturiert ist.

Haltestellen zu erfassen und zu überprüfen ist aber eine Hauptaufgabe. Brauche meist für die Haltestellen genauso lange wie für das Erstellen der 20 Relationen danach.

miche101 wrote:

Mammi71 wrote:
Und die Gefahr vor Augen, irgendwo was versehentlich kaputt zu machen, schränkt mich auch in den weiteren Mapping-Tätigkeiten zunehmend ein. Ich glaube, auf Dauer bekommt das dem Projekt nicht so gut, wenn immer alles komplizierter wird. Das schreckt neue Mapper zunehmend ab.
Keine Angst, keine Angst... Jeder macht Fehler oder ist vielleicht mit der Situation überfordert.

+1, im Zweifel doch einfach hier mal nachfragen ob es korrekt ist.
PTv2 ist wenigstens für die Software einfacher als PTv1. Warum schreckt es ab? Liegt es an der fehlenden Unterstützung der Editor-Software?

miche101 wrote:

Ich sag einmal so... Die Straßen Daten gehen vor und wenn einer mit dem Relationen überfordert ist dann soll das nicht verhindern z.b. den Kreisel einzuzeichnen. Dann ist es OK ein Loch in die Relationen hinein zu reißen.
Mir persönlich graust es schon weil in Poing ein neuer Kreisel geplant ist... Wo 13 Relationen aus der einen, 10 auf der anderen und 5 auf der letzten Straße sind

Das JOSM-Plugin "pt_assistant" bietet dafür eine Funktion an. Bin mir nur nicht sicher wie weit es mit geteilten Auf- bzw Abfahrten klar kommt.

miche101 · 2021-03-18 16:04:18

Weide wrote:

historische Daten heranziehen.

Ja das wäre toll... ist momentan schwer bis unmöglich die Sache anzuschauen wie sie vor der Zerstörung war.. oder gar rückgängig zu machen.

Weide wrote:

Router den Zug genauso bekloppt fahren lassen

Sonderfall beim Zug der über mehreren Ebenen fährt... man braucht ja nicht alles umstellen aber Bus wäre ein anfang... da ändert sich auch regelmässig was und gibt es wesentlich mehr varianten.

miche101 · 2021-03-18 16:07:53

skyper wrote:

PTv2 ist wenigstens für die Software einfacher als PTv1.

Welche Software? außer Editoren, Renderer. OSMand mit dem versucht Öpnv routing ohne Timetable???

ghostrider44 · 2021-03-18 17:46:09

Nachdem das von mir eingestellte Thema doch erhebliche Ausmaße angenommen hat und der Mapper nach dem Umstieg auf JOSM und einigen Tipps die Relationen nicht mehr beschädigt, sondern nach wenigen Tagen schon in der Lage ist, veraltete Relationen zu verbessern und neue anzulegen, sollten wir die Probleme zum Erstellen einer PTv2-Relation nicht größer machen, als sie sind. Die Überschrift zum Thema habe ich deshalb geändert von "beschädigt" auf "bearbeitet", da sie ja so nicht mehr zutraf.

Weide · 2021-03-18 19:31:11

skyper wrote:

An (Bus-)Bahnhöfen wird es etliche Segment-Relationen geben und insgesamt sind es auf jeden Fall noch mehr als bei PTv2.
Habe leider nicht ganz verstanden was Du mit diesen Lücken meinst, wobei ich mir nicht sicher bin, ob leere Relationen gut funktionieren. Ist gar nicht einfach die überhaupt zu finden.

Keine Segmentrelationen! Das hab ich früher irgendwann mal vorgeschlagen und ausgearbeitet, aber beim Ausprobieren auf eigenem Datenbestand hat sich das als zu kompliziert gezeigt. Ich bin inzwischen nicht mehr für Segmentrelationen.

Im obigen Vorschlag gibt es keine zusätzlichen Relationen. Es gibt nur Nodes, die komplizierte Fahrwege in einfache Abschnitte aufteilen. Diese Abschnitte haben keine Schleifen oder Selbstberührungen und keine Lücken und gehen immer vom letzten Markierungsnode zum nächsten. Sie können daher immer automatsch richtig sortiert werden. Splitten von Wegen wird einfach. Viele andere Fehler wie Kürzen eines Weges ohne Beachtung der Relation oder Längssplitten eines Weges ohne Rücksicht auf die Relation werden dabei zu automatisch erkennbaren Fehlern. Mit zwei unmittelbar aufeinanderfolgenden Nodes wird ein leeres Stück angegeben. Bei einfachen Buslinien würde man mit einem Anfangsnode und einem Endnode auskommen ... mehr Markierungsnodes braucht man nur bei komplizierten Wegführungen.

skyper · 2021-03-18 19:40:12

ghostrider44 wrote:

Nachdem das von mir eingestellte Thema doch erhebliche Ausmaße angenommen hat und der Mapper nach dem Umstieg auf JOSM und einigen Tipps die Relationen nicht mehr beschädigt, sondern nach wenigen Tagen schon in der Lage ist, veraltete Relationen zu verbessern und neue anzulegen, sollten wir die Probleme zum Erstellen einer PTv2-Relation nicht größer machen, als sie sind. Die Überschrift zum Thema habe ich deshalb geändert von "beschädigt" auf "bearbeitet", da sie ja so nicht mehr zutraf.

Das nenne ich mal "happy news". Eventuell ist JOSM und PTv2 für manche Personen doch nicht so schwer zu lernen.

skyper · 2021-03-18 19:52:12

Weide wrote:

skyper wrote:
An (Bus-)Bahnhöfen wird es etliche Segment-Relationen geben und insgesamt sind es auf jeden Fall noch mehr als bei PTv2.
Habe leider nicht ganz verstanden was Du mit diesen Lücken meinst, wobei ich mir nicht sicher bin, ob leere Relationen gut funktionieren. Ist gar nicht einfach die überhaupt zu finden.
Keine Segmentrelationen! Das hab ich früher irgendwann mal vorgeschlagen und ausgearbeitet, aber beim Ausprobieren auf eigenem Datenbestand hat sich das als zu kompliziert gezeigt. Ich bin inzwischen nicht mehr für Segmentrelationen.
Im obigen Vorschlag gibt es keine zusätzlichen Relationen. Es gibt nur Nodes, die komplizierte Fahrwege in einfache Abschnitte aufteilen. Diese Abschnitte haben keine Schleifen oder Selbstberührungen und keine Lücken und gehen immer vom letzten Markierungsnode zum nächsten. Sie können daher immer automatsch richtig sortiert werden. Splitten von Wegen wird einfach. Viele andere Fehler wie Kürzen eines Weges ohne Beachtung der Relation oder Längssplitten eines Weges ohne Rücksicht auf die Relation werden dabei zu automatisch erkennbaren Fehlern. Mit zwei unmittelbar aufeinanderfolgenden Nodes wird ein leeres Stück angegeben. Bei einfachen Buslinien würde man mit einem Anfangsnode und einem Endnode auskommen ... mehr Markierungsnodes braucht man nur bei komplizierten Wegführungen.

Ah, danke. Nach erneutem Lesen habe ich es verstanden, auch wie Du das mit Lücken meinst. Für die Markierungsnodes bräuchte es noch eine Rolle und Anfang und Ende ist beim Straßenverkehr ja schon mit der stop_position abgedeckt. Beim Zug ist das ja Ansichtssache.

Für JOSM wäre dafür dieses Ticket interessant: https://josm.openstreetmap.de/ticket/18645

Last edited by skyper (2021-03-18 20:13:28)

skyper · 2021-03-18 20:33:09

miche101 wrote:

Weide wrote:
Router den Zug genauso bekloppt fahren lassen
Sonderfall beim Zug der über mehreren Ebenen fährt... man braucht ja nicht alles umstellen aber Bus wäre ein anfang... da ändert sich auch regelmässig was und gibt es wesentlich mehr varianten.

Wie bitte? Hast Du mal Beispiele? Sehe eher das Gegenteil:

1. RE 7 https://ptna.openstreetmap.de/gtfs/DE/t … -T07-j21-1
2. S1 schon im GTFS zerlegt:
* S1 https://ptna.openstreetmap.de/gtfs/DE/t … 01-F-j21-1
* S10 https://ptna.openstreetmap.de/gtfs/DE/t … 10-F-j21-1
* S11 https://ptna.openstreetmap.de/gtfs/DE/t … 11-F-j21-1

miche101 wrote:

skyper wrote:
PTv2 ist wenigstens für die Software einfacher als PTv1.
Welche Software? außer Editoren, Renderer. OSMand mit dem versucht Öpnv routing ohne Timetable???

Beim Renderer ist die Frage was dargestellt werden soll, aber generell sind strukturierter Daten einfacher zu Verarbeiten. Die Fehleranalyse und PTNA hast Du z.B vergessen. Welche Software kommt den besser klar mit PTv1 anstatt PTv2?

miche101 · 2021-03-18 21:02:08

skyper wrote:

Wie bitte? Hast Du mal Beispiele? Sehe eher das Gegenteil:

Ich weiß nicht was du verstanden hast.. Aber beim Routing arbeitet man lat/lon... Wenn die Wege aber übereinander liegen kann es zu Problemen. Da müsste man noch den Layer angeben um das zu umgehen zu können

skyper wrote:

Fehleranalyse

Stimmt... Aber gibt's eine nützliche Anwendung von ptv2? Ptv1 war und ist gut zum Karte rendern... Das genügte dann auch

Weide · 2021-03-19 06:20:04

skyper wrote:

... und Anfang und Ende ist beim Straßenverkehr ja schon mit der stop_position abgedeckt. Beim Zug ist das ja Ansichtssache.

Die stop_position ist in PTv2 nie verpflichtend vorhanden ... Platform alein reicht ja auch.

Aber ich würde das sowieso nur als Konzept für das nächste PTv sehen und dann auch die Zweiteilung stop-platform rauswerfen. Wir brauchen nur die Anfangs- und Endangaben für das Routing der Passagiere vor und nach Benutzung des ÖPV. Passagiere in diesem Sinn sind Fußgänger, Radfahrer, Rollstuhlfahrer und bei Fähren sogar Autos. Solche Objekte wären meist die jetzigen Platforms, können aber auch mal erheblich davon abweichen (Ich hatte mal einige hundert Meter zwischen der Stelle zu der ich gehen musste und der Stelle an der die Fähre dann abfuhr ... wir wurden als Herde per Bus zum Kai gekarrt. Ständig passiert das z.B. in Schweden bei vielen Busstationen, bei denen man am Bussteig nicht warten kann und darf. Man wartet im Gebäude bis der Busfahrer die Türen des Busses und die Gebäudetüren öffnet und der Bussteig fungiert nur als Fußweg.)

Neuwessi11 · 2021-03-19 20:50:54

Hallo!
Ich möchte nochmal zu dem anfangs angesprochenen Problem zurückkommen, da ich neu hier bin (ein freundliches "Guten Abend!" in die Runde), mich hauptsächlich mit dem Ergänzen und Korrigieren von diversen maxspeeds und lanes befasse (das schien mir bis heute vormittag auch recht einfach und intuitiv zu sein) und von einem Kollegen darauf hingewiesen wurde, dass dabei wegen der öfter mal notwendigen Wegteilungen Fehler bei den Buslinien entstehen können.

Viele der hier gerade geführten Diskussionen fand ich ziemlich faszinierend, aber für mich als Einsteiger definitiv einige Level zu hoch.
Deshalb möchte ich mal ganz konkret die simple Einsteiger-Frage in die Runde werfen:
Was kann ich denn nun abgesehen von der rocket sience machen, damit eine simple Wegteilung nicht alle betroffenen Buslinien zerstört? Ich will doch nur turn:lanes und maxspeeds eintragen ...
Grüße!
Neuwessi11

SafetyIng · 2021-03-19 22:47:35

Neuwessi11 wrote:

Was kann ich denn nun abgesehen von der rocket sience machen, damit eine simple Wegteilung nicht alle betroffenen Buslinien zerstört? Ich will doch nur turn:lanes und maxspeeds eintragen ...

So wie ich den #40 verstanden habe: Anstatt ID eher JOSM verwenden (ich habe bisher keine direkten Erfahrungen dazu, kann mich also nur an den Vorrednern orientieren)

Weide · 2021-03-20 07:23:33

FvGordon wrote:

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.

Leider wird dadurch das Problem nicht vollständig beseitigt.
Beispiel: Läd man die Relation 9197409 und splittet den Weg 26516141, dann fehlen danach immer noch beide angrenzenden Wege der Relation 1721547 und damit ist das Einfügen der neuen Wege dort genauso zufällig wie vorher. (Oder mein JOSM ist zu alt...)

Es bleibt daher dabei:
- den zu splittenden Weg auswählen
- seine beiden Endpunkte zusätzlich auswählen
- ALT-CTRL-D tippen ("Eltern laden")
- dann erst splitten

FvGordon · 2021-03-20 07:57:36

Weide wrote:

Leider wird dadurch das Problem nicht vollständig beseitigt.

Mit Version 17428 von JOSM oder höher (seit 1. Januar 2021) doch. Wie ich oben geschrieben habe, gibt es jetzt folgendes Verhalten bei JOSM:
Ich lade nur den Weg 26516141 (er besteht aus drei Knoten) und teile ihn am mittleren Knoten. Es kommt dann die Feststellung von JOSM in einem neuen Dialog-Fenster, dass dieser Weg von 9 Relationen verwendet wird und weitere Daten heruntergeladen werden müssen. Bestätigt man diese und die nächste Frage, werden die mit den Endknoten dieses zu teilenden Weges verbundenen Wege nachgeladen, um das neue Wegstück korrekt in die Relationen einsortieren zu können.

GerdP · 2021-03-20 09:36:36

FvGordon wrote:

Mit Version 17428 von JOSM oder höher (seit 1. Januar 2021) doch

Nö, leider nicht. Das in #92 beschriebene Problem besteht nach wie vor und ist auch bekannt.

Weide · 2021-03-20 10:53:06

FvGordon wrote:

Ich lade nur den Weg 26516141 ...

Wenn Du den Weg explizit lädst, dann bekommt Du seine Relationen ebenfalls und sobald die alle da sind reicht die neue JOSM-Eigenschaft aus. Wenn man den Weg aber nur indirekt läd (durch Laden der Relation 9197409), dann tritt der beschriebene Effekt auf.

GerdP · 2021-03-20 11:57:13

Das Problem tritt auf, wenn man mit unvollständigen Daten arbeitet und sich darauf verlässt, das der Editor trotzdem irgendwie auf die Idee kommt, dass es Relationen geben könnte, die von der Aktion betroffen sind. Es gibt diverse Methoden, in diese Falle zu tappen, und diverse Versuche seitens der JOSM Entwickler, diese fehlerträchtige Arbeitsweise zu durchschauen. Es gibt aber auch den Wunsch, nicht mehr Daten zu laden als nötig. Da beist sich die Katze in den Schwanz.
Witzigerweise arbeiten anscheinend gerade die PT-Relationsexperten gerne mit unvollständigen Daten und womöglich noch mit verschiedenen lokalen Versionen in mehreren Relations-Editor-Popups. Ich gerate schon in Stress, wenn ich ein solches Popup aufhabe und dann feststelle, dass ich einen Weg auftrennen muss. Ich geh da auf Nummer sicher: Ich mache dann das Popup zu, trenne den Weg, und mach das Popup evtl. wieder auf. Kostet mich viellecht drei Sekunden, erspart mir aber alle möglichen Dateninkonsistenzen.

Weide · 2021-03-20 12:42:15

GerdP wrote:

... diese fehlerträchtige Arbeitsweise zu durchschauen.

Moooooment ... würde der Editor die vorher nicht geladene Relation nicht anfassen, dann könnte man das so sagen. Aber er stellt beim Abspeichern fest, dass auch diese bisher nicht geladene Relation auch von den Änderungen betroffen ist und versucht sie passend vollautomatisch und ohne Rückfragen zu ändern und macht dabei Fehler. Das ist ein Fehler des Editors.

GerdP · 2021-03-20 12:46:41

Passiert das bei JOSM? Wenn ja, gibt es dazu ein Ticket?

skyper · 2021-03-20 13:06:35

Neuwessi11 wrote:

Was kann ich denn nun abgesehen von der rocket sience machen, damit eine simple Wegteilung nicht alle betroffenen Buslinien zerstört? Ich will doch nur turn:lanes und maxspeeds eintragen ...

Ich kenne mich nur mit JOSM aus, von der anderen Editor-Sortware bekomme ich nur Probleme mit, daher meine subjektive Wahrnehmung: Benutze JOSM !

In JOSM bedarf es dann nur darauf zu achten immer innerhalb des Bereichs der komplett heruntergeladenen Daten zu arbeiten. Der Bereich außerhalb wird im Allgemeinen mit diagonaler Streifen gekennzeichnet. Zumindest ein Punkt eines Weges muß innerhalb dieses Bereichs sein. Einzige Möglichkeit, dann noch was kaputt zu machen ohne nicht auch mit auf die Software zeigen zu können ist, einen Punkt von außerhalb nach innerhalb zu verschieben (nie eine gute Idee) und dann zu Teilen.

Wenn Du schon bei Fahrspuren bist, setzte doch doch auch gleich noch `change:lanes[:(forward|backward|both_ways]=*`. Gibt ja auch eine zusätzliche Objektvorlage und mehrere, zusätzliche Darstellungen für Fahrspuren.

Viel Spaß beim Mappen.

ToniE · 2021-03-20 13:30:02

Neuwessi11 wrote:

Was kann ich denn nun abgesehen von der rocket sience machen, damit eine simple Wegteilung nicht alle betroffenen Buslinien zerstört? Ich will doch nur turn:lanes und maxspeeds eintragen ...

Auch ich nutze JOSM und habe mir angewöhnt:

- lade den Weg (genauer: dessen Umgebung), den du teilen willst komplett (+2 m rechts, links, vorne, hinten) herunter, so dass er nirgends in den gestreiften Bereich hineinragt.

Dann hat JOSM die Chance die Position des neuen Ways in der Reihenfolge aller betroffenen Relationen einzuschätzen.
Sollte er dabei Fehler machen: sollten wir ein Ticket erstellen.

Last edited by ToniE (2021-03-20 13:35:40)

Announcement

#76 2021-03-18 13:10:29

Re: Neuer Mapper bearbeitet Busrelationen

#77 2021-03-18 13:14:42

Re: Neuer Mapper bearbeitet Busrelationen

#78 2021-03-18 13:35:27

Re: Neuer Mapper bearbeitet Busrelationen

#79 2021-03-18 13:43:42

Re: Neuer Mapper bearbeitet Busrelationen

#80 2021-03-18 14:10:36

Re: Neuer Mapper bearbeitet Busrelationen

#81 2021-03-18 16:04:18

Re: Neuer Mapper bearbeitet Busrelationen

#82 2021-03-18 16:07:53

Re: Neuer Mapper bearbeitet Busrelationen

#83 2021-03-18 17:46:09

Re: Neuer Mapper bearbeitet Busrelationen

#84 2021-03-18 19:31:11

Re: Neuer Mapper bearbeitet Busrelationen

#85 2021-03-18 19:40:12

Re: Neuer Mapper bearbeitet Busrelationen

#86 2021-03-18 19:52:12

Re: Neuer Mapper bearbeitet Busrelationen

#87 2021-03-18 20:33:09

Re: Neuer Mapper bearbeitet Busrelationen

#88 2021-03-18 21:02:08

Re: Neuer Mapper bearbeitet Busrelationen

#89 2021-03-19 06:20:04

Re: Neuer Mapper bearbeitet Busrelationen

#90 2021-03-19 20:50:54

Re: Neuer Mapper bearbeitet Busrelationen

#91 2021-03-19 22:47:35

Re: Neuer Mapper bearbeitet Busrelationen

#92 2021-03-20 07:23:33

Re: Neuer Mapper bearbeitet Busrelationen

#93 2021-03-20 07:57:36

Re: Neuer Mapper bearbeitet Busrelationen

#94 2021-03-20 09:36:36

Re: Neuer Mapper bearbeitet Busrelationen

#95 2021-03-20 10:53:06

Re: Neuer Mapper bearbeitet Busrelationen

#96 2021-03-20 11:57:13

Re: Neuer Mapper bearbeitet Busrelationen

#97 2021-03-20 12:42:15

Re: Neuer Mapper bearbeitet Busrelationen

#98 2021-03-20 12:46:41

Re: Neuer Mapper bearbeitet Busrelationen

#99 2021-03-20 13:06:35

Re: Neuer Mapper bearbeitet Busrelationen

#100 2021-03-20 13:30:02

Re: Neuer Mapper bearbeitet Busrelationen

Board footer