I thought this might be a problem of the opengeocoder (since the directions api only takes coordinates I thought the addresses are run through the geocoder first) but /geocode/search correctly returns a result for “Untere Holzstraße 4, Solingen” (but not for the other addresses).
Looking up these addresses on pelias or nominatim.openstreetmap.org gives perfect results, so I am not quite sure what data the openrouteservice is based on.
On the maps.ors.org page we use /autocomplete, not /search. We actually just changed it recently. And you’re right, autocomplete doesn’t find it, neither on geocode.earth’s demo. Reason might be that autocomplete doesn’t check for exact addresses. I wasn’t really aware of that until recently though. However, we should maybe think about having a different mechanism to trigger a call to /search@amandus, what do you think? E.g. when the user presses enter it will request /search with the “final” input?
In any case, even with /search those addresses are not really found either on our servers. Just checked our instance and yep: 2 ES nodes crashed irrevocably (for me anyways…). It was just importing new global data and something happened to destroy 2 nodes. Cross fingers it’ll go smoothly this time, then it’s back up to speed and will likely find the above addresses over /search.
first I want to apologize for reviving this old thread but I as this issue does not seem to be resolved yet, I wanted to ask whether there is any progress yet.
I frequently get the message " Error. No address could be found" while the addresses definitely are mapped. This is also a real dealbreaker when I try to recommend your service to other people…
In my case I usually tend to manually position the start and target location on the street in front of the house. Works, but is anything but elegant.
Interestingly, this problem is also present with the OsmAnd~ mobile app. So I am aware that this is definitely an upstream issue.