Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slice function #22

Open
janowicz opened this issue Sep 12, 2014 · 0 comments
Open

Slice function #22

janowicz opened this issue Sep 12, 2014 · 0 comments

Comments

@janowicz
Copy link
Contributor

Function to slice geometry along the boundaries of another geometry.

image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant