Messages

Could you share it via private message? I'd be interested to try and see what may be going on. It can of course be that all external providers started blocking my requests

Here it is: You cannot view this attachment.

Greetings, Ulrich

Is it me, or did overlay maps stop working. No matter which overlay I select, they all stopped working. I either get a message "cannot load map" or no message at all, just no overlay.

I used the m*, G* or M* traffic overlays occasionally.

I have a (custom) overlay for OpenRailwayMaps. This still works fine.
lG uk

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

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

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

Hi,

Since a few versions, I noticed a change in how bike-routes are represented. Locus shows a lot of Streets as "demanding Surface", that are perfectly normal paved streets. I think the interpretation of the OSM flags seems to be off sometimes:

An example:

This is shown as demanding:

You cannot view this attachment.You cannot view this attachment.

On the other hand the way types and surface are the same between demanding and not demanding parts:

You cannot view this attachment.


The OSM Object is https://www.openstreetmap.org/way/16901568

There the way is shown as asphalt *and* grade1 - which means paved. So - at least for me - this does not imply "demanding".

For those interested, this is the streetview of the Road: https://maps.app.goo.gl/9LpCCxVVD4yCGRWd6

So I think there should be some tuning regarding the classification and/or representation as "demanding", because now it is more often misleading than helpful in route planning.

Greetings, Ulrich

Hi,

New bug (edit as noted below):

Track editor Route planner > Select start > My location

Does not work any more

LG uk

I don't like the new colors for the track in "Colored Gradient." I'm having trouble following the course of the track. The colors are very pale. With the old colors, I could see the track much more clearly, and I could spot steep sections much more easily. They stood out right away.

+1

[@slarti76]

Hi @Menion,

@slarti76
I'm probably still confused. All seems to work correctly to me.
My situation: current GPS location in Prague, search for "Kyiv" clearly displays 1130km to the east. Arrow correctly rotates as I rotate with the phone. App Settings > Miscellaneous> Default search/sort location settings have no effect here. GPS or the last known location is always used in the search screen.

Do you have the same experience?

This is, what I meant by confusing. This always confused me, but the discussion triggered the report.

Compare the 2 screens. On the map (without rotation, north up) I use for planning, Götzendorf is to the left (west, blue arrow)
You cannot view this attachment.

In the search screen from the position I was sitting, Götzendorf is up (because I was facing west when sitting)
You cannot view this attachment.

I find it confusing because when planning I don't know where north actually is, but I have a map with fixed orientation. So I would expect the search screen arrows to point on the direction, where I find the results on the map.

Greetings, Ulrich

I think, it depends on the vertikal and horizontal orientation of the phone, the arrows turns depending on both.

Now I get it: It's not screen orientation, it's phone orientation! They arrows actually turn when I rotate the phone. I guess that makes sense for closer destinations, not so much looking for a far away city. 

The main misunderstanding is that I'm thinking "planning", but the actual purpose is "on the road".
I think ideal would be to have two modes:

• On the road: As now, direction from current location, using phone orientation
• Planning: From current map center, using static compass directions

But I admit, probably too much effort for small detail...

Testing and thinking about it:

When the map is locked in "north up", the search should also respect that and show the arrow with respect to north up. (To be consistent with the map shown)

When map rotation is on, then the search should behave like it does now.

I think, this would resolve most of the confusion. Search should simply behave like the actual behavior of the map

Greetings, Ulrich

Serious Bug in 4.33.0.12: Route recalculation during navigation is broken:

• At first everything is fine. Track shown on the map, instructions
  You cannot view this attachment.
  
• If I take a wrong turn, It still looks ok. ? in the top left corner
  You cannot view this attachment.
• Now it starts getting weired: New Instructions appear in the top left corner, but the (new) track is gone on the map. Also the Dashboard Stats for the navigation have disappeared (time left, distance left, etc.)
  You cannot view this attachment.
• And after the next turn, navigation has disappeared and stopped all together
  You cannot view this attachment.

This is pretty bad, since it makes navigation rather unusable.
Using LoRouter, Profile Roadbike

Greetings, Ulrich

Regards search > this is not a new week's work. We've planned it and worked on it for more than a year. I'll push my colleague to give a full explanation here, if needed. Anyway, suggest testing it and thinking about what situations it complicates and if there is an option to keep the new system as is and provide some kind of shortcuts. I can imagine, for example, editing coordinates directly in the "Edit point screen" etc.

For my Usecase it would be an option to populate the search result list (before the search is done) with a list of "prefered Locations" instead of some (arbitrary looking) search results.

lG uk

[@wollewolle]

@wollewolle & @balloni55
ah,so the edit of coordinates > this is a big change in recent Beta versions. We completely removed the old "Grid" screen and integrated all into the search screen. No functionality should be lost, and all features are directly in the top row. So the edit of coordinates, projection etc., is all at the top row.

For me - in the context of Navigation - this is a step back. When I do navigation, I rarely use the search to find the destination. However I have some pre-saved locations (Home, Office, Parents, ...) that were in the Grid - reachable with a direct tap.

Now since all of it is cramed in the top 10% of the screen it is much smaller and I have to swipe left&right to find the proper pre-saved location.

Suggestion would be to have a little more space (like 3 lines or something for the pre-saved locations + Buttons

You cannot view this attachment.

Greetings, Ulrich

[Locus Map 4.33.0.10]

Locus Map 4.33.0.10


Per-sensor disconnect alert — optional audio / vibration warning when a connected sensor drops out. (topic)

That's great, but...

... For the sensor, that gave me the idea, I don't see it: The bike radar (I lost that day). Could you add the alarm for radars (RTL515) as well.


You cannot view this attachment.

Greetings, Ulrich

[@Ulrich Kiermayr]

@Ulrich Kiermayr
Isn't the problem with the dashboard already solved in the latest Beta version?

Unfortunately no. The bubbles are gone, but the dashboard still draws over the guidance/navigation panel, intercepting clicks.

You cannot view this attachment.

LG Ulrich