Create function to aggregate OD data based on spatial zones / points / ids about stplanr HOT 7 CLOSED

Links to discussion here npct/pct-shiny#450 and discussion with @mpadge.

Key part:

Overall we need new functions for aggregating flows based on underlying geometries. Imagine you have an OD level dataset called flow_oa of travel patterns at the OA-WPZ (as we do) and we want to aggregate to the the LSOA-WPZ level (as we may want to do). I'm imagining a function like this:

aggregate.od <- function(od_highres, od_lowres, FUN) {...}

This is moving towards the utility of a class for od data discussed with Richard Ellison in the attached paper, because all ODs would have attached geometries of origins and destinations, making aggregation possible using one method or another. In our use case you would say say:

flow_lsoa_agg = aggregate.od(flow_oa, flow_lsoa, sum)

Note there is a commercial product that does a similar thing: https://saspac.org/

from stplanr.

Also links to this: npct/pct-shiny#291

from stplanr.

As I commented in npct/pct-shiny#450 I think it would be most generalisable if we adopt the geos functions to first generate concordance tables (with proportionate areas) and then use that to aggregate to the more aggregate geographic boundaries.

As an initial version, perhaps simplest to just do this in the most straightforward manner possible and rely on the user to ensure their boundaries are sufficiently accurate to not have too much spillover along boundaries. Some of the code in the calc_catchment functions might be useful as it (effectively) does exactly the same operation except instead of doing it on a polygon layer that covers the same area it just does it for the buffer.

from stplanr.

OK - would you like to create a 1st attempt @richardellison? Or I can. Thanks.

from stplanr.

I should be able to have a go this weekend. What do you want to call the function? aggregate.od as above or od_aggregate?

from stplanr.

od_aggregate for sure in the first instance. If it's a generic function, it would not be visible to the user. Look forward to testing it and makes me think, at some point we should explore a class definition for OD data, probably incorporating tibble and sf but that's certainly for another weekend/week/month/year!

from stplanr.

Closed by @richardellison here: Robinlovelace@4728f43

from stplanr.