I am using ORS public API to get an optimal route between my home-base location to many destinations. I am getting both the optimal itinerary (which destination to visit first, then second, etc) and the actual geometry of the route.
The use case of my application entails knowing the road surface (i.e. distance on paved road, distance on dirt road, etc). However, the returned route geometry doesn’t have this info in its attribute table.
How can I get that info?
I looked into the OSM road data that this service uses and it contains a “road surface” tag. In QGIS, tried to overlay my returned route geometry to this OSM data so that I can select from this data the road segments that correspond to my route. This kind of works but it is approximate since this line-on-line overlay operation is not straightforward when the two layers don’t perfectly align.
My question is, is this something that can be done using the public API?
My next attempt is to try to run the service on my local machine using the OSM road data that I have downloaded. I installed the ORS backend using Docker but I realized I don’t have the “Optimization” endpoint which is what I need to get this optimal route. I am told to get that I need to use Vroom and the information to achieve that is sparse (especially for me who is using Windows).
So, my second question is, if I eventually manage to get this Vroom running on my local machine, will I get back a route geometry that contains the tags from my original input road data?
This does not work with an /optimization-request, but if you have your optimized response, you can use that to query the /directions-endpoint.
Overlaying OSM data in QGIS should work, since the returned geometries should be directly derived from OSM geometries - if you’re using data from the same timestamp, this should be the same.
It is still one row (so, only one geometry for the whole road) and therefore I am not sure how that road surface info is encoded.
By subsetting that column:
surface ← route$extras$surface$values
I get a table apparently containing the surfaced IDs and the distance for each ID. If that’s correct, then this is already good data that I can use. Obviously, I would prefer having each segment geometry separately but, if that’s not possible, then I will settle with this data already.
Thanks.
By the way, this is the list of destinations’ coordinates I am using here:
Hi,
the table you are referring to maps start/end point ids along the route to surface types. You can match these id pairs against the route’s geometry to extract the geometries of individual segments corresponding to different surface types. Please note that these point ids are 0-based so need to be shifted when used as an index to R data structures.
I can’t wrap my head around the structure of the result in this segments object.
It is a list of lists where each of the child lists is also a list of two elements. The first element is a matrix of longitude/latitude pairs and second element is the road surface ID.
I was expecting starts and ends to be pairs of lon/lat coordinates instead.
This is correct, segments is a list of complete segment geometries along with the corresponding surface type ids. If you are interested in the start and end coordinates of the segments, you can easily modify the processing function f to return just these.
This is what made it click in my mind what you did here. Turns out, your previous solution was exactly what I wanted. I just had to convert that matrix into an actual linestring; that’s what I call a “geometry”. Working with sf for a long time, I don’t think of a string of coordinates pairs as a geometry…yet.
Thanks a lot for patience and helping me out; I now have everything I need.
Since my area of interest is located in a remote area, road surface tags from OSM data are not accurate enough. An intern has helped me cleaning the data for this area by eyeballing every road segment overlayed onto a google earth satellite basemap and editing the road surface tags manually.
Now to be able to use this cleaned data, I have to figure out how to get vroom running on my local machine. Right now, I have the ORS engine running fine and accepting API calls.
Any resources I can use?
If your task involves editing road surface tags, you might consider contributing your improvements back directly to openstreetmap.org, unless you are doing so already. This is the preferred approach over local edits, as both you and the community would benefit from it: you would always have access to up-to-date data, while others would see your contributions.
It usually takes around 1-2 weeks for the updates to propagate from there to the ORS public API. The above approach might also save you from setting up a local instance, if only you are fine with the turnover time for updates and the API quotas.
@jschnell Please correct me if I’m wrong, but I’m afraid it’s indeed not particularly well documented how to set up a local vroom instance communicating with ORS. Any hints from you side?
