You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The most basic form is simple and can be done already. Consider a vector of polygons polys, associated values values, and a polygon that we want to interpolate, p1.
In this case, we can simply execute GO.area.(GO.intersection.(polys, (p1,), target = PolygonTrait()) ./ GO.area.(polys) .* values with some normalization factor. However, spatially aware versions of this also exist that could be integrated into Rasters.jl.
That means that area-based interpolation should probably be its own package, accepting GeoInterface geometries and potentially also RTree/STRtree objects to speed up intersection.
FeatureCollections would be decomposed to tables on input. The main entry point should probably return a GI feature. GO.reconstruct would be helpful here.
In order to get raster statistics, we could use something like Rasters.zonal(sum, provided_data; of = polygon). This provides a nice accumulator interface without many allocations. We could also use Stencils.jl to do some stencilling on a fully populated raster, if that proves necessary.
If we do end up using Rasters, then we must mention in many places a method by which you can create a Raster from a regular array.
The text was updated successfully, but these errors were encountered:
See https://gistbok.ucgis.org/bok-topics/areal-interpolation and https://github.com/chris-prener/areal.
The most basic form is simple and can be done already. Consider a vector of polygons
polys
, associated valuesvalues
, and a polygon that we want to interpolate,p1
.In this case, we can simply execute
GO.area.(GO.intersection.(polys, (p1,), target = PolygonTrait()) ./ GO.area.(polys) .* values
with some normalization factor. However, spatially aware versions of this also exist that could be integrated into Rasters.jl.That means that area-based interpolation should probably be its own package, accepting GeoInterface geometries and potentially also RTree/STRtree objects to speed up intersection.
FeatureCollections would be decomposed to tables on input. The main entry point should probably return a GI feature. GO.reconstruct would be helpful here.
In order to get raster statistics, we could use something like
Rasters.zonal(sum, provided_data; of = polygon)
. This provides a nice accumulator interface without many allocations. We could also use Stencils.jl to do some stencilling on a fully populated raster, if that proves necessary.If we do end up using Rasters, then we must mention in many places a method by which you can create a Raster from a regular array.
The text was updated successfully, but these errors were encountered: