Future of location services on OM
dkogan at cds.caltech.edu
Sat Jan 10 16:48:23 CET 2009
There are several free databases of GSM tower locations. I wrote a perl
script that I run on my gta02 to query http://www.opencellid.org/ for
the approximate tower location, and then initialize the AGPS with this
data. Works great. The database is built from user submissions, so it's
not complete, but it will grow.
On Sat, 10 Jan 2009 23:22:02 +0800
"Gergely Imreh" <imrehg at gmail.com> wrote:
> >> Oh, yeah, sounds easy... The problem is that the cell does not
> >> broadcast any location information, so the best you can do is the
> >> go around town, record the signal strength, and try to guess where
> >> the signal is coming from. If there's plain sight it is relatively
> >> straightforward. We tried it in a city - echos, shielding from
> >> buildings... imagine the rest, the signal was all over the place.
> >> Not something that one can analyse without further knowledge or
> >> guesswork. Can send you some logs if you want to check it out
> >> Having a "cell fingerprint" database - storing relative strengths
> >> of multiple cells together with the recorded GPS position - would
> >> provide better operation, but with a cost (in storage place, for
> >> example) that is just not worth the effort. With the current GSM
> >> methods one does not aim for supreme accuracy, just speed (you can
> >> locate which intersection in a city you are in a second, not
> >> within 10+ minutes it usually takes with my GPS).
> > Hi,
> > by simplifying a little but, this could become easier : assume that
> > you log positions/cell relationships: for each cell ID, you compute
> > the geometrical barycenter of the positions. You then store this
> > position and its accuracy (the number of positions/cell
> > relationships, maybe compute the geographical spread of the points)
> > that you used to compute the mean.
> > Assuming an dense, logging you would then have one position per
> > cell, with a "quality factor" (~ how many measures have produced
> > this point), you could then simply have a "nearest neighbour"
> > approach to get to know where you are.
> > It's true that you would not have the real antenna's positions, but
> > you would have positions where many people have "seen" the cell ID,
> > which could turn to be more accurate.
> This is turning into a little bit specialized discussion, away from
> the original "overall direction" question.
> But to answer this: if you wish, I can send you real logged data. I
> tried to do something what you suggest, but it only works well, if you
> have logged data from a cell from all directions and from a number of
> different distances. In real life, you can have a lot of log from one
> side (e.g. west) from what I suspect to be the cell position (based on
> signal strength), while on the other side (e.g. East) there's almost
> nothing because other cells take over the. Buildings change the
> pattern as well. Some times there's no possibility to go all around a
> cell and then it can be really ambiguous where the cell is..... All
> sorts of problems.
> Also, tried real GSM based positioning with such "mean" positions. The
> position one have to base on max. 7 (1 connected + 6 neighbours) cells
> that the phone knows about at any given moment. Now the connected cell
> is not always the one that is the closest - it's the one with the
> strongest signal. In my town it seemed the network deployed a number
> of very strong cells, supplemented with a lot of weaker cells in
> between. My phone was mostly connected to the strong ones all around
> town. Though this would be probably an issue with any other GSM based
> positioning algorithm, because of the limited information the phone
> can have about the network. Have to check how Android uses the cell
> positions/signal strengths.
> Having said all this: I'm not saying it is all impossible. I the
> basics have been done (the CellLocator does it in a very rough
> manner). I was just thinking that it seems right now, if we want to
> compile a a GSM cell database ourselves, that will be 1) difficult, 2)
> inaccurate, 3) user-unfriendly --- but none of these should completely
> stop the effort.
> On the other hand, how well the wifi-based positioning would work?
> Have to take some real life data of that one as well, and try to use
> devel mailing list
> devel at lists.openmoko.org
More information about the devel