Split multi-day bike trip

Hi,

I often use BRouter-web to plan multi-day bike trips. I do a single route within the app to plan everything such as stops and places to stay.

Exporting such a large GPX trace is however an issue : it is slow to import on low end devices, it requires additional splitting or a proper UI to be useful (and OSMAnd~ lacks it).

What about being able to add "split points" in BRouter and export one GPX per segment rather than a full GPX ?

Best,

Great idea!

(Initially I wrote a long list of reasons why supporting multiple independent routes in one view might be preferable instead, but then changed my mind: "split markers" might actually be less complex both for users and in the implementation!)

Challenges I can see:

How to communicate to users that the split feature will come to life after export only? Having a tool in the toolbar is a bit disconnected from an explanation in the (still) hidden Export dialog. We could add a tooltip, but IMO that alone is not enough (and not available on mobile either).
We already have multiple types of markers (start, end, via, POI, overpass POI), so a new type of marker should be sufficiently different (perhaps not only use a different color, but a different shape too, e.g. square?).
A single split marker will create two segments: before and after. As such, configuring name or color of segments cannot be done by clicking on the marker only (and it will get even more confusing for multiple split markers).
Each segment needs a different name (trackname + filename). Auto-numbering is easy to implement, but users might want to use custom names or split by intervals other than days. Adding more fields to the export dialog might work, but is quite disconnected from the map view and ideally you'd be able to name single segments (and retain the name) during planning and not only at the end.
What should happen with split markers when routing changes (either due to a change in profile options, or because waypoints are moved), i.e. are they attached to a particular location or are they defined by a constant distance (or travel time?) to the start of the route (or the previous split marker?)? Surely we do not want to discard split markers in this case.
Implementation-wise, I'm not sure if GPX supports multiple routes per file, and how they end up after import in apps and on devices. This might need testing, and possibly a fallback to save into multiple GPX files instead (although clicking multiple times on "Save" might get pretty annoying).

One idea to solve some of those usability issues might be to introduce a new sidebar, which:

has a tool to place split markers on the route (or should the tool live in the regular toolbar and open the new sidebar on activation?)
lists all segments (i.e. route segments between split markers or between split marker and start/end waypoint) and highlights segments on the map on hover or selection
allows to name segments (with automatic numbering by default)
does not have a duplicate export button (instead, the regular export dialog should get a link to open the new sidebar for detailed configuration)
has room to display more detailed statistics for each segment (e.g. distance, travel time, ascend etc.)
could later be extended to a kind of trip itinerary (e.g. list custom named POIs along the route, allow to add notes to segments, export summary as PDF or TXT etc.)
also solves the problem of not being able to preset a name for single routes (currently you can only give a transient name to routes in the export dialog, and all browser tabs have the same generic name instead of referring to a particular named route)

Hello Phyks, Hello Rkflx,

I understand the need....and the complexity of an implementation... (I am planing a tour from Germany to France, 750 km with 15 bikers...) But I am not sure whether an implementation in the brouter-web would be the best solution...

today brouter-web is the best powefull router, easy to use, (also by most of the bikers without long learning period or IT knowledges)
To win new / more users, I think we should not add functions that address only few users and scare "standard" users

I prefer enhancemenst that make the brouter-web usable by every body...(thank Rkflx for your idee to use Qrcodes as an alternativ by the gpx-export: all my friends use it now on my test instance!) For "several days" trips I upload the GPX-files into a separated tool, here an example of a tour last year: http://www.mygpsfiles.com/app/#tu3s51PV Regards Ess Bee

One idea I already thought about is having a marker menu as popup for route waypoints where you could mark the waypoint as intended stop/pause or overnight stay and potentially give a name (deleting would move to a menu item and shift-click). We could then have an option to just export a specific leg (e.g. simply by number) between such marked waypoints. GPX would also allow to split such legs into multiple trkelements (see gpx element) or into track segments (trkseg, see trkType), don't know how OsmAnd handles those.

Another idea for more general route editing would be to have split and merge actions, potentially also as waypoint menu items. This would also allow to delete, recombine or reverse parts of a route. A simple implemenation could be that only one of the splitted route legs can be active and treated as if it were the only, single route (in all components like export, stats, elevation graph), while the others are ignored until one is selected/activated on the map.

Already the automatic generation of markers to plan the daily distances of a multi-day trip would be a great feature, e.g. for biking. You could have a nice algorithm which takes distance / elevation gain / route condition / physical condition (max elevation gain / 100 km or something similar) into account to generate a suggestion for the markers. Saw this in another gps tool (which name I unfortunately don't remember) and was amazed how good such a prediction could work.

Additionally it would be great if the height diagram could support the manual day trip planning a little bit better. Already now it's possible to select a region in the heigh diagram, showing a start marker and a movable end marker. It would be great, if the height diagram could display in such a selection mode the total distance and the accumulated elevation gain of the selected region between start/end marker in addition, e.g. like in google earth. At the moment only the actual height and the distance from trip start of the end marker is displayed, which is already of great help.

On first sight the waypoint context menu idea sounds good. However after digging deeper I can definitely say that I'm not a fan of them, since they make the common use-case (deleting waypoints) way too cumbersome, only for enabling some seldom used features. Shift-Click seems like a workable alternative, but actually it's not.

You don't load "overnight stops" into your device or app, but track segments. As such, the objects in the UI for handling and by extension naming are segments, not waypoints (unless you want to complicate things). The only point-related activity is when splitting the route into two segments at a particular point. Everything else is segment-related, e.g. those properties:

routing profile (it is often requested to use different profiles for different segments in one session)
name
optionally earmark segment for separated export
segment statistics
and more...

Perhaps we can even get rid of the point-related "split route here" action: What about a sidebar (maybe on the left in this case?) a bit like this:

"Route Day 1" line edit, 80km/..., show/hide inline button, colored stripe and inline color button, mini-preview
"Route Day 2" line edit, 120km/..., show/hide inline button, colored stripe and inline color button, mini-preview
...
"Add New Route" button
"Duplicate Selected Route" button
"Delete" button (could be inline too, but having it separate / not duplicated requires less space and allows to delete multiple shift-selected routes at once too).
"Import track" (could be moved there later from the navbar and the layers tab)

All routes would be displayed on a common map, the currently selected route would be available for editing/export/statistics in the BRouter-Web UI as it is today (thanks for the great idea @nrenner, which is kinda trivial, but easy to miss!), and the buttons would add a new entry to that list. Segment alternatives are easy, and you could sketch multiple ideas and then plan them out in detail or purge them again (which would be hard with the "split markers" approach, which only allows for a single segment between two split points).

When duplicating segments and adapting them by adding and deleting points is very easy (i.e. no context menu...), I don't think split and merge are absolutely required for common use cases. Is planning a route with all details and splitting it only at the end really how people plan trips? I'd guess this is much more iterative in reality, where you'd have a general idea, and then work on segments, try various things, change plans, try alternatives etc.

(I'm not saying split and merge cannot be added later with that approach, in fact they might be even easier this way UI-wise than standalone, but they should not be the main focus. They are simply an often complicated and inflexible, and only sometimes efficient and powerful tool. IMO segments should get our attention first and foremost.)

Note that this can be extended to also list imported tracks too (and optionally convert them to a route), which currently are a bit hard to manage in the layers tab (no delete, no colors, no renaming, no duplication for editing, ...).

@Phyks Would that approach work for you too? (It is a bit more complicated than what I wrote in my initial comment, but so much more flexible.)

@EssBee59 Would you be okay with a BRouter-Web where you could simply ignore a "multiple routes" sidebar (just keep it closed...) and the rest of the UI would (mostly) stay the same?

@nrenner I hope you don't take my comment personally, I'm only trying to work out if there could be a better approach.

@tstreibl I don't believe segments as described above are the best way to help with your heightgraph idea. I think the request makes sense though, so could you please open a new/separate GitHub issue for that? Thanks!

Apart from that, in general todays UIs are moving away from stuffing everything into hard-to-discover and space-restricted context menus, and IMO we should learn from that too. Lots of similar websites are using sidebars for that, and if done right they can be nice to use.

@nrenner Thanks for mentioning trkseg, that's what I meant (but only remembered faintly).

Hello Rkflx, Thank for asking: As you understand, I try to represent my bike-friends. They are using now the Brouter-web, but most of them do not have IT experience....(and as explained were not able to transfer a track from the PC to their smartphone) So, the change you described above is not a problem, as they further can simply calculate a route!

Every enhancement in the last 2 years was very very good!!

My message to the designers and developpers was: Please, don´t forget the unexperienced users! ("experimented" users allways find a solution they their needs)

Regards Ess Bee

nrenner / brouter-web

Split multi-day bike trip #430