GeoClue2

[Eckhart Wörner]

Hi Bastien,

Am Montag, 18. April 2011, 14:45:36 schrieb Bastien Nocera:
> > Altitude), and the first derivative (Speed, Direction, Climb). However,
> > we still don't know the orientation of the device in this room.
> > Why may this information be useful? E.g. a routing application for
> > pedestrians can rotate the map it displays according to the heading of
> > the device.
> 
> I don't think anyone can say it's not useful. But it wouldn't come from
> the same hardware device. The gypsy or gpsd providers should probably
> combine their results with the data from the altimeter if it's a
> separate piece of equipment.

You're talking about the actual implementation here.

> > The GeoClue API is overly complex in some places: to get latitude,
> > longitude and speed, one has to traverse two objects, and then use two
> > different providers.
> 
> You're talking syntactic sugar here.

Yes, this is syntactic sugar.

> Agreed. But the fact that the master provider was so broken made it
> impossible to use.

That's why in my design there's *only* the master provider, which should 
ensure it's actually working. No way to work around it.

> > Applications may be interested in the last known value for some piece of
> > information, even though it is not valid anymore.
> 
> We should have timestamps for the various events given to applications.
> That would solve that particular problem.

I don't see why that would solve the problem.

> > The GeoClue API does not play well with D-Bus: Long-running methods will
> > break as D-Bus puts a timeout on method calls.
> 
> Which methods did you see that were long-running?

AddressToPosition and PositionToAddress are both functions that could easily 
take over a minute (consider a flaky mobile broadband connection), after 30 
seconds the D-Bus timeout already kicks in. (And no, increasing the D-Bus 
timeout is never an option)

> > 	<interface name="org.freedesktop.Geoclue2">
> > 	
> > 		<method name="CreateProvider">
> > 		
> > 			<arg name="path" type="o" direction="out" />
> > 		
> > 		</method>
> 
> That method doesn't seem to allow for errors.

Unless you're OOM, CreateProvider should never error out.

> There's no privacy concerns with address to geocode, or geocode to
> address resolutions. I think this should be implemented as a library,
> instead of trying to add to the confusion by running it in a D-Bus
> service.

Yeah, maybe. I mainly added it because it already had been in GeoClue.

> > - CountryCode, Country, Region, Locality, Area, PostalCode, Street
> 
> Where would those come from? I really don't think we want to pass those
> out from the provider, except as extra metadata, and certainly not in
> that format (we mentioned using a hashtable of string keys and values
> for this in the past).

You do realize GeoClue has this already defined?
(http://folks.o-hand.com/jku/geoclue-docs/Address.html)

Also, if you look at the implementation of D-Bus properties you'll realize 
that properties aren't that different from the current implementation: D-Bus 
uses a{sv} for properties, GeoClue uses a{ss}. I think making GeoClue2 rely on 
D-Bus standards as much as possible is the way forward.

> > An application indicates that it needs one or more properties to
> > function
> > correctly by setting ActiveProperties to the corresponding property
> > names.
> 
> I really don't think using properties is an effective way to pass this
> information along to applications. It's missing all sorts of interesting
> metadata (such as when the data was captured).

Again, there is no regression compared to old GeoClue.

The PropertiesChanged signal fires when new data is available, in the same way 
PositionChanged, VelocityChanged, AddressChanged fired before. The 
PropertiesChanged signal transports the values for all properties that have 
changed, so no extra roundtrip.

Also, every aspect of the data may have been captured at a different time. This 
would mean there's a LatitudeTimestamp, AltitudeTimestamp, HeadingTimestamp, 
SpeedTimestamp, ElevationTimestamp, … That's why I'm uncomfortable with the 
idea of timestamps.
If you think it's unrealistic that these aspects all come from different 
sources, think about a car: there's the gps, there are sensors which measure 
speed, other sensors that measure elevation, there is an integrated compass, 
etc.
(GeoClue2 should of course not be used for controlling airbags ;-) )

Eckhart