[OSM-dev] implemented API for J2SE and J2ME (NameFinder Client API)
Michael Willigens
michael at willigens.de
Tue Apr 21 14:06:38 BST 2009
Zitat von Frederik Ramm <frederik at remote.org>:
> Hi,
>
> marcus.wolschon at googlemail.com wrote:
>> I disagree with the "have to".
>> A new implementation can have a form
>> with inputs for country, city, ..., housenumber and an optional
>> select amenityNearby
>
> Well yes but that would not be something than can replace the old
> namefinder, that would be an additional way of querying the data (which
> would probably mostly be used by automatic geocoders because humans
> don't like that many input fields).
>
> If we want to replace the current Namefinder, we have to be able to do
> the magic it does, including all the language-specific abbreviations
> etc. - even if some people would like to believe this, the Name finder
> does *not* perform a simple database lookup.
>
> Bye
> Frederik
should not be a problem to support this. abbrevate the objects before
indexing:
highways: filter: ave, street, way, strasse, straße etc. same goes
for cities and towns. LDAP supports wildcard queries for the rest and
one could also do a simple for human beings:
p=Earth,Street=Haslachstrasse
"Haslachstrasse" would therefor give "Haslach*" before doing the
query. Without knowing details but by looking on search result,
NamerFinder is probably doing the exact thing.
Needless to say that LDAP strings are not the UserInterface query
inputs but the clients API internal query. Quering something like
"bars near town xy" is also possible by adding filters:
"P=Earth,City=XY" "Category=Amenity Info=Pub". Category and info are
default attributes in old NameFinder as well.
So is there a reason not to at least try it and see how it performs?
Michael
More information about the dev
mailing list