Hello Hanno,
Thanks for your response.
You are right that I failed to understand that you were proposing an API
whose primary concerns were sharing with OpenCellID and maintaining
backwards compatibility with their existing format.
Unfortunately, those goals directly conflict with the other goals I have
heard related to sharing the data in the database with the contributors
to MLS and related to the other two goals you outline in your message.
Hence, my confusion.
You have promised us, from earlier in the project, an API to get access
to the data we were contributing, although only a distilled version
because you have some privacy concerns about the raw data. I had been
expecting you to meet that promise. I have already stated and will
repeat in a different way below, the data offered by your current API do
not meet this promise: the export data lack a 'horizontal accuracy'
estimate and other data quality metadata required to use summary data
rather than raw observations. The export data also lack any information
whatsoever of the contributed wifi data. So this is not the export API I
feel you have promised the community.
Furthermore, your second and third points do not seem to be met either
by your current API.
On 9/3/14 11:09 AM, Hanno Schlichting wrote:
Hi Adrian,
thank you for ...
There are three main use-cases for the data format today:
1. Allow a data exchange between OpenCellID and MLS
2. Allow anyone to download the data and run their own instance of ichnaea with
the same data we have in MLS
3. Allow community members to help validate, visualize and play with the
current data
The second point suggests we could download your API and run an ichnaea
service. However, the Service API defines, in
https://mozilla-ichnaea.readthedocs.org/en/latest/api/index.html#geolocate
, that
A successful result will be:
{
"location": {
"lat": 51.0,
"lng": -0.1
},
"accuracy": 1200.4
}
which means we must be able to go from the exported database to an
estimate of horizontal accuracy, something my earlier message suggested
was missing and could only really be done well from the raw data you do
not share so should be present in the export. But perhaps I am wrong. Do
you actually have a running instance of your service using data exported
via your API? If so, how do you generate the horizontal accuracy
estimate in the API from the export database values?
Your third point suggests that you expect this data to serve the
community to 'help validate, visualize and play with the current data'.
However, for evaluating data quality, you can see that the number of
observations 'samples', and the antenna range estimate 'range' are
insufficient. As an example, we can look at Montevideo, Uruguay where I
have contributed the vast majority of the data to both services so we
are not treading on any one else's privacy toes. OpenCellID provides a
great visualization tool to let you see where it estimates the antennae
locations and lets you see the observation locations it used to make
that estimate. Looking at:
http://opencellid.org/#action=filters.GPSPositions&mcc=748&mnc=7&zoom=16&lat=-34.92149&lon=-56.16738
you see a bunch of markers. If you click on the marker at the top right,
you will see it is placed in the middle of a linear set of observations.
(The map will move a little.) If you click on the marker inside the
water, you will see that it is sharing observations on both side of the
small bay. Both are wrong for different reasons: the first because there
is no off-axis observation to anchor the collection set, the second
because the antennae has a long line of sight across open water and the
position estimate is unconstrained. The data your API offers do not
provide sufficient information for me to filter the position estimates
for quality. The antenna to the right of the 'Facultad de ingeneria,'
for example, is pretty close to being in the right place: the
observations used in the estimate have a good spatial distribution
without gaps between observation and antennae position estimate. So,
with the OpenCellID web service, I can individually identify the quality
of each location estimate. I don't see how to do anything vaguely like
that with the exported data format.
As for your argument that you want to keep bad names for compatibility,
it conflicts directly with your argument that the names don't matter
anyhow because this csv is a positional API. No matter, yours is not the
first API with poor names nor will it be the last. I had again assumed
you were interested in making great API without knowing that your
backwards compatibility goal came first.
Maybe in the future your API will eventually evolve to meeting the goals
you set for yourself and being of use to analyses like the kind I
envision. I had assumed there would eventually be some way to use your
data export to make a wifi density map of Montevideo. I had also thought
there might be some way for me to flag the cell antennae with inaccurate
spatial location to go make further stumbling passes nearby. Both are
trivial analyses, neither appear possible with the current export data.
Fortunately for me, I have been stumbling in the latter half of my
survey of Montevideo with my own tool that gives me access to my own raw
observations so I can use my own observations directly.
Unfortunately, I have grown discouraged by the attitude in this project.
There seems remarkably little bandwidth dedicated to fostering
collaboration (or perhaps simply little interest). Personally, I have
done way more than my fair share of trying to persuade others to
standardize on a great, correct, standardized API. So if you are happy,
fantastic. As for me, my time seems better spend on other efforts absent.
Good luck in your work and have great fun,
~adrian
_______________________________________________
dev-geolocation mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-geolocation
