Add guiding track id to API
I need to know which track is used for guiding. And I would like to get exact track, which means if locus generates a high detailed navigation track based on a low detailed route then I would like to get navigation track and not the route. Because it is very importand that each navigation point does match to the track id to make the compare more easy. I don't want to use point compare based on distance because this will have a lot of trouble with track loop detection.
I did already implement a hack as workarround to look for the static track id 1000000001. For example if I start navigation for my track id 50 locus does generate a navigation track id 1000000001
But now the usecase where my hack does fail:
If you start a navigation to a target point, locus doesn't create 1000000001 it does create track "51" if my track index was at 50.
I would like to get the guide track id over api, this would solve the following problems:
- to find navigation track I try to query 1000000001 and 1000000002 but this will waste time with stack trace generation
- if this does fail, the user has to do a 4 step process, click on the navigation track -> information -> share -> set to active (stores the selected track in memory)
- need to save the user selection in my addon memory
I did try to make this process more easy by hiding the "set to active" activity if I did find a valid navigation track. But unfortunantly the activity disabling does not only destroy the activity it does destroy a whole part of my application context. During the clear of my in memory cache I do loose the user selection as well, which means I don't do this anymore. Unfortunantly it is very complicated to find out which parts of my memory is hold at which instances. I thought I was save because each activity did has synchronized read access to my cache. But looks like some thing is hold in the wrong place and get destroyed during activity disabling.
Would be very nice if you could just add the ID, this would make thing much more easy and robust.
I like this idea 
Good day Falco,
will be added in next (Beta) version
https://github.com/asamm/locus-api/blob/c8398ed1dad18d519955030a39c95cdc5971dd15/locus-api-android/src/main/java/locus/api/android/features/periodicUpdates/UpdateContainer.java#L554
Test it and let me know if it works correctly.
Menion
Good day Falco,
will be added in next (Beta) version
https://github.com/asamm/locus-api/blob/c8398ed1dad18d519955030a39c95cdc5971dd15/locus-api-android/src/main/java/locus/api/android/features/periodicUpdates/UpdateContainer.java#L554
Test it and let me know if it works correctly.
Menion
Thank you, I did enter the Beta programm and will wait for the next Beta release.
Would you like a pull request with documentation updates? I don't have any in mind today, but I could think about problems I did have during using the whole API.
Thank you, I did enter the Beta programm and will wait for the next Beta release.
Would you like a pull request with documentation updates? I don't have any in mind today, but I could think about problems I did have during using the whole API.
Thanks for offer. Docs for Locus API are heavily incomplete, I'm aware of it. Most cases are covered by sample application I believe.
If you have something already written, PR will be welcome. If you just have in mind certain serious problems you had with API, let me know and I'll update/create required documentation for these cases. Thanks.
Thanks for offer. Docs for Locus API are heavily incomplete, I'm aware of it. Most cases are covered by sample application I believe.
If you have something already written, PR will be welcome. If you just have in mind certain serious problems you had with API, let me know and I'll update/create required documentation for these cases. Thanks.
Should I wait for the open beta or is there an closed beta for addon developers?
Should I wait for the open beta or is there an closed beta for addon developers?
It does work great.
But I can't test one of my old usecases:
In the past Locus Map Pro did create a Track called "Navigation" if you did start a navigation based on a existing track. It was a wired usecase because Locus did create a Navigation Track on top of an existng track. It did look like this: https://user-images.githubusercontent.com/8665625/48251893-7132f580-e403-11e8-87ca-ba7cdc8f0e2d.png you did acually see that there were 2 tracks over each other.
There was one special thing about this "Navigation" Track, it had more points then the original track which leads into some problems during matching "next guide point" to existing track. And for that reason I need to test this weird usecase.
Did you remove the "Navigation" track usecase? That would be great because I don't know why it was existing anyway.
It does work great.
But I can't test one of my old usecases:
In the past Locus Map Pro did create a Track called "Navigation" if you did start a navigation based on a existing track. It was a wired usecase because Locus did create a Navigation Track on top of an existng track. It did look like this: https://user-images.githubusercontent.com/8665625/48251893-7132f580-e403-11e8-87ca-ba7cdc8f0e2d.png you did acually see that there were 2 tracks over each other.
There was one special thing about this "Navigation" Track, it had more points then the original track which leads into some problems during matching "next guide point" to existing track. And for that reason I need to test this weird usecase.
Did you remove the "Navigation" track usecase? That would be great because I don't know why it was existing anyway.
Replies have been locked on this page!