Hallo
Nach längerer Pause will ich mal am GSAK-Makro weiterwerkeln. Aber beim Filtern nach Cachestatus führt "Temporarily unavailable" zu einem Fehler. "Archived" etc. geht problemlos.
"Temporarily unavailable" wird aber direkt als gültiger Status in der OKAPI-Anleitung [url=http://www.opencaching.de/okapi/services/caches/geocache.html]http://www.opencaching.de/okapi/services/caches/geocache.html[/url] genannt. Ich habe auch versucht Space durch "_" zu ersetzen, aber der Fehler ist geblieben. Eine Idee ?
Übrigens habe ich die Makro-Kennung durch eigenen Key wie gewünscht umgestellt. Es sollte sich jetzt bei Abfragen entsprechend anmelden.
Cache-Status "Temporarily unavailable" OKAPI -> Fehler bei Abfrage
Ich kann dir jetzt keine direkte Antwort geben (dazu kenne ich die OKAPI-Interna zu wenig), aber vielleicht ein paar Tips für die Fehlersuche.
Habe ich das richtig verstanden, das du den Status als search-parameter verwendest? Sollte ja an sich gehen. Du schreibst von einer Fehlermeldung, welche denn? Wenn sie nicht sichtbar ist, kannst du die Url, die das Makro intern produziert, auch einfach mal in die Adresszeile im Browser pasten und dann abschicken, dann siehst du die Fehlermeldung auf jeden Fall recht gut.
Ansonsten kannst du die Url ja auch mal hier posten (ohne Keys), vll sehen vier (oder mehr) Augen ja mehr las zwei.
HTH
ra_sch
Habe ich das richtig verstanden, das du den Status als search-parameter verwendest? Sollte ja an sich gehen. Du schreibst von einer Fehlermeldung, welche denn? Wenn sie nicht sichtbar ist, kannst du die Url, die das Makro intern produziert, auch einfach mal in die Adresszeile im Browser pasten und dann abschicken, dann siehst du die Fehlermeldung auf jeden Fall recht gut.
Ansonsten kannst du die Url ja auch mal hier posten (ohne Keys), vll sehen vier (oder mehr) Augen ja mehr las zwei.
HTH
ra_sch
-
Recon67
Hi
Fehlermeldung war wohl zu allgemein, sorry. Der aus der Rückmeldung der Suchanfrage erstellte File ist "not well-formed" und kann nicht als XML validiert werden. Das ist immer so, wenn in den Abfrageparametern ein Fehler vorliegt. Das hatte ich bei der bisherigen Programmierung schon reichlich. Wir reden hier von der GSAK-Rückmeldung ! Kurz gesagt, kann GSAK mit den Daten nix anfangen.
Spannend ist, dass ich den Parameter genau wie in der OKAPI-Anleitung (siehe ersten Beitrag) genannt eingetragen habe. Die Angaben "Archived|Available" funktionieren einzeln oder wie hier gezeigt auch zusammen. Bis dahin ist die Programmierung also sauber. Nur eben das "Temporarily unavailable" will nicht. Ich traue dem Leerzeichen nicht. Aber, wie bei anderen Parametern, der Unterstrich "_", hilft auch nicht.
Gruß
Recon
Nachtrag: Sobald das ""Temporarily unavailable"-Problem gelöst ist, sollte das Makro fertig sein. Ich habe eben die letzten Tests gemacht. Man kann jetzt nach D/T, eigenen Founds, eigenen Caches und, wenn's geht, nach Status filtern. Ehrlich gesagt, ist aber das 500er-Limit teilweise ein echtes Hindernis.
Fehlermeldung war wohl zu allgemein, sorry. Der aus der Rückmeldung der Suchanfrage erstellte File ist "not well-formed" und kann nicht als XML validiert werden. Das ist immer so, wenn in den Abfrageparametern ein Fehler vorliegt. Das hatte ich bei der bisherigen Programmierung schon reichlich. Wir reden hier von der GSAK-Rückmeldung ! Kurz gesagt, kann GSAK mit den Daten nix anfangen.
Spannend ist, dass ich den Parameter genau wie in der OKAPI-Anleitung (siehe ersten Beitrag) genannt eingetragen habe. Die Angaben "Archived|Available" funktionieren einzeln oder wie hier gezeigt auch zusammen. Bis dahin ist die Programmierung also sauber. Nur eben das "Temporarily unavailable" will nicht. Ich traue dem Leerzeichen nicht. Aber, wie bei anderen Parametern, der Unterstrich "_", hilft auch nicht.
Gruß
Recon
Nachtrag: Sobald das ""Temporarily unavailable"-Problem gelöst ist, sollte das Makro fertig sein. Ich habe eben die letzten Tests gemacht. Man kann jetzt nach D/T, eigenen Founds, eigenen Caches und, wenn's geht, nach Status filtern. Ehrlich gesagt, ist aber das 500er-Limit teilweise ein echtes Hindernis.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von Recon67 am 06.07.2013, 12:23, insgesamt 1-mal geändert.
-
following
Laut Server-Logfile wird nach "Temporarilyunavailable" gesucht, also irgendwo im Makro geht das Leerzeichen verloren.
Code: Alles auswählen
[05/Jul/2013:20:35:21 +0200] "GET /okapi/services/caches/shortcuts/search_and_retrieve?search_method=services/caches/search/nearest&search_params=%7b%22owner_uuid%22:%22-476e0a38-bd92-102b-b3fc-00163e359752%22,%22terrain%22:%221-5%22,%22difficulty%22:%221-5%22,%22center%22:%2251.132017%7c9.550833%22,%22radius%22:%221500%22,%22status%22:%22Available%7cArchived%7cTemporarilyunavailable%22,%22found_by%22:%22476e0a38-bd92-102b-b3fc-00163e359752%22,%22not_found_by%22:%22%22,%22limit%22:%22500%22,%22offset%22:%220%22%7d&retr_method=services/caches/formatters/gpx&retr_params=%7b%22ns_ground%22:%22true%22,%22ns_gsak%22:%22true%22,%22latest_logs%22:%22true%22,%22lpc%22:%2240%22,%22trackables%22:%22desc:list%22,%22alt_wpts%22:%22true%22%7d&wrap=false&format=xmlmap2&consumer_key=jHc5GLzffKcGjxL3HQhH HTTP/1.1" 400 570 "-" "GSAK"
-
Recon67
Danke für die Antwort, aber seltsam ist das schon
Ich habe das Makro im Debug-Modus laufen lassen und die Parameter werden sauber erstellt. Das kann aber auch das Log einer Abfrage gewesen sein, wo ich das ohne Leerzeichen versucht habe.
Die Makro-Kennung stimmt jetzt ? In Deinem Logfile steht nur "GSAK". Da sollte eigentlich der Makro-Name und mein Nickname als Applikations-Kennung stehen.
Ich habe eben (19:57 MESZ) nochmal zwei Abfragen laufen lassen. Die mit "Temporarily unavailable" führt zum Fehler und ohne funktioniert.
Hier der Teil des GSAK-Debug-Logs
Ich habe das Makro im Debug-Modus laufen lassen und die Parameter werden sauber erstellt. Das kann aber auch das Log einer Abfrage gewesen sein, wo ich das ohne Leerzeichen versucht habe.
Die Makro-Kennung stimmt jetzt ? In Deinem Logfile steht nur "GSAK". Da sollte eigentlich der Makro-Name und mein Nickname als Applikations-Kennung stehen.
Ich habe eben (19:57 MESZ) nochmal zwei Abfragen laufen lassen. Die mit "Temporarily unavailable" führt zum Fehler und ohne funktioniert.
Hier der Teil des GSAK-Debug-Logs
Code: Alles auswählen
$arguments (string) =caches/shortcuts/search_and_retrieve?search_method=services/caches/search/nearest&search_params={"owner_uuid":"-476e0a38-bd92-102b-b3fc-00163e359752","terrain":"1-5","difficulty":"1-5","center":"51.132017|9.550833","radius":"1500","status":"Temporarily unavailable","found_by":"","not_found_by":"476e0a38-bd92-102b-b3fc-00163e359752","limit":"500","offset":"0"}&retr_method=services/caches/formatters/gpx&retr_params={"ns_ground":"true","ns_gsak":"true","latest_logs":"true","lpc":"40","trac
das ergibt dann folgenden logeintrag:
das riecht irgendwie nach doppeltem url-encoding... %25 ergibt das %-zeichen und %20 normalerweise das leerzeichen... scheinbar versucht das makro mit %2520 ein leerzeichen zu encodieren, was auf jeden fall fehlschlagen muss...
Code: Alles auswählen
[06/Jul/2013:19:57:26 +0200] "GET /okapi/services/caches/shortcuts/search_and_retrieve?search_method=services/caches/search/nearest&search_params=%7b%22owner_uuid%22:%22-476e0a38-bd92-102b-b3fc-00163e359752%22,%22terrain%22:%221-5%22,%22difficulty%22:%221-5%22,%22center%22:%2251.132017%7c9.550833%22,%22radius%22:%221500%22,%22status%22:%22Available%7cTemporarily%2520unavailable%7cArchived%22,%22found_by%22:%22%22,%22not_found_by%22:%22476e0a38-bd92-102b-b3fc-00163e359752%22,%22limit%22:%22500%22,%22offset%22:%220%22%7d&retr_method=services/caches/formatters/gpx&retr_params=%7b%22ns_ground%22:%22true%22,%22ns_gsak%22:%22true%22,%22latest_logs%22:%22true%22,%22lpc%22:%2240%22,%22trackables%22:%22desc:list%22,%22alt_wpts%22:%22true%22%7d&wrap=false&format=xmlmap2&consumer_key=jHc5GLzffKcGjxL3HQhH HTTP/1.1" 400 576 "-" "GSAK"gruss Nils (bohrsty)
-
following
[quote="Recon67"]
Die Makro-Kennung stimmt jetzt ? In Deinem Logfile steht nur "GSAK". Da sollte eigentlich der Makro-Name und mein Nickname als Applikations-Kennung stehen.
[/quote]
Dieses Logfile ist vom Webserver, der weiß nix von deinen OKAPI-Daten. Also da steht nur der User-Agent-String von GSAK drin. (Unabhängig davon gibt es eine interne OKAPI-Statistik, die Consumer-Keys aufzeichnet und dann deinen Daten zugeordnet wird; die protokolliert aber nur die Methodennamen, keine Parameter.)
Die Makro-Kennung stimmt jetzt ? In Deinem Logfile steht nur "GSAK". Da sollte eigentlich der Makro-Name und mein Nickname als Applikations-Kennung stehen.
[/quote]
Dieses Logfile ist vom Webserver, der weiß nix von deinen OKAPI-Daten. Also da steht nur der User-Agent-String von GSAK drin. (Unabhängig davon gibt es eine interne OKAPI-Statistik, die Consumer-Keys aufzeichnet und dann deinen Daten zugeordnet wird; die protokolliert aber nur die Methodennamen, keine Parameter.)
-
following
[quote="bohrsty"]
scheinbar versucht das makro mit %2520 ein leerzeichen zu encodieren, was auf jeden fall fehlschlagen muss...
[/quote]
Die Codierung macht wohl GSAK, also das scheint ein Bug in der GetUrl-Funktion von GSAK zu sein. Vielleicht funktioniert es mit PostUrl?
scheinbar versucht das makro mit %2520 ein leerzeichen zu encodieren, was auf jeden fall fehlschlagen muss...
[/quote]
Die Codierung macht wohl GSAK, also das scheint ein Bug in der GetUrl-Funktion von GSAK zu sein. Vielleicht funktioniert es mit PostUrl?
-
Recon67
Ich habe jetzt das Problem auch im GSAK-Forum eingestellt. Scheinbar ist das aber generell ein Problem bei Server-Abfragen. Eine Google-Suche nach "%2520" (Hinweis aus dem GSAK-Forum) gibt reichlich Treffer zum gleichen Problem. Teilweise liegt dort die Ursache sogar auf der Serverseite.
PostUrl in GSAK würde, falls das überhaupt das Problem löst, wieder einen kompletten Umbau im Makro erfordern. Jedenfalls soweit ich das verstanden habe. Die Parameterübergabe scheint dann anders zu funktionieren.
Aufgefallen ist mir übrigens auch noch, dass es einen Status "gesperrt" gibt. Der wird (noch) nicht in der OKAPI berücksichtigt. Bemerkbar macht sich das, wenn man seine gefundenen Caches abfragen will und einige inzwischen "gesperrt" wurden. Die erwischt die Abfrage nicht.
PostUrl in GSAK würde, falls das überhaupt das Problem löst, wieder einen kompletten Umbau im Makro erfordern. Jedenfalls soweit ich das verstanden habe. Die Parameterübergabe scheint dann anders zu funktionieren.
Aufgefallen ist mir übrigens auch noch, dass es einen Status "gesperrt" gibt. Der wird (noch) nicht in der OKAPI berücksichtigt. Bemerkbar macht sich das, wenn man seine gefundenen Caches abfragen will und einige inzwischen "gesperrt" wurden. Die erwischt die Abfrage nicht.
-
following
[quote="Recon67"]
Ich habe jetzt das Problem auch im GSAK-Forum eingestellt. Scheinbar ist das aber generell ein Problem bei Server-Abfragen. Eine Google-Suche nach "%2520" (Hinweis aus dem GSAK-Forum) gibt reichlich Treffer zum gleichen Problem. Teilweise liegt dort die Ursache sogar auf der Serverseite.
[/quote]
Mit Letzterem dürfte ein ungültiger Link auf einer Webseite gemeint sein, das ist was Anderes. Hier wird die URL vom Client selbst erzeugt - der Apache protokolliert nur genau das mit, was der Client abfragt.
Ja, Umstellung auf PostUrl bedeutet dass die Parameter anders übergeben werden müssen: Der Teil nach dem Fragezeichen wird dann getrennt als zweiter Parameter übergeben. Mir fällt auf Anhieb kein anderer schneller Workaround ein, und es ist simpel: Fragezeichen-Position mit At() abfragen, String mit SubStr() in zwei Teile zerlegen.
Es betrifft sicher nicht nur "Temporarily unavailable" sondern alle Leerzeichen. Wenn du z.B. services/users/by_username verwendest, um die User-UUID zu ermitteln, gibt es Probleme mit Leerzeichen im Username - betrifft immerhin 11.356 User auf OC.de.
[quote="Recon67"]
Aufgefallen ist mir übrigens auch noch, dass es einen Status "gesperrt" gibt. Der wird (noch) nicht in der OKAPI berücksichtigt. Bemerkbar macht sich das, wenn man seine gefundenen Caches abfragen will und einige inzwischen "gesperrt" wurden. Die erwischt die Abfrage nicht.
[/quote]
Der Status "gesperrt" wird von der OKAPI nicht unterstützt; diese Caches sind nicht abfragbar. Das hatten wir damals im Team diskutiert und so entschieden - der Einbau in der OKAPI wäre recht aufwändig gewesen, und wir fanden es auch sinnvoll dass gesperrte Caches nicht mitgeliefert werden. Bei eigenen Caches und Funden ist es natürlich ungünstig ...
Ich habe jetzt das Problem auch im GSAK-Forum eingestellt. Scheinbar ist das aber generell ein Problem bei Server-Abfragen. Eine Google-Suche nach "%2520" (Hinweis aus dem GSAK-Forum) gibt reichlich Treffer zum gleichen Problem. Teilweise liegt dort die Ursache sogar auf der Serverseite.
[/quote]
Mit Letzterem dürfte ein ungültiger Link auf einer Webseite gemeint sein, das ist was Anderes. Hier wird die URL vom Client selbst erzeugt - der Apache protokolliert nur genau das mit, was der Client abfragt.
Ja, Umstellung auf PostUrl bedeutet dass die Parameter anders übergeben werden müssen: Der Teil nach dem Fragezeichen wird dann getrennt als zweiter Parameter übergeben. Mir fällt auf Anhieb kein anderer schneller Workaround ein, und es ist simpel: Fragezeichen-Position mit At() abfragen, String mit SubStr() in zwei Teile zerlegen.
Es betrifft sicher nicht nur "Temporarily unavailable" sondern alle Leerzeichen. Wenn du z.B. services/users/by_username verwendest, um die User-UUID zu ermitteln, gibt es Probleme mit Leerzeichen im Username - betrifft immerhin 11.356 User auf OC.de.
[quote="Recon67"]
Aufgefallen ist mir übrigens auch noch, dass es einen Status "gesperrt" gibt. Der wird (noch) nicht in der OKAPI berücksichtigt. Bemerkbar macht sich das, wenn man seine gefundenen Caches abfragen will und einige inzwischen "gesperrt" wurden. Die erwischt die Abfrage nicht.
[/quote]
Der Status "gesperrt" wird von der OKAPI nicht unterstützt; diese Caches sind nicht abfragbar. Das hatten wir damals im Team diskutiert und so entschieden - der Einbau in der OKAPI wäre recht aufwändig gewesen, und wir fanden es auch sinnvoll dass gesperrte Caches nicht mitgeliefert werden. Bei eigenen Caches und Funden ist es natürlich ungünstig ...
Zuletzt geändert von following am 07.07.2013, 16:28, insgesamt 1-mal geändert.
-
Recon67
So einfach ist es dann doch nicht. Die Übergabe "einfach so" als zweiten String-Teil haut einem das nur so um die Ohren. Die Parameter müssen irgendwie zerpflückt werden.following hat geschrieben:
Ja, Umstellung auf PostUrl bedeutet dass die Parameter anders übergeben werden müssen: Der Teil nach dem Fragezeichen wird dann getrennt als zweiter Parameter übergeben. Mir fällt auf Anhieb kein anderer schneller Workaround ein, und es ist simpel: Fragezeichen-Position mit At() abfragen, String mit SubStr() in zwei Teile zerlegen.
Stimmt, hat ein Test eben bestätigt. Bravo.....Es betrifft sicher nicht nur "Temporarily unavailable" sondern alle Leerzeichen. Wenn du z.B. services/users/by_username verwendest, um die User-UUID zu ermitteln, gibt es Probleme mit Leerzeichen im Username - betrifft immerhin 11.356 User auf OC.de.
Das ist jetzt aber.... nervig
Zuletzt geändert von Recon67 am 07.07.2013, 17:41, insgesamt 1-mal geändert.
-
Recon67
So, auch Dank der Hilfe im GSAK-Forum ist das Problem gelöst. Space durch "+" ersetzt und es läuft.
Das Makro geht demnächst an den Start.
Ist via GSAK abrufbar.
Das Makro geht demnächst an den Start.
Ist via GSAK abrufbar.
Zuletzt geändert von Recon67 am 08.07.2013, 21:09, insgesamt 1-mal geändert.