On Thu, 15 Jan 2009 00:59:52 +0100, Stefan Schmidt <ste...@openmoko.org> wrote:
>> I was referring to the fact that I could use their code to do something >> similar. But what I have in mind is to provide a dbus service, providing >> GSM based location. Now I think I understand what you meant above in >> your mail, about integration in FSO. Is it what you had in mind? > > I was thinking along these lines, just thinking , no code or descision: > > * ogsmd offers the MCC/MNC/LAC etc informations via dbus, no need to > duplicate > this. > * What different _does_ you offer? Location from GSM. > * A dbus interface that gives you the name of the city or even the > district with > zero extra costs like tunring on the GPS would be nice. > * You could offer the appr. GPS coordinates from the db. How would we > integrate > this? Some dummy GPS device? > * We want for sure use this when we power up GPS to set the appr. location > so we > can get a faster fix. > > This kind of stuff I would like to see as a service via dbus. Prefered > would be > a subsystem in FSO. This would fit into a framework as it provides data > that > different applications can use. > >> > Well, I would not put to much into the application itself. We have a > framework >> > you improve to your own needs. That's really different from other > systems, make >> > use of it! :) >> > >> > Meaning, I would put the logic and the communication with the > webservice either >> > in a fso subsystem or in a small daemon process. Eyporting a nice API > will allow >> > more then one app to make use of it. I was contenplating (and proposed via ML, IIRC) some time ago utilizing a local DB to store correlations between GSM towers, visible wifi APs and GPS coords when GPS /was/ on, and later retrieving those coordinates (rounded and noting error) on demand by simply requesting 'current location'. If GPS is on that can of course supply precise data from the GPS, but if it's off and the DB includes reference to a visible GSM tower or wifi AP it can return the stored coords with accuracy represented as a separate value. (eg '5' indicating +-5km) So this would entail the DB itself, a daemon stuffing newly-discovered correlations into it, and a dbus interface that both provides current GPS coords if available (with error noted as '0' meaning "presumed accurate"), and provides DB-retrieved approximations when necessary and available. Presuming a daemon in use, it could also calculate rougher approximations based on understanding that even though it has no GPS data stored for the current GSM towers visible, that 10 minutes ago it saw a GSM tower it DID have in the DB, and return coords with a larger error factor noted. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
