Discussion: switch to sf?

[Robinlovelace]

Wondering about the costs and benefits of doing this sooner rather than later.

Thoughts @edzer? One advantage I can think of: we could refactor lots of messy sp code and learn sf in depth.

[edzer]

Way to go, Robin!

More realistically, simple features do not represent networks, so creating, managing and analyzing networks still remains to be done. An advantage would be that you can constrain to LINESTRINGs between nodes, this is something sp cannot do - it only represents MULTILINESTRINGs (which, of course, can be of length 1 - this is the current splanr approach IIRC).

[Robinlovelace]

Thanks for that - yes limiting it to LINESTRINGS will have advantages and creates a good basis for classes representing roads etc if we want to go that way (not sure we do...). One to think about anyway...

[richardellison]

I was thinking about this the other day. Networks are clearly important I think.

If we're adopting sf then we could potentially use the PostGIS topology model (that converts simple features into topologies) in some way.

[edzer]

GDAL has GNM; is that useful? Does it connect to the PostGIS topology model?

[richardellison]

I hadn't seen GNM before. It seems a driver could be written to connect GNM to PostGIS. GNM may be the more appropriate choice though as sf uses GDAL.

Is GNM consistent with the structure of sf?

[edzer]

I haven't looked into that; my assumption is that edges will be features, but a network must consist of nodes, edges, and their graph/topology.

[richardellison]

Yes, I agree that it would be most likely for edges to be features. I suppose you could add additional columns to represent the connecting nodes (anode, bnode). It would then need additional functions to calculate shortest paths, identify weights (could be yet another column), etc.

[Robinlovelace]

Suggested policy: implement all new features that are easily implementable with sf in sf then add an argument sf_out = FALSE which means we'll return an sp object by default unless the user specify otherwise. That way:

1. We don't force people to use these strange things called simple features until they're good and ready (and the package is ready for the prime time).
2. We get to learn sf Wahey.
3. The user gets faster code :)

What do you reckon to this @richardellison?

@edzer are there any issues you know of with setting sf as an import? I.e. is it a pain to install on some computers?

Possible knock-on benefit: will increase knowledge of this new paradigm for spatial data in R and encourage people to upgrade their GDAL version!

[edzer]

The MacOS ports are not yet on CRAN, meaning install.packages("sf") will not work there (Simon Urbanek's build farm is still at gdal 1.11)

[Robinlovelace]

Ah OK, makes sense for that to get sorted then I guess. Ta 4 the info.

[richardellison]

Sounds reasonable but we should wait for MacOS ports unless there is a way of only optionally including it? In other words, check if sf is installed (or available on CRAN) and if not use sp only.

[Robinlovelace]

Agreed. Good discussion. Closing for now and keep an eye open for sf Mac ports!