[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