[gelöst] JOSM zur Bearbeitung selbst erzeugter OSM-Dateien?

cul-de-sac wrote:

Ich habe mir zum Beispiel (per overpass API) eine OSM-Datei mit dem Wiener U-Bahn-Netz erstellt und würde gerne für ein Offline-Kartenprojekt historische Streckenverläufe/Streckenprojekte dazuzeichnen. Wenn ich meine OSM-Datei öffnen will, beschwert sich JOSM über fehlende Versionsdaten (Missing attribute 'version' on OSM primitive with ID xxxxx).

Du musst bei overpass die Meta Daten mit ausgeben, damit JOSM damit arbeiten kann.
Ansonsten sollte das mit JOSM gut funktionieren, wenn Dein Nachfolgeprogramm mit negativen id's zurechtkommt.

JOSM ist ein Editor für u.a. für .osm-Dateien und unabhängig von OSM benutzbar.

Ich empfehle auf jeden Fall

upload="never"

als zusätzliches Attribute im OSM-Header bei Daten, die nicht in die OSM-Datenbank gehören.

Ja, JOSM kann man prinzipiell dazu verwenden, lokal gespeicherte Daten im .osm-Format zu bearbeiten. Ich benutze es z.B., um Testfälle für meine Software zu erstellen.

Den Fehler mit den fehlenden Versionsnummern solltest du umgehen können, indem du die Overpass API bittest, die Metadaten mit auszuliefern. Ich glaube, das Stichwort ist hier "out meta". Alternativ kann man auch recht einfach (z.B. mit Suchen & Ersetzen) in der .osm-Datei fiktionale Versionsnummern ergänzen, aber ich würde es erst mal mit der angepassten Overpass-Anfrage versuchen.

Warum die Einschränkung auf "prinzipiell"? Weil das Programm, mit dem du die bearbeiteten Daten dann weiterverarbeiten möchtest, mit dem JOSM-Dialekt des .osm-Formats klarkommen muss. Außer negativen IDs ist eine Stolperfalle noch das action='delete': Wenn du z.B. etwas löschst, entfernt JOSM das nicht einfach aus der Datei (das ginge über "purge"), sondern merkt nur vor, dass das Objekt gelöscht wurde. Der Grund dafür ist, dass JOSM ja in der Lage sein muss, die Information über die Löschung dem OSM-Server mitzuteilen, wenn die Änderungen irgendwann hochgeladen werden (was bei dir natürlich nie der Fall sein wird).

Tordanik wrote:

Ja, JOSM kann man prinzipiell dazu verwenden, lokal gespeicherte Daten im .osm-Format zu bearbeiten. Ich benutze es z.B., um Testfälle für meine Software zu erstellen.

Ich auch, und wie von skyper erwähnt: upload=never, damit die Daten nich versehentlich bei OSM landen.

Danke euch allen, es funktioniert einwandfrei mit "out meta".
Auch der Hinweis zu upload="never" (mit Anführungszeichen, sonst beschwert sich JOSM) ist sehr hilfreich, der Upload-Pfeil wird gar nicht erst grün:

<osm␣version="0.6"␣upload="never"␣generator="Overpass␣API␣0.7.56.6␣474850e8">

Meine testweise editierte Datei konnte maperitive anstandslos öffnen.
Die Problematik mit dem Löschen von Objekten werde ich im Auge behalten, danke auch für diesen Hinweis. Im Zweifelsfall lösche ich die Daten eben erst später, nach dem Konvertieren zu SVG.

Liebe Grüße
cul-de-sac

"Falschen Alarm" gelöscht

cul-de-sac wrote:

Was mir aufgefallen ist: nach dem Speichern sieht der Beginn der OSM-Datei so aus:

ml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'␣upload='never'␣generator='JOSM'>

Das heißt, JOSM (17013) "verschluckt" das "<?x" von "<?xml". Genauer gesagt, beim ersten Speichern wird die Byte Order Mark entfernt, beim zweiten Speichern das "<?x". Danach nichts mehr.
Maperitive scheint sich daran nicht zu stören und auch JOSM öffnet die so verstümmelte Datei anstandslos!?

Falscher Alarm, es scheint ein Bug meines Editors (UltraEdit) zu sein, der beim Aktualisieren den Dateiinhalt falsch anzeigt.

Sorry
cul-de-sac