curbsides, point_hints etc.
Closed this issue · 6 comments
The /route endpoint of the GraphHopper server (and the Directions API) support some parameters that we cannot use in GH maps so far. Some rather important ones:
- point_hint
- snap_prevention
- curbside
- heading
- pass_through
Not sure how to support these. point_hint and curbside can/need to be specified for each point. pass_through and snap_prevention are global parameters that only need to be specified once. heading is something in between, but it probably would be sufficient to only support a single heading for the first point, then it would also be a 'global' parameter.
Adding some kind of settings menu where we could put such global parameters seems not too complicated. Adding UI elements to specify point_hint and curbside for every point could lead to a bloated interface.
Maybe we could allow setting some parameters via the query input boxes, or a context menu for the markers? Not being able to set curbside/heading certainly makes it harder to test and improve these features.
This is an interesting idea. An even lower level approach would be to just forward a certain set of URL parameters to the API instead of a separate UI. (Of course this means that these parameters disappear after loading the URL and it might be unclear if follow up contain the parameter or not, but probably a similar problem exists with a context menu for markers?)
Entering the parameters into the input boxes seems more reasonable than entering them via the browser's url field, doesn't it? But we would have to make sure this does not interfere with the auto-complete / geocoding menu. If we allowed setting these parameters via a context menu of the markers there would be no need to display the exact values explicitly at all and we could simply visualize them instead. For example we could show a little arrow for the heading or some modified marker for the curbside parameters (?).
(Of course this means that these parameters disappear after loading the URL and it might be unclear if follow up contain the parameter or not, but probably a similar problem exists with a context menu for markers?
In any case the parameters would be stored in the app state, just like the query point coordinates. And we can add them to the url as well, just like the coordinates. Or maybe I did not understand what you meant?
Entering the parameters into the input boxes seems more reasonable than entering them via the browser's url field, doesn't it?
Ah, sure. I thought it to be more a debugging feature as e.g. "heading" is only used for navigation use cases and not for route planning. (btw: in the navi branch we already use "heading")
If we want this to be used "officially" I find a context menu of the marker not a bad solution especially for curbside where there are only 3 values.
btw: we could use the street information of every geocode result by default as a point hint but we would have to make sure that this is somehow visually indicated with a dotted blackline to the snapped point or something.
Probably these additional hints are more a topic for https://explorer.graphhopper.com/ and not for GH Maps?
Yes, especially once we add draggable markers in explorer and we are able to create a route (including curbsides etc) via the url there.