Cgeo: API Geocaching.com

Claro que isso teria que ser coordenado com o nº 9...

cadê a nova api?? Acho que se houver uma API que suporte todos os recursos, devemos usar isso. (mas apenas se o groundpeak alterar a API imediatamente se fizer uma atualização em geocaching.com)

Api está disponível apenas para aplicativos selecionados. Cgeo era um, cgeo opensource não é

Espero que eles não alterem a API com cada alteração nas páginas da Web ...
Caso contrário, poderíamos continuar a rastrear as páginas e atualizar nosso código com todas as alterações que o GC.com implementa em suas páginas da Web...
Eu li que a API agora estará disponível para membros premium e básicos com algumas limitações para membros básicos.
Se você não se importar, entrarei em contato com Ryan na Groundspeak e pedirei a documentação da API.
Floriano.

Temos doc, não temos chave de acesso api

Eu li a notificação sobre a próxima Api algumas semanas atrás. Alguém tem mais algumas indicações?

:( Eu quis dizer que eles atualizam a biblioteca após as alterações no gc.com :D

Então, se você não se importa, eu pediria à Groundspeak uma chave de acesso api para c-geo (e também esclareceria com a Groundspeak que c-geo-opensource é basicamente o mesmo que c-geo com apenas um esclarecimento sobre o licenciamento de código aberto ).
Você pode me enviar uma cópia da documentação ou - se estiver na web em algum lugar - me dar um link para ela?
Floriano.

Sammy se comunicou. Vamos esperar por ele

Entrei em contato com eles há algumas semanas. A resposta foi uma linha que me disse para enviar a eles um aplicativo para acessar a API. Parece que não há documentação pública, você precisa de uma chave de API para o aplicativo e todo usuário deve obter uma chave em um procedimento OAuth. E eles chamam isso de "API pública" ...

Eu acho que não devemos codificar isso. Será mais fácil com a interface do conector para que não faça diferença se importarmos de spidering, API, OC, gpx, web2cgeo...

Absolutamente. Não pensei na autenticação OAuth quando pensei em alternar sucessivamente para a nova API.

@SammysHP : Alice no País das Maravilhas Groundsheep:

"Quando eu uso uma palavra", Humpty Dumpty disse em um tom um tanto desdenhoso, "ela significa exatamente o que eu escolho que ela signifique - nem mais nem menos."
"A questão é", disse Alice, "se você pode fazer as palavras significarem tantas coisas diferentes."
"A questão é", disse Humpty Dumpty, "qual deve ser o mestre - - isso é tudo."

Ontem recebi um e-mail da Groundspeak:

Prezado Sven,

Obrigado por sua paciência enquanto avançamos com o Programa API Geocaching.com. Seguem em anexo dois documentos para análise. Por favor, devolva o Formulário de Inscrição de API preenchido para mim e nós lhe enviaremos uma Chave de Teste de API.

O objetivo deste programa API público é permitir que terceiros confiáveis ​​desenvolvam aplicativos e serviços usando o conjunto de dados geocaching.com que atenderá principalmente aos Membros Premium Groundspeak, ao mesmo tempo em que permite que uma quantidade significativa de serviços seja fornecida para Membros Básicos. A API será fornecida isenta de royalties, para que os desenvolvedores possam gerar receita (ou não) como bem entenderem, sem ter que pagar royalties à Groundspeak pelo acesso aos dados.

Acreditamos que isso proporcionará a você a capacidade de atender melhor à comunidade mais ampla, incluindo novos usuários, ao mesmo tempo em que oferece oportunidades adicionais para que os membros básicos façam upgrade para serviços Premium completos. Idealmente, gostaríamos que os membros que apreciam as experiências introdutórias fizessem o upgrade para a Associação Premium para acesso completo ao aplicativo/serviço. Detalhes específicos sobre esta estrutura estão contidos no Anexo A do Contrato. A concordância com os Termos e um Formulário de Inscrição de API preenchido serão necessários antes do acesso ao banco de dados de Produção e do lançamento formal.

Observe que, como desenvolvedor confiável, esperamos que você não abuse da API, seja na preparação ou na produção. A extração de dados do site geocaching.com não é permitida em nenhum aplicativo ou serviço para membros básicos ou premium. Em vez de permitir a raspagem, preferimos desenvolver chamadas de API para atender às necessidades específicas do desenvolvedor. Se você tiver dúvidas sobre possíveis ações que planeja fazer com a API, poste-as nos fóruns da API e faremos o possível para esclarecer as regras.

Um login via Oauth será necessário para todos os usuários dos aplicativos/serviços habilitados para API. Depois de receber seu formulário de inscrição de API preenchido, enviaremos uma chave de teste para você acessar o servidor de teste. Em seguida, depois de analisar seu produto e sua funcionalidade, avançaremos com a chave de API de produção.

Obrigado novamente. Estamos muito ansiosos para trabalhar com você.

Atenciosamente,

Christy

Christy Luther
Gerente de Desenvolvimento de Negócios
Groundspeak, Inc.
Groundspeak - A Língua da Localização
www.groundspeak.com
www.geocaching.com

Aqui está o contrato de licença da API: http://www.file-upload.net/download-3675937/Groundspeak-API-License-Agreement-17-08-2011.pdf.html

O problema é que a chave deve ser pública, pois cada desenvolvedor compila sua própria compilação (para testar e usar). E pelo que ouvi isso é um problema para a Groundspeak.
Então minha sugestão: espere até que a interface do conector seja realizada e então desenvolva o uso da API como um aplicativo separado.

Olá, dei uma olhada rápida no contrato de licença. Embora eu não veja uma solicitação explícita de confidencialidade em relação à chave da API que talvez possa ser derivada de 4.17 ou 4.18.
O que mata o conceito de um conector externo é provavelmente 4.16 (trabalho derivado) e 5.3 (usuários finais - não outros aplicativos).
Integrando-o em c:geo violaria 4.14.
Os limites básicos de membros são uma piada.
Eu voto apenas para ignorá-lo até que eles apresentem um modelo de licença sensato.

Acho que não há problema em colar um e-mail que alguém recebeu de Bryan:

Oi _________,

Estamos dispostos a fornecer acesso API ao CGeo Opensource. No entanto, como a chave de licença deve ser usada apenas para o aplicativo individual, estamos preocupados que ela possa ser compartilhada publicamente. Se for partilhado publicamente, poderá ser utilizado por outras aplicações e isso resultaria na obrigatoriedade da Groundspeak a cancelar a chave específica. Isso, é claro, quebraria o aplicativo porque ele não seria capaz de acessar os dados.

Então, você pode me ajudar a entender como você planeja limitar o acesso à chave de autenticação? Não pode ser divulgado publicamente em nenhuma circunstância. Como há vários desenvolvedores trabalhando no projeto Opensource, sabemos que é preciso apenas um desenvolvedor para fornecer o código externamente e então todos teremos um problema. Por favor, forneça qualquer informação que você puder e ficaremos felizes em trabalhar diretamente com você, ou com o principal representante do projeto, para fazer este trabalho.

Incluí Christy Luther neste e-mail, pois ela está gerenciando o processo de desenvolvimento para desenvolvedores terceirizados.

Obrigada!

Sinceramente,

Bryan

Então eles estão dispostos a nos ajudar, mas também minha opinião é esperar até (para melhor integração, licença menos rígida, talvez uma API que não precise de chave, mas apenas a chave OAuth).

o que me deslumbra: o Google é capaz de gerenciar esses modelos de desenvolvimento para sua API de mapas. Mas as ovelhas não podem? Bizarro.

Há duas coisas com o Google:

• A API do Google verifica o certificado, com isso o app é assinado. A chave do Groundspeak deve funcionar com todas as plataformas e linguagens de programação.
• A chave da API do Google é gratuita, portanto, todos os desenvolvedores podem obter uma.

Eu sei. É o processo do groundsheep api que está causando problemas aqui à medida que as diferentes culturas colidem: o rígido, como uma maçã, "saia da minha quadra" de St Jeremy e o aberto como o bazar, onde o google é forte. Não poderia ter mais contraste. Quanto à parte dependente do Android: se bem me lembro, você também pode usar o google maps a partir de aplicativos da web de javascript, para que eles pareçam ter um método independente de plataforma. É a mentalidade diferente entre o google e o groundsheep que causa os soluços, o google é não seja mau, mas o que é o groundsheep?

AFAIK a chave para JavaScript verifica o domínio.

Dê outra olhada, desta vez na infraestrutura OSM: eles precisam operar um ambiente aberto, mas projetar seu banco de dados contra uso indevido. Eles não verificam os aplicativos para editar dados do OSM: como isso deve funcionar? A cada novo lançamento, patch, etc... St Jeremy quer verificar todos os aplicativos novamente? Controle a neurose, alguém? Assim, o OSM verifica os usuários. Não parece ser um problema. Talvez esteja faltando alguma coisa, mas por que o modelo OSM não funcionaria para dados de geocaching?

Este foi o meu pensamento quando ouvi sobre a nova API pública.

O problema com a chave da API talvez possa ser resolvido se cada desenvolvedor obtiver sua própria chave - mas olhando para as limitações dos membros básicos, voto contra o uso da api.

A BFKC está em contato com a Groundspeak, então vamos aguardar. Também a única possibilidade de implementar a API é um conector como o da GeOrg: http://android.ranitos.de/files/connector-sample.zip Gosto da forma que é usada para comunicação entre o app e o conector.

Enquanto isso, você pode me enviar uma PM se quiser um link para a documentação da API.

Fechando isso por enquanto, manteremos isso em mente e falaremos sobre isso novamente quando a interface do conector for implementada. Veja o nº 10

O usuário final pode ser responsável por inserir uma chave de usuário válida em c:geo. Os desenvolvedores podem desenvolver cada um com sua própria chave de usuário.

Não, o OAuth requer uma chave secreta para o aplicativo.

Sim, uma chave secreta para gerar uma chave de usuário. Em seguida, a chave do usuário é usada para se comunicar com o servidor da API. Como / onde o usuário chega a chave é com eles.

Você diz que devemos usar a conta de outro aplicativo para nossos propósitos?!

Qual é o problema se apenas um desenvolvedor recebe a chave?
Tem que haver alguém responsável por liberar os lançamentos "oficiais" na loja do Google.
Portanto, esse desenvolvedor adicionaria a chave da API em algum arquivo de configuração que é empacotado no apk.
Se outros desenvolvedores quiserem trabalhar na parte da API do código, eles mesmos podem solicitar acesso à API!
As pessoas que desejam usar versões personalizadas do c:geo precisariam de sua própria chave de API, obviamente, mas acho que a maioria dos usuários não deseja usar versões personalizadas. Em todos os casos, isso seria melhor do que nenhum suporte à API!

A questão da chave é apenas um problema menor. O principal problema é que, de acordo com os termos de licenciamento do groundpeak, você não deve obter caches em seu aplicativo por outros meios que não a API.
Isso significaria que teríamos que construir todas as funcionalidades em torno da API, tornando o c:geo efetivamente um aplicativo somente Premium.

Bem, uma breve atualização sobre este problema.

• Link para o Contrato de Licença da API: http://www.geocaching.com/live/api_license_agreement.aspx
• Há um novo conector para GeOrg que fornece acesso ao gc.com por meio da API: https://play.google.com/store/apps/details?id=georg.connector.gcapi
  Estou em contato com o desenvolvedor e não é tão fácil quanto parece. Não posso falar muito sobre isso em público.
• Havia um plugin para o Locus, geocaching4locus: http://geocaching4locus.eu/
  Ele forneceu acesso também para membros básicos e, adicionalmente, para membros premium (através da API). Mas agora foi bloqueado pelo Groundspeak:

Caros usuários,

Como alguns de vocês sabem, tentamos fornecer serviço para membros básicos e premium com a mesma limitação. Assim, violamos o Contrato de Licença da API Geocaching para membros básicos. Infelizmente, a Groundspeak, Inc. (a empresa que cuida do site Geocaching.com) detectou nossas ações e fomos forçados a suspender temporariamente a distribuição de nosso aplicativo no Google Play e outras lojas de aplicativos. Alguns de vocês provavelmente tiveram problemas com o login nos últimos dias, o que pode estar relacionado a isso.

Depois de pensar muito, decidimos legalizar nosso aplicativo, mas infelizmente isso afeta os membros básicos. Porque os membros básicos estão limitados a baixar três Geocaches completos por dia por este contrato de licença. Esta foi a razão pela qual fizemos o que fizemos antes. Para membros premium será o mesmo limite de antes, 6 000 Geocaches por dia.

A adaptação para novas regras levará vários dias devido à adição de diálogos de confirmação para os membros básicos que são exigidos por este contrato de licença. Espero que lancemos uma nova versão o mais rápido possível, mesmo ao custo de traduções incompletas.

Equipe de desenvolvedores do Geocaching4Locus

Supondo que o c:geo possa obter acesso à API do Groundspeak:

1. Quais pontos do contrato de licença de API existente precisariam ser discutidos e/ou modificados para atender aos nossos requisitos?
2. Podemos manter todas as funções existentes se mudarmos para a API ou quais modificações técnicas seriam necessárias para que a API conseguisse isso? Encontrei esta página de ajuda via Google, mas não sei se isso reflete a API atual.

Veja também o log de IRC 18.05.2015

Status:
A carta para Bryan foi enviada (disponível para a equipe de desenvolvimento na lista de discussão do Googlegroups).
Aguardando feedback.

Apenas para referência adicional e caso alguém queira ver como isso combinaria no modo de trabalho c: geo:
https://api.groundspeak.com/LiveV6/geocaching.svc/help

@Lineflyer Não confio em APIs que tenham tamanhos de fonte diferentes em sua documentação.

Não é uma documentação real, eu diria, mas algo gerado automaticamente a partir de comentários de código.
Clicar no link revela ainda mais coisas que me fazem estremecer um pouco (Tucson.Geocaching.WCF.API.Geocaching.Types).
Parece que eles não estão realmente projetando sua API como tal, mas usam uma estrutura para gerar e expor algo ...

Olá,

Esta API será descontinuada em 1º de maio de 2019, mas uma nova API REST está em produção há alguns meses e a URL de retorno de chamada precisa ser autorizada pela Groundspeak. Portanto, mesmo que as chaves sejam conhecidas, ninguém não pode usá-lo porque o GS redirecionará para o URL de retorno de chamada.

(Eu tenho acesso a esta API).

• Documentação do desenvolvedor - https://api.groundspeak.com/documentation
• Documentação do Swagger - https://api.groundspeak.com/api-docs/index

Estou afraif, este problema não está atualizado. Enquanto isso, os desenvolvedores da equipe principal do c:geo têm a possibilidade de acessar a API mais recente (ambiente de teste) e a documentação também está disponível.
Se você estiver interessado em ajudar, precisamos esclarecer o que você precisaria para isso e fornecer acesso apropriado

Gostaria de ajudá-lo, mas sou desenvolvedor web (php/go), não desenvolvedor Android.

Para atualizar este problema: Estamos em contato com a Groundspeak há muito tempo, avaliando como podemos usar a API. Ainda há alguns problemas em aberto (não técnicos) a serem resolvidos, mas já recebemos chaves de desenvolvimento para a nova API. Como próximo passo, temos que projetar a integração no c:geo (por exemplo, se for apenas um novo conector ou se outras alterações forem necessárias). Para isso e para a fase de implementação seguinte, qualquer ajuda é apreciada.

Alguns termos de uso da API Groundspeak eram problemáticos no passado (impossível ou difícil de obter chaves para fins de desenvolvimento para qualquer pessoa que pergunte, limitações diárias drásticas no número de caches recuperados e suas classificações D/T para membros básicos, impossível mostrar caches de sites simultâneos como opencaching…), esses problemas foram resolvidos ou são esses problemas restantes não técnicos que você mencionou?
Não vejo a Groundspeak mudando de ideia sobre seu modelo de negócios e sua (falta de) abertura, vendo suas atuais restrições de API.

Bem, a Groundspeak mostrou alguma vontade de discutir estas questões não técnicas e já demos algumas propostas. No entanto, para discutir isso, provavelmente precisamos ver o impacto/diferença entre o uso da API e a implementação atual no fluxo de uso.

Prefiro não fornecer detalhes neste fórum aberto, mas com certeza levaremos alguém disposto a trabalhar na implementação da API nesta discussão, além de envolver nossos usuários antes de uma decisão final.

Alguma novidade aqui? Eu me envolvi com a API antes e não é tão ruim para implementar. Também olhou para a nova versão que eles têm agora.
A pergunta é: alguém está liderando este tópico?
Eu sinto que poderia ser um grande impulso para o c:geo fazer isso.
Qual é o atraso técnico?

Qual é o atraso técnico?

Basicamente mão de obra.

Mas ainda há algumas questões em aberto em relação aos termos de uso. Portanto, é altamente possível que uma implementação técnica não seja usada na forma atual ou se não houver acordo com a Groundspeak.

Acho que devemos começar com algum tipo de análise de requisitos abstratos, depois prosseguir com uma lista de áreas afetadas no c:geo e as mudanças necessárias.

Não há impedimento técnico. Se o Api é capaz de suportar todas as funcionalidades que temos agora, deve ser verificado em detalhes.
Do meu lado pessoal, há falta de recursos e falta de um acordo aceitável sobre o uso da API para membros básicos.
BTW: Onde você vê o impulso para o c:geo neste tópico? Seria um pouco 'mais barato' em termos de recursos de desenvolvimento e seria mais barato para o groundpeak servir os usuários do c:geo, mas de outra forma? Não vejo grandes vantagens no c:geo usando a Api para o 'joe médio'. Os usuários avançados certamente têm outros fluxos de trabalho envolvendo GSAK e ferramentas móveis que se conectam a essa cadeia.