Yeah, it really loves to suggest US options.
Also thinking about using embeddings to complement this.
https://cartes.app/#8.61/37.5261/-121.7338 constant up and down movement at any middle zoom level, e.g. this one. zoomed far out or far in (<20km or so visible) it's stable, e.g. https://cartes.app/?allez=San+Francisco+Bay%7Cr9451753%7C-12... moves most of the screen up and down, while https://cartes.app/?allez=San+Francisco+Bay%7Cr9451753%7C-12... is stable. (this appears to be the case roughly anywhere, this is just an example) https://www.dropbox.com/scl/fi/orfhap34liecdon618wkv/Screenc... for a screen recording.
for below, all have "here" selected (not "everywhere") and this same view: https://cartes.app/#12.41/43.0435/-87.89962
"coffee": shows city names in other states, and two places in Iraq.
"valentine": shows... house icons? and a business icon in other states and countries. (top result is apparently a "commune" in France. not sure I'd use a house icon for that tbh)
"valentine coffee": good substring matches for the business name (3 results) and two results in other countries.
"val coffee" (exploring substring behavior): finds one good match from the previous search... but it also shows "Stone Creek Coffee"? what part of that node matches "val" but not "coffee" on its own? https://cartes.app/?allez=Stone+Creek+Coffee%7Cn5066972575%7... -> https://www.openstreetmap.org/node/5066972575
"vendetta": finds 3 good results, e.g. https://cartes.app/?allez=Vendetta+Coffee+Bar%7Cn11268671206... , but why does this work when "valentine" does not?
so... pretty normal results for open-source OSM apps afaict. maybe slightly better than average.
I’ve been working on geocoder which uses a trained model to parse and classify address queries into a tokenized form. In addition to being more accurate than traditional rule-based parsing, this approach also gives the search engine more to work with beyond the tokenized boundaries of each word. The model also attaches provenance annotations to the address components, allowing the geocoder to have a better understanding of the geographic hierarchy of the components makes sense, rather than matching a string in a database.
The code is changing fast but you can try it out entirely in your browser here! Let me know if you’d like to see any specific features not on the roadmap :)
concretely, here's an example search session: https://news.ycombinator.com/item?id=48825127
I mean it when I say that's "maybe slightly better than average". When it gets extra weird I generally go check the OSM node data out of curiosity, and fairly often I find searches returning things where literally no field at all matches any word I searched for, across many different apps. I don't really think that's an address parsing issue, though I have definitely noticed many apps being picky (but completely unspecified) about search formatting when looking for addresses.
There are different ways of using maps. A lot of the stuff I do with mapping apps I really do just pan and zoom, and that works for me.