Dann ist die Kodierung der CSV-Datei kaputt.
Ganz oben hast du noch geschrieben, dass die aus JOSM exportierte GPX-Datei so was wie
enthält. Ich komm grad etwas durcheinander.
Zumindest wissen wir jetzt, dass ab JOSM bei dir alles klargeht mit Unicode, der Fehler muss davor liegen. Öffne die CSV doch mal mit einem guten Editor (z.B. Atom) und speichere sie ausdrücklich in UTF-8-Kodierung wieder ab.
–ks
…öffne ich die csv-Datei in Atom sind auch hier die in der csv-Datei noch als äöü angezeigten Buchstaben wieder ?in schwarzer Raute…
In welcher Software werden sie denn als äöü angezeigt?
–ks
Sorry,
aber jetzt raucht mir selbst der Kopf. Ich fass das noch einmal zusammen. Ich pflege nodes in OSM über Josm ein. Dies node haben den Tag ref=4711
Dann erstelle ich eine Abfrage über overpass-turbo mit dem csv Ergebnis ref lon lat. Diese Ergebnisse markiere ich, kopiere sie in eine Exceldatei und erstelle eine neue Spalte die sich aus ÜFH und dem Wert aus der ref Spalte ergibt. Nun habe ich eine Datei nach dem Muster
latitude longitude name (der Name ist dann ÜFH 4711).
Diese Datei wird als csv gespeichert. Diese csv Datei öffne ich dann in josm und die Umlaute werden dort sofort als ? dargestellt. Das funktioniert also nicht. Also habe ich folgenden Umweg versucht. Ich der CSV-Datei wird der Name mit U anstatt mit Ü geschrieben. Diese Datei kann ich problemlos in josm öffen und als gpx speichern.Ich öffne diese Datei dann im Editor und lass über den ersetzen Dialog U durch Ü ersetzen. Das klappt. Öffne ich diese Datei in OSMAND habe ich wieder meine Fragezeichen
Ich habe jetzt auch mal die Ursprungs csv-Datei mit den Umlauten in Atom geöffnet. Er gibt an, das es eine utf-8 Kodierung handelt, setzt aber die Umlaute direkt in ? um.
Auch der Weg eine Datei mit U anstatt mit Ü zu erstellen, dann in eine funktionierende gpx-Datei umwandeln und dann die gpx-Datei im Editor öffen und mit dem ersetzen Dialog von U auf Ü zu ändern brachte keinen Erfolg…
Das hier …
… und das …
… lassen mich stark vermuten, dass dein Excel kein sauberes UTF-8 exportiert. Das ließe sich herausfinden, wenn du mal die aus Excel exportierte csv-Datei in einem Hexeditor daraufhin untersuchst, was an einer Stelle steht, an der du ein ä eingegeben hast. Dort müsste C3 A4 stehen.
Eine csv-Datei ist eine simple Textdatei, in der pro Tabellenzeile eine Textzeile steht, wobei die Spalten mit Kommas oder Semikola oder was immer du angewählt hast getrennt werden. Eine Zeile, in der in drei Tabellenspalten je ein ä steht, sieht im Texteditor so aus: „ä,ä,ä“ und im Hexeditor (in UTF-8-Kodierung) so: „C3 A4 2C C3 A4 2C C3 A4“ (2C ist das Komma; ein Semikolon wäre 3B).
–ks
ich habe eine csv Datei erstellt in der in Zelle A 1 ein einzelnens kleines ä steht und hab diese Datei in einem Hexeditor (Next Soft Hex Editor MX) geöffnet das Ergebnis lautet:0x0 E4 0D 0A. In der Quickinfo dazu steht
Hex-Wert: E4
Dezimalwert: 228
Ascii-Zeichen: ä
Scheint also wirklich ein Kodierungsproblem von Excel zu sein.
Ich dank euch dann ganz herzlich und mach Schluß für heute.
Eindeutig. Excel speichert dann in Windows-1252 (Systemzeichensatz) oder iso-8859-1 ab. Damit ist der Übeltäter gefunden.
Und wenn ich nochmal Microsoft-bashen darf: In LibreOffice werde ich beim csv-Export gefragt, welche Kodierung ich wünsche. Habs gerade getestet. Und da klappt’s auch mit der utf-8-Kodierung des ä 
–ks
Ließe sich rausfinden, wenn du mal ein € kodieren lässt.
hex 80 (dec 128): Windows-1252
hex A4 (dec 164): iso-8859-15
In iso-8859-1 gibt’s das gar nicht.
Hier ist ne Tabelle: https://de.wikipedia.org/wiki/ISO_8859-1#ISO_8859-1_vs._ISO_8859-15_vs._Windows-1252_vs._Unicode
–ks
Ich habe gerade noch eine Excel Einstellung gefunden in der man expliziet das Format ändern kann. Ich habs tatsächlich jetzt von westeuropäisch oder ähnlich auf utf-8 gesetzt. Das Ergebnis in der gpx-Datei ist aber wieder das ?
Ist so.
Das Format innerhalb Excel ist übrigens nicht entscheidend, sondern nur der Dateityp (die Kodierung) beim Exportieren.
Es gibt aber beim “Speichern unter …” bei Dateityp eine ganze Latte von Möglichkeiten (nicht nur csv unter Win-1252), unter anderem als UTF-8-Text (.txt), der ja leicht in .csv umbenannt werden kann.
Möglicherweise einziger Nachteil: Das Trennzeichen ist da ein Tab.
LibreOffice ist da eindeutig besser (s.o.)
es klappt.
Einzelheiten Morgen… 
-snip-
Die Gemeinde erkennt hier aber noch was Wichtiges (für alle, die mit CSV arbeiten):
Ein csv besteht wirklich nur aus den rohen Daten, mehr nicht. Der csv-Export eines ä in der ersten Zelle erzeugt bei mir (in cp1252 kodiert, also Windows Westeuropäisch) eine Datei, die genau zwei Bytes groß ist: das ä selbst (E4) und ein Zeilenumbruch dahinter (0A). Da kommen keinerlei Metadaten mit, insbesondere keine Informationen über Zeichensatz und Zeichenkodierung. Deshalb ist das eher ein Datenexport als eine Datei – darauf angewiesen, dass der Anwender auf anderem Wege erfährt, in welcher Kodierung darin die Zeichen überhaupt vorliegen. Wenn das der öffnenden Software nicht mitgeteilt wird, kann sie nur raten. Beim Übergang von einem System aufs andere sind Fehler absehbar.
In der Datei stehen nämlich keine Ä und keine ß, da stehen nur Einsen und Nullen (die sich auch, in Vierergruppen sortiert, als Hexziffern darstellen lassen, da ist die Zuordnung noch eindeutig). Welche Sequenz von Einsen und Nullen für welches Zeichen steht, besagen Zeichensatz und Zeichenkodierung.
Die Welt wäre so einfach, wenn alle Systeme Unicode verwendeten und dieses beim Schreiben einer Datei in UTF-8 verpackten. Ein Zeichensatz für alle Schriften der Welt, keine Meta-Angaben mehr nötig. Aber leider ist das, wie wir sehen, nicht der Fall 
obwohl es die Idee für Unicode seit 30 Jahren und Unicode in seiner heutigen Form schon seit 22 Jahren gibt. In der IT-Welt einklich eine Ewigkeit.
–ks
Hallo,
hier die versprochene Rückmeldung. Nachdem Kreuzschnabel schon die csv-Prblematik erlautert hat brauch ich nicht mehr viel hinzufügen ;-). Es ist wirklich so wie hier schon geschrieben wurde, obwohl man in excel bei “speichern unter” unter tools und web die Codierung auf utf-8 stellen kann ist der Zeichnsatz wohl doch nicht so wie er sein sollte. Diese auf diese Art erstellten csv-Dateien werden zwar auch im “Atom-Editor” als utf-8 erkannt, im hex-Editor wird aber wie von Kreuzschnabel beschrieben für das ä E4 ausgegeben, somit erscheinen auch unter osmand keine Umlaute. Mein funktionierender Umweg ist nachfolgend beschriebener Zwischenschritt wie von Seichter beschrieben. Nachdem ich die csv-Datei mit Umlauten erstellt habe öffne ich diese im windowseigenen Editor, klicke auf “speichern unter” und wähle unten utf-8 aus (hier steht ursprünglich ANSI). Diese nun so gespeicherte Datei kann ich in JOSM öffnen und direkt wieder als gpx exportieren. Die auf diese Art und Weise erstellte gpx-Datei zeigt auch in osmand Umlaute an.
Vielleicht hilft es ja dem ein oder anderen hier.
Ein kleiner Wermuttropfen bleibt. Öffne ich diese Datei in flopp.net (basiert auch auf osm) erscheint anstatt des Ü ein Leerzeichen…