Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Radim V

Pages: [1]
1
Troubles & Questions / Re: FIT file with course points
« on: September 25, 2019, 14:47:57 »
Hallo there,
In the recent version of FitSdk by Garmin(20.76.00), there is support for 27 coursepoints.
I am particularly interested in CoursePoint.SEGMENT_START and CoursePoint.SEGMENT_END.
If I generate myself a .fit file using these types and import it to Locus, I get both coursepoints/waypoints displayed.
Just their representation is very basic. This is fine, no problem. I just want to make sure there is no sophisticated mechanism for Garmin's (and Strava, of course :-)) segments in Locus. Do I need to expect any dedicated waypoints coming from Locus, representing them? If any related information has been made public please redirect me. Thanks, Radim.

2
Ahh, sorry, will write.

3
Hallo Locus team,
I am developing two add ons with Locus API. For both of them, I need to represent summits and valleys in the hierarchy of classes around Point. First I need to encode this generic SUMMIT / VALLEY enumeration and return it as a new Waypoint to Locus (using Locus API, not app import). (Many Garmin Edge devices have the ability to tell me "now you are going to be mostly climbing / descending for 5 km / 10 minutes"). I cannot figure out how to properly represent this summit valley classification.
Then I need to decode it from the data containers that Locus uses around Waypoints and map them together with all other enumerations from PointRteAction to a collection of types that Garmin's fitSDK understands. I have been previously working with .tcx files. Locus imports them ok, it assigns nice icons to both summits and valleys and also parses other data from <coursepoint> element like name and description and adds PASS_PLACE PointRteAction. Of course I could encode summits / valleys in the name e.t.c but having those two add ons related in such a tightly coupled way would be very bad. I can provide any details and data needed. Thanks, Radim.

4
Add-ons / hasSpeed() inconsistency in track obtained via API
« on: December 04, 2018, 22:47:16 »
Hallo, I am developing something with Locus API, and in one of my debug dumps I noticed some inconsistency regarding methods  location.hasSpeed(). If you check attached files, namely lines 26, 34, 39 in the .dump file you should see what I mean. GPX file that I imported in locus and consequently got via standard API mechanism (ActionTools.getLocusTrack()) also attached.
Only first "trackpoint" has speed false, all other have speed true, but 0 which is incorrect I think. (location and timestamp are available) 
This is not pressing issue to me as I use location and timestamps to recalculate speed or force constant speed if track is not fully timestamped.
Thanks, Radim

5
Hello Locus,
Sadly, I don't quite remember if Locus(pro) is in  Slopes or Colored elevation mode here . All should be easily reproducible. I may have some vague idea why this is happening but if you elaborate, that would be greatly appreciated. (.hgt filters and transforms geek here). Thanks
Radim, Praque

Pages: [1]