Support sf-objects in run_qgis about rqgis

[eivindhammers]

What is the purpose of this? My code allows the user to use sf as inputs to run_qgis, and loads the processing result into R as sf if load_output is specified. I can't see a use-case for converting sp to sf prior to exporting to shapefile. Isn't the RQGIS workflow always: sf/sp input -> export to .shp -> run QGIS operation [-> import result from operation into R, sf or sp, depending on input class.]

[pat-s]

export to .shp -> run QGIS operation [-> import result from operation into R, sf or sp, depending on input class.]

The export to .shp + the import back into R would be faster if one has supplied a sp object initially.

However, if one supplied a sp object he also expects to get an sp object back in R rather than an sf object. So we would need to convert it back from sf to sp. In the end we end up with two conversions which could even make the code slower for small shapefiles which have low read/write times.
Also, we would need to change the code again if sp becomes deprecated.

Given the fact that sp should be deprecated in the future, one option could be to just write a warning to the user that one should provide a sf object instead of a sp object to speed up performance?

[eivindhammers]

I'm not sure if I understand the problem. No conversion is necessary. If user supplies sp, then writeOGR is used. If user supplies sf, then st_write is used (and vice versa when load_output is set). This lets the user choose her own r-spatial framework. If sp gets deprecated, then nothing needs to be done, except in the case when the number of sp users = 0, at which time you can remove writing/reading of sp objects.

A drawback of forcing sp/sf conversion before writing appears if one or the other adds geometry types which the other does not support.

[pat-s]

Not necessary but maybe useful to speed up heavy processing. @jannes-m could you clarify on this?

A drawback of forcing sp/sf conversion before writing appears if one or the other adds geometry types which the other does not support.

I thought both are fully compatible to each other but maybe there are still open points.

When doing so we would force the users to use sf if they want or not (performing the conversion in the background). This can introduce problems, yes. I would vote for a warning message if sp objects are provided.

[eivindhammers]

Not necessary but maybe useful to speed up heavy processing.

By this you mean the actual QGIS processing or just the preprocessing? Is the structure of the shapefiles different depending on whether it was written from a sf or sp object?

I thought both are fully compatible to each other but maybe there are still open points.

I'm not sure whether it's a likely scenario, or whether there is already a perfect mapping between them. Perhaps we should ask the sf-guys?

I think returning an sf object when the input is sp is gonna cause some confusion (unless both sp and sf is provided as inputs, then we have to pick one class of output). I would rather remove sp completely, or just let the code stand as it is now, with sf and sp coexisting, and returning and output of the same class as inputs, giving sf priority in case of multiple input classes.

But I don't think I have a vote in this :D

[tim-salabim]

In my experience, sf is much faster when reading/writing locally (see benchmark comparison here http://r-spatial.org/r/2016/09/26/future.html). AFAIK coercion between the two is fully supported and is very quick, so it may pay off to handle everything internally using sf and only convert back to sp prior to return. In mapview we have now totally abandoned sp internally (i.e. the first thing we do with an sp object is to convert to sf) and do not even return an sp object if one was injected (yet, I am not sure anyone ever actually uses the objects returned in the @object slot of mapview so I don't think it is quite as heavy an intrusion on workflow as what you have to decide here).
Another point to consider is that providing internal functions for both sp and sf is heavier on the code base.

[jannes-m]

If somebody provides an sp-object, run_qgis internally converts it into an sf-object. Since sf is the future, run_qgis loads shapefiles as sf-objects back into R (which is clearly documented in the help file). Anybody wanting sp-objects instead can either convert the sf- into an sp-object (as(x, "Spatial")) or use readOGR.

implemented in 33c137e