502857 - geolocation: Access to a GPS receiver on UNIXoid platforms

Status: RESOLVED DUPLICATE of bug 492328

(Firefox :: General, enhancement)

Description

[Jan-Benedict Glaw]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092816 Iceweasel/3.0.7 (Debian-3.0.7-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090706 Minefield/3.6a1pre

Right now, the navigator.geolocation.* JS-accessible functions (at least on my Linux box) seem to simply use the javascript implementation of geocoding (which is implemented in NetworkGeolocationProvider.js).

Except maybe in dense metropoles, this method imposes a high uncertainity of user's current location. (If I use that here at my dayjob's location, it's about 4km distance between what it guessed and where I am. And this is only because I work for a larger company located at a quite small village. In other areas, the error is probably much higher.)

Being one who plays with the geolocation stuff (eg. at http://webcontent.osm.lab.rfc822.org/), I want to get useable coordinates. As I don't see a common way for various platforms and architectures to access a GPS receiver (let alone the correct one if there are two or more), I implemented another backend (additional to the Wifi/IP one, the Maemo one and the WindowsMobile implementation) that calls an external script via popen() and getting the required information from there.

The atteched patch is for RFC only, as there are a number of rough edges:

  * There's of course no single script that'll work for everybody.
  * It won't be called at all, because the backend detection logic at
    dom/src/geolocation/nsGeolocation.cpp, method
    nsGeolocationService::nsGeolocationService, isn't really effective
    here, because the JS implementation (NetworkGeolocationProvider.js)
    is already registered beforehand. Thus, the user either has to
    delete that file, or we'll need to write another patch to allow
    a user to choose the backend implementation.
  * The Makefile fragment is likely suboptimal. There should be a check
    for the target platform being POSIX.1 compliant (eg. having popen()).
    But I don't know the whole codebase good enough to get that right.
  * My implementation is based on the WindowsMobile stuff. That was
    choosen because it already implements polled access to the GPS
    receiver. I tried to rip off unneeded stuff, but being primarily
    a C coder (and not C++), I probably missed an opportunity here
    and there...
  * This needs some more documentation. Especially the format that the
    popen()ed program is expected to conform to.

Finally, it works for me and I think that it's a good start for some knowledgeable Firefox hacker to finish it.

Here's an example for a script (crude hack) to provide location information:

-------------------------------------------------------------------
#!/usr/bin/env sh

RESULT="`echo "o" | timeout 0.2 nc localhost gpsd 2> /dev/null | grep -v Killed`"

LATITUDE="`echo "${RESULT}" | cut -f 4 -d ' '`"
LONGITUDE="`echo "${RESULT}" | cut -f 5 -d ' '`"
ALTITUDE="`echo "${RESULT}" | cut -f 6 -d ' '`"
HDOP="`echo "${RESULT}" | cut -f 7 -d ' '`"
VDOP="`echo "${RESULT}" | cut -f 8 -d ' '`"
HEADING="`echo "${RESULT}" | cut -f 9 -d ' '`"
SPEED="`echo "${RESULT}" | cut -f 10 -d ' '`"

if [ -n "${LATITUDE}" -a "${LATITUDE}" != '?' -a -n "${LONGITUDE}" -a "${LONGITUDE}" != '?' ]; then
        VALIDITY="valid"
else
        VALIDITY="invalid"
fi

echo "${VALIDITY}"
echo "${LATITUDE}"
echo "${LONGITUDE}"
echo "${ALTITUDE}"
echo "${HDOP}"
echo "${VDOP}"
echo "${HEADING}"
echo "${SPEED}"
-------------------------------------------------------------------

Some feedback or guidance for further hacking (eg. a chooser for the backend to provide the geolocation information) would be nice.

Reproducible: Always

Steps to Reproduce:
Open some website that's using the navigator.geolocation stuff and realize that you're miles away from where it things you are.

http://webcontent.osm.lab.rfc822.org/  might be a start, choose the "Current location" link on the left.
Actual Results:  
...your geolocation being off for miles or kilometers.

Expected Results:  
Place me to the correct (module some meters) position instead of somewhere in the next larger city :)

Comment 1

[Jan-Benedict Glaw]

Attachment: Patch for calling an external program/script to get the current geolocation

Comment 2

[Jo Hermans]

The bug for adding gpsd support is bug 492328