As Tom Hughes suggested earlier on; perhaps it would be smart to use postgres,
especially since somany postgres/postgis instances are lying around for the mapnik servers that the openstreetmap community uses. My guess would be that a lot of people would be able to support you: http://www.postgresql.org/docs/8.3/static/textsearch.html http://www.postgresql.org/docs/8.3/static/fuzzystrmatch.html The textsearch module for postgresql handles records in the database as "documents"; giving you a broad variety of search functions. Perhaps this is the right compromis between a real search engine and searching records in a database. Regarding the near by; this would mainly mean "select this and that where searchterm="bla" and distance(the_geom, yourlocation) < x. The last query needs an extremely good design since distance functions perform somewhat problematic.. Frederik Ramm wrote: > Hi, > > Nicolas Guillaumin wrote: > >> Excuse me if it's a silly question (I'm a newbie here), but what about using >> a search engine component instead of SQL queries ? >> I think about Apache Lucene (Java search engine) for example ( >> http://lucene.apache.org/) which seems to me a better solution about >> indexing and searching than SQL requests ? >> > > Most of these are based on the concept of "documents" that are > "searched", and they don't usually have a spatial component. > > What we need is something that searches for objects in our database of > roughly half a billion elements, ideally also doing things like "a near > b", where position is expressed in coordinates. > > It is not impossible that some of the existing engines could be tweaked > to work but personally I think we're better of investing work in our own > database. > > Bye > Frederik > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev > > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
