This PR 'buffers' Point geometries, effectively turning them in to Polygon geometries.
It's currently only enabled in the UK, where the lack of open data is a real problem, resulting in incorrect labels for the numerous small towns, hamlets and neighbourhoods where we don't have polygon data.
The code is configurable, in terms of the buffer radius and which records are selected to be buffered.
This will likely have an effect on RAM, although doing it in the UK only will mitigate that somewhat.
The default radius of 0.02 degrees was selected as it's the same value that Nominatim uses for the same task, although they also have larger radii for larger geographies, I chose the more conservative approach for now. I did some spot checking and 0.02 works pretty well.
We will probably need to couple this PR with a small update to the query logic, in the case where more than one neighbourhood matches. In that case, we should choose the record which has the closer centroid.
This PR 'buffers'
Point
geometries, effectively turning them in toPolygon
geometries.It's currently only enabled in the UK, where the lack of open data is a real problem, resulting in incorrect labels for the numerous small towns, hamlets and neighbourhoods where we don't have polygon data.
The code is configurable, in terms of the buffer radius and which records are selected to be buffered.
This will likely have an effect on RAM, although doing it in the UK only will mitigate that somewhat.
The default radius of
0.02
degrees was selected as it's the same value that Nominatim uses for the same task, although they also have larger radii for larger geographies, I chose the more conservative approach for now. I did some spot checking and0.02
works pretty well.We will probably need to couple this PR with a small update to the query logic, in the case where more than one neighbourhood matches. In that case, we should choose the record which has the closer centroid.