A simplicidade do Open-Elevation como projeto de código aberto tem dois lados. O formato de requisição e resposta é realmente fácil de usar, um array de coordenadas na entrada e um array de valores de altitude em metros na saída, mas executá-lo por conta própria significa obter um conjunto de dados de altitude, carregá-lo em um servidor com espaço em disco suficiente para armazená-lo e manter esse servidor disponível sempre que a sua aplicação precisar de uma resposta.
Conjuntos de dados de altitude não são pequenos. Dependendo da resolução e da cobertura geográfica de que um projeto precisa, dados de altitude hospedados por conta própria podem exigir um armazenamento considerável, e dados de maior resolução para uma região específica competem com uma cobertura global mais ampla, porém menos detalhada. Essa decisão, junto com o provisionamento do servidor e a frequência de atualização, é uma responsabilidade real e contínua que a equipe assume no dia em que escolhe a hospedagem própria, e não um custo de configuração pontual.
Um endpoint gerenciado elimina essa responsabilidade em troca de depender da infraestrutura e das escolhas de conjunto de dados de outra pessoa. A consulta de altitude da My Geocode é um endpoint totalmente funcional que retorna a altitude do terreno em metros para uma coordenada informada, com base nos nossos próprios dados de altitude, e não em algo que você mesmo obtém e carrega. A documentação está em /docs/elevation-lookup/.
A forma honesta de comparar esses dois caminhos é olhar para o seu padrão de uso real, e não para uma preferência geral por uma abordagem:
Se as consultas de altitude forem pouco frequentes, por exemplo, geradas apenas quando um usuário visualiza uma rota ou um local específico, a cota diária gratuita de um endpoint gerenciado provavelmente cobre a carga sem nenhuma infraestrutura para manter
Se as consultas de altitude acontecerem em volume alto e estável como parte de um recurso central do produto, vale a pena calcular o custo real por requisição nos preços de um endpoint gerenciado e compará-lo com o custo amortizado de servidor e armazenamento de uma instância hospedada por conta própria
Se o seu caso de uso precisar de dados de altitude em uma resolução ou para uma região que uma escolha de conjunto de dados hospedado por conta própria otimiza especificamente, esse é um motivo legítimo para manter a hospedagem própria, independentemente da comparação de custos
Para equipes que estão migrando de uma instância do Open-Elevation hospedada por conta própria para o endpoint gerenciado, o padrão de requisição (coordenadas na entrada, valores de altitude na saída) continua conceitualmente o mesmo, embora a autenticação passe a ser uma chave enviada como X-API-Key, Authorization: Bearer, autenticação HTTP Basic ou parâmetro de consulta. São 2.500 requisições gratuitas por dia sem nenhuma chave, mais 2.500 gratuitas por chave por dia, contadas por rede, com crédito pré-pago a € 0,0001 por requisição além disso ou uma chave Unlimited a € 50 por mês, com o mesmo preço de todos os outros endpoints da plataforma.
Nenhum dos caminhos é universalmente correto. Um projeto paralelo que ocasionalmente precisa da altitude de algumas coordenadas por dia é bem atendido apenas pelo plano gratuito de um endpoint gerenciado. Uma equipe com requisitos muito específicos de resolução de dados para uma área geográfica restrita pode concluir que a hospedagem própria ainda é a melhor opção, e esse é um resultado legítimo de fazer essa comparação com honestidade.
Automações no-code construídas sobre uma etapa de geocodificação exigem uma abordagem de migração diferente da usada em código próprio. Veja como lidar com essa troca.
Trocar de fornecedor de dados de localização não é apenas uma decisão técnica. Veja o que revisar do lado do processamento de dados e da privacidade nessa mudança.
Desligar a chave de API de um provedor antigo cedo demais ou tarde demais traz riscos nos dois casos. Veja como aposentar credenciais corretamente quando uma migração estiver concluída.