Position API rewrite (was: position accuracy)

[Jussi Kukkonen]

keith preston wrote:
> Interesting you bring this up.   I've been taking a look at the geoclue
> position api for the last day and have been trying to clean it up make it
> sane and useful.   I am trying to add a doxygen layer so that we get some
> decent documentation and expand the examples.   Here is basically the new
> xml files that I am proposing as of now.

Looks great, although it's pretty hard to read:

>  - <?view=page&name=htmlcompose&ver=1chdyj2lqwlxk#> <method name="*version*"
> >
>    <arg type="*i*" name="*major*" direction="*out*" />
>    <arg type="*i*" name="*minor*" direction="*out*" />
>    <arg type="*i*" name="*micro*" direction="*out*" />
>   </method>

Was this by mistake? Can you upload a cleaner version somewhere? Most of
your stuff seemed really good, I'll quote only what I'm going to comment on:

> We should be thinking 3D.   Hostip can return
> 0 for altitude and have a large margin of error.   GPS can return what they
> know.

Agreed, except I don't like returning 0 for missing data -- that has
bitten me in the ass several times (you can imagine how nice a 3D
terrain model looks like when some random points in the model have a
missing altitude value, and that's expressed with a zero...).

>    As for latitude, longitude error. They typically should always be
> the same, but I think it makes sense because all our other methods have 3
> dimensions. 

Ok with me. I'm not sure how we'll translate single error values like
"eph" from gpsd to lat_error and lon_error though.

> Do you see any good addition to the status enum?   I was going to add a
> bunch and then I though a human readable string would be better.   The only
> ones I thought might be useful are.   "No Service Available, No Position
> Available, Currently acquiring position.", are these useful to a program or
> just the user?  If it is useful to the program, then I would add, to the
> user then piggy back on the string message.

I'd like machine readable versions... It makes UI development a lot
easier when you can e.g. show a spinner as long as status is "acquiring"
and change that to a error sign when it's "not available".

The backend error codes I used (backend/geoclue_position_error.h):
  GEOCLUE_POSITION_ERROR_NOSERVICE,
  /* Backend cannot connect to needed service */
  GEOCLUE_POSITION_ERROR_MALFORMEDDATA,
  /* Received data, but it is unreadable */
  GEOCLUE_POSITION_ERROR_NODATA,
  /* Used service cannot provide position data at this time*/
  GEOCLUE_POSITION_ERROR_NOTSUPPORTED,
  /* Backend does not implement this method */

Not sure if the second one has any value.


> I think now I'm am going to change timestamp.   It probably should be
> seconds to the epoch instead of the specific NMEA Time.   This will give us
> date accuracy (except for the rollover in 2038)

timestamp is definitely good. At the same time we might want to think
about validity/time-to-live: Sometimes even the last valid location
would be useful, even if abolutely current info is not available.

> I've been thinking now that we should add a "position_hint" input to the API
> for use in auto submitting your position to Host IP.   There could be some
> kind of configuration for privacy in geoclue master.  I wonder if this could
> be generic for more API.   I know you can do assisted GPS.   is there a good
> way to add this too?

I'm undecided on the data submission issue... I'd probably put the
submission in a separate program.

I fully agree on the privacy config: there should be geoclue-wide
position privacy settings that geoclue _and_ applications can use.
Although it might not be a top priority just yet, this will be very
important when our position data starts to escape to the internet (like
with the Gajim XEP-0080-implementation). Speaking of which, we probably
should follow and take part in xmpp/XEP work in that area.

> I think I am going to change the internals to all positioning calls
> defaultly go to geoclue master and it farms out calls to the available
> backends and arbitrates based on accuracy or some gconf keys (preferred,
> default).

Yay! This was what I was hoping I could do during the summer, but
frankly there was enough work even without getting that far... I fully
support this. It's not trivial though.

> But I think it should also store the most recent position from
> each backend, that way if none of them are available it can default to the
> last timestamp (and maybe prompt the user for manually inputing their
> position)

This I already touched on while discussing timestamps. I guess the other
alternative to master saving position data is that backends have a
method last_position(), and/or that position has some kind of time-to-live ?

About the manual input: I'm working on that right now for Maemo, I'll
post my ideas/mockups to the list soonish. I can already say I don't
like the way the current manual backend works.

> Oh yeah, and I don't know if Jussi, you have done some of the object
> oriented refactor, but I'm going to do some for the positioning api to try
> and make it easier to add a new backend.

Go ahead, I haven't worked on that. It was just a "bug report".

> Ok, so I think that is all I have.   Once this gets done, I think we can go
> "beta stable" on positioning and working on making our automake, debian and
> doxygen very clean so that other program can start using us more.

Yes. The interest is building, we should get ready.

-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/20070809/bbdc4f05/attachment.pgp