Proposal: Location hackfest

Thu May 29 04:41:24 PDT 2014

On Thu, May 29, 2014 at 3:06 AM, Aaron McCarthy
<aaron.mccarthy at jolla.com> wrote:
> Hi,

Hi Aaron,

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

It knows I'm in London but thats it, so I doubt wifi-geolocation is
working. I have tried in a few very different locations in London.

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

I must admit that when inside, I have not been trying against Maps app
but rather in browser and Android apps. My usecase is checkins
(foursquare and facebook).

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

Not with geoclue1, no but with geoclue2, we don't have a plugin
mechanism and for good reasons (as Bastien explained) we'd want to
avoid that. So what I was trying to do with the para above was to
convince you to rely completely on geoclue2's existing built-in source
for geoip and wifi-geolocation. :)

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

That doesn't seem to be much at all and certainly not the main task of
finding the location, which is what geoclue's main (and now only)
functionality.

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

Ah Ok. I did not know this. If ofono provided any docs or even
introspection, I would know a bit more about ofono API.

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

So if I'm understanding this correctly, ofono is providing me info
about cell towers but not GPS? The additional API you talk of above
are added to ofono's dbus service? If so, the addition of support for
ofono + custom GPS API (both could be enabled though configure flag)
in geoclue2 would be the major step then to make geoclue2 working for
you? If you got any docs or introspection XML on the API, that would
be very useful for me.

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

OK. We can think about exposing information about satellite positions.
What comes to mind is a 'GPS' object associated with GPS-based
Location object that exposes various GPS properties.

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

OK so we agree then.

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

Understood.

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

Yeah, as I said it doesn't seem geoclue1 is doing much for you. I'm
hoping geoclue2 will. :)

-- 
Regards,

Zeeshan Ali (Khattak)
________________________________________
Befriend GNOME: http://www.gnome.org/friends/