New to osm, playing with OSM and searching neighbours and find something does not work as I expect

[327840386]

Hi @lonvia, it is my first time to touch with osm from GSOC and I am trying to play with it! I searched some addresses in vancouver and found something does not work as I expect, for example I searched '5900AlderbridgeWay', there was showing with no result. And if I searched '5900 Alderbridge Way', the correct address was showed up. I thought the reason is the preprocessor did not parse the query correctly. Like it did not insert spaces between numbers and letters and it also did not automatically separate house number, street name, and street type (Way, St, Ave). If you correctly do in this way, you can get the correct address showed up on the map. I thought this problem is relevant with the latest issue 'Add query preprocessor for using regular expressions on queries'. I can add a space between the number and the letter, and add a space between street name and its type(the rule in query-processing should be like pattern: ([a-zA-Z]+)(Way|St|Street|Ave|Avenue|Blvd|Boulevard|Rd|Road) replace: \1 \2 .

In japanese preprocessor, it played well! It can efficiently recognize like 都都道府県縣 and 市区區町村. So if you search 東京都新宿区西新宿, after processing, it will be 東京都:新宿区:西新宿. So the map can recognize it and show the correct address up on the map.

It is my small thought after playing with the osm and I am really into the map stuff. I like it! Thank you for guidance and time! I appreciate so much!

[lonvia]

There is a different between letter-based and syllable/word-based scripts here.

In letter-based scripts the spaces are usually significant and will therefore not be left out. For a native writer, they are much more significant then upper vs. lower case. So with your example '5900 Alderbridge Way' people will regularly query for '5900 alderbridge way' but never for '5900AlderbridgeWay'. With that in mind, Nominatim ignores upper vs. lower case but considers spaces mandatory. This mostly works well with two exceptions: we do have special treatment for houenumbers where spaces are used more liberally, and there is a kind of marketing speech emerging which favours CamelCase over using spaces (see #3578). Your suggestion might have merit for the latter. However, the preprocessor would probably not be the base place to handle this. The preprocessor can only make hard this-or-that decisions: given 'AudioDesign', search either for 'AudioDesign' or for 'Audio-Design'. What we'd might want to do is searching for both.

[327840386]

Hi @lonvia, thanks for your clarification!I now understand that spaces are crucial in English-based address parsing and a preprocessor might not be the best place to handle this issue since it enforces a single interpretation instead of allowing multiple possibilities. Given that, would it be possible to adjust the search logic to try both spaced and unspaced versions when an address query fails(If someone who is not native speaker and forget to add spaces between words)? For example, if a user searches "5900AlderbridgeWay" and no result is found, Nominatim could automatically try "5900 Alderbridge Way". This would align with how users often omit spaces in modern queries (Like CamelCase-style inputs).If modifying the search logic is too complex, would an alternative be to provide search suggestions when a query lacks spaces, similar to "Did you mean '5900 Alderbridge Way'?" Thank you for your guidance I appreciate it! I will check the #3578 explore more.

[lonvia]

There are always two ways to handle such variations. You can already compute the variants when loading the data and add the variations in the name as additional names to find an object under in the index. Or you can handle the variations at search time, create different variants of the query and send each of them to the index.

Nominatim has mostly gone the way of pre-processing variants at indexing time. The reasoning behind this is that we know a lot more about the names we are indexing (which language they are in, where the object is locally, what kind of object it is) than we know about the query (might be any language, might search for anything). Not all variations make equally sense in all contexts. So by doing this during indexing time, we can avoid a lot of false positives: creating variants that wouldn't make sense in the context for a human. For the CamelCase names, it also likely makes more sense to do this at index time because a) names in OSM are more likely to have correct casing and b) we can restrict the variants to things like shop names.

On a more practical level: Nominatim doesn't even have the infrastructure for query variants yet. It might be worth introducing something like that but that's a bit of a larger project.

Regarding providing search suggestions. That would rather be something the client has to do. Nominatim does not interact directly with users. It just gets the search requests and responds to them via an API.