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.

• [x] client-side track formatting (#399)
• [x] extend leaflet-routing plugin
• [x] support in all components (hash, distance markers, ...) (#497)
• [x] UI -> follow-up issue #498
• [x] 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 (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 :+1: 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.

[seikkailuendurolla]

I was testing the bouter-web right now and this would be an important feature for me.

[ysveikata]

Very important feature. I see that this is the next milestone. So thanks a lot and looking forward to that!!

Perhaps good to know that some would like to use it not only for connecting routes on land, but also for river routes (e.g. SUP, kayak). Currently, lakes are not available there. And it also happens that one would like to shortly cross land to get from one river (or lake) to another.

[abrensch]

Today I had the idea to do a cheap hack on the server side by (mis?)-using nogo-areas for that purpose

Nogo-Areas with waypoints inside are not really well defined yet.

Up to now, they where just ignored.

So we could define: a nogo-area with 2 adjacent waypoints in it triggers a bee-line between them.

I coded that patch and deployed it at the server instance:

http://brouter.de/brouter-web/#map=14/49.6745/8.5106/standard,route-quality&lonlats=8.514906,49.666311;8.514735,49.673618;8.515635,49.674235;8.513863,49.684217&nogos=8.515257,49.674239,84

It's not yet perfect, e.g. the content of the data-tab for the bee-line is undefined.

Do you think that's an acceptable solution?

reragrs, Arndt

[nrenner]

Hm, I'm currently working on doing this in the client without involving the server.

I have long wanted to move track formatting to the client, so we don't need to re-request the whole route for downloading and roundtrip client information like name and waypoints just for formatting. And I take this issue as a reason to finally do that, in order to avoid a senseless server call for beeline segments that just tells the router to do nothing and echo back the coordinates we already have.

See branch 68-sl-formatting and task list in first comment.

[thof]

Do you think that's an acceptable solution?

A very clever idea! I think it can serve as a perfect temporary workaround until the final solution is ready as described by @nrenner.

Many thanks for this patch @abrensch!

[nrenner]

How should the user interface work for this?

@rkflx has already shared some thoughts in a comment above.

There is a first early implementation in the branch 68-sl-routing (yarn install needed). For that, clicking on the segment (or rather the drag handle, which is harder to get on the dotted line) switches between routing and a straight line, and pressing the ctrl key while clicking to append draws a straight line.

[rkflx]

Awesome, thank you so much @nrenner! Simple patch on the surface, lots of work in the background ;)

I tested it for a bit, I think the interaction pattern works really well and is quite intuitive once discovered. Ctrl-click to append is a nice addition too. Some more observations (many of which you're probably already aware of):

UX:

1. Add usage hints to tool button tooltip (ctrl to append) and click indicator tooltip (click to toggle). In addition, add some documentation / usage hints to support discoverability for mobile users without access to tooltips, e.g. in form of a navbar link to the wiki or a modal as seen on https://brouter.m11n.de.
2. Change to beeline style (or dotted beeline?) when appending as soon as ctrl is held down.
3. Change style of whole segment on mouseover instead of only showing click indicator (to emphasize operations on the whole segment are available, in addition to only adding a via).
4. On mobile, toggling beelines now conflicts a bit with adding vias. How about this (only on mobile, unnecessary on desktop), which is essentially my idea A) from above but with less UI:
   • Tap on segment to toggle special selection mode (indicate by changing colour).
   • Either tap again to toggle beeline.
   • Or drag to add via.
   • Selection mode ends automatically after toggling beeline, adding via or tapping somewhere else.
5. On mobile, there is no way to press ctrl to append. Maybe here beelines should auto-append in case the previous segment is a beeline? (I would not want to have this behaviour on desktop, though.) -- Update: See comment below (Solution 2) for a better idea.
6. How should beelines interact with no-go areas?
   • Idea 1 (not sure how difficult to implement, could be postponed): respect no-go areas in general (i.e. route around them), but ignore specific no-go area if waypoint attached to beeline is inside that no-go area (i.e. make it possible to override no-go areas).
   • Alternative idea 2: always respect no-go areas, but allow to draw non-circular no-go areas.
7. cycle.travel now provides three modes: any way / paved / direct. Should we later decide to also add additional segment modes besides beelines (e.g. paved vs. gravel), the UI pattern would still work, i.e. clicking multiple times could cycle between modes (similar to the route quality coding button).

Bugs / unfinished implementation:

1. Elevation popups appear on non-beeline segments (should be disabled if circular click indicator belongs to beeline, or show on beeline with interpolation?).
2. Elevation graph sometimes shows interpolated values, sometimes elevation is missing completely (should be consistent).
3. Styling, moving waypoints and adding vias sometimes gets stuck in case of a single beeline between start and end (and possibly other cases).
4. When moving waypoints, beeline is updated, but to wrong coordinates (previous position instead of current position).
5. When deleting waypoints, the resulting linetype depends on whether the beeline is attached before or ofter the waypoint (should be more predictable / the same linetype in both cases, not sure which one?). [in case there is a beeline on both sides, the beelines are merged; corresponding to the behaviour for the case of regular routes on both sides]
6. Beelines lost when reversing route.
7. Distance markers missing / remnants.
8. Beeline vias missing in export (beeline currently only between first and last consecutive beeline waypoint).
9. Start/end waypoint missing in export if connected to a beeline.
10. Missing sync/restore to/from URL.
11. Incorrect attribution in analysis and data tabs.
12. Beelines skipped in statistics.
13. Turn instructions missing before, between and after beelines.
14. Mode switching (via the radio button or B key) should only affect appending, but not rerouting triggered by moved vias (see below). Tooltips should be worded accordingly.
15. However, Shift (but not B key, which should only affect appending) should toggle beeline (i.e. invert existing state on both sides independently) when moving/creating via (see below).
16. B-key state not remembered after disabling/enabling drawing mode.
17. Beeline indicator mode UI should be disabled (or hidden, depending on location) once drawing is inactive.

[drdrknox]

This feature is someting I've been waiting so long as it resolves so many situations where the OSM data isn't 100% accurate and ways aren't connected correctly. 100% thumbs up for this feature!

[mjaschen]

and pressing the ctrl key while clicking to append draws a straight line.

ctrl-click on macOS has the same effect as right-clicking, i. e. opening the context menu.

I guess we need either an alternative modifier key for this feature or a different method to append beelines to a route (as ctrl-click is missing not only on macOS but on all mobile devices as well).

[rkflx]

ctrl-click on macOS has the same effect as right-clicking, i. e. opening the context menu.

Is this universal, or something which can be overridden? (In some web apps, the browser's context menu is already replaced by a custom one.)

Anyway, maybe Shift would be a good alternative and work even better due to already being modifier for some shortcuts. Gave this a quick spin (replaced ctrlKey with shiftKey), worked fine for me and the Shift-Drag-Zoom feature still functioned as before.

I'd rather not get into adding a separate mode switcher button (in the sense of replacing Shift entirely with it), since moving the mouse back and forth between route and sidebar kind of defeats the purpose of quick and easy route drawing.

ctrl-click is missing not only on macOS but on all mobile devices as well

@mjaschen Would a behaviour as described in my previous comment (UX-4 and UX-5, edited UX-1) work for you on mobile?

---

There is another point I'd like to bring up. Looking at reactions in mailings list, issue trackers and forums to this feature, there is a common theme: Users are craving for the feature because they want to route around missing or broken OSM data.

Obviously this is only a workaround, and the much more sustainable solution (with a turnaround time of only a couple of hours for fast-updating instances) would be to actually fix the underlying data. I fear that by introducing the beeline feature, we remove an incentive to get involved in fixing the map.

This could be counteracted by encouraging users to contribute fixes or at least add notes to locations needing fixes:

• Provide a button to "Edit the map" (see https://cyclosm.org) and/or "Add a note" (as seen on https://osm.org), e.g. near the attribution notes in the bottom right. (More examples: https://plotaroute.com, https://komoot.com)
• In addition (since users might miss the button or forget about it in that moment), show a passive popup notice (with a "Do not show again" checkbox) with some hints or links once the beeline feature has been used repeatedly (on first use it would probably be too invasive).

Of course not everybody will make the jump, but at least we should lower the hurdle as much as possible. After all, why not contribute something back in exchange for a free of charge service.

Thoughts?

[mjaschen]

Is this universal, or something which can be overridden?

Yes, that behavior is universal and has a long history. Actually ctrl-click is the canonical action on macOS while right-click is just an alternative (source), despite everyone is using right-click nowadays.

Would a behaviour as described in my previous comment (UX-4 and UX-5, edited UX-1) work for you on mobile?

I think UX-4 could work well as long as the behavior is described/documented somewhere (non-modal popup on first use?).

UX-5 would feel odd while using: Imagine start drawing a route, change the last segment to beeline and then notice that the draw mode entirely changed suddenly. I think that would be confusing at least.

Regarding UX-1: Documentation of BRouter-Web in general is needed. I could imagine a modal dialog showing a short introduction (opens via navbar link) with the most important documentation/hint and tricks and a link to a separate in-depth documentation site (with multi-language support).

---

After all, why not contribute something back in exchange for a free of charge service. Thoughts?

Yes, that'd be great! We definitely should collect ideas (in a separate issue).

[rkflx]

UX-5 would feel odd while using: Imagine start drawing a route, change the last segment to beeline and then notice that the draw mode entirely changed suddenly. I think that would be confusing at least.

Well, this is more or less intentional, though it might surprise users: If you only want to add a single beeline segment, drawing a regular route and changing it after the fact to a beeline is not that much additional work. The auto-append feature is more about the use case of drawing a multi-segment beeline, where toggling every single segment would be too much effort. Of course both use cases conflict if only the most recent segment should become a single beeline segment.

Still, I agree this is not ideal yet and we should iterate more on this particular aspect of the design. More ideas:

1. Use a multi-tap gesture to simulate pressing Ctrl, e.g. hold down one (or two?) finger(s), and tap with another finger to add a beeline via (should work because adding is only triggered on tap-up). Disadvantage: Very hard to discover.

2. Show an ad-hoc inline adaptive UI somewhere on the screen, which indicates the current mode and allows to change mode:

   • Location: likely near top or bottom of the map and centered horizontally, to not conflict with controls on the left and right and to not obstruct the area where editing is taking place.
   • Size: Either a single on/off icon-only (+ tooltip) button, or two small radio-like icon-only (+ tooltip) buttons next to each other, clearly indicating the active one (similar to those in the left toolbar), since in particular on mobile screen space is at a premium.
   • Advantage: Would also remove the need for a separate popup explaining the beeline feature to first-time users.
   • Advantage: Scales nicely to potential future segment modes (e.g. gravel).
   • Disadvantage: Needs more space, adds to UI complexity.
   • Disadvantage: Might be slightly confusing (clicking on a segment will toggle that particular segment, clicking on the button will change mode for future segments, i.e. button state and segment state might be out-of-sync).
   • Note: Mode switching should only affect appending, but not rerouting triggered by moved vias. See comment.

3. Show a popup every time after adding a via, asking which segment type to choose. I would definitely not recommend this, since this will become massively annoying for the vast majority of cases (i.e. auto-routed segments).

4. Do not provide a Ctrl-append-like behaviour on mobile, as multi-segment beelines should be less common and a single beeline is quick to toggle after the fact. Simple to implement for now, but requires more taps for some use cases.

I think I'd favour solution 2. (with 4. in second place) for now due to its additional advantages, maybe even on desktop if done in a non-obtrusive way (but this needs testing with an actual prototype).

[rkflx]

Regarding UI/documentation terminology, here is what others are using (with "beeline" in my remarks above mainly referring to what is currently being used in the code):

• https://osmand.net: "Straight line"
• https://cycle.travel: "direct"
• https://outdooractive.com: "Connect points directly", but also "No way found. [...] using a beeline."
• https://ridewithgps.com: "Draw Lines"
• https://alltrails.com: "Smart Routing"
• https://strava.com: "Use manual mode"
• https://komoot.com: "Follow ways", "Plan routes offgrid"
• https://plotaroute.com: "Auto-Plot"
• https://bikemap.net: "Draw route along roads" / "Draw route free - hand"
• https://gpxstudio.github.io: "as the crow flies (straight lines between track points)"
• https://www.judise.nl: "Klikmode: Viapunkt toevoegen / Wegen volgen"
• https://mapmyride.com: "Auto Follow Roads"
• https://gmap-pedometer.com: "Draw route: automatically (for cyclists) / manually (straight lines)"
• https://openrunner.com: "Automatic follow" (this is a global toggle)
• https://onthegomap.com: "Draw straight lines"
• https://sportdistancecalculator.com: "A left mouse click to draw straight lines / A right click to automatically follow known routes"
• https://trailforks.com: "Click points to auto-route between them, or drag the last blue dot to freehand draw", "You can hold down ALT to draw a straight line between points, ignoring the auto-routing."
• Also: https://en.wikipedia.org/wiki/Beeline, https://en.wikipedia.org/wiki/As_the_crow_flies

Apparently there is no common or agreed upon wording for this feature.

"Disable/Enable (Auto?/Smart?-)Routing" sounds more like a global option to me, the most "direct" route could also mean "shortest route over ways" and even beelines could "Follow ways" by chance, making the latter ambiguous. "Toggle Beeline" or "Toggle Straight Line" seem to work better regarding a specific segment and in describing what will be seen on the map.

I'd say let's go with "Toggle Straight Line", since it is used by OsmAnd too, and easy to picture for non-native speakers, unless anyone has a better suggestion?

[mjaschen]

I'd say let's go with "Toggle Straight Line"

+1

[nrenner]

Apparently there is no common or agreed upon wording for this feature.

That was my impression, too. Thanks for the summary.

@mgoyanes wrote:

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

As a non-native speaker "As the crow flies" always sounds to me like a description in search for a word.

I like "beeline", as it's a short, single word. Therefore I use it in code for now, but I don't mind using a different term in the UI.

Although I'm not sure about "beeline". I thought I heard it before, but maybe that was because I had looked it up in the past. leo.org suggests "beeline" as a translation for the German "Luftlinie" ("air line" translated literally). But there is a discussion suggesting that beeline is only used in conjunction with the idiom "to make a beeline for". The british dictionary linked on leo.org for additional information seems to agree with that and only has a definition for the idiom, while the american has it as a stand-alone noun.

Wikipedia defines Bee line it as "an idiom for the shortest route or a straight line between two points", Wiktionary as "A very direct or quick path or trip.", but the usage example is again the term "to make / strike a beeline for / to something". Beeline is also a navigation company, ironically they use the term "Compass mode" (because the device/app just points directly to destination during ride).

There also was a suggestion "querfeldein" for German, the translation is "cross-country", which might also be an option.

[rkflx]

Apparently there is no common or agreed upon wording for this feature.

Not sure about "cross-country". Oxford Learner's Dictionary defines it like this:

1. across fields or open country rather than on roads or a track ("cross-country running", "We rode cross-country").
2. from one part of a country to the other, especially not using main roads or routes ("cross-country train journeys")
3. ​involving two or more countries ("The report contains the findings of a cross-country comparison of crime statistics.")

...which would not be a good description for a paved inner-city back-alley shortcut, and too similar to the activity-related terms "cross-country skiing/running/riding" ("XC bike").

Also, the wording should go well with usage in tooltips: Click to toggle straight line is far more succinct than Click to toggle "As the crow flies"-routing.

If "Beeline" is the name of a bike/navigation related company, this might be a reason to stay away from it, just to avoid any potential confusion or even legal problems.

[bagage]

Thanks again @nrenner and all of contributors/users/testers on this issue!

If anyone is willing to test it without setting up a dev environment, demo is accessible on:

https://brouter.damsy.net/v99.52.4-beeline/

[janusbenissa]

Very nice but how do you draw a strait line? I don't see a icon for it?

[bagage]

Cf https://github.com/nrenner/brouter-web/issues/68#issuecomment-821324601:

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"

[drdrknox]

both ways work brilliant. Also the idea of 2. clicking on an already existing route to switch between follow-way and straight is quite good.

[janusbenissa]

Thanks. Working now but the length is not calculated? https://tinyurl.com/w5668szk

I try to follow the dry river bed.

[nrenner]

Very nice but how do you draw a strait line? I don't see a icon for it?

Thanks for the feedback. It's part of the consideration whether we should have an icon/button for this or not.

Working now but the length is not calculated? https://tinyurl.com/w5668szk

Yes, that's missing. Statistics are provided by the server for the routed part, straight lines are done in the client. This is only a very early implementation, a lot is not working yet (or subject to change), including the hash URL for sharing.

[janusbenissa]

Ok, but looks promising :+1:

[mgoyanes]

Thanks for the feedback. It's part of the consideration whether we should have an icon/button for this or not.

I think an icon/button would be a nice addition to have. I'm using Mac and I'm having trouble with the ctr+click command. I'm unable to draw a strait line.

[Taunide]

With Android a button would be great too.

Gesendet von Yahoo Mail auf Android

Am Sa., Apr. 24, 2021 at 17:56 schrieb @.***>:

Thanks for the feedback. It's part of the consideration whether we should have an icon/button for this or not.

I think an icon/button would be a nice addition to have. I'm using Mac and I'm having trouble with the ctr+click command. I'm unable to draw a strait line.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[rkflx]

I wonder why there is a need to "draw a straight line" right away. Normally, I'd assume the workflow goes like this (an impression which stems from reading many of the wishes wrt. to beelines over the years):

1. Set a new via (either by appending, or more likely mid-route when setting final start and end waypoints beforehand).
2. Observe (bad) routing result.
3. (Unsuccessfully) try to correct routing by setting another via or moving existing vias.
4. Conclude OSM data is missing / non-routable.
5. Toggle beeline (aha!) for one of the existing segments as a workaround.

In some less common cases you might know you want to draw a beeline directly, so we should support that, but it's probably not something which should get first priority when allocating UI space and the user's limited attention.

Isn't the primary and default function of BRouter routing over medium to long distances? If we want to optimize for creating routes from a large number of short-distance beelines from the start and disable routing completely, this would change the whole UI paradigm, many of the existing or future analysis features (e.g. surface statistics) would stop working, the QR-code feature would break down in its current form and routing-related UI (profile switcher, profile settings, ...) would need to get demoted. We should be very clear regarding what to optimize for.

Currently the features to discover beelines (tooltips, style change on hover or select, potential drawing mode indicator radio icons) are not implemented yet, so naturally the question of how to activate beelines comes up with testers. This is generally expected at this stage, in particular if the (not ideally worded) hypothetical task in usability testing would read "Draw a straight line, and tell me if you want a button!" instead of the more useful task "Create a route from here to here, visiting \<unroutable area>, and tell me how it worked out for you!". We should also be careful not to mix up problem ("I cannot discover the feature") and expected solution ("I want a button") when analysing feedback, because more often than not the root cause is somewhere else entirely and "just another button or config option" only adds to the pile of issues.

There is no explicit tool in the toolbar for deleting arbitrary vias, there is no tool to set new vias mid-route, there is no tool to activate a special mode to move vias, and most of the no-go UI is added only on demand. Yet users cope just fine, and it sets us apart from the sometimes quite bloated and therefore hard to use UIs of the competition. BRouter-Web is simple, and at the same time efficient to use. This is a strength, not a weakness. (Assuming a URL/GPX workflow, with other options to share routes to people/devices not (yet?) being implemented.)

In summary:

• We probably cannot avoid something like Idea 2, but it should hide when not in edit mode, and it should not feature too prominently in the UI. Maybe something like Outdooractive has, but less in-your-face.
• When asking users to test again (for which the demo installation is great, although it maybe came a bit too early), let's propose a concrete routing task (where a beeline might be involved for successful completion), and observe/ask how testers do in terms of metrics like learnability, efficiency, memorability, errors and satisfaction. Afterwards, iterate on feedback (either adjust, or rethink).

Sorry if this is a bit long. I hope to increase awareness for a more user-centered design process with usability engineering best practices here, which I think we could profit from (don't get me started on the new elevation graph...). Wikipedia on Usability is a good starting point for anyone interested in digging deeper.

[rkflx]

Now looked at most of the entries listed in https://en.wikipedia.org/wiki/Comparison_of_bicycle_route_planning_websites (see updated comment for those providing beelines). No clear winner wrt. beeline naming, but more mentions of "Straight line". Review did not result in any innovative breakthrough wrt. beeline UI, though.

Still, I noticed one more peculiarity with the occasionally used mode switcher radio buttons: Often there is no way to toggle beelines for existing segments, but there is a workaround: Toggle routing mode and move via a bit. Then the via's next and previous segments will be rerouted with the new routing mode. Obviously this affects not only the intended segment, but it also destroys the segment intended to be left alone, so you have to apply another workaround beforehand by adding more sacrificial vias as safety guides, which can be removed again later on. This also means that for every regular via move you have to check the selected routing mode, or else you might be in for a surprise. Hard do discover, and slow and annoying to use at the same time.

Therefore we should make sure the mode switcher (the permanent radio button, not the temporary and explicitly pressed Shift modifier) only applies to appending, but never affects rerouting triggered by moved vias. (Comments above edited accordingly.)

[nrenner]

After all, why not contribute something back in exchange for a free of charge service.

Yes, that'd be great! We definitely should collect ideas (in a separate issue).

I opened a separate issue on how to encourage OpenStreetMap contributions: #403

[rkflx]

Make draw modifier configurable and switch to Alt

Sorry to interject, but: Alt+Click is often used by X11 desktops (or rather window managers) to drag/resize windows from anywhere, there the event won't even be delivered to the app. Also, it triggers the menubar in Firefox when the beeline action is aborted before clicking. In addition, common practise in desktop applications is to use Alt only for accelerators (i.e. those underlined characters on UI elements), but not for shortcuts or modifiers (except in combination with other modifiers, which we also do not want here). Therefore I would recommend against using Alt for beelines.

Shift-Click collides with Leaflet Shift-Drag for zooming when still moving the mouse a bit while clicking

In theory this problem already exists for adding waypoints vs. dragging the map. Admittedly, zooming is worse than dragging. Nevertheless, nice catch, and one more reason to always test in a diverse set of user contexts.

Options if Shift should be kept:

1. Ignore the problem.
2. Disable drag-zooming (users need to use an alternative zoom method to zoom out again anyway).
3. Add a minimum drag distance before zooming happens. Conceptually this should work, because both addition of the waypoint and executing the zoom is only triggered on mouse-up (drawing a few pixels of the zoom rectangle on mouse-down should not harm anyone, since the drag threshold could be as low as a few pixels and accidental drags are quite fast too, so the rectangle is hardly visible).

Other options:

• Use Ctrl, and reroute the context menu event (which I'm hopeful we can catch, because there are in fact web apps out there overriding the context menu) to mean "beeline at current position" instead. Sadly while technically possible, this would go against Mac platform conventions then.

To me, option 3. seems the most favourable. It could even be delivered later as an optimization (with either option 2. or no countermeasure at all in the meantime), so the beeline feature could be shipped and marketed with Shift from the start.

[nrenner]

3. Add a minimum drag distance before zooming happens.

That's what I also had in mind and implemented now.

[rkflx]

1. Add a minimum drag distance before zooming happens.

That's what I also had in mind and implemented now.

Thanks, that was quick. No issues found so far when trying it out.

As for the rest: Did not test everything from the comment above thoroughly, but many of the most obvious bugs are squashed, nice!

Two more nice-to-have details I noticed (also appended above):

• Let Shift (but not B key, which should only affect appending) toggle beeline (i.e. invert existing state on both sides independently) when moving/creating via.
  • Use case: Reduce the number of clicks needed when manually "bending" an existing route by converting some parts to beelines, i.e. moving/creating via and toggling beelines on both sides could be done with one instead of three (or two, if toggling first before creating) clicks.
  • This would also help to reduce mouse movement, because when creating a via in an unroutable area, the track will snap back on both sides to routable ways far away (assumption: zoomed in far enough, distance below BRouter's threshold), and finding the segments to toggle afterwards could be challenging.
  • In particular, Shift state after mousedown is relevant here, i.e. Shift is available to be pressed down after mousedown and before mouseup, because Drag-Zoom uses Shift only before mousedown.
• Remember B-key state after disabling/enabling drawing mode.

---

Since the visualization (and click/tap-target for non-keyboard users) of the beeline append mode is still not that well-defined, here are a couple more thoughts (nothing final yet, though):

• In general, the button to activate the primary interaction mode of the web app, which is setting start/via/end waypoints to get routes between, is a bit hidden in the left toolbar and could be very hard to find. This is somewhat mitigated by enabling drawing directly after the site has loaded, but at some point users might want to switch off drawing (to fine-tune/analyse/view/export the route as their next step). Now they will really have a hard time finding the relevant button among all other buttons, it is just not very prominent.
• Adding the beeline mode to the left sidebar would make it too crowded, but separating drawing button and beeline mode indicator between left toolbar and e.g. middle of the screen is also not ideal, not only because then the beeline indicator is more prominent than the draw button.
• Therefore: How about moving the draw button to the lower right corner, making it bigger, rounded and colourful? Yes, I am thinking about the typical button familiar from Android apps (e.g. see FAB in Material Design). The beeline mode indicator could then be right next to it, or both could be integrated into a single entity. E.g. once drawing is active (button changes colour), the beeline mode switcher would appear. This would also solve the problem that the beeline mode (unless explicitly requested with Shift) should only affect appending, but not moving vias.
• Simpler alternative: Maybe move Draw to the FAB, and re-purpose the existing draw button as a beeline mode indicator?

[darkmattercoder]

Just to add 2 cents:

I as well am craving hard for that feature. Regarding the concern of @rkflx , that

by introducing the beeline feature, we remove an incentive to get involved in fixing the map.

I think that the opposite would apply here. Often you will base your planning on an existing gpx which someone has recorded previously. From such tracks, chances are, that you will see some ways exist, which are not on the map. By re-routing over existing ways, you will never get to that specific place to actually have a look at the situation to do a proper mapping, unless you note the location separately and try to scout it manually. On long trips (e.g. a several 100k bike packing trip) this might not be a priority, so you need the possibility to improve the map as you go. With a beeline, you still can have your bike computer or smartphone route you over those beelines, keeping you on the desired track. This I think this would even encourage a contribution to OSM rather than miss the opportunity.

For the UX, I personally like the approach komoot does: you have an option in the context of a waypoint to disable "using ways" which leads to beelines from and to that specific waypoint. I find this more intuitive than a manual approach where you first have to select a button to "draw a straight line". I think by having the option in the context of a waypoint it is in the right place. However I also like the Idea that you can modify the routing behaviour as you draw a new node initially when building the route by holding a modifier key such as Ctrl. But then still I'd like to find the option in the context of a waypoint once a route already has been drawn.