I believe the groundspeak API has recently been updated so that it now possible to obtain/show adventure lab stages. Could this be incorporated into Locus?
Adventure labs in Locus
Completed
I would like to request that Locus be add the adventure labs geocaches.
Official app has this solution till April 12, limited to PM users.
If there is appropriate function on API, is chance to implement it into Locus add-on?
https://forums.geocaching.com/GC/index.php?/topic/361419-release-notes-geocaching®-app-adventure-pins-april-12-2021/
Official app has this solution till April 12, limited to PM users.
If there is appropriate function on API, is chance to implement it into Locus add-on?
https://forums.geocaching.com/GC/index.php?/topic/361419-release-notes-geocaching®-app-adventure-pins-april-12-2021/
Great idea... I like to see it.
Great idea... I like to see it.
Don´t like it. Don´t want to see it.
Don´t like it. Don´t want to see it.
It would be really great to see the AdLab icon at the map ... 😏
It would be really great to see the AdLab icon at the map ... 😏
I would enjoy support of Adventure lab too. But I'm afraid this is just possible if Groundspeak has opened their complete Labs-API to 3rd party apps like Locus - which is not available yet.
Right now you have to use other software like GSAK to load Info of Labs, export them into a .gpx file and import this one via Locus.
What is possible is to create a temporary solution based on the limited available API, like GSAK does: Load all Adventure labs within a radius including coordinates, descriptions, questions and draw the Lab-icons on the map.
Not possible is to obtain wheter you already found a certain lab. You would have to set the found status manually.
I would enjoy support of Adventure lab too. But I'm afraid this is just possible if Groundspeak has opened their complete Labs-API to 3rd party apps like Locus - which is not available yet.
Right now you have to use other software like GSAK to load Info of Labs, export them into a .gpx file and import this one via Locus.
What is possible is to create a temporary solution based on the limited available API, like GSAK does: Load all Adventure labs within a radius including coordinates, descriptions, questions and draw the Lab-icons on the map.
Not possible is to obtain wheter you already found a certain lab. You would have to set the found status manually.
Currently, the function has also been implemented to c:geo.
Currently, the function has also been implemented to c:geo.
Lots of votes but still not implemented 😀
Lots of votes but still not implemented 😀
But there is a workarround ... 😉
I use https://gcutils.de/lab2gpx/# to export all ALC points ... and easily import into LM.
But there is a workarround ... 😉
I use https://gcutils.de/lab2gpx/# to export all ALC points ... and easily import into LM.
Hello guys,
hope, most of you noticed, that lab caches are already for some time supported natively in the Locus Map 4 application. I believe you find it useful.
Hello guys,
hope, most of you noticed, that lab caches are already for some time supported natively in the Locus Map 4 application. I believe you find it useful.
I assume you're referring to the option 'GC Live Map' option as well as natively recognizing AL waypoints. That is indeed very nice. Hiking/navigation to AL waypoints via Locus is SO much better than the native displays in the AL app.
However, the web site https://gcutils.de/lab2gpx downloads all the individual stops in an AL, not just the published starting point. Would it not be possible to add this functionality at some point?
I assume you're referring to the option 'GC Live Map' option as well as natively recognizing AL waypoints. That is indeed very nice. Hiking/navigation to AL waypoints via Locus is SO much better than the native displays in the AL app.
However, the web site https://gcutils.de/lab2gpx downloads all the individual stops in an AL, not just the published starting point. Would it not be possible to add this functionality at some point?
At least I am not aware of that. Thanks for the information. Could you also give a hint, where to look for them in Locus?
At least I am not aware of that. Thanks for the information. Could you also give a hint, where to look for them in Locus?
In the Locus Map 4, access to lab caches is along the access to all other caches. There are two places:
- side "Map-screen content" panel > GC Live map
- menu > All features > Geocaching > Search for geocaches
In both cases, the app uses a filter that specifies what to download/display. Here, among other cache types is also the "Lab cache" option.
Hope this helps.
In the Locus Map 4, access to lab caches is along the access to all other caches. There are two places:
- side "Map-screen content" panel > GC Live map
- menu > All features > Geocaching > Search for geocaches
In both cases, the app uses a filter that specifies what to download/display. Here, among other cache types is also the "Lab cache" option.
Hope this helps.
Hi Locus Guys, I'm afraid the topic concerning proper support of Adventure Labs isn't solved, so please remove the "solved" tag. People can use this topic to report future bugs regarding Adventure Labs in Locus
1) Two Weeks ago Groundspeak removed the short "Firebase Dynamic Link" and instead is just working with 36 bytes GUID-strings to identify an Adventure. Often the 5 individual Stages of an Adventure are attached as "Child-Waypoints" within the GPX-file. But Locus isn't able to recognize them as Children if the <name>-Tag of a waypoint is longer than 32 bytes - like with Adventure-GUIDs. User-definied IDs can even be longer by attaching prefixes/suffixes to the pure GUID, e.g 42 bytes: "AL-944F0F8D-6D77-4077-A76D-3195D285EF03-01"
2) Locus isn't able at all to recognize Child-WP at all if loading .GPX files created with C:geo although c:geo's gpx-files are using correct tag <gsak:Parent> to tag the belonging of a child to its Parent.
3) GPX-Export of Adventures isn't done with correct tags:
a) in case of Export-format "GPX v1.1" there are 2 URLs "<link href">, where 1 is a mistake ("https://coord.info/..."). This is also true for exporting Geocaches (https://... and http://...)
b) <gsak:Parent> is missing to tag the belonging of a child to its Parent.
For Import/Export tests I attach a GPX file created by c:geo including 1 Adventure with 1 Stage as child waypoint.
Hi Locus Guys, I'm afraid the topic concerning proper support of Adventure Labs isn't solved, so please remove the "solved" tag. People can use this topic to report future bugs regarding Adventure Labs in Locus
1) Two Weeks ago Groundspeak removed the short "Firebase Dynamic Link" and instead is just working with 36 bytes GUID-strings to identify an Adventure. Often the 5 individual Stages of an Adventure are attached as "Child-Waypoints" within the GPX-file. But Locus isn't able to recognize them as Children if the <name>-Tag of a waypoint is longer than 32 bytes - like with Adventure-GUIDs. User-definied IDs can even be longer by attaching prefixes/suffixes to the pure GUID, e.g 42 bytes: "AL-944F0F8D-6D77-4077-A76D-3195D285EF03-01"
2) Locus isn't able at all to recognize Child-WP at all if loading .GPX files created with C:geo although c:geo's gpx-files are using correct tag <gsak:Parent> to tag the belonging of a child to its Parent.
3) GPX-Export of Adventures isn't done with correct tags:
a) in case of Export-format "GPX v1.1" there are 2 URLs "<link href">, where 1 is a mistake ("https://coord.info/..."). This is also true for exporting Geocaches (https://... and http://...)
b) <gsak:Parent> is missing to tag the belonging of a child to its Parent.
For Import/Export tests I attach a GPX file created by c:geo including 1 Adventure with 1 Stage as child waypoint.
Hello Sonny,
from where comes "AL944F0F8D-6D77-4077-A76D-3195D285EF03" value? Because also the link to Adventure https://labs.geocaching.com/goto/4396aa4b-9362-4c7e-ad93-c60a19541dd6 has different identificator.
Also, in the official GPX system, cache has own ID, in this case it is "4396aa4b-9362-4c7e-ad93-c60a19541dd6". Waypoints are then attached based on this id. In case, waypoint has name with <two letters>-followed by parent ID, it is automatically attached.
I do not know, why GSAK authors created a different style here, but is it incompatible with old working solution.
Hello Sonny,
from where comes "AL944F0F8D-6D77-4077-A76D-3195D285EF03" value? Because also the link to Adventure https://labs.geocaching.com/goto/4396aa4b-9362-4c7e-ad93-c60a19541dd6 has different identificator.
Also, in the official GPX system, cache has own ID, in this case it is "4396aa4b-9362-4c7e-ad93-c60a19541dd6". Waypoints are then attached based on this id. In case, waypoint has name with <two letters>-followed by parent ID, it is automatically attached.
I do not know, why GSAK authors created a different style here, but is it incompatible with old working solution.
Hi Menion,
Well, for whatever reason, but there've historically always been 3 kind of ID's per Advanture Lab delivered by Groundspeak's Lab-API:
1) Adventure ID ("944f0f8d-6d77-4077-a76d-3195d285ef03 in example AL, like GC-code of Geocaches)
2) Deep-Link ID ("4396aa4b-9362-4c7e-ad93-c60a19541dd6" in example AL, like guid-URL of Geocaches)
3) Firebase-Dynamic-Link ID (eg. "VWnv", also some kind of URL, much shorter than 2) and redirecting to 2)
Since 3) is the by most the shortest, Creators of Lab-GPX-files (e.g. Website "Lab2GPX", App "C:Geo", or some GSAK-Makros which both rely on "Lab2GPX" Script), used 3) with some prefix/suffix (eg. "ALVWnv01") to allocate each AL-Stage an individual code, similar to the GC-Code of Geocaches. But 3) was cancelled by Google+Groundspeak some weaks ago, so just 1) and 2) are delivered since 2 weeks.
So it seems to be that 1) (optionally with some prefix/suffix letters to improve differentiation within an App - like "AL944F0F8D-6D77-4077-A76D-3195D285EF03" of example) will be used of all major Lab-GPX creators in the future to code each AL. C:geo is doing this since some 1,2 weeks like in the example-GPX file I sent.
Ref: https://github.com/cgeo/cgeo/issues/17324 and https://github.com/cgeo/cgeo/pull/17329
So these will be what GPX-files will look like which people will load LOCUS to get each Stage of their ALs of interest. Locus should work with them. Just PQs for Geocaches. At least as long as Locus is just able to load basic Header-infos of Labs but not its 5 Lab-Stages, their coordinates and their Listings.
Right now on import is the problem, that Locus isn't able to proper recognize the 5 Stages of a lab as children waypoints of the Header WP. But is importing them as single, individual Waypoints, with the downside the the optical red line-connection on the map of all 5 Stages with its parent is lost.
Then compared with Geocaches, for Labs the "Code"-Line within the main site is missing (before Cachetyp and Hidden-date).
This Code-field would be good if people want to use it like with Geocaches: to open them in external App, or share Code,Name, Coordinates by clicking on the small arrow on the right.
Finally some export details are not working optimal yet, if people want to export/import their Labs with other peoples software (Locus or other software) but this could be fixed later.
Hi Menion,
Well, for whatever reason, but there've historically always been 3 kind of ID's per Advanture Lab delivered by Groundspeak's Lab-API:
1) Adventure ID ("944f0f8d-6d77-4077-a76d-3195d285ef03 in example AL, like GC-code of Geocaches)
2) Deep-Link ID ("4396aa4b-9362-4c7e-ad93-c60a19541dd6" in example AL, like guid-URL of Geocaches)
3) Firebase-Dynamic-Link ID (eg. "VWnv", also some kind of URL, much shorter than 2) and redirecting to 2)
Since 3) is the by most the shortest, Creators of Lab-GPX-files (e.g. Website "Lab2GPX", App "C:Geo", or some GSAK-Makros which both rely on "Lab2GPX" Script), used 3) with some prefix/suffix (eg. "ALVWnv01") to allocate each AL-Stage an individual code, similar to the GC-Code of Geocaches. But 3) was cancelled by Google+Groundspeak some weaks ago, so just 1) and 2) are delivered since 2 weeks.
So it seems to be that 1) (optionally with some prefix/suffix letters to improve differentiation within an App - like "AL944F0F8D-6D77-4077-A76D-3195D285EF03" of example) will be used of all major Lab-GPX creators in the future to code each AL. C:geo is doing this since some 1,2 weeks like in the example-GPX file I sent.
Ref: https://github.com/cgeo/cgeo/issues/17324 and https://github.com/cgeo/cgeo/pull/17329
So these will be what GPX-files will look like which people will load LOCUS to get each Stage of their ALs of interest. Locus should work with them. Just PQs for Geocaches. At least as long as Locus is just able to load basic Header-infos of Labs but not its 5 Lab-Stages, their coordinates and their Listings.
Right now on import is the problem, that Locus isn't able to proper recognize the 5 Stages of a lab as children waypoints of the Header WP. But is importing them as single, individual Waypoints, with the downside the the optical red line-connection on the map of all 5 Stages with its parent is lost.
Then compared with Geocaches, for Labs the "Code"-Line within the main site is missing (before Cachetyp and Hidden-date).
This Code-field would be good if people want to use it like with Geocaches: to open them in external App, or share Code,Name, Coordinates by clicking on the small arrow on the right.
Finally some export details are not working optimal yet, if people want to export/import their Labs with other peoples software (Locus or other software) but this could be fixed later.
Replies have been locked on this page!