position accuracy

[Andrew Turner]

On 8/1/07, Jussi Kukkonen <jhkukkon at cc.hut.fi> wrote:
>
>  Civic location is in a way easier: I guess all that a client would want
> to know is if the backend supports a civic location type or not -- or
> have I overlooked a use case?
>  I'm referring to something like what I proposed earlier:
>
>       <method name="civic_location_support">
>         <arg type="b" name="country" direction="out" />
>         <arg type="b" name="region" direction="out" />
>         <arg type="b" name="locality" direction="out" />
>         <arg type="b" name="area" direction="out" />

what is "area" in terms of an geographic entity? :)

>         <arg type="b" name="postalcode" direction="out" />
>         <arg type="b" name="street" direction="out" />
>         <arg type="b" name="building" direction="out" />
>         <arg type="b" name="floor" direction="out" />
>         <arg type="b" name="room" direction="out" />
>         <arg type="b" name="text" direction="out" />
>       </method>

I suggest having a look at RFC 4119: A Presence-based GEOPRIV Location
Object Format
http://tools.ietf.org/html/rfc4119

and in fact all pieces of GeoPriv just to see what a group of people
spending 6 years thinking about all these problems come up with. :)
>
> In addition to that, I do believe all backends that support coordinate
> position should return a numeric accuracy value -- attaching a

Entirely agreed.

Curiously, what is the entire "message spec" looking like now? How do
we specify what types of data are required and what is optional?


-- 
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