Das ist schwierig einzuschätzen. Ich hatte z.B. sehr häufig Segmentation Faults, auch an unterschiedlichen Stellen und nicht immer reproduzierbar. Wenn das im regulären Betrieb so nicht vorkommt, könnte das eine Besonderheit der Umgebung sein, oder Wechselwirkungen wg. fehlendem GPS oder zu schnellem Rechner oder sowas in der Richtung.
Ich benutze das zum Entwickeln auch auf meinem Core i7 mit libgps ohne angeschlossenes GPS, das ist stabil. Ich habe gerade noch einen Crash gefunden, wenn man das Anlegen eines Projekts abbricht, aber normalerweise darf da nix crashen. Backtrace per Mail an mich oder ein Issue in GitHub aufmachen.
Hallo mmd,
ich experimentiere gerade mit einem seltenen JOSM Problem beim Löschen von Relationen:
https://josm.openstreetmap.de/ticket/15374
TL;DR: Problem taucht auf, wenn Relation 1234 ein Member von Relation 4711 ist und beide in einem CS gelöscht werden sollen.
Bevor ich da viel Arbeit reinstecke: Macht die hier diskutierte Änderung evtl. die Sortierung auf der Editor-Seite überflüssig?
Anders gefragt: Kann das auf der Server Seite gemacht werden?
Wenn nicht, müsste JOSM (wahrscheinlich auch jeder andere Editor) sich vor dem Upload die Daten zur Hierarchie noch mal vom Server holen und dann anhand dieser Daten sortieren.
Das kommt mir jetzt sehr spanisch vor. Jeder Editor der Relationen unterstützt läuft doch sofort in das Problem rein, dass beim Erstellen von mehreren Relationen die Kindrelationen zuerst und dann die Eltern erstellt werden müssen und beim Löschen umgekehrt sortiert werden muss. Aufwand 12 Zeilen Code. IMHO sollte man mit dem map API call auch alle relevanten Relationen bekommen, sprich nochmals den Server abfragen sollte nicht nötig sein (die Doku ist da etwas unklar).
Was ich im Augenblick nicht automatisch mache, ist bei Schleifen zuerst die Relation aus der Elternrelation entfernen (sollte ich wohl noch).
Simon
Es gibt im JOSM die Zeilen, die es sortieren sollen, bei neuen Rels ist das auch kein Problem. Beim Löschen fehlen aber notwendigen Daten, weil Member nicht nur als gelöscht markiert werden sondern wirklich die Memberliste gelöscht wird. Das jetzt nachträglich zu ändern ist ziemlich knifflig.
Das Problem taucht in der Praxis selten auf, weil JOSM wohl zumeist die Rel mit der kleineren id zuerst löscht. Das passt fast immer.
Wenn ich das richtig sehe wird auch JOSM mit Schleifen nicht zurecht kommen.
Das Löschen von Relationen ist (hoffentlich) eine der ganz wenigen Stellen, an denen das Verhalten der neuen und alten Implementierung voneinander abweichen. Bisher ist es in Rails so, dass jede einzelne Änderung in einer osmChange-Nachricht streng von oben nach unten und Schritt für Schritt abgearbeitet wird. Beim Löschen einer Relation muss dann jeweils geprüft werden, ob sie vielleicht noch in einer anderen Relation als Member enthalten ist. Für Parent-Child-Beziehungen muss also zunächst das Child, und dann erst der Parent aufgeführt werden.
Die neue Implementierung weicht hier dahingehend davon ab, dass geschaut wird, ob eine Menge zu löschender Relationen Abhängigkeiten zu dritten Relationen hat. Das wäre also z.B. ein Grandparent, der auf den Parent zeigt, wobei wir die Parent-Child Relationen löschen wollen. Ist das nicht der Fall, können die Relationen gefahrlos gelöscht werden. Damit lassen sich auch 2 Relationen, die sich wechselseitig referenzieren, in einem Schritt löschen.
Ich hatte im “create” Fall schon eine Logik eingebaut, die die alte Rails Logik nachbildet, also streng von oben nach unten geht. Für den “Delete” war das bisher nicht der Fall. Das ist natürlich etwas unschön, weil dann ein Editor, der sich auf dieses Verhalten verlässt, später nicht mehr mit dem alten Rails Port arbeiten kann. Ich muss mal mit Matt klären, ob wir das auch abklemmen müssen.
Generell ist hier das Problem, dass das gewünschte Verhalten nicht wirklich sauber spezifiziert ist, auf der anderen Seite aber von den Rails-Leuten immer ein exakt gleiches Verhalten eingefordert wird. Ich würde daher dringend empfehlen, gedanklich immer davon auszugehen, dass ein osmChange chronologisch von oben nach unten abgearbeitet wird.
OK, das hatte ich befürchtet. Wenn die CS auch von anderen Programmen verstanden werden sollen, kann man das wahrscheinlich auch nicht mehr ändern, ohne eine höhere api version zu erzwingen.