Comments (7)
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.]
from rqgis.
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?
from rqgis.
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.
from rqgis.
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.
from rqgis.
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
from rqgis.
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.
from rqgis.
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
from rqgis.
Related Issues (20)
- RQGIS doesn't recognize SAGA HOT 17
- GRASS7 needs to be installed after QGIS2 HOT 1
- run_qgis() fails silently when OUTPUT not specified and load_output = TRUE HOT 4
- "argument "type_name" is missing, with no default" HOT 2
- ERROR 4 on temporary SAGA files when RQGIS is run inside a function HOT 1
- Unable to open EPSG support file gcs.csv HOT 2
- using RQGIS when LTR is 3.4.6 install on computer HOT 1
- Module '__main__' has no attribute 'RQGIS3' HOT 2
- Python2 support on Homebrew HOT 2
- error in accessing QGIS functionality in R HOT 1
- Errors arising when trying to use files on network as function inputs HOT 4
- Extent mismatch between SAGA through (1) RQGIS and (2) RSAGA (but RSAGA matches the input) HOT 4
- grass7:i.segment does not finish HOT 6
- Error in "grass7:r.neighbors" with method = "6" - sum using raster with NA-values HOT 3
- NA-Bug? HOT 4
- configuration help on macOS high sierra with homebrew osgeo HOT 9
- ERROR in using saga:resampling via RQGIS (but in QGIS it is working) HOT 5
- Producing outputs in loops stops after certain iterations HOT 9
- QGIS3 Support? HOT 11
- v.rast.stats doesn't add a new column HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rqgis.