• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

BUG: <tmpl_var name=NAME>

Inder

Inder

Geowizard
Wurde in letzter Zeit etwas am Zeichensatzhandling verändert?

Wenn ich einen Cache mit Bindestrich im Namen (z.B.: GC1YXAD) mittels Template-Funktion <tmpl_var name=NAME> exportiere, dann wird der Bindestrich zu einem nicht-ASCII-Zeichen umgewandelt und die resultierende GPX vom POI-Loader nicht akzeptiert.

Kann ich das eventuell mit den badchars vermeiden? Hier habe ich schon versucht, das ungültige Zeichen oder den Bindestrich einzusetzen. Beides hat nicht geklappt.

N.B.: wie wäre die korrekte Syntax um mehrere Zeichen auszuschließen?
ich habe aktuell: <tmpl_par name="badchars" value=",">
<tmpl_par name="badchars" value=",""§""%"> oder <tmpl_par name="badchars" value=",§%"> oder <tmpl_par name="badchars" value=",";"§";"%"> ????
 
OP
Inder

Inder

Geowizard
Noch ein paar Beispiele:

<name>GC158V4 U/s MSC 2 Münchner Stammtisch Cache 08/2007 1.5/1.0</name>
<name>GC1RPDT U/s Der Bädercache 07 Südbad München 1.5/1.5</name>
<name>GC1QTTN U/m Sempt-Kette 7 Bonus 2.5/2.0</name>
<name>GC1QTQ0 T/m Sempt-Kette 1 Start 1.0/1.0</name>

Und ein Sonderfall: die beiden nicht darstellbaren Zeichen (Vierecke) unterscheiden sich von oben und auch untereinander:

"11.381720,""48.137250"",""GC17CB4 T/s Coin-Hotel Tränenreicher Abschied 1.0/1.0"""
 
OP
Inder

Inder

Geowizard
Help! Hat keiner eine Idee, was da faul sein könnte?

Aktuell kann ich meine Caches nicht aufs GPS exportieren, da der POI-Loader die Dateien nicht akzeptiert.
 
OP
Inder

Inder

Geowizard
Template:
<#-- CSV -->
<#-- Codecs: ASCII, UTF8 -->
<tmpl_par name="charset" value="ASCII">
<#-- some chars should not appear in the cachename -->
<tmpl_par name="badchars" value=",">
<#-- newline: CR, LF, CRLF -->
<tmpl_par name="newline" value="CRLF">
<tmpl_loop cache_index>
<tmpl_var name=LON>,<tmpl_var name=LAT>,"<tmpl_var name=WAYPOINT> <tmpl_var name=SHORTTYPE>/<tmpl_var name=SHORTSIZE> <tmpl_var name=NAME> <tmpl_var name=DIFFICULTY>/<tmpl_var name=TERRAIN>",,<tmpl_var name=TYPE><br />
<tmpl_if DECRYPTEDHINTS>
<tmpl_par name="newline" value="CRLF">
<tmpl_var name=LON>,<tmpl_var name=LAT>,"<tmpl_var name=WAYPOINT> HINT","<tmpl_var name=DECRYPTEDHINTS>",HINT<br />
</tmpl_if>
</tmpl_loop>


Ich hatte vorher eine etwa 6 Wochen alte NB (genaue Version weiß ich nicht mehr). Damit ging es problemlos. Mit der 2274 NB ist der Fehler da. 2295 NB habe ich soeben getestet: auch fehlerhaft.

Ich habe den Verdacht, dass mit der Umstellung des Datenbankformates auch das Handling der Sonderzeichen beim Export geändert wurde.
 
OP
Inder

Inder

Geowizard
Noch einer mit einer vierten Variante der Sonderzeichen:

"11.310600","48.086680","GC1Q443 T/m Kilpikonnas Castle 1.0/1.5"


Wenn ich alle genannten Varianten der nicht ASCII-Zeichen mittels Editor suchen und ersetzen lasse, dann ist die exportierte CSV-Datei wieder brauchbar. Das nervt aber auf Dauer ziemlich.
 
OP
Inder

Inder

Geowizard
Ich habe es mir gerade in Hex angeschaut:

Aus dem Bindestrich wird Hex 13, aus dem Tief-/Hochkomma 1E und 1C, aus ' wird 19 beim Export


Ich habe jetzt vorübergehend sed.exe benutzt und mir ein Script erzeugt, das vor der Weiterverarbeitung die Non-Asciis jetzt wieder durch passende Ascii-Zeichen ersetzt. Nicht schön, aber funktioniert zumindest.
 
arbor95

arbor95

Geoguru
Deine Aussage, dass das schon mal richtig war ist vermutlich falsch. Ich bin dabei das zu analysieren. Dann kommt der Fix auch bald!
 
MiK

MiK

Geoguru
Z.B. bei GC1QTTN sieht man, dass das kein normaler Bindestrich ist. Wenn man sich die Hex-Darstellung des HTML anschaut sieht man, dass sich der erste und der zweite Bindestrich unterscheiden. Der zweite ist kein normales ASCII-Zeichen.
 
MiK

MiK

Geoguru
Ja, sowas in dieser Richtung. CW macht ein – daraus.
Die Frage ist, ob man eine Handvoll davon sonderbehandelt und "entsprechende" ASCII-Zeichen daraus macht, oder eher alle weglässt.
 
arbor95

arbor95

Geoguru
Wie geschrieben : Das war schon immer so!
Wir müssen neben den bisherigen Möglichkeiten UTF8 und ASCII weitere Konvertierungen definieren.
Eine wäre z.b. SafeXML .
Die Ausgabe sähe dann so aus:

011.31060,48.08668,"GC1Q443 T/m Kilpikonna’s Castle 1.0/1.5",,Traditional Cache
011.31060,48.08668,"GC1Q443 HINT","Der Name ist Programm",HINT
011.92150,48.34757,"GC1QTQ0 T/m Sempt-Kette 1 – Start 1.0/1.0",,Traditional Cache
011.92150,48.34757,"GC1QTQ0 HINT","Geländer links Busch Kniehöhe",HINT

Wenn du damit was anfangen kannst? (Das ist schnell imlpementiert)

Der jetzige ASCII Konverter macht aus Zeichen mit dem Wert > 127 Zeichen in Zeichen mit dem Wert < 127, was ein korrekter Wert für ASCII ist. Allerdings mag dein Importer es wohl nicht, wenn der Wert dieser ASCII Zeichen < 32 wird.

Eine andere pragmatische Lösung alle nicht ASCII-Zeichen durch ein Leerzeichen oder den _ zu ersetzen.

Mehr Gehirn muss man für andere Varianten der Umsetzung investieren.
 
OP
Inder

Inder

Geowizard
araber95 schrieb:
Wie geschrieben : Das war schon immer so!
Zum Vergrößern anklicken....

Das kann ich nicht glauben, da der Export mit dem Template und anschließende Konvertierung + POI-Upload von Dezember 2007 bis jetzt problemlos funktioniert hat (http://www.geoclub.de/viewtopic.php?f=40&t=20839). Erst nach dem Update auf die neue NB-Version weigerte sich der POI-Loader plötzlich, diese zu akzeptieren.
Test rückwärts geht leider nicht, da die Datenbank mit dem alten Format doch nicht mehr kompatibel ist.
 
arbor95

arbor95

Geoguru
Inder schrieb:
araber95 schrieb:
Wie geschrieben : Das war schon immer so!
Zum Vergrößern anklicken....

Das kann ich nicht glauben, da der Export mit dem Template und anschließende Konvertierung + POI-Upload von Dezember 2007 bis jetzt problemlos funktioniert hat (http://www.geoclub.de/viewtopic.php?f=40&t=20839). Erst nach dem Update auf die neue NB-Version weigerte sich der POI-Loader plötzlich, diese zu akzeptieren.
Test rückwärts geht leider nicht, da die Datenbank mit dem alten Format doch nicht mehr kompatibel ist.
Zum Vergrößern anklicken....

Da hattest du keine Cache mit diesen Zeichen denke ich! Aber egal, schauen wir vorwärts nach einer Lösung!

Verantwortlich ist der ewe.io.printwriter mit seinem ASCII Codec. Vielleicht ist da irgendwann einen neue Umsetzungtabelle reingekommen (glaub ich aber nicht).
 
arbor95

arbor95

Geoguru
Eine schnelle Lösung wäre auch:
<tmpl_par name="badchars" value=",\W">

Es sind wohl reguläre Ausdrücke für die badchars erlaubt, aber meine Tests waren da nicht immer erfolgreich. Obiges ist auf jeden Fall eine schnelle Lösung, ohne auf ein neues CW warten zu müssen!
 
OP
Inder

Inder

Geowizard
araber95 schrieb:
egal, was ist mit obigem Beispielexport? Kannst du damit was anfangen?
Zum Vergrößern anklicken....

Sieht am Garmin auch nicht wirklich schön aus.

Im Augenblich lasse ich einen Batchjob mit sed.exe zwischen Export und Konvertierung laufen, der die unbrauchbaren Zeichen in ähnliche ASCII umwandelt (also in normale Anführungszeichen, Bindestriche etc.).
Damit habe ich eine Übergangslösung gefunden, die auch wieder automatisiert läuft. Nicht schön, aber funktioniert und gibt ein gutes Ergebnis.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben