Re: [APP] - version 4.34.+ ( 05/2026 )

[freischneider]

The route is marked as poor in OSM. Potholes, cracks, etc. Bad for road bikes. You should adjust the OSM data if it's better in your local area.

If you are referring to the smoothness=intermediate tag - I think to classify this as "demanding" still is a bit to harsh. Since there is only one category of bad road in locus, it is s bit broad to classify this the same way as some really unrideable roads.

All the smoothness=intermediate I found in my neighborhood do not qualify as demanding. The OSM description also just says "may cause trouble for racing bikes." This is a Konjunktiv and only refers to a small subset of bikes.

So in my opinion the cutoff is better suited at smoothness=bad.

Greetings, Ulrich

It's not impassable. It is passable and has been graded. But with a warning—and that's important. If you ride your road bike into a pothole like that, you'll crash. That's why the warning is important.

[Ulrich Kiermayr]

It's not impassable. It is passable and has been graded. But with a warning—and that's important. If you ride your road bike into a pothole like that, you'll crash. That's why the warning is important.

I think it is a problem that there is only one fixed cutoff for all classes of "bad" surface. In my experience riding a rodadbike the smoothness=intermediate roads that I know do not pose a problem for road biking (except in a race maybe).

So in light of the discussion it would be useful if eiter

• More than one class of "bad" surface to get a better feeling of what to expect without checking every section, what exactly is meant by "demanding"
• make the cutoff configurable to get some liberty to what is accepatable as surface condition and what should generate a warning to accomodate different expectations/material

Greetings, Ulrich

[freischneider]

It's not impassable. It is passable and has been graded. But with a warning—and that's important. If you ride your road bike into a pothole like that, you'll crash. That's why the warning is important.

I think it is a problem that there is only one fixed cutoff for all classes of "bad" surface. In my experience riding a rodadbike the smoothness=intermediate roads that I know do not pose a problem for road biking (except in a race maybe).

So in light of the discussion it would be useful if eiter

• More than one class of "bad" surface to get a better feeling of what to expect without checking every section, what exactly is meant by "demanding"
• make the cutoff configurable to get some liberty to what is accepatable as surface condition and what should generate a warning to accomodate different expectations/material

Greetings, Ulrich

I think it would be most sensible if you submitted a suggestion to the helpdesk. Discussing this here is the wrong place.

[Menion]

Hi guys,

I had a shorter hike + team meeting, so this week > nothing extra new. At least some answers ...

@Tapio
left search screens > can't simulate it, sorry. Back event firstly closes the keyboard and on second event, it correctly do a "back step". Does anyone else have a problem here?

@WildWortWechsel
problem with bottom bar > thanks. Give a try to next app version (tomorrow or next week). We've created an improved system for auto-resize of top bar based on the length of the text, so it should help here.

@Graf Geo
slope coloring > in all charts, yes intent. Useless? I found it pretty useful to see for example speed on bike with colored slopes.

legend > next to track style in the track detail (if coloring is enabled)

@Gerhard57
missing Y value > hmm, and no gap (missing data) in this place? I'll be looking at it.

@Ulrich Kiermayr
not working "My location" > thanks, got it

"demanding surface" > If possible, yes, post it please on the help desk as an idea. This is more on my colleague @Radim V and it will be a lot easier to discuss it with him in a single place there.

@slarti76
100m range > no serious reason. Improved, give it a try in the next version.


Reordering of track screen content:
thanks for the interesting ideas. As I see, everybody has a huge list of ideas and it leads me to stay with minimal customisations for now. So, do not expect too much from it for now. Thanks for understanding.

Anyway, I'll read your posts more carefully, do some summary and definitely think about it.

[Menion]

Version 4.34.1.4 (12.6.2026) - mainly bug-fixes.

   - fix: occasional crash at app start while the initial loading screen is visible
   - fix: geocaching waypoint projection now starts from the waypoint's own coordinates
   - fix: selecting a result in the offline POI search now correctly shows it on the map
   - fix: handling of incorrect track when switching over them directly on the map screen
   - fix: not working "My location" location in Route planner itinerary
   - fix: thin seams no longer show between map tiles on dark maps
   - fix: crash when selecting a vector map theme with no style layers
   - fix: crash when pressing back on a web page that failed to open
   - fix: crash when opening My live location while a live-tracking session was running
   - chg: reduce minimum X-axis distance width to 100m in track charts
   - chg: local map server now works with the Locus web portal over HTTPS (Private Network Access preflight supported)

[Graf Geo]

Thanks for the update.

When I zoom in with two fingers or move the chart in the chart overview, Locus crashes.

[Radim V]

The route is marked as poor in OSM. Potholes, cracks, etc. Bad for road bikes. You should adjust the OSM data if it's better in your local area.

If you are referring to the smoothness=intermediate tag - I think to classify this as "demanding" still is a bit to harsh. Since there is only one category of bad road in locus, it is s bit broad to classify this the same way as some really unrideable roads.

All the smoothness=intermediate I found in my neighborhood do not qualify as demanding. The OSM description also just says "may cause trouble for racing bikes." This is a Konjunktiv and only refers to a small subset of bikes.

So in my opinion the cutoff is better suited at smoothness=bad.

Greetings, Ulrich

Hello Ulrich. I checked the osm manual for mappers. (I always do, when making any kind of osm related configuration). Indeed smoothness=intermediate as seen in the manual is not what I enjoy when riding a road bike. Anyway I have seen more than one report of surface warnings being too strict, so I have changed "intermediate" to ok for road bikes and "bad" to ok for gravel bikes. These are opinionated choices and I have no problem with it, in this particular case. But what I see on the street view is not "intermediate". Inaccurate mapping is also an issue here. Regarding more than one class for warnings - this is already possible (router side, not user side). I have just not yet configured the yellow, orange and red levels. These levels are treated in slightly different way, e.g. yellow warnings disappear first on the map, red are more sticky. The change will be deployed to online router tomorrow, offline with new app version. 

[Ulrich Kiermayr]

Hello Ulrich. I checked the osm manual for mappers. (I always do, when making any kind of osm related configuration). Indeed smoothness=intermediate as seen in the manual is not what I enjoy when riding a road bike. Anyway I have seen more than one report of surface warnings being too strict, so I have changed "intermediate" to ok for road bikes and "bad" to ok for gravel bikes. These are opinionated choices and I have no problem with it, in this particular case. But what I see on the street view is not "intermediate". Inaccurate mapping is also an issue here. Regarding more than one class for warnings - this is already possible (router side, not user side). I have just not yet configured the yellow, orange and red levels. These levels are treated in slightly different way, e.g. yellow warnings disappear first on the map, red are more sticky. The change will be deployed to online router tomorrow, offline with new app version.

I agree. It is also kind of individual, what is still considered as 'ok'.

Your change sounds reasonable (for me), I'll check and can give feedback :-)

Thanks and lG Ulrich

[Harwey]

Version 4.34.1.4.
I have a preset profile for navigation – for example, moving the map cursor down. If I view the route details during navigation and then go back, the cursor no longer moves down but stays in the center of the screen.

[Menion]

Version 4.34.1.5 (19.6.2026)

   - add: (SILVER) pinch-zoom and pan the chart right on the track detail screen — no need to open the full chart first
   - add: (SILVER) zooming the track-detail chart now highlights the matching section directly on the map
   - add: pin the chart on the track detail screen to keep it only visible item + map
   - add: (SILVER) GPS accuracy can now be shown as a track chart variable
   - add: reorder the sections of the track detail screen (chart, description, waypoints and more) to your preference
   - add: optionally stop guidance and navigation automatically after you stop moving, to save battery
   - fix: crash when pinch-zooming a track chart at the deepest zoom level
   - chg: (SILVER) Geocaching Live Map now works on the Android Auto map and updates as you move
   - chg: smoother panning and zooming of track charts on long tracks
   - chg: more accurate calorie estimates — terrain (uphill/downhill) now affects the estimate, and reported calories represent the total energy burned during the activity
   - chg: per-activity calorie values refreshed to the 2024 Compendium of Physical Activities (walking, running, cycling, skiing and more)
   - fix: more accurate calorie estimates when walking, hiking or running uphill
   - fix: more accurate heart-rate-based calorie estimates for female user profiles
   - fix: missing photo overview when picking coordinates on the map in "Image map calibration"
   - fix: crash when entering an invalid value in a BRouter routing-profile parameter
   - fix: incorrect visible URL in the track detail
   - fix: points without a custom icon now show their folder or default icon in lists instead of a plain dot
   - fix: (SILVER) online map overlays such as IGN now load reliably at app start instead of showing a "map is not ready" warning

[Graf Geo]

Some really great improvements! 👍👍

One of the best features is the option to fix and view the elevation chart separately and zoom in on it directly. At last. 🙂

And now you can also move attachments (media) in the 'Reorder Sections' menu. Very good!

I'd also like to be able to sort the charts freely in the overview or hide individual ones, but perhaps that's still to come.

Have a lovely weekend! 🌞

[Andrew Heard]

regards the nice improvement "track-detail chart now highlights the matching section directly on the map", although not specific to this beta release, would it be worthwhile to disable map rotation and auto-centering, while showing the map based on the chart? I find it confusing when I've just saved a track, but the map preview at top is continually rotating, and when I tap the chart & the map is panned, it will revert to GPS position after auto-centering timeout.

[Tapio]

One of the best features is the option to fix and view the elevation chart separately and zoom in on it directly. At last. 🙂

When pinch-zoomed, it shows some weird parallel track. As if it wants to highlight the zoom area, but distorted. Anyone? The orange-white line.

[Tapio]

@Menion, to unify behaviour and make geotagged photos awesome, you could move the map, just like a click on the graph - if we click a geotagged photo. And if geoposition access is an issue, maybe same file time approach as the  selection of photos itself: use closest track timestamp and center track there.
And picture viewer then would be started by long click.

[Graf Geo]

When pinch-zoomed, it shows some weird parallel track. As if it wants to highlight the zoom area, but distorted. Anyone? The orange-white line.

This marks the section that has been enlarged on the elevation profile. Generally speaking, this is fine, but on sections with sharp bends or tight curves, the orange-and-white markings occasionally overlap the route in an unsightly manner. A bit of fine-tuning might be needed here.