Use-cases and interpretation for a Place's relative accuracy

[daniel-j-h]

Please Indicate One:

• [ ] Editorial
• [X] Question
• [X] Feedback
• [ ] Blocking Issue
• [ ] Non-Blocking Issue

Please Describe the Issue:

The accuracy property of a Place is defined as:

Indicates the accuracy of position coordinates on a Place objects. Expressed in properties of percentage. e.g. "94.0" means "94.0% accurate".

But what does it mean for a location to be 94% accurate? What are the use-cases here and how should data consumers interpret a relative accuracy like this?

In the context of a place data consumers need either accuracy in meters to show a radius around the place's location. Or an accuracy in degrees for the latitude and longitude values then the data consumer can calculate the accuracy e.g. in meters on her own.

[evanp]

We've seen this problem before. I agree; I think it's a problem with the spec. We should probably publish an erratum.

[daniel-j-h]

Great to have a path forward here. What are the next actions here? Coming up with a new way of representing accuracy and then publishing an erratum? Or deprecating this property? How can I help?

[gobengo]

When I implemented publishing location for new posts on https://distbin.com, I remember thinking about this.

I use the HTML5 Geolocation API to get Coordinates.

The Coordinates.accuracy read-only property is a strictly positive double representing the accuracy, with a 95% confidence level, of the Coordinates.latitude and Coordinates.longitude properties expressed in meters.

So when I use the Geolocation API and get something like:

{ accuracy: 67 }

I convert it to be an AS Place like (live example):

{
  type: "Place",
  accuracy: 95,
  radius: 67,
  units: "m",
}

I set the as:radius to the accuracy-as-meters. I set as:accuracy to the 95% confidence level required by the geolocation spec.

I have no idea whether this is as intended, it's just the only semisensible thing I could come up with at the time. With radius + accuracy, we currently have enough to express the HTML5 Geolocation API. If you want to change anything, make sure there is a place for confidence level to be expressed.

I wonder if adding a small note to as:accuracy explaining that it should be used for confidence levels would be sufficient to reduce confusion without making breaking changes to spec.

--

From OP:

In the context of a place data consumers need either accuracy in meters to show a radius around the place's location.

Just use as:radius for this.

[evanp]

I think the right resolution here, based on @gobengo 's experience and recommendations, is to leave the accuracy as a percentage confidence measurement, and update the as:radius definition to clarify that it does not mean a loosely-defined area, but gives an error estimate for the lat/lon.

That doesn't explain what a "94.0% accuracy" means for a lat/lon pair. I'm going to take some time to educate myself on the difference between accuracy and radius here, and come up with an Erratum proposal that we could include.

[osmaa]

update the as:radius definition to clarify that it does not mean a loosely-defined area, but gives an error estimate for the lat/lon.

A Place is not described as, nor does irs naming imply, a Coordinate. A Place could be as large as a football field, shopping malli, university campus, or a city.

It does not make sense to define those as a singular WGS-84 coordinate with an error radius - it barely makes sense to define one as a circular area with a center point coordinate.

If you'd really want to solve this, it would take extending the Place with a geo polygon of connected Coordinates, but in the meantime, please don't say a Place's lat/lon/radius is an error estimate. It could be, if it's from a GPS receiver, but of the source is map data, it could be the loosely-defined area.