cellhunter --- the state of development and future

[Onen]

Hi,

ivvmm wrote:
> I wonder how quick is it developed and how much people are involved in?

I am working on a similar project openBmap[1]. A thread has been started 
by Stefan from FSO about the state of the collaboration between the 
projects [2][3]. I am for collaboration and even for merge at least of 
some code or so. To my understanding, so far, cellhunter sees 
collaboration as sharing the data (Sebastian, please correct me if I am 
wrong). In the thread you will see that Sebastian will have little time 
to work on cellhunter until middle May. I let you read his answers in 
the mailing list archives, to make your mind.

OpenBmap is welcoming collaboration. The source code git is 
available[4]. The work is currently going on there. Nick is taking care 
of the server side and website.

The difference between the projects is that we focus on quality of data. 
We don't want to get a database full of bad data. Again you will find 
our arguments in the thread pointed above[5]. I copy paste it here for ease:
<quote>
That is the
reason behind keeping more details about measures. This allows to gather
a lot of data, but with time, we can trash the low quality ones, because
we have got high quality ones since.

This brings three questions:
1. if you have big HPV-Dops, your position is not very precise. If you
add to this that you have a high speed, then when you take your measure,
the GPS position is very inaccurate. And the time you get notified that
the GSM connection has changed, this adds to inaccuracy.

My question is: do people think this argument makes sense?

2. Do OpenCellID or CellHunter think this could be possible to add these
extra fields to their database, and measures? This would allow to use
inaccurate data, until when we have better ones. Then we could filter
the low quality measures. I think we are still all learning a lot, and
this would imply that extra fields could be added in the future. So this
is probably not only a one shot change.

3. The database should also keep track of the software (id and version)
which has logged the data: this allows to ignore/remove data which has
been submitted by a buggy software, even if the bug is discovered much
later. That is also the idea behind keeping the GSM chip model +
Firmware version + GPS chip, etc...
<end of quote>

> In fact no one in my country is using it(looked at the map on
> cellhunter's site). By also looking at the map we can see that many
> regions are already covered.
> 
> So when the next steps will be taken? I mean integrating the ability to
> get a fix from a network cell for GPS clients. TangoGPS for example? Or
> will cellhunter remain just a game?
> 

Jan has started some work on this in the framework (see git logs). On my 
side, I have also started some work on this. Nick and I build sqlite 
files for every country by operator, and I have started a DBus service 
which would
query the file to give the current GSM based location. Because of lack 
of time, this goes slowly though. Any help would be very welcomed. [6]

Feel free to ask if you have questions.

OpenBmap package is located in SHR and FSO repositories (opkg install 
openbmap-logger), and on opkg.org website.

Onen

[1] http://wiki.openmoko.org/wiki/OpenBmap
[2] 
http://projects.linuxtogo.org/pipermail/smartphones-standards/2009-April/000973.html
[3] http://lists.openmoko.org/pipermail/devel/2009-April/005283.html
[4] http://myposition.git.sourceforge.net/git/gitweb.cgi?p=myposition
[5] 
http://projects.linuxtogo.org/pipermail/smartphones-standards/2009-April/000975.html
[6] http://lists.openmoko.org/pipermail/devel/2009-April/005290.html