Specifying an `elevationModel` for energy-efficient route & maximum uphill/downhill slope

[jerstlouis]

In our OSM Routing Engine we have implemented the capability to specify an elevation model in the request allowing to integrate height information for the purpose of calculating energy-efficient routes and specifying maximum uphill and/or downhill slopes.

The slope is also very useful in a pedestrian and bicycling context.

[cportele]

My view is that the typical routing API will not offer the requirements classes "Routing engine", "Routing algorithm" or "Source dataset". This is just too complicated for most users. As a result, I think they should be dropped from Core and be specified in an extension for those special routing APIs that want to expose such information and offer choices (I guess I should open a separate issue about this). A capability to specify a separate elevation model is in the same category, in my view.

We have an implementation of a routing engine for cycling and of course the routing engine uses an elevation model, but that is just built-in and there is no choice to select another elevation model via the API.

[jerstlouis]

@cportele agreed.

Specifying this as an extension, especially with Processes - Part 3: Workflows which allows users to specify an OGC API collection as source data for building the roads network from features and/or an elevation coverage would be quite nice (that's how we implemented this). As a scenario in our MOAW project the elevation coverage was also a nested process creating a DTM by gridifying a dense point cloud.

The other aspect of this issue that we might still want though (in an extension? core?) is being able to specify a maximum uphill and/or downhill slope (as well as the energy-efficient preference -- we added the efficient value so far to the enum).

[gfenoy]

When we were using the OGC WPS 1.0.0 version, it was possible to use the output of the Routes API (coming out of a WPS service execution as a WFS ressource, so let say, an OGC API - Features or a result from the Routes API) as an input for computing and link the elevation information to the geographic point (ref. second screenshot from the 2013 workshop illustrate this quite well, or the screenshot of online server too). I think this is very similar to what @cportele was presenting here, having an external tool re-using the Routes API result for producing new informations about the result.

What I think would have been great is that we may be able to use Processes to invoke the Routes API by using the request the Routes API expect to be provided transparently, simply saying that this input takes the value of this "Routes API invocation". Nevertheless, it would have mean to be able to support POST when fetching href for input passed as references, which is not the case currently nor a planned option in Processes.

[jerstlouis]

@gfenoy Processes - Part 3 - Workflows allows nested processes and OGC API collections as inputs, and processes generating OGC API collection as output.

So the output of one process can be the input of another process.

[gfenoy]

@jerstlouis glad we can thanks to the extension.

But @jerstlouis, can we imagine at a higher level of abstraction, that an "OGC API collection" (which I guess means "OGC API - Features" service which provide access to the feature collection) can be viewed as a WFS service? I feel we can. Then it is the similar using the extension, so how it comes that we reduce that much the capability of Processes that an extension is now required?

Anyway, I still don't understand this restriction about POST when Processes can execute something only using POST. But I may miss something. Anyway, this is another topic that should be discussed more precisely in another ticket. Indeed, how it comes that we would takes advantages of the OpenAPI use without having the capability to invoke execution of services using the GET method.

[jerstlouis]

@gfenoy The idea with Workflows is not to hardcode the request parameters (e.g. format, bbox), so that the same execution request can be used for example to request different areas of interest.

So it is conceptually saying that the input to this process is that collection of data, but leaving it up to the client to build the request URLs which offers more flexibility for negotiating formats, API, and so on. With Workflows, POST is used to first register the workflow, then individual GET requests can trigger the processing and retrieve results for an AoI.

I think with DAPA there is GET support for Processes.

[jeffharrison]

April 27, 2021 Routes SWG meeting confirms that this is a positive direction. This would go in the proposals directory.

Routes SWG will assess whether changes to Charter are required.

[jeffharrison]

06 July 2021 - SWG discussed this and consensus was the MaxUpSlope or MaxDownSlope needs to be done in pre-processing... before the Route is calculated. In other words, this is part of the Cost Function.

[jerstlouis]

The functionality we implemented allows to specify an arbitrary slope value on the client side, i.e. the max slopes are parameters to the cost function. I don't think the API needs to specify whether something has to be pre-processed or done on the fly, since that is on the backend behind the API?

[cportele]

Yes, whether the elevation information has been pre-processed or is processed on the fly is secondary from the API perspective. The key point was in the discussion that the slope is taken into account during the routing. We distinguished at least two different ways to take this into account in the routing process: as a general preference for flatter or steeper routes or as a hard limit, e.g. because the vehicle may have limits).

[jerstlouis]

@cportele Yes that makes sense. The first case can be handled by a preference. The query parameters extension would be for the second case where the client can specify a hard limit (whether for motor vehicle, or e.g. wheelchair accessibility).