Next way point API fields request

[buekliev]

Hi,
I am trying to send some data to my Pebble watch thru companion andoid app which I made from your add-on example app http://docs.locusmap.eu/doku.php?id=manual:locus_api:installation.
The main purpose is to let the user know where to go and how far the way point is, but it will be great to get the same info about the next way point (in case current is not the last one). For that matter would be useful to add a few new fields to the guiding part of the API:

• Is there next point or perhaps the current way point index from the end, so if it equals 0 means it is the last one
• course (bearing and/or azimuth) to the next way point from the position of the active way point
• course (bearing and/or azimuth) to the next way point from the current position
• distance to the next way point from the position of the active way point
• distance to the next way point from the current position

From the part of your code I get that fields used in the API are derived from constants related to the guiding part from 1400 to 1409, I can try other values too but it will be better if you say if there is such interface at all.

Hope I didn't duplicate someone's request and there is a chance of implementing it.

Thanks in advance.

[Menion]

Hello,

I'm always glad to see interest in using of Locus API for some own app.

I'll firstly try to forward you little bit. You are probably using "PeriodicUpdates". So you get from time to time "UpdateContainer" class with various parameters, right? From here you may get current GPS location (thanks to "getLocMyLocation()") and also current waypoint active in guiding ( "getGuideWptLoc()" ). From them you may compute distance and also azimuth (use LocationCompute class).

If current waypoint is last or not may be simply computed by compare of values getGuideDistToFinish() (which should be non-zero if we have enabled guide along track and not to single waypoint) and previous computed distance to waypoint.

Anyway agree that there are missing some parameters from current active guiding along track. So is any parameter really needed and it's not possible to compute it from received values?

[buekliev]

Hello,
first of all thanks for reply, I appreciate your effort in the community and of course in development of that ultimate map app.
You totally get the situation, I really use "UpdateContainer" class to access the changes in the app.
As I read my original message I realize it is not so clear what are my intentions, specially in terms I used, I will try to describe it more unambiguously.

Conditions:
There is a path defined by 3 way points : WP1, WP2, WP3
Active leg points to the WP2 (in a way from WP1 to WP2)

Wanted:

• Course to the WP2 - getGuideWptAzim()
• Distance to the WP2 - getGuideWptDist()
• Is it the last way point as you suggested can be deduced from (getGuideDistToFinish() == getGuideWptDist())
• Course to the WP3 from WP2 - MISSING (would be great to have)
• Distance to the WP3 from WP2 - MISSING (would be great to have)
• Course to the WP3 from current position - MISSING (optional)
• Distance to the WP3 from current position - MISSING (optional)
• Switch to the WP3 (no waiting to get to the WP2) - MISSING (optional)
• Switch to the WP1 (in case I made a mistake and want to get to the WP1 first and start over the guiding) - MISSING (very low priority)

Perhaps it will be suitable to provide some interface to navigate in "Path" and manipulate with WP as "Waypoint" object in "Path" context (now I can create "Waypoint" object from "Location" object "getGuideWptLoc()") with posibility to navigate in "Path". I found "actionStartGuiding(Activity act, Waypoint wpt)"  method in "ActionTools" class but it seams like it will create another point on the map with the same "Location" as the one from previous guiding and start a new guiding to it, which is not ok if I just want to switch to the next WP in my "Path".

Just in case it is not clear I use the word "Path" for drawn and recorded tracks on which can be used "Guide On" action.

I must say that the need in that functionality comes from my experience of using your app as marine navigation app for my sailing adventures and if I had all that stuff on my wrist I would just prepare my route before casting off and would not have to get my phone from my waterproof pocket for all the time.

I can really live without that "navigation in path/switching in WPs" thing and if there is no easy way to do it I would gave up on "Distance and Course to the WP after current one" too but it will be great to have that information ahead so I can prepare my crew to the next change of course before I get to the next WP.

Hope I don't want too much and excuse me if I missed some functionality in the API which already can provide the things I want.

Thanks again.

[Menion]

Precise description, thank you.

Oki, let's try something.

If you pull fresh update from Locus repository, you may check that UpdateContainer class has completely new section for guiding. So check it.

What you need to do, is to test getGuidingType(), to see which guiding is currently active and if will be active navigation, you may get navPoint1 as most closest navigation point (your WPT2) and navPoint2 as next navigation point (your WPT3).

Please be aware that point you get in current Locus version is not real navigation point where Locus navigates you (distance visible in top left corner during navigation). It is a point where Locus points with dashed line during guiding along track. Hmm, harder to explain, I'll have to do some pictures later to make it more clear. but at least for start, new WPT2, WPT3 objects.

Btw. you will need a new Locus version, which will be published probably at start of next week.

[buekliev]

Well that was fast (there is no note of sarcasm, I am genuinely impressed)

I am really looking forward to get the update and I already checked out the code and took a look on it.

I just need only one clarification from you.

"getGuidingType()" returns one of the following constants:
GUIDE_TYPE_DISABLED, GUIDE_TYPE_WAYPOINT, GUIDE_TYPE_TRACK_GUIDE, GUIDE_TYPE_TRACK_NAVIGATION.
Confirm that

• "navPoint1()" gives something only if "type" is GUIDE_TYPE_WAYPOINT or  GUIDE_TYPE_TRACK_GUIDE or GUIDE_TYPE_TRACK_NAVIGATION
• "navPoint2()" will give something only if  "type" is GUIDE_TYPE_TRACK_GUIDE or GUIDE_TYPE_TRACK_NAVIGATION and there is actually another next point
• In case of  GUIDE_TYPE_TRACK_NAVIGATION these points are NOT some points generated by navigation algorithm which are just helping me to get to my destination/semi destination but are actual points of my destination/semi destination  at least for now
• In case of  GUIDE_TYPE_WAYPOINT and GUIDE_TYPE_TRACK_GUIDE same apples as for  GUIDE_TYPE_TRACK_NAVIGATION but there is no obvious reason it to be changed and dashed lines will always point to them directly
• if "type" is GUIDE_TYPE_TRACK_GUIDE it will not change at the last waypoint to GUIDE_TYPE_WAYPOINT

It will be enough just to confirm or not confirm these statements.

I really hope that the next update is not triggered only by my request and I didn't cause much trouble.

Thanks again:)

[Menion]

Better?

- check if navPoint1,2 exists thanks to hasNavPoint1(), hasNavPoint2() functions
- these points exists only for GUIDE_TYPE_TRACK_NAVIGATION
- generally navPoints are exactly same points as if you in Locus starts "Navigate" feature, then tap on top left icon with distance and here on "itinerary". Here you may see all navigation points along route and these are points you now get over API (first two)

- in case of other types (GUIDE_TYPE_WAYPOINT, GUIDE_TYPE_TRACK_GUIDE), there are no new parameters.

In case of guidance to single waypoint, I'm not sure if there is need for any extra data.

In case of guidance along a track ("guide on" in Locus), it is little bit complicated. Imagine you record a track and every 10 metres is new point. Does it have sense to send some information about it over API?

And last think ... some "orders" like move to next point, move to previous etc. this later oki? Because what we discuss now is simple sending of static information about UpdateContainer. What you want require some intents with orders. So some more work and testing.

[buekliev]

Get it,

pity that those points do not work in case of GUIDE_TYPE_TRACK_GUIDE (that is exactly my key point of interest, I don't really need Locus as turn-by-turn navigation, there are no roads in the sea:))

In defense of my proposal of adding that feature to GUIDE_TYPE_TRACK_GUIDE I can say that at each 10m (each WP of the recorded track) the information about next WP is been sent by "getGuideWptDist()" and other related to Guiding point methods anyway so it is not a big overflow to send the same info about the waypoint following the currently active waypoint.
But you are the master and I have to accept your argument and use whatever I can get from the API:)

Of course there is nothing to add in case of GUIDE_TYPE_WAYPOINT, it is already perfect.

I totally agree that the idea of actively navigation between waypoints in a track or navigation thru API is much to ask and it doesn't have such a big priority for me particularly.

It was faster reply, but no updates in the code that time;)

Have a nice evening (in coding I assume:)).