search

bcgov / ols-router

BC Advanced Route Planner
https://bcgov.github.io/ols-router/
Apache License 2.0
23 stars 11 forks source link

In route and directions resources, add support for returning sequence of road segment ids #282

Closed mraross closed 1 year ago

mraross commented 4 years ago

Applications that use the route planner often need to identify roadside features along the best route. For example, OnRoute needs to identify the bridges and tunnels that would block a vehicle of a given height. One way to meet this need is for the route and directions resources to return the sequence of road segment ids of the best route. The sequence should be optional and under control of a Boolean &needSegments parameter to avoid burdening all applications with additional, unwanted response payload and ensure the API is backward-compatible.

mraross commented 4 years ago

If all road authorities (including MoTI) kept ITN updated with their height restrictions, the route planner would only need to return the id's of road segments that had a violated height restriction. Vehicle weight and other dimension restrictions could be handled similarly. Also, the truck resource would only need an &unrestricted Boolean flag instead of a &needSegments. If set to true, the router would ignore vehicle dimensions and road restrictions when computing best route but accumulate and return a list of ids of all road segments that contained violated restrictions. This is a much smaller list than all segment ids in a route.

cmhodgson commented 4 years ago

Returning the list of road segment ids is not a troubling increase in the size of data returned - we already have at least 2 coordinates (and typically more) per segment, potentially plus directions and notifications. If the ids are only returned when specifically requested, then I don't see it being a problem. It feels like that is a more generally useful function, and is less reliant on perfect synchronization of the data from different sources. For example, MoT could add a new restriction at any time, and not require it to be integrated into ITN (which would typically take a month or more to turn-around), as long as they locally associate the restriction with a valid, current ITN segment id.

Either approach does require the router to store the segment ids in memory (which it doesn't currently), and we will have to come up with a way to handle ferry segments, which get merged into complete routes/crossings, and so have several associated ids. I guess we could store the entire list of ids, or we could just use the lowest id associated with the crossing segments as a proxy/placeholder. Shouldn't be a problem for MoT restrictions but could affect other uses.

alixcote commented 1 year ago

Duplicate of the TLIDS #355 . Closing.