Sorry for not replying this email. I am not an active member of the open moko community so I was a little bit overloaded by the mail rate at that time. Hopefully, the OpenVMap guy pointed me this unreplied email, so here are my answer, and it's basically very short:
2009/2/21 Nick <realtimeb...@gmail.com>: > Thomas, > > I agree with you about the train and people in the train. > what about bad gps hdop,... ? > > I agree your approach will be probably enought for assited GPS. > (anyone knows the precision needed ?) > > but I don't think this is the right one for the other services mentionned. > > Thinking of a high quality "my position" service (google kind), > we will not achieve it not treating gps hdop, gps speed... > > so to be constructive in order to merge our databases, > would you be ready to collect gps speed, gps (hvp)dop and make these > info available > in your (very large) measures file ? YES > > From this, I could provide you with a new mapping manager that identify > the cells position calculated with gps (hvp)dop, gps speed when these > values are available > the cells position calculated with no gps (hvp)dop, gps speed because > these values are not available > > We would have only one database with both quantity (the whole database) > and quality for some cells. (Hoping that the best quality, > would be available for all the cells in the future) > > what do you think about it ? > Sounds great! The diifculty will be to do the new computation of all cells with data of various level of quality. Hard but not unpossible > regards, > Nick > > Thomas Landspurg a écrit : >> >> >> 2009/2/20 Nick <realtimeb...@gmail.com <mailto:realtimeb...@gmail.com>> >> >> Thomas, >> >> After trying to reach you a few times last year, >> i am really glad to have some news from you now. >> >> >> The easiest way is to use the email mentionned in the Web page! ;-) >> >> >> >> I am reponsible for the openBmap website. And yes, it would be a great >> thing to merge our projects ! >> >> The number of logs you have is very impressive ! well done ! >> >> My concern would be about the quality of your data . >> >> you still mention on the front page >> >> "Note:If you want a professional CellID Database, I suggest you to >> go to >> Navizon >> who provides top services and databases." >> >> what do you mean ? >> >> >> >> Tihs mean that there are company that have created huge databases of >> high quality by spendig a lot of money on it, and they make money by >> selling these data. Navizon pays his users for this, and other are >> throwing a lot of money on this too, by sending people doing measures, >> or by buying operators database. That's exactly the same difference >> between OpenStreetMap and Navteq/Teleatlas. OpenStreetMap is free, >> provided by the community, but of a lower quality than their >> commercial counterpart except on some specific area not covered by >> these equivalents. Of course, the objective is to reach the same >> quality, but this will take time. >> >> >> >> >> and after importing 800 000 of your gps points in january, I see that >> for instance >> gps speed, gps hdop, gps pdop, gps vdop are not available >> (at least at the begining of this huge measures.txt file !), >> >> >> A bad pdop, vdop, hdop and i am positioned at 1 km from my real >> position ... >> What if i am in a high speed train at 300 km/h? or in plane ? (yes, it >> can work in planes...) >> >> >> >> Let's go back to the basics: the objective of these database if to >> provied an positionning to create services using localisation on top >> of this database. Let's take the sample of an high speed train: there >> is high chances that all the sample will came from people in the train >> itself, and not from the neighbour outside (train don't go at 300 km/h >> in high density area). So this mean that the REAL position of the cell >> will never be accuratly computed, which is not an issue, because the >> only interesting information is the user position. So sampling mesures >> even some errors is fine as long as it works fine to get user position. >> So the philosophy behing opencellid was to reach the 80/20 ratio: >> acheiving the 80% of functionality will require only 20% of the time >> needed to do these 100% functionality. So that's why we have a simple >> and elegant API, that is used by different devices with different >> capacities, while acheiving exactly this objective: providing an >> accurate cell id positionning. >> >> >> >> In my opinion, considering the following services >> >> *** asisted gps >> *** "cell id" to google "my position" kind of service >> *** "cell id" to "town name" service >> >> >> >> the real questions are: >> what precision do we need for openmoko location service through >> gsm cell >> id ? >> what precision our possibly merged database would provide ? >> >> >> Assisted GPS does not require huge precision. I am not an expert, but >> I would be curious to know what is the precision needed to get an >> assisted GPS. Using triangulation is a different story, and this >> obvisouly will work fine only in high density area, where you also >> have high density cells. So again, there is a direct correlation >> between the precision and the density of the area. >> Note also that OpenCellID use LAC (Local Area Code) to provide an >> alternate positioning with a lower precision if a cell is not know, >> but if the LAC is know. Typically other cells has been discovered in >> the same area. >> So once you get CellID positionning, you can use reverse geocoding >> service to get the town for instance. >> >> >> >> >> what do you think about the above considerations ? >> >> really glad to hear from you ! >> >> regards, >> Nick >> >> Thomas Landspurg a écrit : >> > >> > >> > 2009/2/20 Onen <onen.om <http://onen.om> >> <http://onen.om>@free.fr <http://free.fr> <http://free.fr>> >> > >> > Hi Thomas, >> > >> > Thomas Landspurg wrote: >> > > >> > > Dear OpenMoko community (and thanks ed for pointing this >> out). >> > > >> > > I am behind the opencellid.org <http://opencellid.org> >> <http://opencellid.org> >> > <http://opencellid.org> project, and it >> > > seems that there are some discussion around it these day >> on the >> > mailing >> > > list. >> > > >> > >> > Last month, and today, indeed. >> > >> > >> > Yes, I've get to it today! It's a pity not to have been notified of >> > such discussion before. I've been through them, and I want to >> add some >> > clarification about difference between database: >> > >> > - OpenCellID can also store signal strengh. But one of the issue, is >> > heterogenity between datas. Some client don't have this information, >> > and this create some additional complexity. That's why this >> > information is for now only stored but not yet used. And in all was, >> > if you want it, it's in the measure table, and not in the cell >> table. >> > >> > - About the barycenter of the area/instead of barycenter: it's not >> > always the best way to do it, as it give more value to false datas. >> > while the "simple" barycenter reduce these. Another option would >> be to >> > exclude data that would be completely "out of range" >> > >> > And more "general" information about the databse: more than 500 >> > developers have registered to get an API key. Obvisouly not 500 >> > application are out, but show the interest of the community >> > >> > >> > >> > >> > > So let me clarifiy: >> > > >> > > - As described in the web site, the license is under >> creative common >> > > share alike 3.0. I had several request today stating that just >> > linking >> > > to the license was not clear enough, so I will re-clarify >> it on >> > the web >> > > site, but also in this list. >> > > >> > >> > Last time I checked (and other people, see the post I >> pointed out >> > earlier today), it was not clear. But today, as people had a >> look >> > again, >> > it seems to me pretty clear :-) >> > >> > >> > Last time, it was written under creative common license, with a link >> > to the creative common share alike license. I am sorry if this >> was not >> > clear enough, but as you see, a simple mail is enough to get it >> corrected. >> > >> > >> > >> > >> > > - I am surprised to see statment that I did not answer to some >> > > questions. I've verified,and all openmoko request have been >> > answered. I >> > > am not perfect, and may be some emails have been missed, but a >> > search on >> > > openmoko on my mail box did not raise any pending question. >> > > >> > >> > Not sure what you mean by openmoko request... When I stated that >> > neither >> > us nor openmoko did get an answer, I should have written: >> "If I recall >> > correclty openmoko tried to reach opencellid, but I have not >> heard of >> > any response. We tried to contact opencellid, but got no >> response." I >> > personally have not tried to reach you. But Nick yes, >> without answer, >> > for what I have understood. >> > >> > >> > Would be curious to have his email just to check. I am quite sure >> > I've answered to all demands like this. >> > >> > >> > > There is more than 100 000 cells covered, with 5.5 >> millions of >> > > measure, and more cells will be "donated" soon. We expect to >> > reach 200 >> > > 000 cells in the coming weeks thanks to a new project >> donation. >> > There is >> > > also more than 10 different clients (windows mobile, symbian, >> > > blackberry, j2me,...) gathering the database. >> > > >> > >> > Is there different countries? >> > >> > >> > Yes, the stats page show all countries: >> > >> > http://www.opencellid.org/cell/stats >> > >> > >> > >> > Good to see there is no client for openmoko, otherwise I may >> have >> > worked >> > for nothing ;-) >> > >> > >> > Yes, I've heard that other where working on such client too! >> > >> > >> > >> > > I've been running this project since more than one year >> , with an >> > > objective to push community efforts around cell id. So I would >> > be more >> > > than happy to see new effort joining this project instead of >> > creating >> > > separate efforts. So let's join effort and create >> something big! >> > > >> > >> > I am very glad to read this, especially as I was very >> disappointed not >> > being able to leverage the existing work you have done. For >> my part I >> > work on the client side. A logger/uploader. I guess it would be >> > easy to >> > modify it to upload to your database if we go that way. But >> for now, I >> > think it would be good Nick (who takes care of the server side) >> > and you >> > keep discussing, in order to evaluate a possible merger. >> > >> > As there are also plans on embedding the database on the >> phone, and >> > using it to locate, I would like to know if this part would >> interest >> > you? Or only the server side and upload? >> > >> > >> > The idea is to provide all the means to do so. So if there is >> anything >> > that is needed to help you to do this, I would be happy to >> provide it. >> > For instance, a way to send an area and get the list of cells in >> that >> > area. I amalready working on such functionality. >> > But the switch to from OpenBMap to OpenCellID should be quite fast >> > as I assume that the API is probably the same, or very close to. ( >> > http://www.opencellid.org/api ) >> > >> > >> > >> > > And as a reminder, the complete data base is available for >> > download. >> > > >> > > So if you have any question/interrogation, feel free to share >> > them with >> > > me so we can clarify this. >> > > >> > > Regards, >> > >> > Great we can move along. I hated this feeling of reinventing the >> > wheel! >> > >> > >> > So do I! >> > >> > >> > >> > Onen >> > >> > >> > _______________________________________________ >> > Openmoko community mailing list >> > community@lists.openmoko.org >> <mailto:community@lists.openmoko.org> >> <mailto:community@lists.openmoko.org >> <mailto:community@lists.openmoko.org>> >> > http://lists.openmoko.org/mailman/listinfo/community >> > >> > >> > >> > >> > -- >> > Thomas LANDSPURG >> > 8Motions >> > Founder/CTO >> > http://www.8motions.com >> > http://www.opencellid.org >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Openmoko community mailing list >> > community@lists.openmoko.org <mailto:community@lists.openmoko.org> >> > http://lists.openmoko.org/mailman/listinfo/community >> > >> >> _______________________________________________ >> Openmoko community mailing list >> community@lists.openmoko.org <mailto:community@lists.openmoko.org> >> http://lists.openmoko.org/mailman/listinfo/community >> >> >> >> >> -- >> Thomas LANDSPURG >> 8Motions >> Founder/CTO >> http://www.8motions.com >> http://www.opencellid.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Thomas LANDSPURG 8Motions Founder/CTO http://www.8motions.com http://www.opencellid.org _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community