Hey all,
Interesting news, coming from Andreas Gal on the dev-b2g list:
On 3/24/14, 9:22 AM, Andreas Gal wrote:
>
> Support for the Mozilla Location Service is available in trunk builds
> I believe, and we will start using it in production devices soon as
> well.
>
> Thanks,
>
> Andreas
Does this mean that a bunch of work has been done on MLS vetting the
data quality and improving the error estimates to bring it up to
production quality? What kind of analyses are being performed on the
data to evaluate their quality? What kinds of algorithms are being
developed to improve error estimates? I had not been aware that this
kind of work was ongoing and thought that for now MLS was acting like a
pretty dumb data repository and that the 'service' was offering
exceedingly coarse positions with fixed error estimates at the kilometer
scale.
We must all know that there are many issues with the quality of the data
accumulated so far. Similarly, we all surely know how horrible the
experience is to be given a geospatial position which is grossly
inaccurate; some will even have personal experience of the waste of time
and endless walking that can result when being forced to rely on such
data but being given grossly inaccurate positions. So I wonder how you
are expecting to protect Firefox OS users from the current data quality
and algorithmic analysis issues.
My own work trying to grapple with this is only just getting to the
point where I can think about analysis. I have a prototype stumbler app
and am accumulating a systematic (but nonetheless problematic) data set
of Montevideo, wherein all data are essentially gathered in the same way
(at bike speed, at times of good satellite availability, with the same
value for the maximum acceptable positioning error, ...). Since I am
holding on to the data, as well as uploading it to OpenCellID and MLS, I
will be able eventually to do real analysis of the results.
Already, I have started wondering about problems in the data gathering
of the Wifi base station locations. (I suspect, but have not yet
confirmed, that the hardware and code behind the
navigator.mozWifiManager API call are storing signals based on the
periodic broadcast from wifi base stations but only dropping the base
station after some timeout. I am seeing residence times of base stations
in the data reported by the above API of around a full minute, a time
within which I have moved far out of radio contact with the base
station, far enough away that relating the later positions to the wifi
base station makes for a crummy position estimate (~300meters of that
error term alone). Confirming this and figuring out how to handle it
will require a bunch of field work, something I am not yet sure how to
do.) A solution might eventually be to eliminate the presence of a wifi
for all positions beyond a certain distance (or time) from initial
observation (or at a position or time based on some calculation
involving initial observation and the evolution of signal strength),
something which could even be done on the server eventually for already
accumulated data. Are you already doing this kind of analysis? If so,
how? Do you dump the database into PostGIS and do analysis there, or
have you written your own geospatial algorithms?
It would be interesting to have the discussion of the work you are doing
to bring the whole system up to production quality on the
https://mozilla-ichnaea.readthedocs.org/en/latest/calculation.html
web page. That should probably include a discussion of all the different
error terms you are considering in the position analysis and how
multiple observations attenuate the different terms.
Thanks for any info,
~adrian
On Mar 24, 2014, at 12:16 PM, Adrian Custer <[email protected]> wrote:
On 3/24/14, 8:45 AM, Marek Raida wrote:
Hello, could someone tell me please, if hybrid Wifi/aGPS
positioning should work in FFOS 1.3? Accordingly to
https://wiki.mozilla.org/B2G/Roadmap it was added to 1.2 (but
strangely without any issue reference). I've spent a week
running around town with Android device with mozStumbler turned
on and acquired a lot of data
(https://location.services.mozilla.com/leaders - user revelon ;-)
, but still, getting position outside is painfully painfully
slow, and inside of building nearly impossible (on device GP
Revolution). Thank you for an answer/status, Marek
_______________________________________________ dev-b2g mailing
list [email protected]
https://lists.mozilla.org/listinfo/dev-b2g
Hey Marek,
Glad you were productive stumbling.
As I understand things, none of your data are exposed to the
Firefox OS Geolocation call. The Firefox OS navigator.geolocation
call works but still relies on the service of a third party (some
Google service if I remember right). This means you won't see your
data that way. However, the call should work on your phone, so I am
not sure why it does not. Perhaps, that service does not have
coverage of your area?
Mozilla Location Services, which gets the Stumbler data, is not
used for Firefox OS Geolocation. MozLocServ is still in data
acquisition mode (although you can manually call the service to ask
for its estimate of your position, but that has fixed and very poor
error estimates). You can ask questions about MozLocSev on another
list:
[email protected]
where you might get more precise answers about how your uploaded
data are being processed and used.
cheers, ~adrian _______________________________________________
dev-b2g mailing list [email protected]
https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
