We are getting discrepancies in route calculations. When using the LAT/LNG or full address in the operational RouteXL we get the same route in both instances.
When using the LAT/LNG or full address at test.routexl.nl we get two different routes.
In both cases we use Google Maps API to geocode the full address to the LAT/LNG.
Only when using the full addresses at test.routexl.nl we get the expected route, i.e. the route Google suggests with waypoint optimization. We know this route is the best route in real life.
The actual problem is related to the API: we must first geocode the addresses and then insert it in your API. However, the RouteXL API is giving the wrong route (just like the production UI does). When using the full address at test.routexl.nl it produces the right route.
Apparently some slight issues in geocoding results in small differences that in turn result in different routes…
There are several differences between the live and test server.
On live, Google Maps is used for the tiles and geocoding. The optimization of the order of stops is however based on OpenStreetMap. The final directions and paths between stops are again Google Maps.
On test, it’s OpenStreetMap for tiles, optimization, directions and paths. Geocoding comes from several sources: Bing, Here, Photon, Mapquest and Nominatim. You can select you preferred geocoding service in the options. There is no Google Maps on the test server.
Also, the test server has the latest and greatest optimization algorithm. Generally it is faster and generates better routes. But it’s currently running on slower and less reliable hardware.
The API is in line with the live server. That means OpenStreetMap network and the stable optimization algorithm on fast hardware.
The routes are more or less the same. That is, Route 1 is the reversed version of Route 2. The total travel time is 1:36 hours for both. If there are no restrictions in place, like time windows or pickup & delivery, minimizing total travel time is the target for the optimization algorithm.
A few cm’s difference, which may come from rounding, will impact the initial route that is set up as starting point for optimization. The initial route is not based on actual travel times but “as the crow flies”. The initial route may very well impact the final route, especially if there are two which have the same totals.
That’s not our intention. Although website and API are running the same optimization model, both have different applications, user profiles and business models. For one thing, the website has advertisements and the API has not.
It should not be stated that the API is free up to 20 stops. The API is free for all routes up to 10 stops as stated in the official documentation. If you upgrade you can post up to 150 stops. Upgrades are available starting 5 EUR/day.
Just make sure to get a day pass as an upgrade on your account and as not an access code. The one-off access codes are also on the website and require no registration. These can not be used for the API, which has user authentication.
The API and website have their own databases. To work together, they need to share the same database. That’s on our list for development but it is complicated. There is not a time line for it at this moment. Frankly, because not enough users have asked for it. I would advise you to make a seperate thread on this subject on this forum so it gets more attention.
Exactly the same thing happens on test server (with any of the geocoders).
The lat/lng exactly matches the original address, so in theory it should be exactly the same?
Even if the lat/lng would be off by a few cm’s here and there, it should in theory not affect a route of 100km+?
I think this might actually be an exceptional issue. I check the waypoints and it seems the addresses and Google geocodes actually differ here and there.
For example: Hofdijk 531, Rotterdam is geocoded to 51.9274495, 4.4803649 by Google.
When we compare both results on the map, there is a clear difference.
Lat/lng:
Actual address:
Now the route also clearly differs a bit here. We have 10 waypoints in total, so if this happens 7 or 8 times in the total routing it might actually turn out that driving the other way around is more time/distance efficient. Only by a small margin, but still the algorithm works fine as it’s looking for the very shortest time/distance possible.
The issues is clearly with an ‘error’ that occurs on geocoding the address, it’s not RouteXL’s problem.
We’ll do a test by using the Bing API to geocode. Bing specifies a lat/lng specifically for routing, that might work out a lot better.
Would it be possible to bring parity between the usage limit of the UI and the API?
In some places it states that both the UI and the API can handle 20 waypoints in a request. However, in practice it seem only the UI can do this and the API is limted to 10.
For our testing purposes it would be great to have this as 20 waypoints is enough to prove the system works or not. 10 waypoints allows for only very simple routing and doesn’t really bring us the proof of concept we’re looking for.
Ah i see! I had no idea that the pricing model also applied directly to the API, I thought these were just for the website. So, in other words we can just buy a ‘day pass’ and do some large scale testing with that before we move to monthly plan?
