Open bgeorge56 opened 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.
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.
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.
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.