Proposal: Location hackfest

[Aaron McCarthy]

Hi,

On Tue, 27 May 2014 17:25:50 Zeeshan Ali wrote:
> On Tue, May 27, 2014 at 5:30 AM, Aaron McCarthy
> 
> <aaron.mccarthy at jolla.com> wrote:
> > On Mon, 26 May 2014 14:56:08 Bastien Nocera wrote:
> >> What sources would you want to use?
> > 
> > The Nokia/HERE WLAN and cellid positioning service.
> 
> Right. One of the reasons I was looking forward to meeting you at
> hackfest was that I was hoping to convince you/Jolla to rely on
> Mozilla Location Service instead. Having used location-based apps on
> Jolla for many months now, I see that geolocation hardly ever gets a
> good fix on me unless I'm outside and GPS comes into play. I'm not
> even in some remote area of the world but rather London (not the one
> in Kentucky :)).

Define good. Does it give you any position estimate at all? What is its 
reported accuracy? How far off is it from your true position. We haven't had 
any reports specifically about cellid/wlan positioning being inaccurate. An 
accuracy estimate of the position fix provided by HERE is visualised in the 
Maps application.

> Mozilla location service OTOH seems to be doing a much better job.
> Keeping in mind that Mozilla provides an easy way to submit wifi and
> cell data (and geoclue has an option to enable that in the config), I
> think its a much promising service than Nokia's.

The current architecture does not preclude using multiple sources. Currently 
due to RPM package dependencies the HERE and GPS providers are pulled in. 
Apart from that all application using positioning are agnostic to the actual 
providers used.

> >> If the requirements are more complicated than that, maybe reimplementing
> >> Geoclue's API in another D-Bus service would be a better idea.
> > 
> > That would require re-implementing all of Geoclue, no?
> 
> Correct but from your description of Nokia here, it doesn't seem
> geoclue is doing a lot anyway for you right now.

Our use of Geoclue1 is currently acting as a manager of position providers. 
Its main usefulness is starting and stopping the position providers that meet 
the requirements requested by applications.

> If you are OK with use of Mozilla location service for
> wifi-geolocation and geoip, there is only 1 hurdle in making geoclue2
> work on Jolla: Communication with Modem to get cell tower info and GPS
> info. For that my plan was that platforms either provide me with
> ModemManager or Ofono API. I was under the impression that Jolla, like
> Firefox OS has Ofono API implemented so you won't have to do anything
> in that regard but since I'm wrong,

Sorry there must have been a misunderstanding there. When I mentioned Ofono it 
was in regards to GPS. ModemManager apparently provides a GPS interface that 
you currently use. I haven't seen a GPS interface in Ofono.

We provide the Ofono API. What I do know is that the information provided by 
the existing Ofono API was not sufficient for the HERE implementation. 
Additional APIs were implemented to provide more cellular network 
measurements. There should be sufficient APIs available to implement the 
Mozilla location service.

> >> > > >> Zeeshan wants to know so we can debate whether to add them or not.
> >> > > >> Do we
> >> > > >> need a separate satellites api (e.g. a pass-through form gypsy)
> >> > > >> that
> >> > > >> we
> >> > > >> dynamically query if its available at runtime?
> >> > > > 
> >> > > > If Geoclue2 supports GPS,
> >> > > 
> >> > > Geoclue2 supports GPS only in modems. There is a TODO about adding
> >> > > support for standalone GPS devices.
> >> > > 
> >> > > > why not pull the satellite information directly from
> >> > > > the NMEA stream. I would prefer that the satellite information
> >> > > > comes
> >> > > > directly from the same source as the position updates.
> >> > > 
> >> > > Sure, what I was interested in is the use case but yeah, I can expose
> >> > > that if needed. Do we want all NMEA traces or only GPGGA?
> >> > 
> >> > Providing access to the NMEA stream would enable application to get
> >> > access
> >> > to data that is not otherwise exposed via the Geoclue2 API.
> >> 
> >> What are the use cases for this? Is it useful for something other than
> >> estimating how long it would take for the GPS to get a fix?
> > 
> > For satellite information that would be the main use case. Useful for
> > debugging but that's about it.
> 
> Well for that usecase, I'll just make Geoclue spit NMEA traces on the
> console. :) If you are looking at this data for debugging, you are
> debugging geoclue, not the UI app using it.

I've never seen a real need to know where the satellites are. There are a lot 
of application in the various application stores that show satellite 
positions, presumably some people find this useful.

> > There is other useful data in the NMEA stream, for application specific
> > use
> > cases. The one that immediately comes to mind is the current magnetic
> > variation, which is required to calibrate the compass sensor.
> 
> Why can't geoclue gather this info and provide that instead of
> exposing raw NMEA?

We currently do that. The extracted magnetic variation is stored in a 
gconf/dconf key.

I'm not necessarily advocating for access to the NMEA stream. Sometimes it is 
not NMEA but a binary protocol. What I am advocating for is a single point of 
access for position information and any auxiliary data associated with that 
position.

Geoclue1 (the master daemon) was intended to be a proxy for the individual 
providers. But due to various half integrated extensions, bugs and other 
limitations we found that it was not possible to use it in this capacity. 
Instead after the Geoclue1 master daemon selects the best available position 
provider for a given application, the application connects directly to the 
provider.

Cheers,

-- 
Aaron McCarthy