The current approach looks good on large window sizes but takes up too much space on small screens.

• The logo needs too much space (I think it takes up too much space in every case)
• Route alternatives are displayed as rows. This takes too much horizontal screen space
• The search box itself takes up too much space especially when more via points are displayed
• close or hide elevation widget

Some things are not rendered correclty on iOS/Safari. Have this issue here to not forget about it since I'm not developing on a mac

• Add Point button doesn't layout correctly
• Select element is not styled nicely
• Can't select routes on the map with current event listener setup
• Elevation widget doesn't work on small screens (it is too big and needs to be layout differently)
• Map Style Switch is not visibile on small screens

update the url parameter in the browser window to make the query reproducible

Have only point coordinates until reverse geoconding is added

Add a marker symbol for query points.

Visually pick up markers to clarify which textbox changes which marker

instead of vertical list we could try a more compact horizontal list on mobile devices or use an info box near each route on the map to select the route

See also #44

This feature was also used for better printing.

We need two way geocoding.

1. When markers are set on the map an adress close by needs to be searched and displayed in the search box
2. When an adress is entered into the serach box an according coordiante needs to be resolved

The original gh-maps-client already did something on this topic probably @karussell kann give some insight on this.

[Forked from graphhopper/graphhopper#775|

In addition to "Set as End", an option to "Extend route To" would be very useful. This would turn the current end point into an intermediate point, then set the selected location as the end point.

As qwant/google/bing maps we eventually want to display route alternatives.

To maintain a fast impressio maybe do two requests

1. Request single route
2. Request multiple routes after single route has been received

Maybe requesting multiple routes right away is also fast enough. This should be tested though

• adding start and end points
• insert? (dragging route?)
• delete

I guess renting a box at Hetzner Cloud would suffice. Alternatively syncing the built app to an AWS Bucket would also work.

• While at it, set up a continous deployment from travis.
• Also, add a production webpack configuration with minification, tree shaking and all the other fuzz.

Currently the url only stores the coordinates of selected points. It should also store the addresstext of points if present

It would be nice to have the graph also available for debugging purposes even if no elevation data is present.

e.g display a flat 0m graph with color gradient for elevation=false + debug=true + details=

This is currently important (as the old GH maps allows a lot):

• ability to add more than 3 via points
• use scrollbar somehow if too many via points. Currently several elements disappear on Desktop if adding more and more via points.
• insert via points in the correct order through right click
• drag and drop of the points in the left panel to reorder points

related #143

Currently you can block an area if vehicle=generic&ch.disable=true. We need this in the UI, maybe with some of the UI commits in graphhopper/graphhopper#890 or via leaflet.draw? Related graphhopper/graphhopper#789

introduce a concept where it is easy to internationalize the user facing strings

Reuse existing translations (web.*):
https://docs.google.com/spreadsheets/d/10HKSFmxGVEIO92loVQetVmjXT0qpf3EA2jxuQSSYTdU/edit?pli=1#gid=0

@karussell create one JSON file with all translations: https://github.com/graphhopper/graphhopper/tree/master/core/src/main/resources/com/graphhopper/util

Additionally send correct locale parameter to API to get localized instructions.

Continuing from graphhopper/graphhopper#2239 the following things could/should be improved:

• allow negating areas using == false
• check syntax for areas section (geojson)
• support boolean encoded values without ==/!= true/false? This is important especially for, e.g. if: true, limit to: 100
• auto-convert tabs to spaces, visualize space characters -> no longer needed since we use json now
• fix missing auto completion for e.g. road_class ==| MOTORWAY && in_berlin
• support negation operator !
• support heading penalty
• enable soft wraps? disable line numbers, disable error icons in left gutter
• full screen for editor?
• show 'no suggestions' popup instead of not showing anything when there are no suggestions?
• auto-complete some values, like empty lists for speed/priority, type: Polygon/Feature, else: "" etc.
• support areas defined in server-side profiles, does this even work?
• auto-complete for YAML JSON, especially speed/priority/areas/distance_influence/limit_to/multiply_by would be nice
• give better feedback for hard-to-find indentation errors (maybe use match brackets api to find closing bracket) -> not as critical for JSON anymore, we use match brackets though
• enable close-brackets: https://codemirror.net/demo/closebrackets.html
• catch YAML JSON syntax errors that aren't caught currently, e.g. {}[].
• maybe trigger autocomplete automatically without pressing Ctrl+Space? At least in certain cases? This way maybe users not familiar with auto-complete get to know it more easily.
• probably related to above: update (or close?) auto-complete popup when user keeps typing after it was opened?
• auto-complete for numeric encoded values? maybe just show a hint saying that one needs to enter a number? show "type a number" as suggestion and insert nothing when user presses enter
• tweak CM 'mode' especially indentation is not useful at all, e.g. for almost all cases it does the opposite of what we want, see here: https://codemirror.net/doc/manual.html#modeapi -> not as critical for json, and we use a black font for now since the default (red) seems a bit too much
• simplify error messages (now that they are shown at their origin) ?
• maybe use tooltips to provide some documentation, e.g. for speed/priority/distance_influence
• make it easy to translate error messages? but first make them as simple as possible.
• maybe use code mirror bracket matching
• adjust colors, theme and styles
• check code mirror options to see if we need anything besides the defaults, maybe customize the 'mode'?
• handle YAML multiline syntax like >+ and |... https://stackoverflow.com/a/21699210 we use JSON now
• dark theme and VIM keybindings (just kidding...)

... or in address suggestion list.

http://gh-maps-react.s3-website.eu-central-1.amazonaws.com/?point=14.239884671170358%2C51.38756272791164&point=14.239884671170358%2C51.38756272791164&vehicle=car

There should be a way to initialize the app with some (route request) state and also export the current state. Low-level editing of the request state would also be useful. So far this was possible by editing the URL in the browser's address box, but especially with custom models the URL will become too long.

Maybe there should be a (somewhat hidden) text box that displays the route request as JSON. This way users can easily copy the request to include it somewhere else in their application (use it against the Directions API for example) or share it somewhere to report a routing related problem etc.

Editing this text box would allow setting low-level parameters that are not covered elsewhere in the UI and this way we could also import the JSON that was exported by someone else. We probably need some basic validation for this such that the UI won't be in a broken state in case invalid JSON is inserted.

Not sure yet, just leaving this here for discussion.

I'd find it convenient to be able to center the map view to a specific latitude/longitude, as in the simple search box seen on common mapping services. In particular, when working with a route that has dozens of points covering hundreds of kilometers, it's difficult to home in on a specific place (e.g. a customer location) to see how the map routes nearby.

This is something peter requested as well. Find a suitable unit testing framework and test things right from the beginning

See graphhopper/graphhopper#2264

While starting unit testing on QueryStore I had trouble mocking the api functions. To make things easier when testing convert the collection of api functions into a class which can be injected into e.g. the QueryStore. This way it can be easily mocked with jest

• Convert Api into class
• inject api object where needed
• Maybe divide Api types and Api implementation into separate files?
• Fix api unit tests
• Write up Unit tests for Query Store

• on app start have search box
• have map
• query info endpoint
• retrieve bounding box
• zoom map to bounding box

When I type a location in the first input, then "tab" into second, then type a location in the second input and hit return it should show the route. Currently it is required that I select a location from both suggestion lists to update the route.

Also when copy and pasting a location as coordinate it does not route although no geocoding needs to be done.

e.g. via an x icon or pre-selected text that disappears if typing starts

Some interesting options:

• POI layer
• There is a nice weather overlay showing the current weather in the cities. CC0 licensed
• Also the turn restriction overlay would be interesting to add. CC0 licensed
• Mapillary. I've also heard about that yandex allows panorama images to be used in OSM (maybe that means we can integrate them in leaflet too)?
• Traffic layer from ESRI
• Wikipedia articles via wikipedia api - here is a google maps example using it

duplicate #6

without dialog - create it client-side as we could need it for all alternatives.

We want a single point of translation between ui state and GH request object

Add markers when clicking onto the map. Implementing the folowing behaviour for now:

1. First left click: Place from marker
2. Second left click: Place to marker and send query
3. Next Click remove Markers and route go to 1.

There are several things we can improve:

• If we have a very short route it is zoomed to it even if overview is lost. I.e. we need a minimum bbox (or minium zoom parameter?).
• Additionally ensure that the markers are inside this bbox. https://graphhopper.com/maps2/?point=51.393745872521635,14.263346645918233&point=51.389093074131665,14.27498616022396&vehicle=car
• Additionally we have a flickering for the initial map as we first set the default center and zoom and then set the route (or /info) bounding box. We could avoid this instead of calling fitBounds initially when we calculate zoom+center from bounding box or use mapbox/mapbox-gl-js#5518 see #71
• the map is zoomed out too much (world is visible twice)

Pretty buttons and stuff like that
Logo

Adding a single line of code requires more than 10s to rebuild on my laptop. Do we have to expect this is going to get worse? Is there something we can do about it? If not could it even be worth looking into other build tools like snowpack or vite for example?

Select the vehicle used for the routing request. The following options are avaliable "car" "bike" "foot" "hike" "mtb" "racingbike" "scooter" "truck" "small_truck"

The info endpoint of the GH Server gives information about the supported vehicles by this very instance.

This issue inlcudes:

• Parsing the supported vehicles from the info endpoint
• Giving the user a way to choose a vehicle for routing from the supported vehicles
• Add the vehicle parameter to the routing request
• Add vehicle parameter to url