GeoNames Forum

noticed behavior of the http://www.geonames.org/export/web-services.html#postalCodeSearch

when searching for place names (placename_startsWith) it only looks in one field which contains the primary spelling of the place name in the primary local language.

examples from switzerland:
- Fribourg (no match for Freiburg)
- Genève (no match for Genf)

also, accents must match:
- Geneve finds nothing
- Zurich finds nothing

in contrast to this, the http://api.geonames.org/search service does match
- accented characters vs. us-ascii. maybe that's done with additional fields with the spelling in us-ascii, i don't know
- multiple languages (genf/geneve/genève) etc.

my use case:
a search form with an optional geo search attribute. the user can select a place as a search criteria, and only nearby records are shown. selecting the place works by typing a zip code and/or place name, and then selecting one of the offerings.
the 'postalCodeSearch' seems to be the correct web service for this: it offers searching by post code, or by place name, and returns the coordinates.
the 'search' service does not allow searching by post code, and does not return post codes either. so when looking for a place name like 'Pfäffikon' much more post processing needs to be done (filtering, and finding the zip code).
combining multiple api methods and firing multiple calls for one search to get the data that i need sounds like a pain.

it would be great if the 'postalCodeSearch' was behaving like the 'search' service.

I confirm that :

placename_startsWith=Genèv returns Genève
placename_startsWith=Genev returns nothing

@Marc: any idea how to fix this ?

Thanks Christophe.

The placename_startsWith was an issue on the server side. The service now does a conversion to ascii for this parameter and will find the places.

The translations to other languages are not yet implemented in the postal code search. This is still on the todo list.

Best Regards

Marc