El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Por qué los datos de elevación se tratan como algo secundario
En este sector, los datos de elevación tienen más un problema de imagen que un problema técnico. Se presentan como algo agradable de tener, un adorno añadido a una vista de mapa o a una herramienta de planificación de vuelos, en lugar de como datos de los que dependen aplicaciones reales y prácticas: evaluación del riesgo de inundación, planificación del drenaje, trabajo agrícola, cálculos de franqueamiento de obstáculos en aviación, evaluación de terrenos para construcción. Ninguno de estos es un uso de nicho. Todos necesitan que la elevación del terreno se trate con la misma seriedad que una coordenada o una dirección, no como un extra decorativo pegado a un producto de mapas.
Creamos la elevación como un endpoint real con su propio lugar en el producto, no como un oscuro campo opcional enterrado en una respuesta de geocodificación que la mayoría de las integraciones ni siquiera saben que existe. Tiene el mismo precio que todo lo demás: está cubierta por la cuota gratuita diaria y se factura al mismo precio de 0,0001 € por solicitud a partir de ahí, o está incluida en la misma clave Unlimited de 50 €, exactamente igual que las consultas de geocodificación, IP y zona horaria. No lleva asociado un precio aparte y más alto que indique que se considera una función especializada en lugar de una estándar.
Parte de la razón por la que la elevación se infravalora es que resulta realmente menos visible en un producto típico de consumo que una dirección o un marcador en un mapa. Nadie percibe los datos de elevación directamente, como sí percibe una dirección incorrecta en un formulario de entrega. Esa invisibilidad para el usuario final no hace que los datos subyacentes sean menos importantes para los sistemas que dependen de ellos. Un cálculo de drenaje que falla porque la cifra de elevación que lo alimentaba era incorrecta no se anuncia como lo hace una dirección errónea. Aparece más tarde, como una consecuencia en el mundo real, en una decisión que daba por buena la altura del terreno.
Tratamos la elevación como una de las partes de nuestro producto que funciona plenamente y que se puede describir con seguridad y de forma concreta, junto con los datos de IP y de zona horaria, precisamente porque creemos que merece la misma confianza y la misma inversión que cualquier otro endpoint principal, no una salvedad ni una nota al pie. También está disponible como añadido opcional sobre una respuesta estándar para quienes quieren la elevación del terreno junto con una consulta de ubicación que ya están haciendo, sin necesidad de un producto especializado aparte ni de un contrato aparte solo para acceder a ella.
La idea de fondo es que la elevación es justo el tipo de categoría de datos que sale perjudicada cuando un producto toma la visibilidad para el usuario final como indicador de su importancia real. Algunos de los usos de datos de ubicación con más consecuencias, en agricultura, ingeniería y evaluación de riesgos, funcionan por completo con datos que el usuario final del producto resultante nunca verá directamente. Crear bien esos datos y ponerles precio como a una función estándar en lugar de como a un complemento especializado es una apuesta por que las partes invisibles de un sistema merecen el mismo cuidado que las visibles, porque las decisiones que se toman sobre ellas son igual de reales.