Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Un archivo GPX grabado con un móvil o con un dispositivo GPS básico suele tener valores de elevación que faltan por completo o son notablemente imprecisos, ya que las lecturas de altitud de los GPS de consumo suelen ser mucho menos fiables que la latitud y la longitud que registran.
Analiza los puntos del track del archivo GPX, extrae solo la latitud y la longitud de cada uno y descarta los valores de elevación existentes que vas a sustituir.
<trkpt lat="45.8326" lon="6.8652"><ele>1050</ele></trkpt>Envía las coordenadas extraídas a /v1/elevation, ya sea con el parámetro points para un archivo pequeño o con un array POST en bloque para uno más grande.
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210}
]
}No todos los usos necesitan procesar un track completo. Antes de publicar la descripción de una ruta de senderismo, una sola llamada confirma la elevación en el propio punto de inicio del sendero.
GET /v1/elevation?lat=45.8326&lon=6.8652Esto devuelve la misma estructura de resultado con una sola entrada, útil para comprobar puntualmente una cifra de elevación de salida o de llegada citada en las notas de la ruta sin tener que tocar el archivo GPX completo.
Los resultados vuelven en el mismo orden que las coordenadas que enviaste, así que escribe elevation_m de vuelta en la etiqueta ele de cada punto del track haciendo coincidir la posición, y sustituye el valor registrado originalmente por el consultado.
<trkpt lat="45.8326" lon="6.8652"><ele>1035</ele></trkpt>No mezcles el formato del parámetro de consulta points y un cuerpo POST en bloque dentro de un mismo trabajo sin ser coherente en cómo haces coincidir los resultados con los puntos del track. Tanto el parámetro points como el array JSON devuelven los resultados en el orden indicado, pero obtener las coordenadas de un punto mediante un parámetro de consulta y las del resto mediante un POST en bloque, y luego combinar los dos conjuntos de respuestas por suposición en lugar de por coincidencia explícita de coordenadas, es una forma fácil de introducir un error de desfase de uno en el archivo reescrito.
Un archivo GPX puede tener miles de puntos de track registrados a intervalos cortos. Enriquecer cada uno de ellos supone una solicitud por punto, lo que se acumula en un track largo. Reducir el muestreo a un intervalo más amplio antes de consultar la elevación y luego interpolar entre los valores consultados para los puntos intermedios es una forma razonable de reducir el número de solicitudes sin dejar de obtener un perfil de aspecto preciso.
Un track que baja por una costa o atraviesa un delta de baja altitud puede devolver legítimamente un valor de elevation_m igual o cercano a cero, u ocasionalmente un pequeño número negativo para terrenos bajo el nivel del mar. Ninguno de los dos es un error. Trata un valor cercano a cero como una lectura real plausible para ese terreno en lugar de filtrarlo como un dato erróneo.
Cada punto enriquecido es una solicitud. Un track de senderismo modesto con unos cientos de puntos, muestreado a partir de una grabación original mucho mayor, se queda muy dentro de las 2.500 solicitudes gratuitas al día incluidas con cada clave.
Limpiar así los datos de elevación convierte un track inestable grabado con el móvil en algo que vale la pena compartir o analizar. La documentación de consulta de elevación describe tanto el parámetro points como el formato de solicitud en bloque.