Un perfil de elevación para una ruta de senderismo o un trayecto en coche rara vez es una sola coordenada. Son decenas, a veces cientos, de puntos a lo largo de un recorrido, y cada uno necesita un dato de elevación para construir un gráfico de desnivel o estimar el esfuerzo a lo largo del camino. Ese patrón de uso, muchas coordenadas al servicio de una ruta continua, es lo que hemos optimizado específicamente en una revisión reciente de /v1/elevation.
La estructura de solicitud y respuesta del endpoint no ha cambiado, y todo lo documentado en /docs/elevation-lookup/ sigue aplicándose exactamente como está escrito. Lo que ha cambiado es la eficiencia con la que se procesa internamente un lote grande de coordenadas a lo largo de una ruta, con el objetivo de reducir el tiempo necesario para obtener el perfil de elevación de un recorrido largo en lugar de un único punto aislado.
Como una solicitud por lotes cuenta cada coordenada como un elemento, exactamente igual que siempre, esta mejora afecta a la velocidad, no a los precios ni al comportamiento de la cuota. Una ruta con doscientos puntos de coordenadas sigue contando como doscientas solicitudes frente a la cuota que corresponda, ya sea la cuota diaria gratuita, el crédito prepago a 0,0001 € por solicitud o la cobertura de un paquete Unlimited. Lo que cambia es cuánto tarda en llegar la respuesta, algo que importa directamente a todo lo que construya un perfil de ruta de forma interactiva y no como una tarea en segundo plano.
Esta misma mejora se traslada a nuestro host de compatibilidad con Open-Elevation en /compatibility/open-elevation/, ya que usa el mismo endpoint de elevación subyacente. Todo lo que ya envía lotes del tamaño de una ruta a través de ese host se beneficia del procesamiento más rápido sin necesidad de ningún cambio en la integración.
Las aplicaciones de rutas y senderismo suelen ser exactamente donde este tipo de mejora se nota de forma más directa, ya que un perfil de elevación que tarda bastante más en cargarse que la propia ruta crea un retraso visible para el usuario que espera frente a un mapa. Una respuesta más rápida para estos lotes más largos, con forma de ruta, elimina esa diferencia.
Si tu aplicación solicita la elevación de rutas formadas por muchas coordenadas, ya sea para senderismo, ciclismo o indicaciones en coche, deberías notarlo como una mejora discreta en la rapidez con la que llega un perfil completo, sin que haya que cambiar nada más en la integración. La documentación completa del endpoint sigue estando en /docs/elevation-lookup/.