outline overall sp to dplyr story

[mdsumner]

We can do all the "simple" verbs as .Spatial methods by just operating on @data and returning the slightly modified object. Even summarise_ can be done by unioning all geometries.

But, as soon as we need group_by the inflexibility of @data prevents use of extended data_frames.

Natural hierarchy then is

• dplyr verbs with .Spatial methods (only goes so far)
• sp_df structures, where the fortify(ied) object table sits nested in each row
• the fortify tables can be nested further, into parts and their vertices (matches sp structures)
• turn this inside out with db_df so we can properly normalize the tables and deal with shared vertices and shared branches

sp_df is dplyr-ready simply by unnesting and re-nesting, though the geometric operations need design

db_df is nested but with incongruous tables in each row (like a db Tables table)

db_df then spawns multiple topological models:

1. Objects, Branches, Vertices (where vertices is the x, y, part-id version of fortify)
2. Objects, Branches, BxV, Vertices (with unique vertices and vertex-link-branch in BxV)
3. Objects, Primitives, Vertices (created from 2 with RTriangle, Primitives can just sit on 2)
4. Edge or face based models, planar straight line graphs

4 somehow lives between 2 and 3 I think because the PSLG is first created from the Branches - try this

[mdsumner]

This is done in main part. The rest is the gris / sptable crossover.

[mdsumner]

Working on the edge model in inst/examples/EDGES.r

[mdsumner]

move this to gris