Skip to content

Output all waypoints as loc parameters, using empty string for missing #384

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from

Conversation

Aebima
Copy link

@Aebima Aebima commented Jul 1, 2025

What was changed:
Updated the code to output all waypoints as loc parameters.
For any missing waypoints, an empty string is used as the value.
Why:
This ensures that the output always includes the correct number of loc parameters, even if some waypoints are missing, improving compatibility and predictability for downstream consumers.

@sfkeller
Copy link

sfkeller commented Jul 1, 2025

This pull request primarily solves the following problem or use case:

I want to send someone a link to OSRM, with end coordinates (destination), leaving the start coordinates empty. I want to leave the determination of the start coordinates to the recipient and user: He starts OSRM with my link and then selects the start coordinates himself. This functionality is also useful for operations control centers, for example, which can use it to transmit to the emergency vehicles an OSRM link with destination coordinates.

Currently, I can pass several loc parameters to the OSRM frontend. But if the first loc parameter is empty, it is ignored and the next loc parameter that is not empty moves up. This means that the OSRM frontend will then fill the start coordinates with my end coordinates, which I don't want.

Here is an example that does not work as desired without this pull request: https://routing.osm.ch/?z=18&center=47.376090%2C8.547234&loc=&loc=47.376091%2C8.546521&hl=en&alt=0&srv=3. Note the ...&loc=&loc=47.37..., and that the first &loc= is deleted after the URL rewrite call and replaced with the second &loc=47.37....

@frodrigo
Copy link
Member

frodrigo commented Jul 2, 2025

Sound reasonable to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants