Closed Ironholds closed 7 years ago
yeah, just checked, looks like you can have sp classes in a list
and we'd only want the sp
Spatial classes supported. There are some additional classes in rgeos
, but that requires GEOS
lib, which is what we want to avoid dealing with
Gotcha! So the classes with a matching WKT name? (e.g. Polygon?)
yeah, so
sp::SpatialPolygons
sp::SpatialPolygonsDataFrame
(this is the above just with data.frame attached I thinksp
doesn't have a multipolygon equiv. i don't think (equiv. i guess is just many polygons within one of the above 2 classes)
would be nice to be able to do more sp classes if easy enough - that way people that only need sp to WKT conversion can avoid GEOS
lib - i don't have a sense for how hard this is though
Hmn, so output format for this will be...interesting: a SpatialPolygons object can contain multiple polygons, and thence multiple WKT objects. So the options are:
Got a preference?
I imagine
SpatialPolygons
object has > 1 polygon, then convert to either MULTIPOLYGON
WKT or many POLYGON
WKT'sSpatialPolygons
objects ??
Makes sense. So then we'd end up with....
sp_convert(sp, group = FALSE)
which produces a list of vectors of WKT POLYGONS and group=TRUE producing a mixture of polygons and multipolygons. Sound good?
Yes
Can do!
So when we have a multiple-nested set of polygons within an SP - e.g. the last one here:
str(SpP@polygons)
List of 3
$ :Formal class 'Polygons' [package "sp"] with 5 slots
.. ..@ Polygons :List of 1
.. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
.. .. .. .. ..@ labpt : num [1:2] 2.7 3.55
.. .. .. .. ..@ area : num 5.5
.. .. .. .. ..@ hole : logi FALSE
.. .. .. .. ..@ ringDir: int 1
.. .. .. .. ..@ coords : num [1:5, 1:2] 2 1 4 4 2 2 4 5 3 2
.. ..@ plotOrder: int 1
.. ..@ labpt : num [1:2] 2.7 3.55
.. ..@ ID : chr "s1"
.. ..@ area : num 5.5
$ :Formal class 'Polygons' [package "sp"] with 5 slots
.. ..@ Polygons :List of 1
.. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
.. .. .. .. ..@ labpt : num [1:2] 3.67 2.33
.. .. .. .. ..@ area : num 1.5
.. .. .. .. ..@ hole : logi FALSE
.. .. .. .. ..@ ringDir: int 1
.. .. .. .. ..@ coords : num [1:4, 1:2] 5 2 4 5 2 2 3 2
.. ..@ plotOrder: int 1
.. ..@ labpt : num [1:2] 3.67 2.33
.. ..@ ID : chr "s2"
.. ..@ area : num 1.5
$ :Formal class 'Polygons' [package "sp"] with 5 slots
.. ..@ Polygons :List of 2
.. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
.. .. .. .. ..@ labpt : num [1:2] 6.13 3.93
.. .. .. .. ..@ area : num 10
.. .. .. .. ..@ hole : logi FALSE
.. .. .. .. ..@ ringDir: int 1
.. .. .. .. ..@ coords : num [1:5, 1:2] 4 10 5 4 4 5 5 2 3 5
.. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
.. .. .. .. ..@ labpt : num [1:2] 5.5 3.5
.. .. .. .. ..@ area : num 1
.. .. .. .. ..@ hole : logi TRUE
.. .. .. .. ..@ ringDir: int -1
.. .. .. .. ..@ coords : num [1:5, 1:2] 5 5 6 6 5 4 3 3 4 4
Is it acceptable to collapse the entire object into a list of coords matrices, or is there special handling needed? At that point we're talking polygons inside polygons inside polygons inside a list ;p
At least for use cases for packages we maintain, I don't think we'll need to worry about this level of complexity - I'll leave up to you to decide
Collapsing it is!
For each class of
sp
WKT object, there should be a converter that turns them into WKT.It should:
sp
object, or a List ofsp
objects (hopefully - not actually checked this is possible yet);