[OSM-dev] Fwd: [OSM-newbies] Reverse geo coding
Emilie Laffray
emilie.laffray at gmail.com
Mon Jun 15 15:26:03 BST 2009
Michael Handerek wrote:
> Ok, I realized it that there are no guaranty of the completeness of
> boundaries. Anyway, it is possible to build area geometries of
> administratives in order to check if nodes belongs to or not.
> Both methods have weaknesses, so in my opinion a combination of both is
> the best way to get nearly proper results.
> But how about the performance aspect?
>
>
Performance is not really a problem if you are doing it right. Postgis
is very efficient and it is possible to get fast and midly geographical
queries in less than 10 ms with tables with 80 millions rows.
> I think to organize area geometries like this. The geometries should be
> generated during the import of osm data. Additionally the geometries
> should be grouped by continent, country and city in order to do a top to
> bottom check. So, basically the search will be done in 3 steps.
> Considering that administrative boundaries are not complete and doing
> the search in combination with nearest continent/country/city-nodes, may
> it will be faster use bounding boxes instead of more precisely bounding
> areas.
>
What you write is interesting but if you really want something to
perform as fast as possible, one way is simply to keep all the
information in each of the geometries as you call them. For example,
towns will have information about the higher levels, which means you do
a simple query, etc.... There are so many ways of optimizing the kind of
queries you are talking about.
In addition, I would suggest that you look at ST_DWITHIN and other
similar functions. They use Postgis indexes by default, meaning they
already do the implicit bounding boxes.
A nearest neighbour algorithm can be slow if you are not careful.
Bostongis website has an interesting implementation which works very
well, but you define the parameters based on the information of your
database. It also means that it works well on homogeneous database but
not necessarily on heterogeneous database since the density of points is
varying based on the countries.
Emilie Laffray
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090615/8cb673f9/attachment.pgp>
More information about the dev
mailing list