[Feature request] Make max_results limit configurable

[Sarrasor]

Is your feature request related to a problem? Please describe.
We are implementing a street geometry search based on Nominatim. The results should include the full geometry of a street, which is not how OSM stores them. Thus, the ways returned by Nominatim are merged into one MultiLineString geometry. Due to the hardcoded limitation of 50 results per query, although documentation mentions 40, the geometries of big streets are incomplete. When we increase the number of results to larger numbers, the problem is alleviated with no visible drops in performance, although no proper benchmarking was performed

Describe the solution you'd like

• The proposal is to add a parameter similar to those in the General Parameters section that would define the limitation on the max number of results with the default value of 50

Describe alternatives you've considered

• One can use exclude_place_ids, but that requires making multiple requests to Nominatim, although, a user makes only one request for a specific street
• Another way is to monkey-patch the docker image/container, but that seems like a temporary solution

[lonvia]

I'm a bit reluctant to add more configuration parameters for the frontend. They are a bit of a pain to work with. And this kind of parameter is unlikely to be used much.

The server API implementation is a very thin layer around the Nominatim library these days. Only the glue layer has the restrictions on the maximum requests. Patching the single line should be fairly save.

Or if you want to take this a bit further, you could even consider adding your own custom endpoint that runs the street merging on the server side. If you find a nice solution, this might even be something to consider adding into main Nominatim. See also the very, very long-standing request in #114.

[Sarrasor]

Thanks for the reply! We'll resort to monkey-patching then.

Regarding the street merging, I'll look into the issue you've mentioned and see if our use case matches the situation described. Currently, we are doing a naive merging with shapely.line_merge, but one might need to consider tags when merging. For example, one way has two lanes, and another - three. If we merge those ways, the lane semantics will be lost. We are playing with those options, I'll let you know when we settle on something.