c:geo "kann" jetzt auch Opencaching

[ra_sch]

So, dass mit dem Attribut haben wir in c:geo mal auseinandergezogen (auch wenn das OC-GPX das GC Attribut liefert. Vll lassen wir uns da auch noch etwas anderes einfallen).
Dass mit dem deutschen Hint funktioniert in meiner aktuellen Entwicklerversion (basierend auf OKAPI) auch schon erledigt (dank 'preferred language'), insofern werden wir das in der xmlapi-version wohl nicht mehr glattziehen.

Gruß
ra_sch

[following]

Wie macht ihr es denn mit den OKAPI-Attributen? Bislang kommen die ja nur als Textliste mit, in der jeweiligen Sprache (auch in GPX).

OKAPI-Attribut-IDs sind in Arbeit, aber da ist noch einiges dran zu tun. Wäre es für c:geo hilfreich / wichtig, dass die OKAPI Attribut-IDs liefert, oder braucht ihr dieses Feature nicht?

[ra_sch]

Die Antwort ist recht einfach (wenn auch für mich überraschend): Wi rmachen bei der OKAPI noch gar nichts mit den Attributen - da liegt also auch noch ein Stück Arbeit

[ra_sch]

Ich habe jetzt mal die Diskussion auf Google code dazu nachgelesen. Wenn man das 'richtig' machen will, ist dass schon eine größere Aufgabe.
Von c:geo-Seite hätte ich da aich eher einen pragmatischen Ansatz. Solange ich stabile Ids bekomme (egal ob als String oder numerisch) mappe ich die auch gerne selbst erstmal von jedem Knoten auf meine interne Tabelle.
Ein einfacher 'Hack' um das zu erreichen könnte ein Feld attrnames_en sein - dann habe ich stabile Ids und kann mir pro Knoten die Liste der gültigen Strings holen und einbauen (muß ja auch nicht 'en' sein, Hauptsache unabhängig von langpref).
Der Hauptpunkt hier ist, dass ich als App-Entwickler ungern Strings pro Cache speichern und anzeigen möchte, sondern ids und Icons.

Gruß
ra_sch

[following]

[quote="ra_sch"]
Ich habe jetzt mal die Diskussion auf Google code dazu nachgelesen. Wenn man das 'richtig' machen will, ist dass schon eine größere Aufgabe.
...
Ein einfacher 'Hack' um das zu erreichen könnte ein Feld attrnames_en sein - [/quote]

Eher geht ein Kamel durch ein Nadelöhr, als dass ich Wrygiel dazu überreden kann, einen Hack in die OKAPI einzubauen. 

Ok, ich werde mal schauen ob ich die OKAPI-Attribute etwas forcieren kann.

[ra_sch]

Was ich in der Diskussion gelesen habe, klang aber nicht wirklich nach mal eben schnell, insofern würde ich da eher noch mal ein paar Tage ins Land gehen lassen und drüber nachdenken (von meiner Seite), bevor du das forcierst. Wenn das Konzept für die Attribute robust sein soll, kann das ruhig noch einen Moment reifen.
In wie vielen Sprachen gibt es den eigentlich die oc.de Attribute? de|en|it|es ?
Da ist es vll. sinnstiftender wenn ich das für den Moment auf unserer Seite 'hacke'.

[following]

[quote="ra_sch"]
In wie vielen Sprachen gibt es den eigentlich die oc.de Attribute? de|en|it|es ?
[/quote]

Bis jetzt diese vier, ja. Demnächst könnten noch 2-3 Sprachen hinzukommen.

[following]

Oder du machst eine zweite Abfrage nur für die Attribute, mit langpref=en.

[ra_sch]

Ist auch eine Möglichkeit, für c:geo aber ziemlich hässlich. Momentan habe ich den Code auf 'search_and_retrieve' umgestellt, aus meiner Sicht sehr effektiv um mit einem Roundtrip alle Infos zu bekommen und dann die Daten Cacheweise zu interpretieren und zu speichern. Wenn ich das jetzt aufspalte, muß ich entweder alle Caches im Speicher halten (kann auf einem Smartphone schon mal ein Problem sein) oder sie dann nochmal laden (ist auch nicht performant).
Ich werd auch mal schauen, was bei uns im Team noch so für Ideen aufschlagen.

[ra_sch]

Mal als Rückmeldung zum aktuellen Stand bei c:geo: Ich habe mir jetzt mal eure netterweise zusammengestellte 'attributes.xml' bei google-code rausgeklaubt und daraus eine Übersetzterklasse generiert (ich weiß, dass ich die Datei nicht verwenden soll, weil sie sich ändern kann, aber dann passe ich halt das Genereirungstool an, ist kein Teil von c:geo direkt).
Das funktioniert soweit ich das sehen kann ganz gut, insofern steht geht das jetzt für mich auf die Zielgerade. Mal schauen, vll. kriegen wir so sogar oc.pl gleich noch mit ins Boot...

Gruß
ra_sch

[mic@]

[quote="flopp"]Die neuste Version von c:geo kann jetzt auch (rudimentär) mit Opencaching.de umgehen![/quote]

Aber so richtig integriert ist oc.de noch nicht in c:geo.
Ich wollte z.B. gestern meinen Newbie-Cache aufrufen (ist ein oc-only), aber wenn
ich nach Caches des Benutzers "mic@" suche, kommen nur meine paar gc-Caches 

[ra_sch]

[quote="mic@"]
[quote="flopp"]Die neuste Version von c:geo kann jetzt auch (rudimentär) mit Opencaching.de umgehen![/quote]

Aber so richtig integriert ist oc.de noch nicht in c:geo.
Ich wollte z.B. gestern meinen Newbie-Cache aufrufen (ist ein oc-only), aber wenn
ich nach Caches des Benutzers "mic@" suche, kommen nur meine paar gc-Caches 
[/quote]

Ja, da müssen wir uns noch etwas nacharbeiten. Momentan suchen wir bei der Koordinaten- und Livemap-Suche bei beiden (sofern angehakt), bei der Geocode-Suche auf der entsprechenden Plattform und bei den anderen Suchen nur auf gc.com.

Kommt mit auf die ToDo-List für die OKAPI-Version, danke für den Hinweis!

ra_sch

[mic@]

[quote="ra_sch"]Ja, da müssen wir uns noch etwas nacharbeiten. Momentan suchen wir bei der Koordinaten- und Livemap-Suche bei beiden (sofern angehakt)...[/quote]

Kann es sein, daß über die Livemap-Suche Caches übersehen werden.
Ich war heute in Sachsen und stand direkt vor GC459ZB ,
aber auf der Karte war der nicht zu sehen !?!
Überhaupt ist die Karte etwas zäh, selbst in der Einstellung "schnellstens".

[ra_sch]

Die Performance der Live-Map für GC hängt natürlich stark von geocaching.com ab und ist generell im Durchschnitt  schlechter als für opencaching.de
Bezüglich deines aktuellen Problems: Hast du die neueste Version? Geocaching.com hat die Livemap geändert, da ist das Update vom 16.05. erforderlich.

HTH

ra_sch

[mic@]

[quote="ra_sch"]Hast du die neueste Version?[/quote]

Wahrscheinlich nicht. Laut App nutze ich 2013.05.13
Leider gibt es keine Menüpunkt zum Update innerhalb der App (oder habe ich es übersehen),
und online zieht es sich selber auch kein Update runter, wenn ich c:geo starte.