Consider moving accuracy to properties in the route.

[aickin]

When a GPS device moves through an environment, especially an urban environment, the accuracy of the signal can vary tremendously. This means it's possible that some points on a GPS route may have an accuracy of a meter while others points in the route may have accuracy of 10 or 30 meters or whatever. In this kind of case, it's not entirely clear what to send in the accuracy field for a trip, since it varies so much.

I'd suggest that maybe it would be better to move the accuracy field into the route GeoJSON, like this:

"route": {
    "type": "FeatureCollection",
    "features": [{
        "type": "Feature",
        "properties": {
            "timestamp": 1529968782.421409,
            "accuracy": 1,
        },
        "geometry": {
            "type": "Point",
            "coordinates": [
                -118.46710503101347,
                33.9909333514159
            ]
        }
    },
    {
        "type": "Feature",
        "properties": {
            "timestamp": 1531007628.3774529
            "accuracy": 10,
        },
        "geometry": {
            "type": "Point",
            "coordinates": [
                -118.464851975441,
                33.990366257735
            ]
        }
    }]
}

[ezheidtmann]

Strongly agree; accuracy information should always be associated with a point location.

In our experience with smartphone chips, GPS location accuracy is communicated in two ways.

• Android - accuracy - "radius of 68% confidence" (although our experience shows this definition is not rigorous)
• iOS - horizontalAccuracy - "radius of uncertainty for the location"

In the general case, it doesn't appear that accuracy can be reliably computed from standard NMEA sentences but I bet most stacks can produce a radius of uncertainty.

Of course, the real location isn't always within the radius, even when the radius is very small. And both smartphone platforms have additional layers of location processing that can add errors. So we always track which platform produced a location so we can process differently if needed.

---

So I'd suggest using the field horizontalAccuracy for clarity, and perhaps including a GPS platform enum in the route or trip description.

"route": {
    "type": "FeatureCollection",
    "features": [{
        "type": "Feature",
        "properties": {
            "timestamp": 1529968782.421409,
            "horizontalAccuracy": 1,
        },
        "geometry": {
            "type": "Point",
            "coordinates": [
                -118.46710503101347,
                33.9909333514159
            ]
        }
    },
    {
        "type": "Feature",
        "properties": {
            "timestamp": 1531007628.3774529,
            "horizontalAccuracy": 10,
        },
        "geometry": {
            "type": "Point",
            "coordinates": [
                -118.464851975441,
                33.990366257735
            ]
        }
    }],
    "properties": {
        "gpsProvider": "ios"
    }
}

Happy to prepare a PR if either of these changes sound good.

[jfh01]

Flagging #61 as a separate, but related issue.

[thekaveman]

@aickin moving accuracy like this is a good idea - PR (from anyone) more than welcome.

@ezheidtmann you bring up an interesting mobile/smart phone perspective for how different devices communicate this information differently. But to be clear, within MDS the device in question is the GPS unit mounted to the vehicle -- the e-scooter, e-bike, etc. -- that tracks the vehicle's location. See also #37 for some related context. I do not believe that MDS is attempting to catalog all of these possible device configurations.

The device in question is definitely not the provider's customer's personal cell phone/device.

Tagging @hunterowens @toddapetersen for insight as well.

[ezheidtmann]

@thekaveman I present the accuracy information as context from our area of expertise, and as a possible basis for a definition of accuracy to be included in the spec. (These definitions are common & I believe all providers should be able to provide an accuracy figure that is useful for analysis)

We've seen that some providers don't have GPS chips on all their devices (they rely on customer devices for location information); others run Android on the scooters. I don't know how many providers are currently uploading locations from their devices rather than relying on customer devices.

In any case, I suggest that space be provided for providers to include a hint about the source of GPS data, to aid further analysis.

[hunterowens]

Strongly in favor of moving accuracy to be associated with any associated points, thanks for the heads up all.

If providers are piggybacking off of cellular GPS, rather than using onboard per @thekaveman suggestion, it seems like it would be impossible to know where a device is if it is not active. (For example, rider finishes ride, then device is moved by hand/theft/etc, seems like it would result in thousands of "stolen" devices that are actually on street.)

Either way, let's get a PR that includes accuracy associated with points. I prefer the original @aickin implementation compared to @ezheidtmann as I expect that the points should be coming from device, at least in status change. For routes, I would be okay including ios/android/other devices if that results in a better sample rate in the data structure.

TL:DR; GPS points in status_change should almost always come from an onboard device since it is representing the removal/addition of the device to and/or from the public right of way. For the routes structure inside the trips endpoint, which is more about planning purposes, it may be useful to get iOS/Android data for fidelity.

[schnuerle]

Should this be an optional field across MDS whenever location/telemetry data is used? I haven't heard much talk of this in practice with cities or providers, but if it's still a need 2 years later we can look to add it.

[thekaveman]

@schnuerle it is an optional field now for Provider trips. I believe this issue started as a simple suggestion to move the accuracy field from the top-level into the route object (similar to how we added stop_id directly to geometric data vs. at the top-level). Since the accuracy for any given point measurement may be different from a subsequent measurement (i.e. the idea that the trip itself has an accuracy measurement is somewhat... inaccurate).

[quicklywilliam]

Plus one on this. There are several other GPS fields we'd love to see besides accuracy that are available on Agency but not Provider. This includes speed, heading, the number of satellites fixed and the altitude. These data can be tremendously helpful to filtering and cleaning up GPS data.

Also, this effort to bring /trips to Agency is related (in so far as we are slowly but surely unifying all the things):
#550

[quicklywilliam]

@schnuerle per our conversation today, should we tag this as a 2.0 issue? Or I can file a new one?

[schnuerle]

Thanks for reviving this issue you all. I think it can be closed in favor of a more up to date issue with a more accurate title and description that summarizes the current issue and how it could be solved.

[schnuerle]

Being addressed by #653. Please review that PR and leave comments there if interested.