/search/?q=query URL format no longer supported (should be /search?q=query)

[scbhooshan]

What did you search for?

bangalore

https://nominatim.openstreetmap.org/search/?q=banga&format=json&addressdetails=1&limit=3&countrycodes=in%2Cus&accept-language=en

What result did you get?

<title>404 Not Found</title>

What result did you expect?

When the result in the right place and just named wrongly:

[
{
"place_id": 297963002,
"licence": "Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright",
"osm_type": "relation",
"osm_id": 1960177,
"lat": "22.9964948",
"lon": "87.6855882",
"class": "boundary",
"type": "administrative",
"place_rank": 8,
"importance": 0.6474964049356986,
"addresstype": "state",
"name": "West Bengal",
"display_name": "West Bengal, India",
"address": {
"state": "West Bengal",
"ISO3166-2-lvl4": "IN-WB",
"country": "India",
"country_code": "in"
},
"boundingbox": [
"21.5473014",
"27.2212039",
"85.8200883",
"89.8725414"
]
}
]
// 20230802132021
// https://nominatim.openstreetmap.org/search?q=banga&format=json&addressdetails=1&limit=3&countrycodes=in%2Cus&accept-language=en
​
[
{
"place_id": 297963002,
"licence": "Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright",
"osm_type": "relation",
"osm_id": 1960177,
"lat": "22.9964948",
"lon": "87.6855882",
"class": "boundary",
"type": "administrative",
"place_rank": 8,
"importance": 0.6474964049356986,
"addresstype": "state",
"name": "West Bengal",
"display_name": "West Bengal, India",
"address": {
"state": "West Bengal",
"ISO3166-2-lvl4": "IN-WB",
"country": "India",
"country_code": "in"
},
"boundingbox": [
"21.5473014",
"27.2212039",
"85.8200883",
"89.8725414"
]
}
]

When the result missing completely:

Further details

[mtmail]

Where do you see a HTTP 400 error? If a result is not found the API usually returns HTTP 200.

[lonvia]

The new implementation is stricter when it comes to the URL. /search/? is no longer permissible, you need to use `/search?'. Do we really need backward compatibility here? The syntax was always wrong. I'd rather see that people fix their code.

[lonvia]

I see that we have the old slash syntax still in the docs: https://nominatim.org/release-docs/develop/api/Search/#json-with-svg-polygon That definitely needs to go away.

[scbhooshan]

Dear Sarah Hoffmannn, Thank you for your prompt response. Sorry we are getting 404 error message not 400. Inside ol-geocoder.js I could see we are using an old url. Regards, Bhooshan.

…

On Wed, Aug 2, 2023 at 2:19 PM Sarah Hoffmann ***@***.***> wrote: I see that we have the old slash syntax still in the docs: https://nominatim.org/release-docs/develop/api/Search/#json-with-svg-polygon That definitely needs to go away. — Reply to this email directly, view it on GitHub <#3134 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGHZQDR6FOS3JQWROLRZJTXTIIBBANCNFSM6AAAAAA3A3ORIE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[scbhooshan]

constructor() { this.settings = { url: 'https://nominatim.openstreetmap.org/search/', params: { q: '', format: 'json', addressdetails: 1, limit: 10, countrycodes: '', 'accept-language': 'en-US', }, }; } On Wed, Aug 2, 2023 at 2:30 PM Saro Chandra Bhooshan ***@***.***> wrote:

…

Dear Sarah Hoffmannn, Thank you for your prompt response. Sorry we are getting 404 error message not 400. Inside ol-geocoder.js I could see we are using an old url. Regards, Bhooshan. On Wed, Aug 2, 2023 at 2:19 PM Sarah Hoffmann ***@***.***> wrote: > I see that we have the old slash syntax still in the docs: > https://nominatim.org/release-docs/develop/api/Search/#json-with-svg-polygon > That definitely needs to go away. > > — > Reply to this email directly, view it on GitHub > <#3134 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABGHZQDR6FOS3JQWROLRZJTXTIIBBANCNFSM6AAAAAA3A3ORIE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[lonvia]

Lovely. Opened an issue there but this project looks to be mostly dead.

[szeidler]

Also ran into the issue today. What is quite interesting is, that in our local environments the URL with the trailing slash still seem to work, on our servers it gives the 404. But it's indeed an easy fix to change the base url.

[lonvia]

The new implementation is only live on one of our servers right now. Depending on the location of your server you get the new or old behaviour. I see how this can be annoying when the test environment happily keeps working. Sorry about that. I'll see to it that we quickly disable the URL pattern on all servers.

I've decided against monkey-patching to support the old style URL because eventually it would only move the problem two years down the road for everybody.

[deryckchan]

I've encountered the same issue today, and after some debugging I landed on the "API no longer accessible via this URL" error page that links to this thread, thank you. As @lonvia pointed out above, the "incorrect" search/ syntax was used in documentation examples, so I think this breaking change has widespread impact.

[rbyjoswald]

As @lonvia pointed out above, the "incorrect" search/ syntax was used in documentation examples, so I think this breaking change has widespread impact.

Encountered the same today. Any chance for a rollback with another grace-period (say 15-30 days?!)?

[lorello]

we are in the same conditions: haundred of websites to patch because we are using the wrong but well documented way to call your API. @Ionvia A backward compatible solution would be very appreciated, even for just a couple of weeks.

[richterb]

Same here, a month-long grace period would be enough to properly update all our code to the new proper URL and would be greatly appreciated. The summer period doesn't help with updates and deployments either.

[mtmail]

The new implementation is only live on one of our servers right now.

That server was temporarily taken down by OpenStreetMap operations team 24h ago so the new implementions isn't live any more.

[lonvia]

A grace period only makes sense, if there are means to reach your users. We don't have these means. That is the downside to providing an API without API keys or other login restrictions. Yes, we could add a grace period of 30 days but it just means that I'll have the same discussion again in 30 days with a different set of people.

The 404 with the helpful message is being sent on all servers now to make it as easy for you find and fix the problem. I'm really sorry for the inconvenience.

[alexdezi]

Is there any way at all to have the compatibility with the /? Some third party solutions basically stopped worked, because the use the well documented (but wrong) way of calling the API.

[mtmail]

@alexdezi Can you list or link those third party solutions which are not working for you?

[alexdezi]

I am for example currently working with a Wordpress theme that has integrated that API query using the /. Funny enough it's a few sites with the same purpose, on some I managed to get the location query done on time, and on some it suddenly stopped working. After a lot of debugging I realized that the query is implemented incorrectly despite the documentations showing it like that.

[MuhammadNaeem42]

please anyone guide me how i change old URL to New URL i am running OSRM in docker

i follow this steps to run OSRM in docker
https://hub.docker.com/r/osrm/osrm-backend/

[mtmail]

@MuhammadNaeem42 You need to update the leaflet-control-geocoder dependency. See Project-OSRM/osrm-frontend#370 For follow-up questions contact the osrm-frontend repository maintainers.