Messages

Below is not just in beta but pro as well...

if the export directory is invalid, and then long tap on a track, then tap Export, an orange msgbox is displayed with the correct problem, BUT only for a very short period, 100ms.

Also happens if you're exporting to an online service (OSM in my case), and you're in airplane mode with no internet connection.  Stupid mistake on my part.  (I mentioned this over on the help desk, with a different root cause; root cause was fixed, thanks.)  Once again, I needed to record a video with my camera, and step through it frame-by-frame to read the message.

(The error message, in orange, is behind a green "Process successful", which isn't true.)

[GPS Averaging]

I have some feedback on the new built-in GPS Averaging feature in beta 3.39.4.2:

First, the really obvious glitch.  My true coordinates are N53 W113, but the averaging screen shows S113 E053!  N/S are switched, E/W are switched, and even the order between the two numbers is switched.  Oh, and there's a leading zero that's not needed.  Also, it shows a distance of almost 14000km, which I assume is half the circumference of the earth.

But more importantly, there's an issue that's been around for years.  Once you tap Confirm, you're back at the point's Basic Info screen, with correct coordinates.  But the altitude is not what you just measured.  It appears to be SRTM altitude, but who wants that number when you've just measured a more accurate one with GPS?  And "Get" is ambiguous; what does it do?  (My best guess is, fetches SRTM altitude again, if not already known.)

Occasionally I like to measure peak altitudes for updating OSM, but have to remember to record the altitude separately because I can't trust the built-in field.  (Can't trust because it's ambiguous, and the number is different than I expected to see.)

Also, the choice of "GPS Averaging" as the name could cause confusion, as it's the same as the name of an external app doing the same function.  Since "My Location" and "GPS Averaging" are similar concepts, maybe you want different names such "My Location - Quick" and "My Location - Averaged"?

And one time only (first time), when I tapped "Get", the app disappeared.  A few times after that, no problem.

PS, it's a great solution to the problem of the external app having become malware.  Though for my own use, I managed to find an old good copy.

[@Viajero Perdido]

@Viajero Perdido
"Rockies": enjoy it and send us some photo from the field tests, so we have some kind of "nonworking" post here

Since you asked, how can I resist? 

I never knew grizzly bears came in white!  Shot from the porch of the Stanley Mitchell Hut in Yoho National Park, at close range.  This bear and its normal-colored sibling came around twice during the day.  Amazing to see.


There are a few more pictures in my geocache log here.

Sorry, I have no field test results.  I only carry Pro in the field, after some confusion in the past with G4L getting confused between two Locus versions (Beta/Pro).  But I eagerly await the next Pro version with the labels fix, thanks again.

As others have mentioned, the .3 beta seems to have fixed the cut-off text problem, even with magnified (200%) text.  Thank you!

I think I might have seen one text label disappear as I panned it into view, but that might have been a brain problem on my part (coffee not fully absorbed), because I couldn't reproduce it.

But essentially, I consider this fixed.   

I'm disappearing into the Rockies now for a week and can't reply to anything, sorry.

Magnifying the text of offline maps seems to increase the likelihood of labels being truncated.  I usually do 150% where it's fairly noticeable, and at 200% it's quite noticeable.

Text labels are still sometimes cut off at tile boundaries with Beta 3.39.3.1 when using OAM ML V4 maps.  LoMaps (which are still V3, right?) seem fine.

I asked earlier if there was a secret "hack" way to force V4 labels to render properly.  That's because I noticed that when you see a cut-off label, you can zoom out one notch, then in one notch, and it renders properly.  I'd thought, maybe there was a software hack to internally do the same thing, or something like it.

I don't remember what the advantages of V4 are, but I know this is the disadvantage.

Thanks for tweaking that; I'll check it out shortly.  (Just got back from a trip, so I'm slow in replying.)

I noticed the wiki isn't consistent about this; the page for tracktype https://wiki.openstreetmap.org/wiki/Key:tracktype suggests there is usage when combined with path, and well, I've seen it with my own eyes.    Cheers.

Hi again.  I'm really enjoying outdoorV4.

But maybe, a bug.  I think the combination of highway=path and tracktype=* makes trails invisible with both outdoorV4 and desertV4.

I couldn't force https://www.openstreetmap.org/way/120426357 to display, even when ticking all the checkboxes, and I think tracktype might be the cause.  This is with the June 2019 Alberta_ML.map from OAM.  The other V4 themes I have all displayed the trail.

Thanks as always,
VP

Nice and fast, as promised.     I'm starting to really like the V4 maps together with the outdoorV4 or active RT5 theme, and also little things like the fact natural=mountain_range now renders.

But one nagging thing...  The labels.  They're still being cut off at random, and I still need to dance around (out/in often works) to make the entire text render.  I refer to peaks, city names, and so on.

Is there any hope for a fix to label rendering?

Is there any secret "hack", maybe a config-file setting, that forces a little extra work to make the labels render reliably?  I'm willing to sacrifice some speed and hack something undocumented, if there's even a way...

A great map is a thing of beauty, and we are so close with the vector maps.   

I should have tried the beta or waited for the next release before speaking up, sorry.  Just tried the beta, and the performance issue is gone.  Thanks!

As you said in the release notes, "massive performance optimizations". 

.Best usually is to give me steps to simulate it.

Short and sweet:
1. Enable 20,000+ geocaches in one region
2. Zoom in to opposite side of planet, and note responsiveness.

No tracks visible, no map overlays, nothing else fancy.  I'll charge up the old tablet I use for betas, and give the beta a try...

You wrote you have visible "3 personal waypoints". Does it mean 3 cache waypoints that are connected by the thin line with it's cache?

Sorry, no.  Those were simply 3 manually-entered waypoints (great dim-sum, etc), with no connection to the great mass of caching waypoints far away.

Just checked again.  I turned on ~21,000 geocaches in Canada, then zoomed into a Hong Kong offline map, where only 3 personal waypoints are shown, nothing else nearby, and POIs are turned off as well.  Result: lag, can lift finger before it reacts.  A small but noticeable fraction of a second.

Then I turned off (hid) all those faraway Canadian geocaches.  Result: Hong Kong is nice and fast, very responsive!

Then I enabled "POI grouping".  Same result, both cases.

I assume this might be triggered by LoMap POIs too...

[laggy]

Hi.  Apologies if this was already discussed up-thread or in another language.

3.38.7 is really laggy when panning the map.  For a typical swipe-to-pan, you drag your finger across the screen, but the map doesn't react until after you've lifted the finger!

Psychologically, it sucks the energy out of exploring the map.

This happens with LoMaps, OAM V3, and OAM V4, on my low-DPI phone, also the high-DPI tablet.  Scrolling elsewhere, eg in the geocache logs list, is normal and responsive.

Is there a drag threshold that's set too high?  Is this something I can adjust?

EDIT:  Ah, I suppose I could turn off some of the ~15,000 geocaches I've got visible.  Trimming that down to ~4000 (my local area) made all the difference, performance acceptable again.  (The others were far outside the area covered by the current view, so should they have made a difference?)

[thank you]

First off, a big thank you for updating G4L for the new API.

I did find one glitch with 3.0.0.  When you "Download logs" from the Locus share menu, it also downloads log image thumbnails as usual, but in reverse order.  For example, my two logs on https://coord.info/GC2ZTTK .  (I assume it's G4L handling that.)

Sometimes you like to tell a story with the pictures, and are careful to upload them in the correct order.  Groundspeak then displays them in that same order on the cache page.  But for now, G4L inserts them in reverse order.

I trust that's a simple fix.  Hope so.  Thanks.