Proposal: Location hackfest

Tue May 27 09:25:50 PDT 2014

Hi Aaron,

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:
>> Hey,
>>
>> On Mon, 2014-05-26 at 13:23 +1000, Aaron McCarthy wrote:
>> <snip>
>>
>> > I don't know if ofono provides such an API. That way it is implemented in
>> > Jolla/SailfishOS is that the GPS device is accessed directly and not via
>> > ofono. Hardware-wise the GPS closely connected to the modem. From user
>> > space this is only exposed when the GPS device is informed of which
>> > mobile data APN is connected and should be used to download assistance
>> > data.
>>
>> Which means that the GPS can't be used if there is Wi-Fi signal but no
>> mobile signal? I think the exact steps for "enabling" (or making
>> available) the GPS device to applications that use Geoclue is slightly
>> different on a computer, and on a "always connected to the GSM network"
>> mobile phone.
>
> GPS can be used in this situation. But it means that the time to first fix may
> be slow. Assistance data (SUPL download) currently only works over the mobile
> data connection. In this mode the data will be downloaded directly from the
> GPS satellites, as stand alone GPS units do. Which requires a stronger signal
> and time.
>
>> > > > GeoClue1 supports external position providers. My understanding is
>> > > > that
>> > > > GeoClue2 has a single positioning daemon with all providers built in
>> > > > (maybe as plugin?). This is useful for implementing proprietary
>> > > > because
>> > > > of license requirements and run-time security restrictions.
>> > >
>> > > We currently don't have plugin support but I'm more hoping we don't
>> > > need external provides but rather geoclue be able to use all available
>> > > external sources: ModemManager, ofono etc. For WiFi geolocation, we
>> > > have been using NetworkManager for getting list of wifis around and
>> > > Mozilla Location Service for querying location based on that list. As
>> > > part of this hackfest, I completed the work to use wpa_supplicant
>> > > directly instead of NetworkManager so I'm hoping that helps in
>> > > portability a lot already.
>> > >
>> > > Geoclue uses the geolocate API (compatible with Google's geolocation
>> > > API) and its possible to tell geoclue to use some other service
>> > > through the config file.
>> > >
>> > > However, if there really is a usecase for allowing pluggable sources,
>> > > we can certainly look into that.
>> >
>> > I'm looking at this from the perspective of integrating a proprietary
>> > position source. Geoclue1 provided a clear separation between closed
>> > proprietary code and the GPL/LGPL code.
>>
>> A proprietary source doesn't have to mean a proprietary implementation.
>
> I am aware of that, but sometimes it is out of my control. It would not be
> buildable as it links against proprietary libraries and headers, not
> externally available.
>
>> 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 :)).

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.

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

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, I'm hoping there is a way and will
to implement either of those APIs? You don't have to implement the
whole API even, just the one that geoclue uses (e.g no SMS or calling
related API) and it can very well be proprietary.

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

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

>> I don't think that Geoclue should be providing API that it cannot
>> guarantee (depending on the modem used, you might not get access to this
>> information).
>
> One of the features of DBus is that you can dynamically publish object paths
> and interfaces. The alternative is to require applications to get this
> information via a separate service. Which service may not be obvious for the
> application. It was mentioned that Geoclue2 currently only supports GPS via
> ModemManager with support for standalone GPS planned. The application would
> need to know which interface/service to use. The application would no longer
> be decoupled from the underlying providers.

No it wont be but if it needs such internal and speciifc information,
its not your typical app that just needs to know where user currnently
is etc.

>> (As I mentioned in the other mail, discussing this on the Geoclue list
>> would be highly appreciated).
>
> I will subscribe.

Cool. I hope you do so before your next reply so I don't have to
forward messages there anymore. :) I've put it on CC btw.

-- 
Regards,

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