Messages

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

[@Menion]

Currently, app compute times as:

• track time - all times between trackpoints. Breaks are skipped and not computed
• track time (movement) - same as track time, but only when speed is above the threshold (around 2km/h)

What you want is to change this behaviour to

• track time - simply difference in time between the first and last point
• track time (movement) - all times between trackpoints. Breaks are skipped and not computed

Any opinions? Maybe introduce a third time? 

I would expect (and am used to) the current behaviour.

If a third time is introduced, then add a "wallclock time" which is the delta between first and last point of track.

@Menion
Is it possible to do something about https://forum.locusmap.eu/index.php?msg=80839? If not, I'd have to redesign the Dashboard somehow.

Greetings, Ulrich

Hi,

I found a dashboard issue: the dashboard draws over the guidance/navigation icons in the top left corner. In guidance this is especially problematic, since the icon is not clickable (covered by the dashboard). Biggest problem with that: I can't stop guidance mode.

I think, this started when the new graphs layout started in the dashboard. In older versions, this was not an issue.

You cannot view this attachment.

Another serious bug:

The track editor causes Locus to crash.

Same here 

LG uk

[Locus Map 4.33.0.6 (1211)]

Locus Map 4.33.0.6 (1211)

Some nice additional and risky versions before the holidays.

Locus store is broken for me. It is stuck in the loading screen. And when I click on the profile button top right, locus crashes.

You cannot view this attachment.

Greetings, Ulrich

thanks for the great job you have done. The two finger zooming of the chart is great. Nevertheless, "gestures" are a nice weather respectively an indoor feature always causing trouble outdoors: Rain on the display, gloves when its cold etc. makes it very difficult to use gestures. Insofar I support Graf Geos suggestion of additional zooming buttons like before.

Since I use Locus as a bike computer/Navi I second this idea to have buttons.

Greetings Ulrich

Hi Menion,

Thanks for the great work - regarding charts: I noticed, that the Dashboard-Charts are now smaller (and the axes are labeled). I'd prefer bigger chats with no labels to fill fully fill the spot in the dashboard.

Would it be possible to make this configurable.

lG Ulrich

Thanks guys. I've improved this. During start > no change will happen next time. I'll make this "Optimise database" task optional somehow.

Maybe an option somwhere around the clear cache in the menu? That would be the place I would look for such an option.

Waiting during start > hmm, some of you are not patiente  . App does a "vacuum" task on the database > result should be a lot lot faster access to data. On my own database, it took around 2 minutes, so I expected a very low number of users will have to wait too long.

@Menion - +5 minutes here waiting. I guess I wasn't expecting the startup time to be any different to other startups - just small text "update of databases" - could provide better warning to expect longer delay. But why on 2nd startup did it run immediately then? Was "vacuum" only once-off?
 

Same here. I gave up after 3 Minutes stuck at 52% and killed the app. Some indicator that the App is not stuck or frozen would be helpful. The restart after the kill also went *a lot* faster

Greetings, Ulrich

@ Ulrich Kiermayr:
I assume that this is intentional or perhaps unavoidable. Due to the perspective, the map elements would have to be displayed smaller and smaller/closer together on the horizon (theoretically infinitely), which would no longer be possible to render meaningfully.

I don't think so. Given the visible street names in the blank area, there is no (in) visible horizon. It is just a little tilt where there is still only ground visible. Moreover, a horizon would be a straight line (not a 90°corner)

To me it looks like there are just three tiles missing on top.

Greetings, uk