Topics

I'm looking for a (internal/external) LoMaps-theme which shows more bicycle-related information, like:

• vending machines for bicycle tubes (OSM: amenity=vending_machine, vending=bicycle_tube) or
• charging stations for ebikes (OSM: amenity=charging_station, bicycle=yes)

Currently, I use an overpass query and import this as POIs to Locus Maps, but it would be nice to have this information directly shown in the map (e.g. using the hike&bike theme). Or are these nodes excluded from LoMaps to save space?

I used Locus to find a Chirp geocache (using the ANT+-manager and an ANT-adapter connected via USB-OTG).

Everything worked perfect 

However, if I try to connect to the Geocaching sensor (or any other sensor) without an ANT-adapter present in the system, I get just a toast message like "process interrupted". This is not very helpful, especially for less-technical-skilled users. I'd expect something like "There is no ANT-adapter available." or "Could not connect to ANT-adapter"...

[the top most item will be deselected and the chosen action is applied to the remaining points only.]

There is a small bug in selecting multiple items in a sorted list of POIs, when selecting multiple points, the topmost point is deselected.

To reproduce:

• take any list of POIs, sorted by name (other sort options probably show the same issue)
• deselect all items
• now select some of the first items, including the top most POI
• try to run any action on the selected items (e.g. "change icon") - the top most item will be deselected and the chosen action is applied to the remaining points only.

This happens to me reproducable in the last released version as well as in the latest beta (3.8.2.3).

Small UI problem when entering coordinates, e.g. here:
Search -> Move Map -> Coordinates -> enter coordinates in WGS format and change longitude from 'E' to 'W'
Result: empty label (instead of an expected 'W')

Were there any changes regarding the automatic change of the color scheme (day-/nightmode) in the latest released version?

It seems to me that the color scheme does not switch automatically any more. It stays in day mode, even if it's late enough to switch to the dark color scheme. If I disable the automatic switching (via fast settings) and enable it again, the color mode is switched immediately.

In case it matters:
* navigation mode active
* online map
* map rotation / autozoom turned on
* Nexus 5, Android 5.0.1

Thanks & regards,
mambofive.

Gibt es hier Nutzer von opencaching.de?
Ich habe ein kleines Perl-Script geschrieben, das mir Caches von opencaching.de herunterlädt und etwas anpasst, damit möglichst viel der opencaching-spezifischen Informationen nach Locus zu importieren.
So werden die Attribute (die z.T. anders sind als bei geocaching.com) in das Listing mit eingebaut, Geokretys mit importiert und Wegpunkte aus Texten in der Personal Cache-Note angelegt (so wie bei geocaching4locus).
Das Script läuft in Perl, ich habe es unter Linux im Einsatz, es läuft aber auch unter Windows (ActivePerl vorausgesetzt). Eine kleine Doku ist auch mit dabei.
Es ist für den Eigenbedarf entstanden, wer Lust/Bedarf/Interesse hat, kann es ja gerne mal ausprobieren. Ich freue mich über Rückmeldungen.

Das Script gibt es hier: http://github.com/ebillen/oc2go

When I tap on a cache on the map, the new (nice!) pop-up label opens.
If I tap on the pop-up label, the cache details page opens.

If I repeat this several times (open pop-up-label, open cache details, back button, open cache details, back button...), Locus crashes reproducably - sometimes after 2-3 iterations, sometimes after 10.

If I can produce some debug output / logs etc., please tell me.

[Update 1]

In version 3.2.2, a full backup in Locus results in a file sized ~12kb (although Locus reports the backup as finished successfully), whereas my backups are usually 10-15 MB.

Since I don't believe in a new compression algorythm  , I think there is something going wrong here...

Update 1: the zip file contains only a folder "_varios", "data" and "icons" is missing.

Update 2: seems to be fixed in 3.2.2.2 (beta)...

Since updating to the latest vesion yesterday, I randomly get error messages regarding file access, mostly srtm files. See attachement.

The file WWW15MGH.DAC named in the message does not exist in my Locus folder. I didn't see this message in the previous Locus version. However, I can't see anything not working properly, it's just the message popup...

In version 2.20:
If I refresh a geocache (using gc4l), each refresh creates a new "set" of associated waypoints for this cache. So after e.g. five refreshs, I have five "parking location" associated with that cache.

I'm sure this has been discussed before, but I can't find a topic matching the search term "geokrety"...

So, what about supporting geokretys in Locus?

Currently, we have an Android App (Geokrety Logger) which supports basic logging functions for GeoKretys, but is not (yet) integrated into Locus.

These are my ideas about basic GeoKrety support in Locus:

• A general switch to turn GeoKrety support on or off, there are may cachers which ignore them...
• Locus should know about GeoKretys in caches and display them in a separate tab similar to geocaching.com-trackables. This information can be retrieved online (e.g. http://geokrety.org/export2.php?wpt=GC43), Locus should be able to update this information for single caches or a list of selected caches (like gcvote support).
• Filter and sorting functions should support geokretys
• For basic logging functionality ("retrieve this geokrety from this cache", "drop a geokrety from my inventory in this cache", etc.), the Geokrety Logger App could be used, Locus should provide short cuts to call this app and pass GC-code, tracking code etc to the app, so I don't have to enter the same information there again.

Just my 2 cents, what do other geocachers think about this?

If I display a list of geocaches, sorted by date of last update, and update some single geocaches manually, their position in the list is not changed unless I close the list and reopen it.
Is it possible to dynamically reorder the list after single geocaches have been updated/changed?

When refreshing a larger number (some more than 1000 caches) via gc4l, I get the attached message ("Slower! You've reached the limit of maximum actions / calls per minute").



I don't know the limitations of the gc API, but if there are limits for total number of refreshes and/or refreshes/minute, IMHO Locus should respect them and warn me (or reduce speed of refreshing) before getting stopped by gc.com.

This is not a big issue of course - I can split my caches and refresh them in several steps (and probably I should do some housekeeping on my device and clean up some old data...  )

[overwritten and set back to N 0° E0°]

Multicaches often have waypoints where you have to compute the coordinates while doing the cache. These waypoints are created with coordinates N 0° 00.000 E 000° 00.000; I usually adapt the coordinates of these waypoints according to my findings when doing a multi.

When refreshing a cache (e.g. using geocaching4locus), the coordinates of these associated waypoints are overwritten and set back to N 0° E0°, no matter wether the "keep data while importing" setting in the geocaching section is set or not; whereas other information in the cache (like personal notes) is not overwritten.

IMHO the refresh should no touch these waypoints if the "keep data while importing" setting is set.
Refreshing should only
* add new logs,
* update the cache description and the status,
* change trackables in the cache and
* update the number of favorite points...

[coordinates]

When I use navigation in Locus, I can use the recently used list to define start and destination of navigation.

However, the list shows recently used POIs, recently used address searches and recently used coordinates. The coordinate entries might come from geocaching activities or route recalculations of former navigation activities.

I don't see a reason why coordinates should be listed in this recently used list, the list would be much clearer and easier to use without them. So I suggest to filter the list and display only 'named' targets and leave away all coordinate entries here.

Very  small issue with visibility of waypoints:

If I refresh the gcvote-information of a geocache, it's waypoints are hidden afterwards - no matter wether they were visible before or not.

This (small) problem is related to my post on getsatisfaction.

Locus crashes reproducibly when deleting geocaches from a search result set.

Steps to reproduce:

• search for a geocache by name
• from the search result set, select a cache. The cache details are shown, there is no "tools" menu available.
• Now, update the cache via gc4l (3rd party menu -> update cache)
• The cache is updated, the details of the updated cache are displayed, this time showing a "tools" menu
• Now delete the cache using "tools"->"delete"
• The cache is deleted, but still available in the search result set. If you select it again from the search result set, Locus crashes.

After deleting the cache, Locus should update the search result set accordingly to avoid that.

However, without the last step this is a possibility to delete caches from a search result; I was still missing that function described in my getsatisfaction post.  

Previous released version (2.12.0) had a problem with logging caches, every newline was converted to a "n".

The current released version (2.12.1) fixes that, however, when logging a trackable online via GC Live -> Log a trackable, that conversion still occurs.

[for sure]

Probably not a Locus problem (that's why I post this here and not on getsatisfaction) - I think Android is responsible for this problem:

When I receive a phone call while navigation is active, Locus exits if the phone call takes longer (~10-15 mins). When the phone call ends, Locus is restarted, but the navigation track is gone. I have to stop somewhere and start a new navigation by choosing the destination again.

I know the Android task manager option to stop apps in background after some time if the display lock is active - but Locus for sure is not the list of apps to stop.

Does anybody know an Android setting which could be responsible for that? Android Version is 2.3.6.

 :idea: BTW, it would be more useful if Locus stayed in foreground while the phone call is active, so that I can still follow the navigation. On a previous phone running on Symbian, OviMaps stayed in foreground when a phone call was received. While the phone call was active, there was a green headset symbol in one corner of the map, but the map with the navigation was still in foreground.

Hi menion,

how does the new import feature for PQs work? I successfully linked locus to my gc account, but when I try to download a PQ, locus tells me that there are no pocket queries to download.

Thanks,
 Elmar / mambofive.