I think it would be really nice to showcase the multimodal power of Valhalla. Some functions we could make use of can be found here https://github.com/valhalla/demos/blob/gh-pages/routing/js/lrm/L.Routing.Mapzen.js

Ref valhalla/valhalla#3680

as long as we don’t allow to set a specific type for each waypoint in the app, we should set an explicit „type“ of „via“. Would actually be nice to have a dropdown to select the type eventually.

EDIT: might also be more issues in how we parse the response. I just repeated what Dave said in the Valhalla issue, didn’t look into it at all.

In context menu (after click into map), we can copy coordinates and afterwards paste them into 1 (i.e. from/start) or 2 (i.e. target/desination) or via points. It would be more convenient if context menu would offer to directly set that location as start/via/target.

Since we implemented a warnings array for user feedback, we should find a way to display them. E.g. one of the most important information it returns is when we clamp the value of an input costing option to a default value when it's out of bounds, e.g. top_speed can only be 10 - 252 km/h and if it exceeds that range we clamp it to 140. That's important info for the user.

The app's layout is a bit of a mess on phone screens, see:

Notes / Possible solutions / Thoughts:

• https://maps.openrouteservice.org/#/ does the responsive-ness on small screens quite well but probably very different to this app. All the advanced features and options are hidden in a sidebar
• If the width is below a certain threshold, the floating-dialog-like box could become full-width (without margin and shadow), this saves a few pixels
• move the small buttons (delete, add, settings) to the bottom (and/or own row). This makes the whole dialog less broad
• just use the common "drag handle" icon for the drag handle, i.e. no numbers, not styled as a button. I think would also be better usability-wise, because it simply is no button and the concept+icon of drag handles is reasonably well understood E.g. like here https://magento.stackexchange.com/questions/272519/how-to-add-draggable-handle-for-configure-product-variants-in-magento-2
• if there is (still) not enough space, it is a common pattern to ellipsize the button bar at the top, the remaining transport modes being behind a "..." button (in a dropdown menu)
• the settings dialog should respect the boundaries of the main dialog, i.e. not appear behind it. If there is not enough space horizontally, it could go below the main dialog. It may be worth a thought to not show the settings dialog by default and/or only if the screen is wide enough

This feature request was triggered by streetcomplete/StreetComplete#3905 , a request to add the valhalla demo to the list of useful OpenStreetMap showcase links in StreetComplete.

we should take the proper defaults for car. as of now car won't be routed through bridges less than 4 m high.

I just PRd the code defaults for those, there were none so far: https://github.com/valhalla/valhalla/pull/3593/files

In the "Distance" box of a driving route a time of 22 min 43 sec is calculated.
The "Route Summary" on the map when the mouse is over the route shows this as 1h 22 min.

Difficult to describe in words so see the attached screen grab.

In the GUI, please allow to quickly +easily reset a single or all settings (driveway factor, step penalty,...) to default values. Example use cases

• You changed settings for a very specific, untypical trip, e.g. with your visiting grandpa in his wheelchair or 2 year old nice, and now you'd like to compute a route for yourself with "normal" settings
• You experience a weird routing result like valhalla/valhalla#3573 and would like to rule out that it is caused by a setting you unintetionally changed to a weird value

A route output will contain info whether it contains ferry, toll sections etc. We could display them as small labels in the "Directions" box.

Right now, we're not testing. We could add some basic e2e tests with e.g. cypress.

oops haha picked that up on the OSM forum: https://community.openstreetmap.org/t/neue-routing-engine-valhalla/7204/16.

When I open valhalla.openstreetmap.de on Android 10 in Ecosia 4.4.1 (AFAIK chromium based) or FireFox 98.3.0, it looks like this:

Issues

• The initial size of "directions" is wider than screen, i.e. one must zoom out via inverted squeeze-gesture (done for the screenshot) XOR move to the right by swipe gesture, then the right part of the dialog appears – which is especially important to toggle "settings" dialog. The gesture must be executed on the dialog and not the map to have the desired effect. I would expect a dialog that is not wider than viewport (preferred by me because less interaction required to use the website) XOR also the map as wide as the dialogs so it looks consistent (not preferred as both would be wider than viewport thus some parts are initially hidden).
• "settings" dialog starts left of viewport. I would expect at least x=0 or even a little higher.
• "settings" dialog is always behind "directions" dialog, thus unusable. I would expect "settings" appears on top of "directions" as "settings" can be closed via X button and opened again from "directions" dialog, XOR "settings" is vertically (not layer) below/above the map and "settings".
• most of the tools on the right are behind "directions" and thus not usable. I would expect "directions" dialog can be minimized/collapsed XOR is vertically above/below the map, so I can see a screen filling map and access the tools on the right.

We should update this app soon. We got a few more costing options merged recently.

When we try to log in using Google , if we use a name which is already taken , the error still persists even after the name is changed.
and sign-up button also stays disabled

Would it be possible to integrate the application with Transitland data? To add the "public transport" option.

I would like to know if your map really calculate routes for trucks. And will avoid tunnels that are not allowed to trucks?

In context menu (after click into map), the two coordinate formats lat, lon and lon, lat are offered. Most software including Valhalla do only unserstand Latitude, Longitude so please color code that format in green and/or make the other visibly lighter grey, so users are more likely to use the "usually working format".

Because I do not see lon, lat much used, IMHO we could replace it with another widely spread format, i.e. 37° 13' 49.1808'' N 18° 21' 27.6732'' E

We should do the same as most map apps and remember the last extent when visiting the website. It's safe to just put it in the local browser store IMO. Smth we might want to do for more info than just extent, e.g. last used costing model?

At the very right bottom, a click onto the link "About this service and privacy policy" shows https://map.project-osrm.org/about.html with infos about OSRM instead valhalla - I doubt this is really appropriate...

When the app loads, we should remove the via waypoint by default. It should just show origin & destination.

It would be very handy if you could share a route with specific settings via an URL.
E.g. if Valhalla yields an unexpected route, you could share the URL for demonstration when reporting the issue at valhalla.

why not..

Currently the sidebar content does not use the full viewport height, which becomes a problem when geocode results are displayed (see image: the lower ones disappear).

There's probably two things we should do here:

1. Have sidebar make use of the available height
2. increase z-index of the geocode suggestion list

For debugging it'd be super helpful if we could quickly switch to openstreetmap.org.

For now, it'd be enough (for me) to have a tool button in the right vertical toolbar to just switch to (more or less) the same map extent on osm.org. We get a lot of issues with links of our web app where we'd like to see the tagging quickly.

Eventually we could add a button in the Directions dialog to generate the same route on osm.org, but less of a priority.

Also, it'd be cool to optionally issue a locate request in the left-click menu to jump to the first way's OSM link.

When I call https://valhalla.openstreetmap.de/ it shows "Directions" tab and Vienna in the map.

When I enter "selters" in 1 (i.e. from/start) and choose one of the offered locations, I still see Vienna but I'd expect to see the area arount the chosen location so I can

• choose the route target from the map without much panning & zooming
• confirm I did choose the correct one - there are 2 towns of that name in 7km distance (even same administrative region) and one more 50km away (other region). There are many more examples for location names that are used multiple times "sufficiently nearby" each other to be mixed up, where "sufficiently nearby" depends on how well you know the region, what transportation mode you use etc.

When I enter a location in 2 (i.e. target / destination), I would expect the map to show either the entered target (same as above) or the whole route. I slightly favor the route.

When adding further points or changing a point, same as for target.

When using isochrones tab, I'd expect the map to show either the entered location (same as above) or the biggest polygone/isochrone.

Everyone who’s interested to apply to GSoC 2023:

please wait with contributions until the projects are announced. We’ll update here once we’d like to start the initial candidate coordination.

EDIT: I realized this is having the exact opposite effect I intended :D We appreciate your enthusiasm! It's good to express your interest here. But please hold off with PRs to not waste your own time. We will soon announce how to organize the candidate selection. Only selected candidates will be required to put in a PR. So please, no pull requests if you're interested.

Just had a confusion about the costing defaults of the web app at valhalla/valhalla#3767. I realized we're swapping the defaults Valhalla uses for width & height. Quick fix.

https://valhalla.openstreetmap.de/directions?profile=bicycle&wps=13.376197814941408%2C52.547776790183214%2C13.38589668273926%2C52.55713840780446%2C13.393707275390627%2C52.5650153081717%2C13.390789031982424%2C52.56655304975672%2C13.389244079589846%2C52.57029962885746

In many cases, elevation change and steepness are contradicting, see this example:

Calculate any route at valhalla.openstreetmap.de and you will get a window "Directions" where you can click "Show Maneuvers" and get instructions like these

If you click "Download" just above the directions and besides to "Show Maneuvers", a GeoJSON is downloaded but it does only contain the pure dot list = way, but not any metadata. What metadata do I think of?

• I heavily miss the navigation points, i.e. start, end, if existing any via points. They help to tell apart several downloaded routes. To my limited understanding of GeoJSON spec, this is easily possible by adding a member properties to all navigation points, with sub-members like e.g. name (e.g. "L5010, Einöd, Gemeinde Herzogenburg, Bezirk St. Pölten, Niederösterreich, 3130, Österreich") and role (any of "start", "via", "target"). If you know one really widely understood standard for that in GeoJSON, let's use that one instead of inventing yet another format :-) In a time boxed research, I did find several standards, e.g. apidocs.geoapify.com which seems to be – to my limited understanding of GeoJSON – a proper GeoJSON extension.
• I heavily miss distance, duration, mode of transportation. They help to tell apart several downloaded routes, but also to quickly get an idea whether a route is feasible for available time & energy.
• I heavily miss directions/maneuvers shown on website. They are important to enable humans to "execute" the route, but also for further processing like estimating/visualizing remaining time & distance. Same as above for standards. If you do not know one widely used one, we can IMHO just recycle the format delivered to the website, or use any of the standards, e.g. apidocs.geoapify.com uses
  "steps": [{ "from_index": 0, "to_index": 1, "distance": 55, "time": 5.71, "instruction": { "text": "Drive southeast on Avenue Jacques Georgin." } }, { ... } ]
• I moderately miss settings like penalties for certain way types. They can be helpful to tell apart if you use different settings (e.g. cycling with your small kids versus cycling with your racing club mates), for debugging and for support requests (e.g. understanding why a steep hill is or is not used by bicycle mode). This seems to be easy to implement as there already is a serialization behind "Copy Settings to Clipboard" button.
• I slightly miss it, but for debugging and support requests, the following could be useful as they make clearer how to reproduce: URL to re-generate this route. Generation time and server and software version.

most issues land over in valhalla/valhalla. maybe less if we include a link to this repo.

We should also highlight somewhere how old the data is. It's always +/- 2 days, but people don't necessarily know that. Simply a request to https://valhalla1.openstreetmap.de/status

Let's try this again:

READ AND FOLLOW THIS CAREFULLY IF YOU WANT TO BE CONSIDERED

We highly appreciate the volume of people who want to be considered for our project idea for GSoC 2023. However, please hold off raising PRs. There is an application process behind GSoC and we will follow it. You will be notified when the application process for contributors is opened (either by us and/or Google) and only then should you apply.

We will close any PRs which will be opened after this issue and will not consider the person raising it. Consider it a first test.

See picture

Browser: Firefox 98.0.1 (64-bit), Windows 11

With the enabled height API we can send a route response to Valhalla to get the full elevation profile and use https://github.com/GIScience/Leaflet.Heightgraph for it.

Hello,
I want to use /optimized_route endpoint instead of /route 'cause i want to re order (re shuffling) waypoint with optimistic weight parameter and best route.
"trip": {
"locations": [
{
"type": "break",
"lat": 48.815081,
"lon": 9.186547,
"original_index": 0
},
{
"type": "break",
"lat": 48.760268,
"lon": 9.153295,
"side_of_street": "right",
"original_index": 2
},
{
"type": "break",
"lat": 48.757094,
"lon": 9.161224,
"side_of_street": "left",
"original_index": 1
},
{
"type": "break",
"lat": 48.791314,
"lon": 9.155888,
"side_of_street": "left",
"original_index": 3
}
]
}
as you can see in response json valhalla re-order waypoint index (array Index) and give original_index for referencing.
best regards.

if no route was calculated we shouldn't have to re-draw/re-request the same height graph. not sure about re-drawing, probably insignificant @TimMcCauley ?

It would be great to clarify the license on this repo with a LICENSE.md or COPYING file.

Thanks!

Valhalla comes with many languages installed, let's make use of them.

reported first by @georg-d in valhalla/valhalla#3573

e.g. https://valhalla.openstreetmap.de/directions?profile=pedestrian&wps=9.884691238403322%2C47.599319584622%2C9.872074127197267%2C47.602632914527724

reports 1:15 h where valhalla only responds with 936 secs = 15.6 mins. somehow there seems to be 1 hour added.

When calculating routes between points that are not far from each other, the map view always zooms out, so that the route becomes way to small to see.

While React class components are not going anywhere any time soon, functional components have become the new norm. A rewrite using functional components and hooks could make the application future proof and might offer a way to simplify the code along the way (especially the React <-> Leaflet interactions, which are all buried inside one big Map component).