Hallo!
Ich habe mit JOSM lokal in einem Stadtplan zahlreiche POIs erstellt, die im “description”-Feld alle einen gemeinsamen Begriff haben.
Jetzt suche ich nach einer Möglichkeit, die Werte (Koordinaten und Tags) all dieser (noch nicht zu OSM hochgeladenen) Nodes auszugeben. Ziel ist eine Excel-Tabelle, die aber auch gerne auf Umwegen erreicht werden kann.
Hat jemand eine Idee, wie ich das elegant bewerkstelligen könnte?
Daten lassen sich aus JOSM heraus im osm (xml), gpx oder json Format ausgeben.
Alle noch nicht hochgeladenen Objekte haben eine id < 0, so dass sich diese leicht aus den übrigen filtern lassen.
Das osm oder gpx Format lässt sich meist mit einigen Textersetzungen in ein csv Format umwandeln.
Das Filtern der POIs müsste durch “description=Stadtkunst” geschehen, denn es sind nicht in jedem Fall neu erstellte Nodes, machmal wurden auch bestehende um den genannten description-Wert ergänzt.
Als Newbee ist mir auch leider nicht klar, wie ich in JOSM für die Ausgabe filtern kann (weder nach description-Tag noch nach ID).
Von XML zu CSV würde ich mir zutrauen. Entscheidend ist das Filtern für den Export.
Neuen Layer anlegen, wieder in den anderen Layer wechseln, gewünschte Objekte auswählen (Suche nach description=Stadtkunst), “Bearbeiten->Auswahl vereinigen” und den neuen Layer als Ziel angeben. Jetzt sind in dem neuen Layer nur die gewünschten Objekte. Den Layer in einem geeigneten Format speichern und dann weiter verarbeiten.
Für mich wäre das einfachste, entweder bei der Wandlung xml->cvs oder im cvs zu filtern.
Danke für die Hilfe. Nun melde ich mich nochmal:
Das Selektieren, Exportieren (XML) und Importieren (Excel) klappt mit der Anleitung von GerdP prima.
Leider ist das Ergebnis noch nicht ganz brauchbar, denn es wird jeder tag in einer eigenen Zeile positioniert und spaltenmäßig nur nach key und value unterschieden. Ziel wäre es, die tag-keys im Spaltenkopf zu haben und die tag-values in der richtigen Spalte zu finden.
Hat jemand eine Idee, wie ich das (in XML oder in Excel) lösen kann? – Ist ein wenig OffTopic, ich weiß 
Wenn Du mit XML das OSM-Format meinst, dann nimm osmconvert --csv
https://wiki.openstreetmap.org/wiki/DE:Osmconvert#Schreiben_von_CSV-Dateien
Wow!
Hat ein bisschen Einarbeitung gebraucht, aber jetzt läuft’s (fast) rund. 
Eine Frage noch: Kann ich die Zeichencodierung bei Ausgabe irgendwie beeinflussen?
Statt Schlo├ƒplatz sollte natürlich Schloßplatz zu stehen kommen – entsprechend bei den Umlauten.
Beim Speichern als .osm meines Wissens nicht, aber Excel sollte inzwischen auch mit utf-8-Kodierung beim Import umgehen können.
Mein Excel 2002 nicht, aber ich habe es mit Libre Office und etlichen Web-Konvertern probiert, leider ohne Erfolg. UTF-8 ist zwar noch die beste Importoption, doch alle Umlaute bleiben maskiert.
Aus JOSM als .osm gespeicherte Daten müssten auf alle Fälle utf8-kodiert sein. Welches sind die Schritte genau bis zur csv-Datei und wie sind ggf. die Zwischenergebnisse kodiert?
Wenn Du mit Windows unterwegs bist, wäre Notepad++ geeignet, die Zeichenkodierung zu prüfen und ggf. zu konvertieren.
Laut notepad++ sind die OSM-Daten UTF-8 codiert. Wenn ich sie - wie von DD1GJ vorgeschlagen - mit osmconvert64 unter Win10 in eine CSV-Datei verwandle, entstehen leider die beschriebenen Maskierungen für äöüÄÖÜß.
Wenn ich die OSM-Datei in notepad++ in eine andere Codierung konvertiere und danach mit osmconvert64 umwandle, entstehen in der CSV-Datei andere Maskierungen, aber leider noch immer keine Klarschrift der fraglichen Umlaute. Probiert habe ich das mit ANSI, OEM-852 und Windows-1250.
Verwendest Du bei osmconvert -o für die Ausgabe oder leitest Du mit > in eine Datei um? Bei ersterem sollte es keine Probleme geben.
Danke, das war das Missing-Link!
Ich hatte in osmconvert gar keine Dateiausgabe angestoßen, sondern das Ergebnis aus dem Fenster der Eingabeaufforderung kopiert.
Mit -o=dateiname.csv entsteht nun eine Datei, die in notepad++ korrekte Umlaute in UTF-8 enthält. Mein altes Excel interpretiert sie zwar immer noch falsch, doch mit den Importoptionen des aktuellen LibreOffice wird die Tabelle korrekt eingelesen.