Ich hatte halt festgestellt, dass GpsBabel abbricht, wenn die Eingabedatei Zeichen außerhalb des ASCII-Zeichenvorrats enthält. Daher der vorgeschaltete Schritt mit Perl.

Mmm, ist mir noch nie aufgefallen. Kann das daran liegen, dass ich immer nur kleine POI-Dateien länderweise erzeugt habe? Ich habe es gerade mal mit der aktuellen Europa-Datei versucht, tut ohne Probleme, kein Abbruch.
In deinem Blog schreibst du: "Im ersten Schritt wird die CSV-Datei für die anschliessende Konvertierung mit gpsbabel vorbereitet".
Müsste das nicht "GPX-Datei" heissen?

Ich hatte das Problem letztes Jahr. Damals war ab und zu der lange Bindestrich in den Dateien, was dann zu dem Abbruch von Gpsbabel geführt hat. Jetzt finde ich diesen Bindestrich nicht mehr in den Dateien. Ob der lange Bindestrich von Archie kam oder von mir weiss ich nicht mehr. Ich hatte damals die Archies GPX-Waypoints in QLandkarteGT bearbeitet. Ich weiss nur noch, dass ich ein paar Tage gebraucht habe, um die Ursache einzugrenzen. Ich muss da mal bei Gelegenheit weiter nachforschen.

Ja, danke für den Hinweis. Ich habe gestern von den CSV-Dateien auf GPX umgestellt. Da ist mir das durch die Lappen gegangen.

Update, um Archie und GpsBabel (teilweise) zu entlasten:

Die Archies-Dateien sind reines US-ASCII, ohne Sonderzeichen, auch keine Umlaute, und können daher mit GpsBabel problemlos in eine GPI-Datei konvertiert werden. Bearbeitet man die Archies-Wegpunkte oder erstellt man eine eigene Wegpunktdatei, dann wird die GPX-Datei von QLandkarteGT, QMapShack und wahrscheinlich auch anderen Track-Editoren in UTF8-Codierung gespeichert. GpsBabel übernimmt die Texte, und somit ggf. UTF8-codierte Sonderzeichen eins zu eins in die GPI-Datei. Damit kommt das Garmin, zumindest mein Etrex 30, nicht zurecht und ignorieren die GPI-Datei.