API Optimización

Introducción

Open Street es un servicio de optimización de itinerarios a partir de bibliotecas de programación Open source y de un motor de búsqueda interno. Basicamente, si usted conoce los puntos de encuentro pero no sabe en que orden es preferible recorrerlos, Open Street le puede ser útil.

Nuestra aplicación web utiliza las API Open Street, especialmente aquellas que permiten optimizar los trayectos, solucionando el problema del comerciante vehiculado.

El lanzamiento de un cálculo por la API de optimización

Protocolo utilizado

Esta API utiliza el método GET implementado en el protocolo HTTP 1.1. Podemos utilizarlo desde un navegador web estándar o cualquier otra biblioteca para descargar datos desde un servidor web. Esta API optimización no es capaz de recibir caracteres especiales o acentuados, pero las direcciones URL aún debe ser codificadas correctamente. Los nuevos navegadores codifican automáticamente las direcciones URL, pero no siempre las bibliotecas HTTP.

Todas nuestras API son compatibles con la compresión gzip, por lo que es muy recomendable activar esta característica en su cliente HTTP. Para verificar que la compresión está activa, el encabezado de la solicitud del cliente debe incluir Accept-Encoding: “gzip, deflate” y la cabecera de la respuesta del servidor debe incluir Content-Encoding: “gzip”. Esto reduce casi un 50% del tiempo de descarga de datos.

El tiempo de cálculo aumenta con el número de puntos. Específicamente, se incrementa al cuadrado del número de puntos. Se tarda unos pocos segundos para diez puntos, y pocos minutos para cientos de puntos. Para obtener más información sobre la predicción del tiempo de calculo, pinche aquí.

Por tanto, es importante que el cliente HTTP utilizado sea compatible con un tiempo de espera de varios minutos. A petición, podemos proporcionar la función que da el tiempo de cálculo estimado basado en el número de puntos con el fin de implementar una barra de progreso en una aplicación.

Nuestro motor de resolución aprovecha una memora interna que permite acelerar una consulta desde el momento en que se ha solicitado. De este modo, al lanzar un cálculo, o simplemente al cambiar algunos puntos de un cálculo iniciado, el tiempo de resolución será significativamente más corto.

Datos de entrada

Para funcionar, esta API requiere datos proporcionados como parámetros de URL. En la siguiente tabla, los asteriscos * indican los parámetros que se requieren para ejecutar un cálculo.

Los puntos geográficos a optimizar deben necesariamente ser introducidos en formatos de latitud, longitud, y no como direcciones postales. La API de codificación geográfica Open Street permite esta conversión.

Parámetros Valor Explicación
pts* 46.2021852,5.2221591 Los puntos de paso deben ser separados por barras verticales |. Los números deben ser de 1 a 10 cifras decimales. La ausencia de decimal es rechazada debido a que no es lo suficientemente específico para describir un lugar.
nb* 3 a varios cientos Número de puntos sometidos. Debe ser coherente con el parámetro pts, y permite garantizar la integridad de la transmisión.
mode driving ou bicycling ou walking Medio de transporte: coche, bicicleta o peatón. Las distancias se modifican para utilizar los canales adaptados a cada uno de estos medios. Por razones técnicas, hemos inhabilitado actualmente los medios “bicycling” y “walking”.
unit m o s La elección de la unidad de trabajo para optimizar la distancia en metros, o el tiempo de viaje en cuestión de segundos.
tour open o closed La elección de una ruta de bucle abierto sin retorno al punto de partida o en circuito cerrado con retorno al punto de partida.
key* caracteres Clave de autenticación de cada usuario.

En cuanto a los medios de transporte (modo), muchas pruebas se llevaron a cabo para los viajes en coche, y menos para el ciclismo o peatón.

La unidad de trabajo (unidad) recomendada es m.

El tipo de ruta (tour) cambia profundamente la interpretación que se hace de los resultados. En el primer caso de bucle cerrado, el resultado no posee realmente un punto de partida, y el bucle puede ser recorrido en el orden deseado. En el segundo caso de bucle abierto, el punto de partida es el primer punto proporcionado a la API, mientras que el punto de llegada es el último punto proporcionado a la API; el orden del resultado debe ser considerado como tál.

Con el parámetro a su vez “cerrado”, los resultados de la API se pueden presentar en cualquier dirección. Es por esto que se puede encontrar una diferencia entre este modo y el modo “abierto” en el que se habría fijado el mismo punto de partida al punto de llegada: el sentido de la marcha del bucle puede ser revertida.

Un ejemplo concreto

Consideremos el ejemplo simple de un trayecto de cuatro puntos donde se desea calcular el orden optimizado de paso.

Punto Dirección postal Datos lat,lon
A 135 rue Saint-Leu, 80000, Amiens, France 49.8998757,2.300284
B 1 rue Marcel Cuny-Cronne, 54039, Baccarat, France 48.4510104,6.7483327
C 37 rue Bronzac, 94230, Cachan, France 48.7830011,2.333158
D 1 Boulevard Maréchal Foch, 76200, Dieppe, France 49.929876,1.078363

Las direcciones postales han sido previamente convertidas en coordenadas de latitud, longitud a través de nuestra API de geocodificación. Aquí le mostramos como aparece esta consulta formulada para la optimización de la API. Tenga en cuenta que se requiere una clave de autenticación válida.

 

El procesamiento de los resultados de la API de optimización

Datos de salida

El formato de datos de salida es un objeto JSON que puede ser descargado y procesado por una aplicación, o visualizado a traves de un navegador. La compresión relacionada con el protocolo HTTP es gestionado por el cliente HTTP de forma transparente para el desarrollador. A continuación la tabla de parámetros de salida.

Parámetros Explicaciones
DIMENSION Dimensión del problema, cifra idéntica al parámetro de entrada nb.
TOUR Idéntica al parámetro de entrada y se muestra como un recordatorio.
COMPUTE_TIME Tiempo de cálculo puro en segundos.
TOTAL_TIME Tiempo de procesamiento de datos y del cálculo en segundos.
OPTIMIZATION Orden de trayecto optimizado utilizando los indices de la solicitud inicial.
STEPS_DURATIONS Tiempo de búsqueda por etapa (en segundos).
STEPS_DISTANCES Distancia recorrida por etapa (en metros).

Una muestra del objeto json tal y como es reenviado por la API.

Recomendaciones de uso

Cuando se trata de este objeto JSON, debe recuperar los valores a traves de su canal asociado, y no por su posición en el de documento o en el numero de línea. De hecho, otros datos pueden ser insertados en el futuro y esta es la única manera de respetar la compatibilidad. Es posible, sin riesgo, transformar el objeto JSON en una tabla de su lengua de programación con una biblioteca especializada, bajo la condicion de conservar los canales y valores. Para obtener más información sobre JSON, visite el sitio json.org que proporciona una lista de las bibliotecas de decodificación en diferentes idiomas.

Hay que tener en cuenta las recomendaciones relativas a la interpretación de los datos según el parámetro tour utilizado. En esta caso específico, la ruta es un bucle entonces podemos tomar en la dirección deseada, y desde el punto deseado. Por defecto, el primer punto del bucle es el primer punto de la consulta.

Al calcular una optimización de rutas, los lugares de partida y de llegada pueden ser almacenes, oficinas centrales, hogar, hotel, etc. Es importante incluir estos puntos en la optimización, y no sólo citas puntos.

Para este simple cálculo de cuatro puntos, se observa que el orden optimizado es idéntico al orden de la solicitud. Sería diferente para un cálculo de 40 puntos.

Para los cálculos que tiene numerosos puntos (varias decenas), podemos constatar una variabilidad del resultado multiplicando las solicitudes. Esto es bastante normal porque nuestro algoritmo de resolución se inicializa a traves de una variable aleatoria. Sin embargo debe tener en cuenta que estos resultados tienen longitudes totales cercanas al 95%. Si desea tener la certeza absoluta de obtener la mejor optimización de kilometros, tiene la posibilidad de relanzar un cálculo varias veces y tomar el mejor resultado.

Los códigos de error

Puede ocurrir que el calculo falle debido a un error en la solicitud o un error interno de nuestros servidores. Éstos son el tipo de código que se pueden mostrar.

La siguiente tabla describe el significado de los diferentes códigos que pueden presentarse al utilizar nuestra API. Toda salida que no contenga los datos de con la frase “optimización” debe ser considerado como un error. Los siguientes mensajes de error pueden cambiar y es por eso que es mejor para probar la presencia de la frase “optimización” para detectar un error.

Código Explicaciones
SYNTAX_ERROR La petición esta incompleta o contiene un error.
INVALID_LATLON Las coordenadas de latitud, longitud no son décimales entre 1 a 10 décimales.
WRONG_KEY Su clave de autenticación es falsa. Contáctenos.
NB_IS_INCONSISTENT El parámetro nb es falso.
LIMIT_REACHED Usted ha agotado sus cuotas. Saber más.

Los siguientes códigos son particularmente raros pero resulta útil conocerlos.

Código Explicaciones
BINARY_NOT_FOUND El sistema de resolución esta ausente, obsoleto o corrompido. Contáctenos.
INTMAXDATA_TOO_BIG Las distancias entre los puntos es muy grande, superiores a la distancia París-Pekín. Puede significarse de un error de geocodificacion en el continente equivocado.
PRESET_UNKNOWN Error de la configuración del sistema. Contáctenos.
RESOLVER_HAS_FAILED La resolución ha fallado luego de una normalización de la matriz. Contáctenos.
RESULTS_NOT_FOUND El problema no tiene solución. Contáctenos.
DISTANCES_TIMEOUT Problema interno. Contáctenos.
DISTANCES_ERROR Problema interno. Contáctenos.

Desarrollos futuros

  • Otros parámetros facultativos serán desarrollados para afinar el cálculo
  • El método GET del protócolo HTTP limita el tamaño de las peticiones a 8 Ko, es decir aproximadamente 200 coordenadas en una sola optimización. Este limite sera sobrepasado en el futuro por el uso facultativo del método POST.