[APP] - version 2.14.X+ (updated 3.9.2013)

[gynta]

..try test version in first post

nice! - it's better then nothing  <!-- s:mrgreen: -->:mrgreen:<!-- s:mrgreen: -->

[attachment=0:4mgtmrd6]<!-- ia0 -->Screenshot_2013-08-06-16-18-29.png<!-- ia0 -->[/attachment:4mgtmrd6]
edit
 -> background info

[menion]

I was sitting on this in the evening almost two hours and in the end I fell asleep on chair . As with some other features - I agree the some better and faster system is needed, but here I don't like simple adding few buttons to this menu. Usually some time helps, so for now just this button, improvements later

[ta-ka]

@menion
Thank you for the reply to the suggestions of the texts/translations.
I, of course, agree with and respect your decision.

[Mek]

menion,
about the problem with updating cache coordinates, I tried the "Update cache" functionality in Locus on GC1C6P1 now again an it still does not work.
Then I tried the same with GC2F2D0, which already has updated coordinates in Locus (and its icon is marked with star) - its coordinates were not lost, they stayed corrected as they were. I deleted GC2F2D0 and downloaded it again using the Import GC functionality and it was correct, with corrected coordinates. Deleting GC1C6P1 an reimporting does not bring its corrected coordinates. Strange.
So I dug into the data that is downloaded from GC into Locus using Shark (and Wireshark) and I found the following difference:
For GC1C6P1, there are original AND corrected coordinates in the JSON, and for GC2F2D0 there are only corrected ones. I recall I mistakenly used the "Correct coordinates" feature for GC1C6P1 and entered the original coordinates, which then I reverted back by using Restore, and then entered the correct final coordinates - maybe that's why there are two of them in the output. Compare (output from Wireshark):

GC1C6P1:

Code: [Select]

"UserWaypoints":[{"CacheCode":"GC1C6P1","Description":"Coordinate Override","ID":3231097,"IsCorrectedCoordinate":false,"Latitude":49.16325,"Longitude":18.778467,"UTCDate":"/Date(1375635535977-0700)/","UserID":5884890},{"CacheCode":"GC1C6P1","Description":"Coordinate Override","ID":3237835,"IsCorrectedCoordinate":true,"Latitude":49.1543,"Longitude":18.811467,"UTCDate":"/Date(1375719794327-0700)/","UserID":5884890}]}],"PQCount":0,"CacheCodes":[],"CacheLimits":{"CachesLeft":5994,"CurrentCacheCount":6,"MaxCacheCount":6000}}
GC2F2D0:

Code: [Select]

"UserWaypoints":[{"CacheCode":"GC2F2D0","Description":"Coordinate Override","ID":2609483,"IsCorrectedCoordinate":true,"Latitude":49.173217,"Longitude":18.81005,"UTCDate":"/Date(1367657873907-0700)/","UserID":5884890}]}],"PQCount":0,"CacheCodes":[],"CacheLimits":{"CachesLeft":5993,"CurrentCacheCount":7,"MaxCacheCount":6000}}
It looks to me that Locus took the first "Coordinate override" regardless of its "IsCorrectedCoordinate" attribute being true or false.

Now I found another issue - I generated a pocket query for Zilina and near caches, imported this GPX into Locus and all my solved caches were at corrected coordinates, so far so good (including GC1C6P1). But they were not marked with star - and this is important because then in the field I don't know if the cache really is in that place or those are just the dummy coordinates. I know it worked OK not so long ago (a month?) so something must have gone wrong...

[menion]

mek it's quite complicated to test it. Data you checked by Shark are received by Geocaching4Locus, and what in the end comes into Locus itself is absolutely different.

about problems with import from PQ files: I've changed coordinates to one cache, generated PQ and after import, cache is on correct coordinates (changed) and no star (as computed). But if I check generated PQ files, there is no hint that this cache is computed. I also do not remember that something like this existed before. So are you sure, it worked in this way?

[KaHeMu]

When I solve a mystery cache then first I change coordinates in Locus. Cache is marked as computed. After that I correct coordinates at GC.
In Locus preference for importing PQ is set to leaving own data during import process.

Now the red star for computed/ corrected coordinates in Locus is always on.

Regards,
KaHeMu

Sent using TapaTalk

[Mek]

But if I check generated PQ files, there is no hint that this cache is computed. I also do not remember that something like this existed before. So are you sure, it worked in this way?

Absolutely. I went caching to Ostrava a month ago and I made a pocket query with solved caches there, they all had the little star in the corner. I also looked at the gpx file I made today and yes, there is no hint about the coordinates being corrected. It came to my mind that perhaps I could compare the gpx I used a month ago with the one generated today but sadly I don't have it anymore
Now I think it could have something to do with recent site upgrade on GC.com, they f**ed up something I am afraid. I will try asking on their forums.

[menion]

hmm when you went to ostrava, isn't there chance you had some data downloaded by any add-on? I should expect that cache with corrected coordinates should have in GPX file final waypoint with these coordinates, but nothing like this is there. So maybe that this is a problem. Cache has already fixed coordinates and waypoint is missing.

[Martin Sloup]

Sorry for corrected coordinates. When I wrote the stuff around this, there wasn't field IsCorrectedCoordinate. I will try to fix it ASAP. Today I'm returning back from vacation, so maybe at evening.

[Mek]

hmm when you went to ostrava, isn't there chance you had some data downloaded by any add-on? I should expect that cache with corrected coordinates should have in GPX file final waypoint with these coordinates, but nothing like this is there. So maybe that this is a problem. Cache has already fixed coordinates and waypoint is missing.

On GC.com forums they told me that the GPX files coming from PQs actually never contained any flag about corrected coordinates, so now I am confused. Perhaps I really just used the G4L addon but just don't remember that? Anyway, if that is true, I hope they implement this feature at some point...
Arcao: thanks for quick response and fix in advance

[menion]

fine, I also think that it never were there . There is more then this, what is missing in exported GPX files, but for unknown reason, they do not update GPX files specification ... maybe for them just prefer using their API over GPX files ...

[john_percy]

I don't know if you class this as a display bug, but on vector maps, short elements of dotted lines may disappear for certain angles at high zoom. For example, using a V-Scale theme to display OpenAndromaps Great Britain map, the short elements of power lines disappear on sections where the lines run close to 45 degrees. I know this is not a Locus built-in theme nor a Locus Store map, that's why I am slightly hesitant about flagging it here - but as far as I can see it is a display bug in Locus. [attachment=1:k2pnprjp]2013-08-07 23.06.56.jpg[/attachment:k2pnprjp][attachment=0:k2pnprjp]2013-08-07 23.05.56.jpg[/attachment:k2pnprjp]

Edit: The points illustrated above are: N 52° 10.877' W 01° 00.129' and N 52° 10.574' W 00° 59.969'. A similar problem occurs with the Locus England map and Locus built-in Hiking & Cycling themes, which display major power lines, though I initially thought they did not.

[jusc]

In version 2.14.1 is added a new feature : "ability to turn on screen also........". What is it, or where can I set it for use?

[menion]

menu > settings > global > control screen on/off ... very usable, you'll see

[Bucky Kid]

I report on this version following bugs: long pressing zoom in/out buttons makes Locus crash with any kind of map
and
Screen turns off during work sometimes in random situation (I don't observe this behavior with other apps,)

I also see map shading inactive for zoom kevels 100% and above. Is this bug or intention? I'd like to have map shading for all zoom levels if possible.

Sent from LT22i using Tapatalk 2