Allow straight lines

[bagage]

Would it be possible to draw some straight lines? It is mostly useful when you know that a route is there but not present on OSM right know; instead of making a detour you just want to have a straight line.
I don't know how much effort it would require but it would be definitely help, ie I mainly would use it to map actually missing ways.

• client-side track formatting (Client-side track formatting #399)
• extend leaflet-routing plugin
• support in all components (hash, distance markers, ...) (Add straight line support to routing #497)
• UI -> follow-up issue Keep number of buttons on screen low #498
• some remaining tasks

_{edit (nrenner): task list}

[nrenner]

Examples are gpsies.com and outdooractive.com, see also Discussion
BRouter, routing problem, manuell selection way (bridge /ferry) - manuelle Routenauswahl für Teilabschnitt (Brücke / Fähre)–Google Groups (German)

[lorissaa]

Hello, i search for a same function!
gpsies.com has such a function: in the sidebar with a checkbox "follow roads". Is this by routing always checked, follow ways, and unchecked on during routing makes direkt lines, and continue routing on ways checked the checkbox.
Is it possible to install it in brouter-web?

[gimoya]

IMHO this is a very important feature! Please consider an implemantation, if possible! Thanks!

[nrenner]

Some more requests in the Group:

• BRouter Web - waypoints and shortcuts
• Is any way to add no-routed line to route?
• Changing Profile while Routing

Probably related server issue: abrensch/brouter#145.

Seems like the most popular feature request right now, adding it to the "next" milestone.

Just not to route a segment sounds easy at first, but we request the whole route from the server when exporting. So I guess the server would need to support straight line segments, and we would need to pass the additional info which segments are straight lines. Don't know if Android apps would benefit from a server implementation as well, @poutnikl mentioned Locus supporting "straight line routing" for individual segments, but not when recalculating the whole route (if I understand correctly).

I think there currently isn't a way to store additional info on route segments, probably not a big deal, but I guess I personally would want to evaluate switching the routing plugin (#261) first, before putting more work into it.

[bagage]

@nrenner an alternative would be that brouter-web ask brouter engine each segments individually, and rebuild the result from it? It wouldn't work great when exporting to gpx/tcx file, but for rendering only it should be OK?

[nrenner]

The client itself already does only ever request individual segments, even when recalculating the whole route on profile change. Skipping the server request for straight segments will probably make sense there.

But we still need a solution for the export formats. I'm not saying that it's hard, just wanted to mention that it's probably a bit more effort and making things a bit more complicated than one might expect at first.

And yes, we should already have all information in the client to build the whole route, so this raises the question again, if we really need to call the server for exporting.

One concern is, if concatenating segments from individual requests is actually producing the same result as requesting the whole route at once. @abrensch said he made it to be consistent a while ago, so I don't see a problem here. But this isn't a given and the whole route behaving the same as the individual segments also has some drawbacks, as far as I can see:

• initially, start and end point of adjoining segments were not guaranteed to match when requested individually
• no height when via point is on bridge/tunnel (bug in hight model at bridges abrensch/brouter#70)
• no continuous elevation buffer, cost can differ for exact same route with different via position
• turn instruction when via point is exactly on junction node?
• ... ?

The question is where and how to do the formatting, see also previous discussions in #226 and abrensch/brouter#91:

1. as is on the server, passing straight segment flags in parameters
2. client-only, would duplicate the server formatting code, including multiple turn instruction formats depending on the current profile setting
3. use server as pure formatting service without routing, passing concatenated tracks instead of route waypoints
4. export requests individual segments instead of whole route, without straight segments, and somehow merges the formatted segments into one document (your suggestion?)

@abrensch we briefly talked about straight line segments at SotM, and I take it that it wouldn't be a big effort to support those in the server? The other question is, do you think it makes sense to have this in the server or would you prefer if we handled it in the client only?

[pipiiri]

Bonjour
serai t'il possible d'avoir une fonction pour tirer une ligne droite dans un tracé lorsqu'il ni a pas de voirie sur la carte.je prépare mes circuits de randonnée sur l'ordinateur et je l'exporte en KML pour l'utiliser sur le smartphone mais je suis souvent bloquer par ce problème.
un exemple en pièce jointe.

[bagage]

Oui @pipiiri c'est exactement ce à quoi ce ticket fait référence. Ça demande du boulot dans l'application qui n'a pas encore eu lieu mais j'espère qu'un jour ça sera implementé. En attendant, n'hésitez pas à rajouter un 👍 sur le premier poste, afin qu'on puisse analyser la priorité des tickets. Merci !

[polyscias]

Understood straight lines are a wanted feature but it means in think in most cases that the openstreetmap data does not have the paths that the user wants to take.

Looking at it from a system view, the preferred solution is to update the map so it is working in the future and others can also benefit. It is good not only to use openstreetmap but also to contribute.

So how about:

1. Popping up a indication when drawing straight line that it would be good to update the openstreetmap data if only by adding a OpenStreetMap Note.
2. Save all straight line somewhere on a server so openstreetmap volunteers can have a look and update the map

Point 2 has some privacy implications so a checkbox to untick this functionality?

[Phyks]

I had the same issue today with a ferry which BRouter was ignoring on my road. I ended up breaking the route into multiple parts and having multiple GPX. Lead me to another idea, would it be simpler to handle multiple routes in the BRouter interface (multiple start / end pairs of points) instead of changing BRouter to handle straight lines?

[poutnikl]

@Phyks Something similar to LocusMap app route segments in its planner, where each segment is calculated independently in a serie of route calculations, where some segments may be straight segments.

[nrenner]

I hope to get started working on it this week.

[rkflx]

I recently noticed a similar feature on https://cycle.travel/, not sure for how long it has been there already: You can now click on a via point and select "Go any way / paved / direct to next".

The UI is a bit hard to spot on first glance, but has an advantageous property compared to a dedicated "draw a straight line" tool: It allows to change sections of the route inline, not only append straight lines while drawing. Still, I find their pop-up context menu for vias gets in the way too often, I prefer BRouter's approach (delete on click) which is much faster to use. So how about this (unless you already have a better UI in mind):

Idea A)

• Draw a route by clicking to add vias (as before).
• Drag a section to create an inline via (as before).
• Click on a section to convert it to a straight line and possibly change its colour and/or line style (currently nothing happens on clicking).
• Click on a straight line to enable routing for this section again (i.e. it should be possible to undo straight line routing again).
• Extend the hover popup help to also mention that clicking toggles straight line routing.
• On touch screens you currently have to long-press to add a via. Here a pop-up context menu to choose between "Add via" and "Convert to straight line" might be needed.

This approach is probably efficient to use, but still a bit hard to discover in the first place (you have to experiment or notice the popup help) and not ideal on mobile.

Idea B)

• Add a new tool button which toggles "straight line editing mode".
• If activated, clicking on a section toggles between straight line (with a different colour) and regular routing. (Other modes could be added later on.)
• The mode stays active until it is disabled again via the tool button.
• Optional: Change the route's colour when the mode is active (so users see that they are in a different mode on the map too), and highlight sections on mouse hover (so users know which section will be affected after clicking).

This approach is slightly easier to discover and works well on mobile. It needs two additional clicks for a single straight line (still only two extra clicks in total for multiple straight lines), but since adding straight lines is probably much less common than adding vias, it should be okay. Nevertheless, it adds one more tool button, of which there are already too many. With so many steps it might also be difficult for users to know they have to click on the route too after toggling the new mode (they might think it auto-applies on the section they last "looked at / thought about").

Personally, I'd probably prefer A) for its efficiency and simplicity, but I can see other people might like B) too.

[mgoyanes]

I believe that this is called, at least in some places, route "As the crow flies".

[marwjk]

I've been using brouterweb for a few days now and I really like it so far - great job, thx :-)

Me too, can only confirm the wish for this feature. It would be very helpful indeed, not only in the case of inaccuracies or errors in the map, but also if you have to change from one path to another cross-country (bike or hike). For such cases it currently seems not to be possible to create a usable routing. Or is there any other work-around, beside splitting to different routes?

[mash-graz]

i also would appreciate some support for this feature!

although i usually try to improve the OSM road data just as well to share knowledge about my running routes in the woods with others, there are often cases, where you simply can not draw the most practical chosen way on a correct public map (e.g. it slightly ignores some offical regulations, crosses private grounds/fields, etc.). it would be really helpful, if brouter-web would support workaround capabilities for this class of very common real world circumstances as well.

[peterelli]

Hello,
Thanks for this great tool. On behalf of many users out there, I would like to highlight two topics concerning route planning and creation.
These are the possibility (priority 1) to draw straight lines independently from the map and (priority 2) to show POIs which are of interest for your own route planning and which should later optionally be saved together with the track. (POIs around the current track)
Thanks for your work and for the best planning tool on the web.
Peter

[Taunide]

"Add straight line" : we had this usefull feature in gpsies.com (which is ceased now sadly).

Sometimes just a few meters are missing, i.e. to get away from a fast, dangerous street.

To create crossings at OSM where none are visible as a workaround isn't a right way to use OSM.

[darkmattercoder]

Thank you @mjaschen for the setup. Basically it works good.

I played around a bit and have the following feedback (not sure, whether any of this is related to the concrete instance, but I assume no...)

• Sometimes, when a beeline is involved, parts of the route seem to fail to render the Height shading (hope that is the correct English term). This does not apply for all of the cases. Sometimes, reverting a beeline to a normal segment, the height shading appear again for the whole routes. Beelines are mostly either in a greyish or blueish shade, but sometimes, after toggling back and forth, I saw them with the height shading design sometimes.
• The most annoying thing I noticed is, that at some point after rearranging segments, switching beelines on and off, I always get into a situation where the drag handle does not work anymore. Neither for beeline segments nor for the rest of the route. The route is from this point on not changeable anymore at all. I still can delete some waypoints. What I cannot delete anymore (left click has no effect at all) are beeline segment waypoints. They stay rendered on the map (but they are rendered as the drag handle, not as a waypoint) and seem to do nothing on click.
• Both of the above issues are fixed as soon as I reload the page. However, a reload also resets all beelines to be regular routed segments again.
• I have a slight feeling, that the above both applies more often, when a beeline is produced via ctrl+mouse rather than by clicking on a segment. I also noticed a drawn beeline (ctrl and click) caused an incomplete export as gpx, even if after the beeline segment, a regular segment is appended (see next point)
• The export of the planned route with beelines does not export beeline segments which are at the beginning or at the end of the track.
• I also have the impression that things with beelines work worse, once a waypoint is set in an area where no vector is in the map.

I know, that this is not the best exact technical description of what I did, but thats the things I found so far by klicking around a few minutes.

[nrenner]

Thanks for the feedback, but it's really too early for error reports, this is still in the middle of development and not ready to be used yet.

[rkflx]

const beelineButton = L.easyButton({
transition-duration: 0.3s;
height: 0;

I guess this is good enough for now, maybe buttons can be reorganized later.

While I may have hoped for a more collaborative discussion design-wise, it is what it is, so I won't waste more time on it. Let me know once it makes sense to post new bugs I discovered after the recent beeline commits.

[nrenner]

This is not set in stone yet, it was just the most straightforward way, using an EasyButton example. I was going to comment on that and perhaps open a separate issue.

[ravenfeld]

Hurry to have this feature, it's what I need to track my MTB and trail rides.
I've become a fan of brouter-web because I can have all the layers I want and I have exactly the maps that are most adapted to my practices.
Very good work, sorry I can't help, I don't know js well.

[rkflx]

brouter-web commit 47f3a06
Improve route interactivity by using canvas

This one increases the visual gap between cursor and trailer+marker significantly during mouse movement when dragging vias or adding waypoints (for both my mobile and desktop setup). Even for slow movements I can observe gaps up to 150px. Performance becomes really laggy, i.e. redrawing of trailer+marker cannot keep up with the cursor movement anymore at all. Increasing window/canvas size makes it even worse.

This has been fine before, and now sadly degrades the user experience quite a bit. TBH, that's not a compromise I'm willing to make.

In addition, the change from SVG to canvas introduces a weird bug: When clicking next to the route within a distance of tolerance, it zooms in (tested on mobile and with Chromium's dev tools in "Desktop (touch)" mode).

tolerance does not seem to work for SVG according to Leaflet/Leaflet#7515 (although it sounds like implementing it for SVG in the future is not ruled out yet). Hopefully there is another solution, e.g. by somehow handling it client-side for only the cases we care about? Find an alternative for the dashed line beeline visuals? Or at the very least BR.Browser.touch could be used to fall back to the SVG renderer on desktop / non-touch platforms!?

[nrenner]

Switching to canvas is a bit of a bold move that might have unexpected consequences, so far I have found and fixed two issues.

This one increases the visual gap between cursor and trailer+marker significantly during mouse movement when dragging vias or adding waypoints (for both my mobile and desktop setup).

I haven't noticed anything like that, will see if I can reproduce and would be interesting to investigate. Generally I would expect Canvas to be faster than SVG. OpenLayers has switched everything from SVG and DOM to Canvas.

When clicking next to the route within a distance of tolerance, it zooms in

I have seen that during development, but not anymore. Will need to check again.

Hopefully there is another solution

I would first want do check if there is anything going wrong or to be improved or if Canvas is really slower in some cases.

I have looked at some plugins that add a tolerance for SVG by adding a wider, invisible line on top. But they all just duplicate the layer and its geometry, which might also have perfomance implications.

[rkflx]

I'm not making this stuff up, in fact I arrived at the commit via git bisect ;) . For my upcoming patch series I am currently looking into how it affects performance too, let's see when I'll find time to share results of my testing.

OpenLayers has switched everything from SVG and DOM to Canvas.

maplibre-gl-js is using canvas too, and is even slower. BRouter-Web is about the only fast (as in "what works fast on your machine might be very slow on my machine") app left, I'd be wary of giving up that differentiating factor. I mean, I could just revert the change for my own installation, but I'm mentioning it here because it could affect more people.

My general impression after reading lots of StackOverflow discussions is that canvas is supposed to be used if performance of thousands of single map objects matters (e.g. live view of a public transport network), but it can be slower for simple use cases (like displaying a map and a single track).

I would first want do check if there is anything going wrong or to be improved or if Canvas is really slower in some cases.

Something nice to know I found, but probably more related to Leaflet itself rather than our use of it: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas

(Looking at Leaflet<slash>issues/7350, I'm not so sure canvas is very well optimized in Leaflet yet...)

I also noticed in Leaflet's docs that the renderer can be changed for single paths too opposed to applying it to the whole map. Did not try this yet, though.

Do you know why tolerance is not implemented for SVG currently, i.e. is there a fundamental problem?

(If we have no other choice than to use canvas in the end, then perhaps it can be done in a way which has less impact, e.g. only on mobile, or only for beelines...)

[stefanct]

Just some minor feedback because it has been discussed: As a long-term OSM contributor I would not like to see contributions that are solely made to make some routing work. In the last years OSM increasingly gets worse in some aspects because of lowering hurdles for editing so that "everybody" can do it. Pushing people to contribute who are not really interested and don't care for the correctness of the data does not help OSM at all - rather the opposite: it creates more work for the experienced people to clean up behind those who are not willing to invest time in learning how to do it properly.

I have briefly tested the ctrl-click implementation and apart from some minor problems (related to deleting nodes part of beeline segments which arguably are not even bugs) it is a very nice improvement that fixes my biggest problem in brouter-web, yay. The only problem that I can see that is not a bug is that the feature is too hidden which is a very bad thing (I strongly disagree with some "UX" folks on that - features need to be discoverable from the UI itself). One way to improve on that would be to change the supposed line and/or cursor when ctrl is held to indicate the changed behavior. Making the line non-dashed would make it pretty obvious IMHO. The user would still need to discover it somehow but such an indicator makes it way more easy to find compared to if nothing changes until you actually click.

[Taunide]

Thanks, I've tested https://brouter.damsy.net/v99.52.4-beeline/ for a while and it works good and useable on a Windows device for me.
But it seems so that the distance isn't increased when adding straight lines to a route. The overall total is lower as it should be.
One can create subsequent straight line points in a row, which is usefull, but when exporting the route as gpx the points don't show up in the file.
For working with an Android device in the field, I would wish an extra button for changing between routing points and straight lines and back.
I agree to some people that adding this feature could help to avoid the mapping of some very "own" paths into openstreetmap just to make routing work.

[isartrails]

Cf #68 (comment):

1. Use ctrl+click when adding a new routing point

2. or click on an already existing route to toggle between "straight line" and "follow-way line"

1. ctrl+click doesn't work on my mac, it opens the context menue.
2. I did not understand "existing route"...

[mjaschen]

I did not understand "existing route"...

Just click on any given route segment (between two points). Example video:

https://docs.google.com/uc?id=1gLOsoaGYboeyrX5UIP7s0o0cwhBusHiB

[nrenner]

@isartrails

1. ctrl+click doesn't work on my mac, it opens the context menue.

It's shift+click now.

[nrenner]

I think this is ready for testing now (on the master branch).

Given that this has been taking so long, I guess I will leave the UI as is, especially the toggle button, see follow-up issue #498 for later.

Usage:

• append straight lines by activating the toggle button that appears when drawing is active (B key) or by holding Shift key while clicking
• change an existing route segment beween two markers to a straight line (and back) by clicking on it (or rather the edit handle)

Mobile behaviour will change a bit:

• increased touch tolerance, so it's easier to hit the route line for dragging and tapping
• for adding a via point, you previously needed to tap on the route first to make the edit handle appear then drag that. Now you can drag the route right away
• previously a tap on the route made the Heightgraph map marker appear (simulating mouse hover), now a tap switches the segment into a straight line (corresponding to a click on desktop), the height marker can still be shown after a long press

[drdrknox]

Hi @nrenner
I'd love to help testing but it seems I'm on the wrong instance (I've been using https://brouter-next.m11n.de/) - is that correct? Because on this one the caption on the straight line icons says "Toggle straight line - B Taste" but in fact it's pressing Strg+dragging a straight line, neither B nor Shift-key do work which is why I was assuming I could be on the wrong instance?
Best regards
Paul

[mjaschen]

@drdrknox The version on brouter-next.m11n.de is outdated.

I've merged the changes and deployed the new version to bikerouter.de.

[0709wiwiwi]

@mjaschen
Does the job. Excellent. Thanks.

[drdrknox]

I've also tested it, perfect job and great addition to the brouter functions!

[nrenner]

@0709wiwiwi this seems to be unrelated to the current issue - can you please open a new issue for that.

[0709wiwiwi]

OK Roger. I hope I did it correctly. (Not used to be active here)