Retrieving Position.Location coordinates in semicircles units not possible?

Although the coordinates of Position.Location can be defined with :semicircles format, they can't be retrieved in semicircles units.

The coordinates can only be retrieved using the methods toDegrees() or toRadians().

Does anyone know why there is no method toSemicircles()?

EDIT:
What is the unit semicircles and what are the benefits?

For example, the second hand of a watch can move continuously and smoothly or snap to every second. In the latter case, the angle of the second hand is mapped onto a grid of 60 seconds / 360 degrees.

Similarly, the exact geographic angles lat/lon can be mapped onto a grid with the size of the maximum value of a Lang.Number, which is 2^31 = 2,147,483,648 = 0x80000000. Therefore the formulas for the calculation of semicircles are

semicircles = degrees * 0x80000000 semicircles / 180 degrees
semicircles = radians * 0x80000000 semicircles / Math.PI

This conversion results in a small rounding error, since the true angle usually doesn't exactly hit the grid point. However, the advantage is that half of the memory space is saved. A pair of lat/lon in radians or degrees needs size of storage for two Lang.Double (64bit) and a pair of lat/lon in semicircles needs size of storage for two Lang.Number (32bit).

For example to store a course with every second recording for a time period of 1h = 3600sec in an array, storage is needed (without the overhead due to the object representation and for the management of the array):

32bit * 2 * 3600 = 230.400bit = 28,8kB for numbers
64bit * 2 * 3600 = 460.800bit = 57,6kB for doubles

Moreover, the execution performance of numbers is more efficient than that of doubles.

And because of these advantages, especially the smaller memory size, in a location object lat/lon are stored in semicircles and also in the fit the course points are stored in semicircles.

  • Thanks. Yes, I know.

    But why isn't it implemented in the API. It's such a basic functionality since the coordinates are stored in semicircles units in the location object and also fit files uses semicircles.

  • And even the semicircles barrel has a method toSemicircles()

  • When the Position module was made, semicircles were primarily thought to be something most developers would not be interested in, so it wasn't included (it's not a commonly-used format as far as I'm aware).

    As I recall (this was several years ago), we decided that the semicircle use case was not common enough to add to the API, but it seemed like a good example for our Barrel feature, which was under development at the time. The benefit to the barrel is that it requires no firmware changes or integration testing to make semicircles available for the relatively small number of developers interested in the capability.

  • Thanks for the explanation.

    When the Position module was made, semicircles were primarily thought to be something most developers would not be interested in, so it wasn't included (it's not a commonly-used format as far as I'm aware).
    for the relatively small number of developers interested in the capability.

    With time devs have learned the nuts and bolts of programming and their apps are more sophisticated.

    It's more elegant and doesn't need any calculation if the location object has the method toSemicircles(). But anyway, to keep it simple I code my own toSemicircles() as a workaround which gets the coordinates with toRadians() or toDegrees() and then calculates semicircles.

    But I don't understand that there are changes in the firmware of the devices necessary. IMO it's only a small extension of the CIQ API in that adding the getter method toSemicircles() for retrieving the private member variables lat and lon of the location object, similar to the barrel

    public function toSemicircles() {
    return [_lat, _lon];
    }

    and adding the :format option to call this method similar to the barrel

    ...
    case instanceof Semicircles.Coordinate:
    result = value.toSemicircles();
    break;
    ...

    This results in 6 additional lines of code in the CIQ API and probably be the same amount of new lines in the docs or am I wrong?

  • Adding this to the CIQ API means adding it to the CIQ VM, which is part of the firmware, which means a FW change, and for some devices, the FW doesn't get updated that often.  Providing a barrel, no change to the API, VM, or FW, and you can use it today.

  • Many thanks, now it's clear for me.