Open daniel-j-h opened 6 years ago
We've seen this problem before. I agree; I think it's a problem with the spec. We should probably publish an erratum.
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?
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.
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.
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.
Please Indicate One:
Please Describe the Issue:
The accuracy property of a Place is defined as:
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.