opengeospatial / ogcapi-routes

public repo for OGC API - Routes Standards Working Group
Other
10 stars 3 forks source link

Support for composite routes #60

Open bgeorge56 opened 2 years ago

bgeorge56 commented 2 years ago

It would be helpful to explore the case of multi point route responses, which are found commonly in in cases such as long distance truck routing. Such a response would include multiple sub routes and users often ask for details of each sub route, such as driving directions. Since the current OGC standard maps each segment as a feature, a sub route would be represented as a feature collection. Following this, the composite route (the entire route) would be required to be represented as an array of feature collections. This would not be compliant with the current version of standards and it would be useful to explore the inclusion of the case of multipoint routes in OGC routing standard.

jerstlouis commented 2 years ago

Perhaps this should be handled by a "featureType": "waypoint" for a point feature after the last segment reaching a waypoint in the output features of the route. This would clearly indicate when a waypoint from the route request was reached.

cportele commented 2 years ago

The difference to a current routing request with intermediate waypoints in the requirements class of the same name is whether the intermediate waypoints are processed in the provided sequence or if the routing algorithm sees them as a set and tries to find the fastest/shortest/etc route where the intermediate points can occur in any order. This could be handled in the request by a flag that states whether the intermediate waypoints should be processed in order or not.

With regard to the result: So far, the result is always a single route. But also in the current case of intermediate waypoints in sequence, would there be a demand in some cases to make the sub-routes with their individual duration, length, etc. explicit and return a Composite Route that consists of GeoJSON FeatureCollections that are the sub-routes. The Composite Route would then be a JSON object with the same properties as a Route (name, duration, length; duration and length are the sum of the sub-routes) and an array of Route objects. Whether the result is returned as a single Route or a Composite Route is just a slightly different representation of the result and we could add another flag in the Intermediate Waypoints requirements class to control whether the result is a single Route object or a Composite Route object.

Edited to add: Yes, it also makes sense to be clear when a segment ends in an intermediate waypoint, whether adding another "waypoint" feature type or simply flag it in the segment.

jeffharrison commented 1 year ago

On Oct 18 Clemens, Jerome and Nacho (and SWG Chair) agree we will identify route segments that end at an intermediate waypoint with a feature type "waypoint" as proposed by @jerstlouis .. and @cportele will add it to the REM Draft.