O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
Por que os dados de altitude são tratados como algo secundário
Os dados de altitude têm, neste setor, mais um problema de imagem do que um problema técnico. Eles são apresentados como algo bom de ter, um enfeite adicionado a uma visualização de mapa ou a uma ferramenta de planejamento de voo, em vez de dados dos quais aplicações práticas e reais de fato dependem: avaliação de risco de enchentes, planejamento de drenagem, trabalho agrícola, cálculos de separação de obstáculos na aviação, avaliação de terrenos para construção. Nenhum desses é um uso de nicho. Todos eles precisam que a altitude do terreno seja tratada com a mesma seriedade que uma coordenada ou um endereço, e não como um extra decorativo pendurado em um produto de mapas.
Construímos a altitude como um endpoint de verdade, com seu próprio lugar no produto, e não como um campo opcional obscuro enterrado em uma resposta de geocodificação que a maioria das integrações nunca percebe que existe. Ela tem o mesmo preço de todo o resto, coberta pela cota gratuita diária e cobrada aos mesmos € 0,0001 por requisição além dela, ou incluída na mesma chave Unlimited de € 50, exatamente como as consultas de geocodificação, IP e fuso horário. Não há um preço separado e mais alto associado a ela que sinalize que ela é considerada um recurso especial em vez de um recurso padrão.
Parte do motivo pelo qual a altitude é subestimada é que ela é de fato menos visível em um produto típico voltado ao consumidor do que um endereço ou um marcador em um mapa. Ninguém percebe dados de altitude diretamente como percebe um endereço errado em um formulário de entrega. Essa invisibilidade para o usuário final não torna os dados subjacentes menos importantes para os sistemas que dependem deles. Um cálculo de drenagem que está errado porque o valor de altitude que o alimenta estava incorreto não se anuncia como um endereço ruim. Ele aparece mais tarde, como uma consequência no mundo real, em uma decisão que presumiu que a altura do terreno estava correta.
Tratamos a altitude como uma das partes do nosso produto que está totalmente funcional e que podemos descrever concretamente com segurança, junto com os dados de IP e de fuso horário, justamente porque achamos que ela merece a mesma confiança e o mesmo investimento que qualquer outro endpoint central, e não uma ressalva ou uma nota de rodapé. Ela também está disponível como um complemento opcional adicionado a uma resposta padrão, para quem quer a altitude do terreno junto com uma consulta de localização que já está fazendo, sem exigir um produto especial separado ou um contrato separado só para acessá-la.
O ponto mais amplo é que a altitude é exatamente o tipo de categoria de dados que sofre quando um produto trata a visibilidade para o usuário final como indicador de importância real. Alguns dos usos mais relevantes de dados de localização na agricultura, na engenharia e na avaliação de riscos funcionam inteiramente com dados que o usuário final do produto resultante nunca verá diretamente. Construir bem esses dados, e cobrar por eles como um recurso padrão em vez de um complemento especial, é uma aposta de que as partes invisíveis de um sistema merecem o mesmo cuidado que as visíveis, porque as decisões construídas sobre elas são igualmente reais.