What determines order of results when limiting by 1 (default)?
Hello,
I’m using the forward geocoding endpoint and really only care for polygon geojson responses. This has been working great for the most part.
Recently run into an issue that has me a bit confused. Locally during testing, I run a query for Colorado Springs, CO, USA and get back the first result, which contains the polygon I want for this locale.
But in my staging remote environment, the first result is strangely a point type (not polygon) and it seems to be tied to a specific zip/postal code.
Why would the behavior change here for the exact same query? The only difference I can see is the AWS region changes (this info is in the response headers). If I set the limit to 2, I get the response as expected. What determines the order here?
Приєднуйтесь до обговорення — додайте повідомлення нижче:
That was our thought too, so sounds like we’re on the right path. Thank you!
Hello,
as the upstream data that is pulled in here is a “living creature” where sometimes the interlinking between city relations and city center nodes may break (and be repaired later on), it’s a good idea to use a limit of 2 and check each of the returned results for osm_type=relation (or in geojson format for category=boundary instead of category=place) to be on the happy side and use that one if you need a geojson polygon. You can also send us any reports on cities you’ll find at support(at)geocodingapi.net.
As an update here, Colorado Springs is now returning a polygon for a city focused result by default first, so thanks for that. We are finding other instances of this though with other cities, and discussing workarounds on our end for the issue. Just wanted to raise it because its difficult to know how extensive this is just on a few geocoding calls with various cities.
Got it, thanks for the quick response!
Hello,
so you’ve found an edge case where two data entries (the city as boundary and the city as city_centre) where not interlinked properly due to one being broken once in upstream data while also being to large to be updated normally. With both of them not being interlinked in the DBs and both having the same importance for the search for the city, the order between those two was random. We fixed the data and updated the interlinked status of those and now you should be getting the boundary including the geojson when searching for Colorado Springs. This is a rare occasion of a chain of edge cases playing together in the continuous update process across all our backends.