[quote="following"]
Prima, vielen Dank! Dann werde ich die Nanos zeitgleich mit dem Serverumzug freigeben, als kleines Zusatzbonbon. Bis dahin könnt ihr sie auf dem alten Testserver ausprobieren.
[/quote]
Super! Vielen Dank!
BTW: Ich habe eben mal einen Nanocache auf dem Testserver angelegt und das GPX gezogen. Darin ist der Nano als Micro deklariert. Soll das so sein?
Ansonsten habe ich mal von Hand auf Nano geändert und OCM kommt super damit klar. Ich habe das GPX auch direkt mal an einen Bekannten geschickt, damit der das durch allerlei Software und Geräte laufen lässt. Mal schauen was er zu berichten weiß...
[quote="Schrottie"]
BTW: Ich habe eben mal einen Nanocache auf dem Testserver angelegt und das GPX gezogen. Darin ist der Nano als Micro deklariert. Soll das so sein?
[/quote]
Ja, ich habe die Befürchtung dass irgendwelche Tools auf die Nase fallen könnten. OX kennt Nanos (Größe 1.0-1.5) und schreibt auch "Micro" in die GPX-Datei. Hmm.
Dann sollten wir es beim GPX so machen wie bisher auch: Direkt am Marktführer orientieren um damit maximale Kompatibilität zu erreichen. Also wie auch Garmin in solchen Fällen Micro ins GPX schreiben und erst wenn GC irgendwann den Nano einführt, die Sache entsprechend anpassen. Das sollte schon so passen und wenn jemand gezielt nach Nanos suchen will, dann tut er das eh über die Webseite bzw. wer größere Datenbestände mit GSAK und Konsorten verwalten will, der wird vermutlich gespeicherte Suchen verwenden und kann Nanos ja schon darin ausfiltern. Somit ist der wirkliche Bedarf, den Nano schon im GPX so zu benennen, eher gering.
[quote="Schrottie"]Dann sollten wir es beim GPX so machen ... in solchen Fällen Micro ins GPX schreiben [/quote]
naja, passt ja im Prinzip - micro heisst ja Filmdösle und kleiner, und kleiner, das sind nanos ja definitiv
Ich hab hier offenbar einen Bug gefunden bei der neuen Nano-Größe. Ich hab gerade einen meiner Caches angepasst auf die neue Größe und der taucht in meiner gespeicherten Suche nach meinen eigenen Caches nicht mehr auf, obwohl der Haken bei "nano" gesetzt ist.
Suche ist diese hier:
http://www.opencaching.de/search.php?searchto=searchbyowner&showresult=1&expert=0&output=HTML&utf8=1&sort=bydistance&orderRatingFirst=0&f_userowner=0&f_userfound=0&f_inactive=1&f_ignored=0&f_otherPlatforms=0&country=&difficultymin=0&difficultymax=0&terrainmin=0&terrainmax=0&cachetype=1%3B2%3B3%3B4%3B5%3B6%3B7%3B8%3B9%3B10&cachesize=1%3B2%3B3%3B4%3B5%3B6%3B7&cache_attribs=&cache_attribs_not=&owner=hcy
Cache ist dieser:
http://www.opencaching.de/viewcache.php?wp=OC88CE
Als die Suche gespeichert wurde, existierte die Größe "nano" noch nicht. Sie sollte zu allen alten gespeicherten Suchen hinzugefügt werden, die vor der Nano-Einführung schon existierten und "micro" oder "sonstige" enthalten. Mal schauen ob ich das hinbekomme, ist etwas knifflig.
Ok, auf dem Produktivsystem (alt und neu) ist es korrigiert; auf dem Testsystem mach ich mir die Mühe nicht.
Es war leider nicht unterscheidbar, welche gespeicherten Suchen vor der Nano-Einführung vor einer Woche angelegt wurden und welche danach. Falls jemand sich in den letzten sechs Tagen eine Suche explizit ohne Nanos angelegt hat (aber mit Micro und/oder Sonstige), sind da nun auch die Nanos mit drin. Bei bislang 5 Nano-Listings sollte sich der Schaden aber aber in Grenzen halten.
Ich hab mir noch doch mal den Ocprop-Quelltext durchgesehen und dort eine Funktion gefunden, die komplettte OC-Cachelistings mit geänderten GC-Listings überschreibt, inklusive der Größe. Demnach darf man diese Ocprop-Funktion bei OC-Nanos nicht verwenden, wenn sie Nanos bleiben sollen.
Hab einen Weg gefunden, um das unabhängig von Ocprop zu lösen. Es betrifft nicht nur Nano, sondern z.B. auch Cachetypen wie Drive-In und Mathe-/Phsikcache - ist also schon ein älteres Problem.
Ocprop identifiziert sich als "user agent", also wir können sehen dass die Daten von Ocprop stammen und dann das Handling für Nanos etc. selbst übernehmen. Wenn auf GC Micro oder Sonstige Größe eingestellt ist, bleibt auf OC Nano stehen etc.
Das ist auch die langfristig bessere Lösung - ist der Code einmal geschrieben, kann man es bequem z.B. an neue Cachetypen anpassen, also wir haben immer unter Kontrolle was Ocprop hier macht. Ich schreib' mal ein Todo, denke das eilt nicht.
Gute Idee. Ich werde HSCA aber trotzdem nochmal diesbezüglich kontaktieren, denn ocprop muss ja eh überarbeitet werden und da können solche Spezialfälle auch gleich bedacht werden.
Die Lösung auf OC-Seite wäre allerdings einfacher (5-10 Codezeilen), sauberer und zukunftssicherer.
Ocprop liest OC-Daten per HTML-Parsing aus, d.h. wenn wir was an den Templates umstricken kann es auf die Schnauze fallen. Das war in der Vergangenheit schon mehrfach der Fall, und es ging in den letzten Jahren nur gut weil die OC-Entwicklung stillstand. Für das vorliegende Problem müsste Ocprop zusätzlich die Cachegröße und den Cachetyp von OC auslesen, also zusätzlichen HTML-Code parsen.
Daher wäre es mir lieber, HSCA nicht darauf ansetzen, bzw. ihm zu schreiben dass wir das nun doch selbst lösen. Dann wissen wir, dass es für immer funktionieren wird, statt uns eine weitere Ocprop-Zeitbombe einzuhandeln.
Gern auch so. Meine Idee wäre nur gewesen, das ocprop so umgebaut wird, das künftig ausschließlich beim ersten Übertragen eines Listings auch die Größe berücksichtigt wird, bei späteren Änderungen jedoch nicht.