Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

addLocalFile fails (on GDAL3/PROJ6) #6

Closed
lbusett opened this issue Dec 9, 2019 · 6 comments
Closed

addLocalFile fails (on GDAL3/PROJ6) #6

lbusett opened this issue Dec 9, 2019 · 6 comments

Comments

@lbusett
Copy link
Contributor

lbusett commented Dec 9, 2019

On a recently updated system with GDAL3/PROJ6, this currently fails:

destfile = tempfile(fileext = ".gpkg")

st_write(st_as_sf(gadmCHE), dsn = destfile)

leaflet() %>%
  addTiles() %>%
  leafem::addLocalFile(destfile)

with:

Error in CPL_proj_is_valid(p4s) : 
  Expecting a single string value: [type=character; extent=3].
In addition: Warning message:
In if (is.na(x)) NA_crs_ else if (inherits(x, "crs")) x else if (is.numeric(x)) CPL_crs_from_epsg(as.integer(x)) else if (is.character(x)) { :
 
 Error in CPL_proj_is_valid(p4s) : 
  Expecting a single string value: [type=character; extent=3]. 

, because:

prj = gdalUtils::gdalsrsinfo(file, o = "proj4")

gives:

 prj
[1] ""                                    "+proj=longlat +datum=WGS84 +no_defs"
[3] ""  

This could be solved substituting:

prj = gdalUtils::gdalsrsinfo(file, o = "proj4") 

with, for example,

 prj = sp::CRS(rgdal::ogrInfo(file)$p4s)

Although this would require adding rgdal as an import, I think it would also allow to more easily introduce PROJ6 workflows based on WKT strings (r-spatial/discuss#28)

@tim-salabim
Copy link
Member

tim-salabim commented Dec 9, 2019

@lbusett thanks for testing this under GDAL3/PROJ6! Very much appreciated!

Wouldn't something like

prj = prj[grep("+proj=", prj)]

be enough though?

@tim-salabim
Copy link
Member

@lbusett I just pushed the (my) proposed change. Could you please re-test on GDAL3/PROJ6 to see if it solves the issue?

@lbusett
Copy link
Contributor Author

lbusett commented Dec 9, 2019

Yeah, I guess that should work and is much simpler - I'll test tomorrow on Linux.
I thought that it would not work on both PROJ4 and PROJ6, so I was proposing the rgdal solution, also because that would give access to the WKT strings needed for PROJ6 reprojection workflows. However, I now noticed that, since reprojection here is based on system calls to ogr2ogr, that would not probably be needed.

@lbusett
Copy link
Contributor Author

lbusett commented Dec 10, 2019

@tim-salabim

tested now: I confirm this works also on GDAL3/PROJ6. CLosing here.

@lbusett
Copy link
Contributor Author

lbusett commented Dec 12, 2019

@tim-salabim

heads-up for this, potentially giving problems for the use of ogr2ogr on windows machines with GDAL 3:

r-spatial/discuss#31

@tim-salabim
Copy link
Member

@lbusett thanks for the heads-up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants