If a way segment contains more than one `surface` tags (e.g.
`surface=*` and `cycleway:surface=*`), the tag best suited for the
current routing type (currently only *cycling* is supported) is
selected.
i.e. if a `cycleway:surface=` tag belongs to the current way segment
it will be used for the analysis exclusively (all other `surface`
tags are skipped from now on).
- use FileReader.readAsDataURL (for iOS Chromium)
- add alternative Download from Server for now until proven in Prod and fixed in iOS Firefox (no i18n)
- replace cloud icons as client-side now
The `surface` tag exists in different variants,
e.g. `surface`, `cycleway:surface` etc.
Previously, the `surface` and `smoothness` tags were only processed for route analysis if they were found in their canonical form in the BRouter server response.
With this commit, the variants are normalized down to the main tag name which has the effect that they're included in the route analysis.
Fixes#438
* use a local variable (best practices)
* Add OpenStreetMap notes as overlay.
This commit adds a new layer which renders OpenStreetMap notes in the
current view.
The layer can be activated via the "More" button in the layers sidebar.
Fixes#439
Users might want to assign custom tracknames, which requires deleting the
default name either entirely or parts of it.
By pre-selecting parts of the trackname, users can start typing right away
after opening the dialog. `Ctrl+A` to select everything is still possible,
but keeping the distance in the filename by default comes in handy,
e.g. when using a file manager not displaying the track length.
NB: Might need adaptation once trackname validation becomes less strict,
i.e. currently "(" and "->" as specified in the message catalog are replaced
with ' - ' by the validator before being inserted into the dialog.
Test Plan:
- Open "Export" dialog ("Location - Other Location - 2km")
- Open "Export" dialog for roundtrip ("Location - 1km")
- In both cases the complete trackname except for the distance
information (including separator) should be selected.
- No unwanted behaviour even if Nominatim is slow or down.
Consider additional cases:
- flag got reset when deleting and adding first waypoint
- don't show empty on load, postpone to update
- don't store state when hidden because empty
Using i18next's "nesting" and "interpolation" features should reduce the
overall number of strings to translate, as well as provide a
standardized pattern for shortcut tooltips (if applicable).
Note that this approach is still allowing for flexibility regarding
differently structured sentences in each language.
Resolves#315
Press 'G' to open the profile switcher, select a profile with the arrow
keys, apply with 'Enter' and close the switcher with 'Escape'.
While 'T' and 'P' will be / were already taken, 'G' is at least easily
reachable with the left hand for users using a mouse with their right
hand at the same time.
Since Bootstrap keeps updating the tooltip when changing options in the
dropdown (which is useful in case the text is longer than the width of
the control), the shortcut text needs to be applied dynamically too.
Do not allow browser keyboard shortcuts to trigger route functions,
e.g. pressing Ctrl+P triggers printing in most browsers, but should not
at the same time switch BRouter-Web to POI mode. This can be prevented
by filtering for modifiers.
In the same fashion, when modal dialogs or dropdowns are open it should
not be possible to activate map functions in the background now.
Finally, inhibit shortcuts in number input fields too, as found in the
editable number input fields in the customize profile options.
Previously only regular text input fields were protected.
To make those checks easier to use, they are deduplicated and moved to
Util.js.
When hovering over rows in the analysis tab, highlighted sections for
the route could only be seen on the regular route, but not when any of
the color-coded route visualisations were selected.
Patch based on a similar fix for data table in d33c795200.
There are some ways the look of the analysis tab can be polished:
- Properly right-align the length header
(it had extra margins required for the sorting arrows in the data tab)
- Use the same font size for table header and body (like in the data tab)
- Improve padding of the totals row (to align with the rows above)
- Add missing style for headings, so they look more balanced
(the CSS was already there, but the wrong class was used in the HTML)
- Fine-tune vertical spacing (to help visual grouping)
- Remove unused and redundant CSS
- Do not show yellow hover effect over table header
- adds a new analysis tab in the sidebar
- the analysis tab shows length distribution for different way types, surface, and smoothness
- table rows can be hovered/clicked to highlight the according segments on the map (similar behaviour as the detailed data table)
- localization is implemented for `de` and `en`
- the method for finding segment edges was extracted from `js/control/TrackMessages.js` into `js/util/TrackEdges.js` as it's used in the new analysis class too (the Gulp config was changed to reflect that)
Notes:
I had the idea to use the *DataTable* plugin for rendering the tables but decided against it. The only meaningful way to sort such a table is by the length column and that's already the case. So it's just three plain, old HTML tables, rendered by jQuery.
For meaningful statistics the `processUnusedTags` setting has to be enabled in the routing profile. Only in this case the BRouter backend includes all needed tags (`highway`, `surface`, and `smoothness`) for *every* route segment in the response. I’ve enabled that setting for all profiles at my BRouter-web instance at <https://brouter.m11n.de/>.
