Add infill from points

[brynpickering]

Adds feature to infill land-use areas using point data, like US address point data or the UK UPRN open database.

Also adds the API to add more infill methods in future.

To deal with a known pyproj issue due to Arup SSL/firewall oddities, I've added a snippet to the top-level __init__.py that emulates what we've done in pam and genet. Added here because it was causing test failures.

Checklist

Any checks which are not relevant to the PR can be pre-checked by the PR creator.
All others should be checked by the reviewer(s).
You can add extra checklist items here if required by the PR.

• CHANGELOG updated
• Tests added to cover contribution
• Documentation updated

[val-ismaili]

This is looking good. Some points:

• Could you share a photo of this point_source infilling in action? We can add it to the documentation config.md page as well. We've already got a photo for the spacing method. Maybe worth changing this so both are of the same location but just with different methods?
• I can see you've allowed user to put in spatial file format of their choice - maybe add a line in the documentation to say it can be of .geojson, .gpkg, .parquet formats as are the general supported formats for osmox now.
• I'm unclear how metadata of the point source dataset gets carried through. Could we enable the user to map columns from the reference dataset to match the osmox facilities columns such as area, floors etc. Dataset might not have them so the defaults / size inputs make sense, but if the data is there can we map that in?

[val-ismaili]

Then finally a data structure query - on small scales it'll be easy enough to sense check an area of infilling. But when doing it on large scale it will be difficult to keep track of what's OSM and what has been infilled - can we make use of layers in a spatial file format such as .gpkg? OSM processed data goes into one layer and then the results from the infilling into another (same file though). This would just make it easier to keep track of additions and sense check results. I don't think .parquet supports layers, but could we give this layering option for when writing to .gpkg ?

[brynpickering]

Could you share a photo of this point_source infilling in action? We can add it to the documentation config.md page as well. We've already got a photo for the spacing method. Maybe worth changing this so both are of the same location but just with different methods?

Sure, I'll work on that for isle of man.

I can see you've allowed user to put in spatial file format of their choice - maybe add a line in the documentation to say it can be of .geojson, .gpkg, .parquet formats as are the general supported formats for osmox now.

will do.

I'm unclear how metadata of the point source dataset gets carried through. Could we enable the user to map columns from the reference dataset to match the osmox facilities columns such as area, floors etc. Dataset might not have them so the defaults / size inputs make sense, but if the data is there can we map that in?

No metadata. This would be my preferred initial approach. I.e., it is a drop-in replacement for infilling with generic spacing. It does not attempt to add extra info. I could see a benefit of having some metadata in future but then you need to be very good about verifying the format of the input data file.

But when doing it on large scale it will be difficult to keep track of what's OSM and what has been infilled

This is captured in the current approach (no layers): the infilled points get an index name prepended with fill_. I wouldn't go with layers as you they are so specific to geopackages and you need to make sure you save your geospatial data to file with layers to benefit from loading a specific layer later.

[val-ismaili]

No metadata. This would be my preferred initial approach. I.e., it is a drop-in replacement for infilling with generic spacing. It does not attempt to add extra info. I could see a benefit of having some metadata in future but then you need to be very good about verifying the format of the input data file.

Yeah makes sense for the initial approach - can add an issue to keep track of this down the line.

This is captured in the current approach (no layers): the infilled points get an index name prepended with fill_. I wouldn't go with layers as you they are so specific to geopackages and you need to make sure you save your geospatial data to file with layers to benefit from loading a specific layer later

Yeah noted on the specificity to geopackages. I didn't see the addition of fill_ - that works!

[brynpickering]

@val-ismaili I've added a figure and some more text to the docs.

[mfitz]

Looks good. That image you've just added definitely makes it quicker and easier to understand the new infill-from-points-file functionality.