[Question]: Distinguish between real '0' and no-data '0'

[Priyantha-Kingslake]

Please check the following before submitting a new issue.

• [x] I have searched the existing issues.
• [x] I have carefully read the documentation.

Please select for which platform(s) you need help

• [x] Android
• [ ] iOS
• [ ] Linux
• [ ] macOS
• [ ] Web
• [ ] Windows

Your question

The following is extracted from within package implementation

/// The speed at which the devices is traveling in meters per second over
  /// ground.
  ///
  /// The speed is not available on all devices. In these cases the value is
  /// 0.0.
  final double speed;

  /// The estimated speed accuracy of this position, in meters per second.
  ///
  /// The speedAccuracy is not available on all devices. In these cases the
  /// value is 0.0.
  final double speedAccuracy;

according to this we get 0when there is no data. How do we distinguish whether this 0 means no-data or real 0?

Could no-data be changed to return null? Or expose getters to identify the value between real and not-found.

Version

14.0.1

[Priyantha-Kingslake]

I also noticed that this is not constant per device. I have ~30% out of all location fixes with 0, 0 for heading and heading_accuracy

[TimHoogstrate]

Dear @Priyantha-Kingslake,

For iOS speed can have a negative value. That indicates that the speed is not valid:

  // A negative speed value indicates an invalid speed.
    // When the speedAccuracy contains a negative number, the value in the speed property is invalid.
    //
    // Relevant documentation:
    // - https://developer.apple.com/documentation/corelocation/cllocation/1423798-speed?language=objc

On Android we check if speed is available... If it is available we pass the .speed() property. So it seems that the platform interface documentation is not entirely correct.

I need to update the documentation.

Kind regards,

The other question

I also noticed that this is not constant per device. I have ~30% out of all location fixes with 0, 0 for heading and heading_accuracy

in Android, the heading is represented by the bearing.

if (location.hasBearing()) position.put("heading", (double) location.getBearing());

The bearing is the angle to the magnetic north.

Returns the estimated bearing accuracy in degrees of this location at the 68th percentile confidence level. This means that there is 68% chance that the true bearing at the time of this location falls within getBearing() ()} +/- this uncertainty.

on iOS We use the course.

// A negative course value indicates that the course information is invalid.
    // When courseAccuracy contains a negative number, the value in the course property is invalid.
    //
    // Relevant documentation:
    // - https://developer.apple.com/documentation/corelocation/cllocation/1423832-course?language=objc
    // - https://developer.apple.com/documentation/corelocation/cllocation/3524338-courseaccuracy?language=objc
    double heading = location.course;

Overview Heading and course information are commonly used by navigation apps to help guide the user to a destination. The heading of a user’s device is its current orientation relative to magnetic or true north. Devices with GPS can report course information, which represents the direction in which the device is moving. The Compass app in iOS uses heading information to implement a magnetic compass interface, as shown in Figure 1. Augmented reality apps might use this information to determine which direction the user is facing.

I need to discuss these properties within the team because we might need to update the documentation.

Kind regards,

[Priyantha-Kingslake]

For iOS speed can have a negative value. That indicates that the speed is not valid

If a negative value for speed indicates invalid data, wouldn’t it be better for the plugin to return that as null instead? Negative values may be interpreted as meaningful data, unless it really is in certain scenarios.

On Android we check if speed is available... If it is available we pass the .speed() property.

Just to clarify, I'm talking about all the fields provided by Position object, not only speed and speedAccuracy. They all defaults to 0 which is misleading.

Shouldn’t it return null when the field is genuinely unavailable?

[TimHoogstrate]

For iOS speed can have a negative value. That indicates that the speed is not valid

If a negative value for speed indicates invalid data, wouldn’t it be better for the plugin to return that as null instead? Negative values may be interpreted as meaningful data, unless it really is in certain scenarios.

On Android we check if speed is available... If it is available we pass the .speed() property.

Just to clarify, I'm talking about all the fields provided by Position object, not only speed and speedAccuracy. They all defaults to 0 which is misleading.

Shouldn’t it return null when the field is genuinely unavailable?

Good question, This is a result of synchronising between all different platforms. So for now we choose to synchronise among all the different platforms. HOWEVER, we are still planning to move towards exposing more native API's in the future. So for now I suppose we keep it as it is. But in the planned refactors native API's will be exposed that would implement your requirement. Nonetheless, I think we should clarify the documentation first.

Kind regards,

[Priyantha-Kingslake]

Thanks for the clarification