-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Groundspeak API?
- Ersteller peter51d
- Erstellt am
Wenn denn eine API käme stünde einer Integration in (W)CB ja nichts entgegen, da dann sicher der GC-Login abgefagt würde und damit wäre ein Premium von einem Basic einfach zu unterscheiden.
Anders natürlich, wenn die Programmierer zur Kasse gebeten würden....
Sorry, war in der Eile im falschen Thread gelandet
Anders natürlich, wenn die Programmierer zur Kasse gebeten würden....
Sorry, war in der Eile im falschen Thread gelandet
GeoSilverio
Geowizard
Gerade heute kam ein Groundspeak-Feedback, in dem erwähnt wurde, dass die API in einer Art Beta-Stadium nun von etwa 20 Entwicklern getestet würde...
Ist denn da jemand von cachebox mit dran beteiligt?
Hier mal die Originalnachricht:
A Update: We are currently in the process of testing the API with approximately 20 developers, including many of the applications and services requested in the feedback comments below. Ideally, these API enabled applications will be available for launch within the next 30-45 days.
Ist denn da jemand von cachebox mit dran beteiligt?
Hier mal die Originalnachricht:
A Update: We are currently in the process of testing the API with approximately 20 developers, including many of the applications and services requested in the feedback comments below. Ideally, these API enabled applications will be available for launch within the next 30-45 days.
tower27
Geowizard
GeoSilverio
Geowizard
Nein, nur eben das es nun tatsächlich wohl in die Testphase geht.
Vielleicht könnte sich einer der Entwickler (oder als Entwicklerteam) mal direkt an Groundspeak wenden? Evtl. ist das zielführender, als dieses Voting?
Vielleicht könnte sich einer der Entwickler (oder als Entwicklerteam) mal direkt an Groundspeak wenden? Evtl. ist das zielführender, als dieses Voting?
Egal, ob die API kostenfrei ist oder nicht (und für wen) ... CB ist rein DB-orientiert und hat keine Onlinezugriffe außer Field Notes und Found-Anzahl. Wenn was fehlt bitte ergänzen...
GCzII geht da schon lang den Weg des Spiderns, ich glaub dort ist der Programmieraufwand geringer als bei CB.
Die Frage ist eher, was kann und/oder soll die API und was kann und/oder soll CB ... wie geht eines Tages Beides zusammen?
Eine Kooperation von GS und dem Programmierer-Team von (W)CB dürfte da wohl das kleinste Problem werden.
GCzII geht da schon lang den Weg des Spiderns, ich glaub dort ist der Programmieraufwand geringer als bei CB.
Die Frage ist eher, was kann und/oder soll die API und was kann und/oder soll CB ... wie geht eines Tages Beides zusammen?
Eine Kooperation von GS und dem Programmierer-Team von (W)CB dürfte da wohl das kleinste Problem werden.
cacheboxer
Geomaster
Ganz spontan ohne Anspruch auf Vollständigkeit: PQs erstellen, PQs laden, Bilder importieren, Spoiler laden, Karten laden, Route berechnen, GCVote-Bewertung importieren, GCVote-Bewertung abgeben,...Timo TA93 schrieb:
Geocaching ist ein Immer-und-Überall-Hobby.. CB trägt dem zur Zeit durch Masse Rechnung. Es wäre schon ungemein praktisch, wenn man sich schnell die Dosen in der momentanen Umgebung anzeigen lassen könnte.
Die anderen Online-Funktionen wären erheblich schneller und weniger fehleranfällig, wenn dazu offizielle APIs genutzt werden würden, anstatt GC die Infos halblegal abzutrotzen.
Das von Dir oft bemängelte Handling archivierter und deaktivierter Caches wäre durch einen Status-Check per API schnell und elegant zu lösen.
MfG
Da ich eine API für sehr nützlich halte, hab ich auch dafür votiert.
In GSAK gibts die Möglichkeit den Staus zu checken, leider aber nur für einzelne Caches und nicht automatisch für die betreffende DB. Auch da wäre die API hilfreich, denn ich denke, damit würde der Traffic auf den Servern von GC drastisch verringert weil nicht mehr die PQ`s immer neu gezogen werden müßten. PQ`s brauchten dann nur neu veröffentlichte Caches enthalten.....
Mal schauen, wie das irgendwann mal mit (W)CB zusammengeht....
In GSAK gibts die Möglichkeit den Staus zu checken, leider aber nur für einzelne Caches und nicht automatisch für die betreffende DB. Auch da wäre die API hilfreich, denn ich denke, damit würde der Traffic auf den Servern von GC drastisch verringert weil nicht mehr die PQ`s immer neu gezogen werden müßten. PQ`s brauchten dann nur neu veröffentlichte Caches enthalten.....
Mal schauen, wie das irgendwann mal mit (W)CB zusammengeht....
GeoSilverio
Geowizard
Naja, so wie ich viele Internetnutzer einschätze (und wie es bei Mobac ja schon war), werden mit einer API zur Not halt alle Caches alle 5 Minuten auf Aktualisierung und neue Logs überprüft.... 
Das mag durchaus sein, bis auch der letzte Depp gemerkt hat, daß sich nicht alles stündlich ändert ...
Neue Funktionen regen doch zum "Probieren" an ... oder?
Ich rede NUR für mich, mir reichts wenn ich vor einer Tour checken kann, sind die ausgewählten Caches auch wirklich aktiv... Wenn dabei die ganze DB schnell und unkompliziert auf Status überprüft wird ist das schon ein Bonus. Will ich eine 20er Runde machen und muß 20 Caches einzeln prüfen ... Zeit ist Geld, oder hast du zuviel davon?
Neue Funktionen regen doch zum "Probieren" an ... oder?
Ich rede NUR für mich, mir reichts wenn ich vor einer Tour checken kann, sind die ausgewählten Caches auch wirklich aktiv... Wenn dabei die ganze DB schnell und unkompliziert auf Status überprüft wird ist das schon ein Bonus. Will ich eine 20er Runde machen und muß 20 Caches einzeln prüfen ... Zeit ist Geld, oder hast du zuviel davon?
GeoSilverio
Geowizard
Ja, ich habs vorhin auch gelesen.
Der Text in der Nachricht widerspricht ein wenig dem, was der c:geo-Entwickler vor ein paar Tagen schrieb. (Zur Info: Der c:geo-Entwickler stellt die Weiterentwicklung an dem Programm ein. Hauptgrund dafür ist wohl, dass er sich mit der Politik von Groundspeak immer weniger anfreunden konnte.)
Jedenfalls schrieb er, dass er die API von Groundspeak bekommen hätte, Groundspeak selbst aber eine Version 2 in seinen eigenen (ja eher mittelmäßigen) Programmen zum Einsatz bringt und die third-party-developer mit einer Version 1 vorlieb nehmen müssten.
In der Nachricht von Groundspeak steht aber, dass dem nicht so sei.
Wie auch immer, ich plädiere trotzdem dafür, sich der Sache mit der API nochmal anzunehmen. Falls der c:geo-Entwickler tatsächlich dann nicht mehr weiter entwickelt, wäre cachebox auf Android DER Renner.
Ist es auch so schon, nur hat c:geo ja die gc.com-Webseite gespidert und aus welchem Grund auch immer, stehen die Leute da unbedingt drauf, möglichst NICHTS zu zahlen und möglichst ALLES zu bekommen.
Mit API wäre dann wenigstens für die Premium-User jederzeit der Abruf von Caches in der Nähe und Logs zu beliebiger Zeit direkt online möglich, wodurch zumindest für Fälle, in denen man "mal unverhofft wo ganz anders ist", die PQ-Generierung nicht mehr nötig wäre.
Evtl. kann die API auch direkt loggen und die found-Statistik abgleichen
Der Text in der Nachricht widerspricht ein wenig dem, was der c:geo-Entwickler vor ein paar Tagen schrieb. (Zur Info: Der c:geo-Entwickler stellt die Weiterentwicklung an dem Programm ein. Hauptgrund dafür ist wohl, dass er sich mit der Politik von Groundspeak immer weniger anfreunden konnte.)
Jedenfalls schrieb er, dass er die API von Groundspeak bekommen hätte, Groundspeak selbst aber eine Version 2 in seinen eigenen (ja eher mittelmäßigen) Programmen zum Einsatz bringt und die third-party-developer mit einer Version 1 vorlieb nehmen müssten.
In der Nachricht von Groundspeak steht aber, dass dem nicht so sei.
Wie auch immer, ich plädiere trotzdem dafür, sich der Sache mit der API nochmal anzunehmen. Falls der c:geo-Entwickler tatsächlich dann nicht mehr weiter entwickelt, wäre cachebox auf Android DER Renner.
Ist es auch so schon, nur hat c:geo ja die gc.com-Webseite gespidert und aus welchem Grund auch immer, stehen die Leute da unbedingt drauf, möglichst NICHTS zu zahlen und möglichst ALLES zu bekommen.
Mit API wäre dann wenigstens für die Premium-User jederzeit der Abruf von Caches in der Nähe und Logs zu beliebiger Zeit direkt online möglich, wodurch zumindest für Fälle, in denen man "mal unverhofft wo ganz anders ist", die PQ-Generierung nicht mehr nötig wäre.
Evtl. kann die API auch direkt loggen und die found-Statistik abgleichen
Silverio schrieb:
Diese Begründung ist in meinen Augen ja nun mal sehr schwach. Groundspeak ist ein Wirtschaftsunternehmen - und wenn es nur dazu dient die laufenden Kosten zu decken (aber daran glaubt ja wohl keiner, oder?).
Wir waren bis jetzt auf PQ oder nicht mit der TOU zu vereinbarenden Methoden angewiesen. Wenn es nun eine Schnittstelle gibt die davon einen Teil (klein, groß - keine Ahnung) abdeckt und damit unsere Bedürfnisse zumindest in Teilen wieder in der Bereich der TOU schiebt, dann sollten wir erstmal zufrieden sein.
Und wo steht geschrieben dass ein Unternehmen anderen Leuten kostenlos die neuste Version zur Verfügung stellen muss?
Und auch dass die versuchen durch eventuelle Vorteile der neueren API ihre eigenen Programme nach vorne zu bringen, ist in meinen Augen auch egal.
Im Gegenteil bin ich der Meinung das GS schon sehr sehr offen gegenüber den ganzen Programmieren ist - sie erlauben nämlich die Verwendung der freigegebenen API (wenn auch erst an ausgewählte Personen) auch in kommerziellen Programmen - und so wie es im Moment klingt ohne eine Beteiligung an den Einnahmen.
Und dass die Entwicklung so "schleppend" voran geht, hängt wohl auch mit der Vielzahl der Wünsche zusammen (schaut mal unter Feedback) - und dass ja nun genau abgewogen werden muss was für Folgen Änderungen haben. Gerade bei so einer API muss ja getestet werden welche Auswirkungen das auf die Soft- und Hardware hat. Sonst sind hinterher wieder alle am Motzen weil GC.com andauernd weg oder sehr langsam ist.
Gruß aus Godesberg
Jens
GeoSilverio
Geowizard
Ja, das ist schon klar, ich wollte auch die Meinung des Entwicklers nur kurz zusammenfassen.
Auf der anderen Seite muss man schon sagen:
Ohne die Cacher gäbs Groundspeak ja nicht, sprich das ganze Ding wäre leer oder Jeremy müsste alle caches selbst legen.
Klar müssen Mitarbeiter, Environment und Internet-Zugang bezahlt werden.
Dazu muss man aber ja nicht immer gleich übers Ziel raus schießen und die Leute gängeln, die meine Lieferanten und Kunden gleichzeitig sind. Und zudem noch jedem anderen Knüppel in den Weg legen, der nicht 24 Stunden am Tag die Groundspeak-Fahne anbetet.
Aber vielleicht ist es auch einfach nur die Mentalität der Amerikaner? Ich weiß es nicht.
Auf der anderen Seite muss man schon sagen:
Ohne die Cacher gäbs Groundspeak ja nicht, sprich das ganze Ding wäre leer oder Jeremy müsste alle caches selbst legen.
Klar müssen Mitarbeiter, Environment und Internet-Zugang bezahlt werden.
Dazu muss man aber ja nicht immer gleich übers Ziel raus schießen und die Leute gängeln, die meine Lieferanten und Kunden gleichzeitig sind. Und zudem noch jedem anderen Knüppel in den Weg legen, der nicht 24 Stunden am Tag die Groundspeak-Fahne anbetet.
Aber vielleicht ist es auch einfach nur die Mentalität der Amerikaner? Ich weiß es nicht.
cacheboxer
Geomaster
Wir diskutieren hier ja nicht die Geschäftspolitik von Groundspeak, sondern darüber, was cachebox! guttut und was nicht.
Ich kenne die Groundspeak API nicht, aber APIs haben im allgemeinen (ganz abgesehen von den TOU) den Vorteil, dass sie stabil sind, sich also nicht mit jedem Website-Update ändern und handlicher zu programmieren, performanter und zuverlässiger sind, als automatisierte Interaktionen mit dem UI der Website, wie cachebox sie jetzt nutzt.
Ausserdem gehe ich stark davon aus, dass die API für mobile Anwendungen wie cachebox! sinnvolle Dienste zur Verfügung stellt, von denen cachebox! wirklich profitieren kann.
Ich denke, dass cachebox! durch die Nutzung der APIs nur gewinnen kann.
Natürlich wäre es nicht fair, wenn Groundspeak sich die Nutzung einer "besseren" API für die eigenen Produkte vorbehalte. Klar stellt die Nutzung der API indirekt eine Unterstützung für Groundspeak dar, weil cachebox! als toller Client für die Plattform zahlende Kunden für Groundspeak generiert. Groundspeak ist aber ja nun kein bekannter Menschenrechtsverletzer und strebt m.W. auch nicht die Weltherrschaft an - die ethisch-moralische Güterabwägung spricht für mich für die Nutzung der API. Zur Erinnerung: cachbox! läuft auf einem Microsoft-Betriebssystem und sieht seine Zukunft auf einem Google-Betriebssystem.
Wer den Kampf gegen die Kommerzialisierung des Hobbys führen will, macht das kostenfreie cachebox! einfach besser, als die kostenpflichtigen Groundspeak-Apps. Aus meiner Erfahrung als cachebox!-Nutzer behaupte ich, dass David hier durchaus den Kampf gegen Goliath aufnehmen kann.
MfG
Ich kenne die Groundspeak API nicht, aber APIs haben im allgemeinen (ganz abgesehen von den TOU) den Vorteil, dass sie stabil sind, sich also nicht mit jedem Website-Update ändern und handlicher zu programmieren, performanter und zuverlässiger sind, als automatisierte Interaktionen mit dem UI der Website, wie cachebox sie jetzt nutzt.
Ausserdem gehe ich stark davon aus, dass die API für mobile Anwendungen wie cachebox! sinnvolle Dienste zur Verfügung stellt, von denen cachebox! wirklich profitieren kann.
Ich denke, dass cachebox! durch die Nutzung der APIs nur gewinnen kann.
Natürlich wäre es nicht fair, wenn Groundspeak sich die Nutzung einer "besseren" API für die eigenen Produkte vorbehalte. Klar stellt die Nutzung der API indirekt eine Unterstützung für Groundspeak dar, weil cachebox! als toller Client für die Plattform zahlende Kunden für Groundspeak generiert. Groundspeak ist aber ja nun kein bekannter Menschenrechtsverletzer und strebt m.W. auch nicht die Weltherrschaft an - die ethisch-moralische Güterabwägung spricht für mich für die Nutzung der API. Zur Erinnerung: cachbox! läuft auf einem Microsoft-Betriebssystem und sieht seine Zukunft auf einem Google-Betriebssystem.
Wer den Kampf gegen die Kommerzialisierung des Hobbys führen will, macht das kostenfreie cachebox! einfach besser, als die kostenpflichtigen Groundspeak-Apps. Aus meiner Erfahrung als cachebox!-Nutzer behaupte ich, dass David hier durchaus den Kampf gegen Goliath aufnehmen kann.
MfG