Error with CRS check

[alvitello]

Hi -- I'm having this issue when trying to run Banks to Centerline and Centerline Migration in QGis 3.6.3:

[1] "C:/Program Files/R/R-3.5.3/library/sf" Linking to GEOS 3.6.1, GDAL 2.2.3, PROJ 4.9.3 [1] "C:/Program Files/R/R-3.5.3/library/raster" Loading required package: sp Error in identicalCRS(Original, Final) : unable to find an inherited method for function 'proj4string' for signature '"sf"' Calls: stopifnot ... tryCatch -> tryCatchList -> tryCatchOne -> Execution halted

I've double-checked in R to have all the packages installed and updated, but still got the same result. Tried different files (some of them already analyzed some times ago). Thanks

[mlt]

That is odd as that check was there for a long time. The quick workaround is to comment out that line. It is there to check whether there is no mix up between coordinate systems as files can come from different sources and one may forget to re-project or something. I'll look into details.

At the first glance it looks like there is some sort of mixup with sp vs sf packages https://gis.stackexchange.com/q/307432/7795 . I do not recall ever dealing with sf but solely sp. Though it has been a while...

Seems like other set of functions shall be used https://r-spatial.github.io/sf/reference/st_crs.html Looks like the 2 packages are not compatible however it seems that this might be a workaround to convert it back to Spatial.

[alvitello]

Yeah I tried that but got the same error from the other line where the same function is called. I will have a look at the workaround you just posted. Thanks meanwhile

[alvitello]

Hi Mikhail -- I've been working around a bit on the code, but I can't still figure out why is not working properly in QGIS 3.6.3-Noosa (it does work smoothly in Qgis 2.8 Wien though).

As far as I understand, the vectors are intrpreted as "sf" object (instead of "sp" object) in Qgis 3.6.3, and that should cause the issue with the identicalCRS call (as well as all the other call for function related to the sp package).

What is strange thoug is that the code works perfectly in R, as I try what follows (example files attached to this email):

library(sp) library(rgdal)

Original <- readOGR('t0_line.shp') Final <- readOGR('t1_line.shp')

Years <- 1 spar <- .4 Curvature_multiplier <- 1e5 Step_pattern <- 'symmetricP05' Step <- 50

source('rscripts/Channel migration.rsx') writeOGR(Migration, '.', "migration", driver='ESRI Shapefile')

So it seems that the problem is with the Qgis Rscript. Apparently, it should be enough to tell the script that the input vectors are sp (instad of sf) objects, which should be easy but I can't figure out how to to it. Any suggestions are really appreciated. Thanks a bunch. Alvise

Il 08/11/2019 22:43, Mikhail Titov ha scritto:

That is odd as that check was there for a long time. The quick workaround is to comment out that line https://github.com/mlt/QGIS-Processing-tools/blob/master/rscripts/Channel%20migration.rsx#L15. It is there to check whether there is no mix up between coordinate systems as files can come from different sources and one may forget to re-project or something. I'll look into details.

At the first glance it looks like there is some sort of rework on sp/sf package internals. https://gis.stackexchange.com/q/307432/7795 . I do not recall ever dealing with /sf/ but solely /sp/. Though it has been a while...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mlt/QGIS-Processing-tools/issues/2?email_source=notifications&email_token=ALSEIXUFRJ7FJZYNNAWUR4TQSXMQXA5CNFSM4JKXQWWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDTNY6A#issuecomment-552000632, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSEIXSY5MJVX2VUIC43BKTQSXMQXANCNFSM4JKXQWWA.

--

Finotello Alvise Postdoctoral Research Fellow Dept. of Geosciences University of Padova via G.Gradenigo, Padova IT-35131 skype: alvise.fino

[alvitello]

Ah sorry -- I forgot to mention that I tried this workaround at the beginning of the Centerline migration code to switch from sf back to sp:

Vector processing=group

Start=vector

End=vector

Years=number 1

Migration=output vector

spar=number .4

Curvature_multiplier=number 1e5

Min_curvature=number 1e-3

Step_pattern=string symmetricP05

Step=number 25

library(dtw)

Original<-sf:::as_Spatial(Start$geom) Final<-sf:::as_Spatial(End$geom)

So I got rid of the issue with identicalCRS, the script seems to to work (I get the "Merging results" message) but then I get this error:

"Loading required package: sp Performing alignment... Generating migration lines... Merging results Error in UseMethod("st_write") : no applicable method for 'st_write' applied to an object of class "c('SpatialLinesDataFrame', 'SpatialLines', 'Spatial', 'SpatialVector')" Calls: st_write Execution halted"

which I cannot get rid of. A

Il 17/12/2019 15:45, Finotello Alvise ha scritto:

Hi Mikhail -- I've been working around a bit on the code, but I can't still figure out why is not working properly in QGIS 3.6.3-Noosa (it does work smoothly in Qgis 2.8 Wien though).

As far as I understand, the vectors are intrpreted as "sf" object (instead of "sp" object) in Qgis 3.6.3, and that should cause the issue with the identicalCRS call (as well as all the other call for function related to the sp package).

What is strange thoug is that the code works perfectly in R, as I try what follows (example files attached to this email):

library(sp) library(rgdal)

Original <- readOGR('t0_line.shp') Final <- readOGR('t1_line.shp')

Years <- 1 spar <- .4 Curvature_multiplier <- 1e5 Step_pattern <- 'symmetricP05' Step <- 50

source('rscripts/Channel migration.rsx') writeOGR(Migration, '.', "migration", driver='ESRI Shapefile')

So it seems that the problem is with the Qgis Rscript. Apparently, it should be enough to tell the script that the input vectors are sp (instad of sf) objects, which should be easy but I can't figure out how to to it. Any suggestions are really appreciated. Thanks a bunch. Alvise

Il 08/11/2019 22:43, Mikhail Titov ha scritto:

That is odd as that check was there for a long time. The quick workaround is to comment out that line https://github.com/mlt/QGIS-Processing-tools/blob/master/rscripts/Channel%20migration.rsx#L15. It is there to check whether there is no mix up between coordinate systems as files can come from different sources and one may forget to re-project or something. I'll look into details.

At the first glance it looks like there is some sort of rework on sp/sf package internals. https://gis.stackexchange.com/q/307432/7795 . I do not recall ever dealing with /sf/ but solely /sp/. Though it has been a while...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mlt/QGIS-Processing-tools/issues/2?email_source=notifications&email_token=ALSEIXUFRJ7FJZYNNAWUR4TQSXMQXA5CNFSM4JKXQWWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDTNY6A#issuecomment-552000632, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSEIXSY5MJVX2VUIC43BKTQSXMQXANCNFSM4JKXQWWA.

--

Finotello Alvise Postdoctoral Research Fellow Dept. of Geosciences University of Padova via G.Gradenigo, Padova IT-35131 skype: alvise.fino

--

Finotello Alvise Postdoctoral Research Fellow Dept. of Geosciences University of Padova via G.Gradenigo, Padova IT-35131 skype: alvise.fino

[mlt]

Indeed, most of the time I used these scripts lately, it was outside of QGIS. So I never came across this issue. I tend to agree that QGIS Processing for R switched to SF package internally. IIRC there is no explicit write statement when using QGIS unlike when working directly in R.

The best approach from now on is for me to adjust scripts accordingly as SF gets widely adopted. I'll look into it. Meanwhile, you can try to cast back results from sp to sf at the very end of each scripts that you use.

[alvitello]

Thanks Mikhail -- I've followed your suggestions and I've been able to get the "Banks to Centerline" and "Channel Migration" scripts to work with very limited fixing - just converting the vector back and forth from sp to sf. I've attached the scripts.

Thanks a lot for your kind suggestion.

Alvise

P.s.: have you ever considered writing a brief paper on this methodology for computing meandering channel migration? I don't know why it has been overlooked for so long, but it is becoming the state of the art technique and I think you should get full credit for applying the dtw to river geomorphology. Not sure if you'd be interested in this, but I know for sure that I would cite this a lot in the near future, and the same goes for other people I collaborate with which are as much enthusiastic as I am about this methodology. Let me know what you think, and thanks again.

Il 17/12/2019 20:36, Mikhail Titov ha scritto:

Indeed, most of the time I used these scripts lately, it was outside of QGIS. So I never came across this issue. I tend to agree that QGIS Processing for R switched to SF package internally. IIRC there is no explicit /write/ statement when using QGIS unlike when working directly in R.

The best approach from now on is for me to adjust scripts accordingly as SF gets widely adopted. I'll look into it. Meanwhile, you can try to cast back results from sp to sf at the very end of each scripts that you use.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mlt/QGIS-Processing-tools/issues/2?email_source=notifications&email_token=ALSEIXVGA7FAJ34FKB6CTTTQZES3JA5CNFSM4JKXQWWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHDWMNQ#issuecomment-566715958, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSEIXQTANGYRZ5J263TIK3QZES3JANCNFSM4JKXQWWA.

--

Finotello Alvise Postdoctoral Research Fellow Dept. of Geosciences University of Padova via G.Gradenigo, Padova IT-35131 skype: alvise.fino