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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community