Probleme nach API-Umstellung

Hallo zusammen,

am Wochenende konnte ich es nicht lassen und habe ein bisschen gemappt. Die Datenbank wurde ja im read-only-Modus betrieben, also konnte ich mir den aktuellen “State of the Map” herunterladen. Ich habe dann meine Änderungen in JOSM durchgeführt und dann in eine OSM-Datei abgespeichert. Ich löse erst die Konflikte auf und versuche dann den Upload. Nach Eingabe eines Kommentars zum Changeset versucht JOSM de Upload, nach vielleicht 40 Sekunden erscheint aber folgende Fehlermeldung:

Mein Changeset 888473 hat im Gegensatz zu anderen Changesets keine Bounding-Box. Hat jemand eine Ahnung, wie ich meine Daten hochgeladen bekomme? Es sind ziemlich viele Änderungen…

Gruß

PS: Ich benutze JOSM Version 1545 SVN.

Änderungen in heruntergeladenen API 0.5 Daten bekommst du nicht in die API 0.6, du musst also nochmal neu anfangen. Das gibt ansonsten Konflikte mit den alten heruntergeladenen Daten. Das war aber lange und nicht erst seit gestern bekannt.

Nur leere 0.5 Daten mit absolut neu gezeichneten Daten welche nicht heruntergeldaen wurden lassen sich hochladen. So hab ich es gemacht.

Dazu muss man folgenden “Trick” anwenden. Die OSM Datei in einem XML Editor öffnen und folgendes tun.

Ganz oben

<osm version='0.5' generator='JOSM'>

in folgendes ändern

<osm version='0.6' generator='JOSM'>

Dann mit suchen und ersetzen alle…

<node
<way
<relation

mit folgendem ersetzen

<node version='1'
<way version='1'
<relation version='1'

Ansonsten bin ich ein bisschen geteilter Meinung. Die Performance wurde heute Abend ja zum Glück besser. Das Laden dauerte heute ewig.

Dann muss man in JOSM unbedingt den Upload anpassen. Der Statusbalken geht sofort auf 100% und es passiert nichts, nur wer JOSM per Kommandozeile startet, sieht im CMD Fenster das überhaupt etwas passiert. Dort zeigt er anlegen des Changesets, Upload, eventuelle Fehler und schließen des Sets an. Leider auch dort keinerlei Fortschritt des eigentlichen Uploads. Der Upload funktioniert im Moment also nur nach Prinzip Hoffnung. Starten, warten und hoffen das es glatt geht. Ich möchte nicht wissen, wieviele JOSM heute entnervt abgeschossen haben und bis zum Bugfix noch abschießen werden. Ohne CMD Fenster und Geduld, sieht das schlicht nach Hänger aus.

Das Changeset ansich ist ganz nett. Der Zwangskommentar eher weniger. Weniger ist manchmal mehr. Man muss nicht jeden mal eben umgesetzen Node kommentieren. Ich sehe schon Listen voller “qwertz” und “asdfg”.

Ich habe meine über das Wochenende lokal zwischengespeicherten, neu erfassten Daten in JOSM aus dem lokalen Layer (V0.5) in den neu heruntergeladenen Layer (V0.6) per Copy&Paste (ging seltsamerweise nur über das Menu, nicht mit STRG+C/V) übernommen. Natürlich müssen dann bestehende Punkte verschmolzen werden, aber ist immer noch einfacher als alles neuzuzeichnen.

Ansonsten stimme ich Mirko bei: Der nicht funktionierende Fortschrittsanzeiger in JOSM sollte dringend wieder so funktionieren wie vorher. Der Kommentar zu den Änderungen ist vielleicht eine gute Idee, aber was bzw. in welcher Form sollte denn dort was eingetragen werden?

Die Performance beim Up-/Download ist inzwischen wieder sehr gut, meinem Eindruck nach sogar besser als ‘früher’.

Schneller ist mit diesem API0.6 misst nichts geworden, ganz im Gegenteil.

Alles kreuzlahm… oder JOSM bekommt überhaupt keine Daten. Beim Upload das selbe wo gestern Upgeloadete Daten nicht angekommen sind. Zumindest seit paar Stunden funktioniert der Forumlogin wieder. Mit diesen Slippymaps stimmt auch was nicht. Teilweise lassen diese sich nicht mehr bewegen und nur ein Zoom In/Out funktioniert noch.

Da ich die Entsprechung aus dem Bereich Softwareentwicklung kenne und in unserem Team für den vernünftigen Umgang damit zuständig war, übertrage ich mal ein paar Faustregeln:

  • Sachen, die nichts miteinander zu tun haben, getrennt reinschieben.
    (Ganz strikt sollte man das bei Sachen beachten, die geographisch weit auseinanderliegen. Wenn man z.B. eine Telefonzelle in Nordfinnland und einen Briefkasten in Südspanien als eine gemeinsame Änderung hinzufügt, dann umfasst die Änderung ein riesiges geographisches Gebiet. Ein Programm, dass die letzten Änderungen für einen Vorort von Hintertupfingen berücksichtigen will, muss dann diese Änderung erst analysieren…)

  • Sachen, die viel miteinander zu tun haben, zusammen reinschieben. Daraus ergibt sich dann ja auch schon ein sinnvoller Text wie etwa “Bushaltestellen in Bonn-Beuel Nord ergänzt/überarbeitet.”

-kleine Korrekturen haben meist keinen sinnvollen Text. Da ist ein einfaches “Korrektur, Schleswig” durchaus passend. Es ergibt keinen Sinn, die geänderten Tags im Text aufzuzählen.

-systematische Korrekturen eines Gebiets sollten die Systematik beschreiben: “Konfessionstags der römisch katholischen Kirchen in Ingolstadt korrigiert”

Schwierig wird es vor allem dann, wenn man die Uploads nicht nach inhaltlichen Gesichtspunkten machen will, sondern halt dann, wenn man gerade Kaffee kochen will … Dann ist es schwer, einen sinnvollen Text zu finden und das ganze System bringt nicht mehr viel.

Das passt nicht wirklich mit der Praxis zusammen. Mal davon abgesehen das selbt Programmierer ihren Code oftmals aus Faulheit nicht sauber kommentieren, wird sich Otto Normal Mapper kaum an irgendwelchen Sets orientieren.

Oft macht man viele Dinge in einem rutsch. Ich sammle z.B. alles und lade es dann in der Nacht hoch. Meist wenn Relationen dazwischen liegen, um die Bearbeitungszeit kurz zu halten und mögliche Fehler durch Paralelarbeiten zu minimieren. Das alles nun in irgendwelche mehr oder minder sinnvolle Sets mit hilfreichen Kommentaren aufzuteilen, artet in sinnloser Mehrarbeit aus. Wenn es gerade passt ist nichts dagegen einzuwenden, ansonsten werde ich das nicht weiter beachten. Manchmal hat man noch den einen oder anderen entfernten Node der mitgehen soll. Dafür ein Extra Set aufmachen ist eher lästig. Für die Kontrolle hat man noch immer ITO. Dort orientiert man sich wirklich nur am ausgesuchten Gebiet und nicht an ganzen Sessions.

Leider klappt das so bei mir nicht.

Da ich doch leider etwas viel am Wochenende getan habe, wäre es schön, ein kleines Konvertierungsprogamm zu Hand zu haben, um die Daten von API 0.5 auf 0.6 zu bringen.

Sonst muß ich wohl in den sauren Apfel beißen…

Es gibt da ein Phyton Script. Ich hatte hier die händische Variante aufgeschrieben, weil das schneller geht als Phyton zu installieren, was die überwältigende Mehrheit wohl nicht standardmäßig auf Kiste haben dürfte.

Das Script macht aber genau das gleiche. Versionsnummer ändern und die Version an die Zeile hängen. Also entweder hast du einen Fehler gemacht oder die Dasten sind kaputt. Ansonsten funktioniert das so einwandfrei.

Hast du auch einen geeigneten XML Editor genommen oder einfach Notepad? Mit Notepad falsch gespeicherte OSM werden geschrottet und nichtmal mehr von JOSM angenommen.

Hab’s natürlich mit dem Notepad gemacht. :frowning:

Werde es dann noch einmal mit einem XML Editor versuchen.

Vielen Dank für die schnelle Antwort.

Auch mit Peter’s XML Editor (version 2.0) klappt es so nicht.

Wenn ich die Versionen API 0.5 und 0.6 vergleiche, so fällt mir als gravierender Unterschied auf:

<osm version='0.6' generator='JOSM'>

Wenn ich dann in einen neuen gesichertem OSM-File (API 0.6) nach z.B.

<node version='1'

suche, dann stelle ich immer fest, diese Textzeile ist nirgends zu finden. Wie gesagt in neuen OSM-Files und nicht in dem alten.

Habe ich da etwas falsch verstanden, oder soll ich schon einmal meinen sauren Apfel holen?!

Es gibt ein JOSM-Ticket zu meinem Problem:
http://josm.openstreetmap.de/ticket/2440

ThorFs Tipp mit Copy-und-Paste hat bei mir leider nicht funktioniert.

Mirkos Tipp trifft leider nicht auf mich zu, da ich auch Verbindungen zu bestehenden Ways habe. Allerdings bin ich skeptisch, ob das Einfügen von “version=1” mein Problem überhaupt lösen könnte, denn mit JOSM im API 0.6-Format gespeicherte Dateien enthalten nicht “version=1” für neue Nodes, Ways und Relationen.

Keine Ahnung was ihr da veranstaltet, aber anscheinend macht ihr irgendwas verkehrt. Wie und was kann ich per Ferdiagnose auch nicht herausfinden. Anstatt mir zu sagen was JOSM verbockt, wäre konkreter Input hilfreich. Also ob das wirklich neue Daten sind und was gemacht wurde.

JOSM schreibt im Moment auch Null als Dateiversion. Was der Speichert ist daher erstmal vollkommen Wurst. Vollkommen 0.6 tauglich ist das ganze noch nichtg. Lade mal eine Datei herunter. Jede Node, Way oder Relationszeile hat an irgendeiner Stelle eine Versionsnummer. Ich habe gestern ein am Wochenende angelegtes File mit knapp 5000 Nodes und 1200 Ways mit obiger Methode erfolgreich Konfliktfrei hochgeladen. Das muss also funktionieren. Die Methode ist auch nicht von mir sondern aus dem Script, dieses stammt von einem aus dem Dev Bereich. Und da die die API verbockt haben, wird der Schreiber des Scripts schon wissen was er macht. Fakt ist, es funktioniert.

Bei dem mit Altdaten vermischten File, würde ich mir keine Hoffnungen machen. Diese Daten sind ja bereits in der DB vorhanden und auf 0.6 konvertiert. Die haben ihre enstprechenden Versionsnummern. Die müsste man den Klonen im entpsrechendem File zuordnen. Sollte keiner mit viel Langeweile ein Tool schreiben, ginge das nur Händisch. In der Zeit sind die Sachen aber schon 3 mal geändert und schneller neu gezeichnet. Also fang lieber gleich nochmal an, deinen Fehler wird dir keiner ausbügeln.

Die OSM-Datei ist hier: http://josm.openstreetmap.de/attachment/ticket/2440/unterrombach.osm.bz2

Kannst Du bitte den Link posten? Ich würde mir das Skript gerne anschauen.

Deine Datei brauche ich nicht. Mit den Altdaten ist das wie schon geschrieben aussichtslos. Das wird keiner Fixen. Schneller gehts das Gebiet nochmal zu saugen und die Änderungen erneut einzutragen. Es wurde ja seit Spätherbst 73 lang und breit erläutert, dass gänderte Altdaten aus der 0.5 nach der Umstellung nutzlos sind. Wer nicht hören will, muss halt fühlen. :smiley:

Hier der Link zum Scrict…
http://lists.openstreetmap.org/pipermail/talk/attachments/20090420/f1f911fb/attachment.bin

Da stehen die selben Aktionen wie oben drin. Nur eben als Python Script verpackt… Nutzt in dem Fall mit den Altdaten aber auch nur nix.