position accuracy

[Jussi Kukkonen]

I'm sure I answered this already. Must have imagined...

Andrew Turner wrote:
> 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.

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

In addition to that, I do believe all backends that support coordinate
position should return a numeric accuracy value -- attaching a
"accuracy=city" to a coordinate pair does not make sense to me. It does
become sensible when I consider the source of the hostip coordinate
data, but we _shouldn't_ consider it: that would break the abstraction.
 I'm thinking something like this:

      <method name="position_accuracy">
        <arg type="i" name="accuracy" direction="out" />
      </method>


-jussi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/geoclue/attachments/20070801/e4f8ae0b/attachment.pgp