position accuracy

Andrew Turner ajturner at highearthorbit.com
Fri Jul 27 13:09:27 PDT 2007


Hrm, I think it may be more beneficial to primary support "civic
accuracy" first, e.g. accuracy = [street, city, postcode, region,
country] as most backends will provide this kind of accuracy. Also,
"city" is more meaningful than saying 2000m.

GPS is really the special case here in providing a DOP that is a
linear distance. That should be offered, but I would say it would be
an additional field - maybe when accuracy=precise then there is a
distance measurement.



On 7/27/07, Jussi Kukkonen <jhkukkon at cc.hut.fi> wrote:
>
> I've added a basic civic_location method to the position API, will
> commit today or during weekend (after a bit more testing).
>
> I'll probably work on tuning that next week, but I'd also like a to add
> position accuracy to the API, something that'll give the applications
> some idea how to use and present the coordinates. I'm thinking int in
> meters would be fine (gpsd even has that available: "Horizontal position
> uncertainty", althoough I've yet to check if it actually is valid). For
> other backends we'll just have to pull a number out of thin air -- e.g.
> 20000m for hostip.
>
> Any opinions on whether it should be an argument in current_position or
> a method of it's own?
>
> -jussi
>
>
>
>
> _______________________________________________
> GeoClue mailing list
> GeoClue at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/geoclue
>
>
>


-- 
Andrew Turner
ajturner at highearthorbit.com      42.2774N x 83.7611W
http://highearthorbit.com              Ann Arbor, Michigan, USA
Introduction to Neogeography - http://oreilly.com/catalog/neogeography


More information about the GeoClue mailing list