... searching for "Lancelot Court, Hull" took about 1:10 and yielded about 20 results, none of them to the exact place but all of them containing part of the address string (for example, "Hull Road, London" - made up as I do not remember the exact example but I hope you get my drift).
I could not reproduce it again, every subsequent search for the same address gave me one exact result. But I did see entries in the OSM server log that looked a bit like this (this is a repeated test this morning, with the same result): Code: INFO: 08:54:55 Request: /v1/search?limit=25&search=Lanc INFO: 08:55:38 Parsed query [GB]: house: {lanc}; INFO: 08:55:38 Parsed query [GB]: h-0: {lanc}; INFO: 08:55:41 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull INFO: 08:56:19 Parsed query [GB]: city: {hull}; road: {lancelot court}; INFO: 08:56:19 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court}; OK, I thought, I can understand partial search queries resulting from the instant search while typing. But what if I enter the address quickly, for example by pasting it or selecting from history? So I tried: Code: INFO: 09:04:16 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull INFO: 09:04:51 Parsed query [GB]: city: {hull}; road: {lancelot court}; INFO: 09:04:51 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court}; As you can see, there is always a 30-40 seconds delay between the "Request" line and "Parsed query". That cannot be explained by partial searches.
INFO: 08:54:55 Request: /v1/search?limit=25&search=Lanc INFO: 08:55:38 Parsed query [GB]: house: {lanc}; INFO: 08:55:38 Parsed query [GB]: h-0: {lanc}; INFO: 08:55:41 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull INFO: 08:56:19 Parsed query [GB]: city: {hull}; road: {lancelot court}; INFO: 08:56:19 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court};
INFO: 09:04:16 Request: /v1/search?limit=25&search=Lancelot+Court,+Hull INFO: 09:04:51 Parsed query [GB]: city: {hull}; road: {lancelot court}; INFO: 09:04:51 Parsed query [GB]: h-0: {hull}; h-1: {lancelot court};
This looks like a map problem rather than the maps client's. Here is my example. I searched for "Redwick Road, Magor" and got no results. Then I changed the search to just "Redwick Road" and found a match... in Magor! Except that the search result did not say it was in Magor, it said it was in Monmouthshire. Here is the query and the location for your entertainment: Code: INFO: 09:13:01 Request: /v1/search?limit=25&search=Redwick+Road INFO: 09:13:02 Request: /v1/mbgl/style?style=osmbright-car-en INFO: 09:13:35 Parsed query [GB]: road: {redwick road}; INFO: 09:13:35 Parsed query [GB]: h-0: {redwick road};
INFO: 09:13:01 Request: /v1/search?limit=25&search=Redwick+Road INFO: 09:13:02 Request: /v1/mbgl/style?style=osmbright-car-en INFO: 09:13:35 Parsed query [GB]: road: {redwick road}; INFO: 09:13:35 Parsed query [GB]: h-0: {redwick road};
I noticed that again, on the same road. Then, about 30 minutes later, on the A423, the voice instructions said "eigh-four-twenty-tree" rather than the expected, "eigh-four-two-three". So I guess something somewhere is trying to be too clever and splits longer numbers into groups of two digits. A423 into A-4-23, A404 into A-4-04. Then something else is being even more clever and shortens 04 into 4.
Lastly, I am encountering this issue every time, no matter how long or short the route or the navigation session is. It was first observed in WhoGo and is still present in Pure. Life is too short so I am always rebooting at the end of navigation.