[APP] - version 3.3.X+ (updated 4.10.2014)

[Bucky Kid]

hi, I have disfavour about the method how estimated time to arrive on navigation is determined. I observe it highly depends on current speed. This tends to display strongly incorrect values if speed during trip highly fluctuates (ie: long uphill or downhill stage with bike). I wish the estimated time would be determined from much longer term (ideally from beginning trip) -> The longer term for estimated time determining the finest ETA value. This is very simple to calc - distance passed (on track) since starting navigation / track length (remaining length since starting navigation if starting in middle) * elapsed time since starting navigation

[menion]

What a nice surprise .. http://www.bestmobileappawards.com/app-submission/locus-map. Did you already recommended app by top button as me?

@christian: write me please step-by-step what you do. Thanks

@merillius: damn, I have no idea where is a problem and seems you are only one with such issue. Do you have simple name & passwork or it contains any special characters? So I may simulate your login credentials.

@CaptKaos: another possitive feedback. I'm maybe going to start think, that I did it good . Use for them ... in old version, checkboxes were dual-function. So when you wanted to delete all tracks, you firstly had to check them (load them on map). Now it`s not needed. You may simply delete tracks that are not loaded. So it`s faster and more intuitive. And also because of this, top buttons may helps you to select faster what you need.

@Bucky Kid: it`s more clever now then before. Anyway problem is probably if you use guiding or navigation with generated navigation orders right? In these cases, Locus do not know if you do "car ride / hike / bike", so it takes "hike" as default which has predefined speed around 4 km/h. I`ll improve it soon (hope), but not in the way you wants, because I`m worried result won`t be good in case something dramatically change during navigation (from bike to foot etc.)

[balloni55]

if i record a track and take pictures, red arrow-icons are displayed on picture position after saveing the track.
If i export  this track, also red arrow icon is exported and visible.
But if i hide this track and reopen it, the photo icon is displayed and also if i export this track!


And this red arrow icon is also stored in track preview map, so i have to change styl to reload it and now the photoicon is also visible here.
flowers= not reloaded, free= reloaded

[CaptKaos2]

Thanks for the answer Menion, understand now after a play with it.

CK

[michaelbechtold]

@Bucky Kid: it`s more clever now then before. Anyway problem is probably if you use guiding or navigation with generated navigation orders right? In these cases, Locus do not know if you do "car ride / hike / bike", so it takes "hike" as default which has predefined speed around 4 km/h. I`ll improve it soon (hope), but not in the way you wants, because I`m worried result won`t be good in case something dramatically change during navigation (from bike to foot etc.)

Hi Menion,
with intransparent "magic" (confirming best intents, but they won't help) you will never silence those discussions. Why not offer car/bike/hike/from start/last 30 mins (or similar) - and let people switch by a finger tip, and disclose what baseline is used for what ETA they currently see.
Just my 2c
Cheers
Michael

[menion]

@balloni: thanks, fixed

@michael: let's discuss about it, when I improve this system . Anyway thanks for a feedback, I see it in a similar way.

[balloni55]

if i export a poi or track with attached pictures as .kmz and disable "insert formatted discription" in export dialog, the pictures are also exported with .kmz but they are not displayed with e.g. GE
I think CDATA is not complete in this case.

[menion]

@balloni: Ihis problematic work with attachments is in locus for a very long time, sorry. It's not a work on a few hours to make ti all work correctly, so that's why it's still not yet working as expected ... :/

@0709: thanks, I'll check it

btw: fixed version is out, so hope all major issues will be fixed

[Stargaterunner]

Hello Menion,

I found a bug in the geocache filter menu Locus Pro 3.3.1
If I use the filter for something and nothing is found, and after that I clear the filter and nothing is to see. I must go out to the menu and then back to the caches...now i see the caches..
look my little video :-)

[jusc]

Version 3.3.1.
I try to find out, how I can change the colour of a track.
What is the difference between "Grundfarbe" (primary colour) and "Umrandung" (border line) colour?
If I choose a tansparent primary colour and a full colour for border line, the whole track line gets the full border line colour without any transparency.
I thought I would get small border lines with a transparent middle of the track.
Maybe I missunderstand the function?

Thanks in advance

[gynta]

If I choose a tansparent primary colour and a full colour for border line, the whole track line gets the full border line colour without any transparency.

-> http://help.locusmap.eu/responses/transparency-draw-black-outline-dark-trackline-color

...but we already talking about this. (in german Forum)
http://forum.locusmap.eu/index.php?topic=4214.0

[jusc]

...but we already talking about this. (in german Forum)
http://forum.locusmap.eu/index.php?topic=4214.0

Yes, but:

[gynta]

Ah ok

fix means
http://help.locusmap.eu/responses/colorpicker-opaque-transparency-ignored

[menion]

@stargaterunner: eh, thanks!

One question to all: if you use "Fill altitude" and Locus offer you "Online" and "Offline" method - has "Online" any usage to any of you or should I completely remove this possibility??

[gynta]

"Fill altitude" - has "Online" any usage to any of you

I use it whenever Wi-Fi is available. (...but 90% for testing)