Function to slice geometry along the boundaries of another geometry.
Example SQL (using the small spandex test data to slice parcels along block group boundaries):
with a as(
select
heather_farms.parcel_id,
heather_farms.calc_area,
heather_farms.shape_area,
heather_farms.parcel_acr,
heather_farms.shape_leng,
st_intersection(heather_farms.geom, hf_bg.geom) as geom
FROM heather_farms, hf_bg
where st_intersects(heather_farms.geom, hf_bg.geom)
), b as(
select *, st_area(geom) as icalc_area from a
)
select
parcel_id,
geom,
icalc_area/calc_area*shape_area as shape_area,
icalc_area/calc_area*parcel_acr as parcel_acr,
icalc_area/calc_area*shape_leng as shape_leng
from b
This function will typically be applied in the context of parcels. Post-slice child parcels will be assigned field values from the parent parcel, with the user specifying fields for which parent value is taken as is and fields for which the parent value is allocated to the children weighted by area. In the example above, parcel_id is taken from the parent parcel as is, and shape_area/parcel_acr/shape_leng are allocated by area.
Options for preventing slivers will be provided. For parcel slices that result in slivers, the parent parcel is left intact. Slivers can be defined by area (e.g. area < 500) and/or by shape (e.g.((perimeter/4.0)/sqrt(area)) > 2).
Parcels will be sliced so that boundaries align with those of key summary geographies and control geographies. Summary geographies are any geography that simulation results will be summarized at (i.e. disaggregate agents will be aggregated to this level). Slicing parcels along key boundaries ensures a clean accounting of land: parcels will nest cleanly within higher level geographies. This is also useful during imputation- when small area control totals are to be met, but parcel boundaries don’t align with the control boundaries, unintended side-effects can result.
The key idea is: geography.aggregate(parcel.land_area) should equal geography.land_area. Examples of situations encountered in the past where parcel slicing is useful: block-level controls are desired but block boundaries are frequently inconsistent with parcel boundaries, zonal boundaries bisect a set of parcels so the parcels are sliced to ensure a clean accounting of land up to the zone level (a key summary geography); zonal boundaries are smaller than parcels in an area with a very large parcel (so that some zones contain zero parcels and are thus undevelopable) and the large parcel is sliced up into smaller parcels corresponding to zone boundaries; a control geography contains a few parcels in their entirety and a number of other parcels where a significant proportion of their land area overlaps with the control geography but the centroid of those parcels does not fall within the control geography- when replicating agents/buildings to match the geography’s control total the resulting agents/buildings are allocated to sliced parcels so they do not get artificially stuffed into the few parcels that are entirely within the boundary.
Slicing and reshaping parcels appropriately has implications for the correct calculation of other spatial operations like proportion_overlap.
Function to slice geometry along the boundaries of another geometry.
Example SQL (using the small spandex test data to slice parcels along block group boundaries):
This function will typically be applied in the context of parcels. Post-slice child parcels will be assigned field values from the parent parcel, with the user specifying fields for which parent value is taken as is and fields for which the parent value is allocated to the children weighted by area. In the example above, parcel_id is taken from the parent parcel as is, and shape_area/parcel_acr/shape_leng are allocated by area.
Options for preventing slivers will be provided. For parcel slices that result in slivers, the parent parcel is left intact. Slivers can be defined by area (e.g. area < 500) and/or by shape (e.g.((perimeter/4.0)/sqrt(area)) > 2).
Parcels will be sliced so that boundaries align with those of key summary geographies and control geographies. Summary geographies are any geography that simulation results will be summarized at (i.e. disaggregate agents will be aggregated to this level). Slicing parcels along key boundaries ensures a clean accounting of land: parcels will nest cleanly within higher level geographies. This is also useful during imputation- when small area control totals are to be met, but parcel boundaries don’t align with the control boundaries, unintended side-effects can result.
The key idea is: geography.aggregate(parcel.land_area) should equal geography.land_area. Examples of situations encountered in the past where parcel slicing is useful: block-level controls are desired but block boundaries are frequently inconsistent with parcel boundaries, zonal boundaries bisect a set of parcels so the parcels are sliced to ensure a clean accounting of land up to the zone level (a key summary geography); zonal boundaries are smaller than parcels in an area with a very large parcel (so that some zones contain zero parcels and are thus undevelopable) and the large parcel is sliced up into smaller parcels corresponding to zone boundaries; a control geography contains a few parcels in their entirety and a number of other parcels where a significant proportion of their land area overlaps with the control geography but the centroid of those parcels does not fall within the control geography- when replicating agents/buildings to match the geography’s control total the resulting agents/buildings are allocated to sliced parcels so they do not get artificially stuffed into the few parcels that are entirely within the boundary.
Slicing and reshaping parcels appropriately has implications for the correct calculation of other spatial operations like proportion_overlap.