Add ability to use a non WKTid based crs when calling esri2sf()
jacpete opened this issue · 3 comments
I am adding in a copy of my findings after working on #25 below. Essentially without requiring the user to download and install an external copy of GDAL (outside of the the binaries that ship with/ or are linked to with the {sf} package or trying to package it with this library, I think the solution will be to do a feature request to the {sf} package to get an interface to convert any GDAL compatible CRS to an ESRI WKT. When I get the issue made for {sf} I will link it below so that we can track it. I will probably try to tinker with doing the pull request for the {sf} package myself, but I have never worked with C++ before so it will probably be quite the learning curve. In the meantime the esri2sf() crs argument can only accept WKTid's unless anyone has a different solution.
So I've been working on a pull request for this issue and I am hitting a small snag. For the outSR parameter in getEsriFeaturesByIds() ESRI's query format (https://developers.arcgis.com/rest/services-reference/enterprise/query-feature-service-layer-.htm) requires the input to be either a WKTid or spatial reference JSON object that can be formatted to contain an ESRI wkt. In my testing and research, the ESRI wkt is different than the normal OGR WKT generally given by R, but GDAL does have the power to convert to it. What I am looking for now is a way to interface with the GDAL library linked in R through the {sf} package. On linux this is pretty easy because GDAL is compiled and installed separately from the sf install, but on Windows (and I think OSX but I don't run this OS to test) the GDAL library is compiled and installed with the {sf} binaries and it makes it difficult to interface with the GDAL library directly.
Without a way to link to GDAL, we will be limited in our inputs for the crs argument. We will have to restrict it to only using WKTids These can be either EPSG or ESRI authority WKTids though as the ESRI query format seems to be able to handle either without direct specification. However, sf::st_sf() does require direct specification so I added a helper (hidden) function getWKTidAuthority to do a direct query to the proj.db SQLite database in the PROJ library linked to by the {sf} package. This function adds imported dependencies for the {DBI} and {RSQLite} packages which were imported or suggested by {sf} already.
https://github.com/jacpete/esri2sf/blob/62c6e8a3368d1fe9bfe24e400110d5e8606e3fe8/R/zzz.R#L149-L172
To extend the function to be able to accept any crs format you can generally use in R (e.g., proj4string, WKT, numeric EPSG) there will need to be an interface directly to the GDAL gdalsrsinfo command line tool (I think it may be easiest to create and issue in {sf} to extend sf::gdal_utils() for this one; https://gdal.org/programs/gdalsrsinfo.html) or improve the {Rccp} interface to exportToWkt C++ API (https://gdal.org/api/ogrspatialref.html#_CPPv4NK19OGRSpatialReference11exportToWktEPPcPPCKc) with an option to specify the FORMAT parameter and create an exported R function to control it. While I think the implementation of the first option may allow slightly easier access to the functionality, I think the addition of the second may already be being discussed by package authors (see comment on line 115 of code from {sf} below.
https://github.com/r-spatial/sf/blob/405ca1ca4ebdbd5672948aea88251e5d12004740/src/gdal.cpp#L115-L128
Originally posted by @jacpete in #25 (comment) #25
@edzer got to this super quick and added in the functionality to {sf} with this commit. I will work on another pull request to add this functionality into the esri2sf() function. For now, the change will need access to the development version of sf installed with remotes::install_github("r-spatial/sf") but should be in an upcoming {sf} update to CRAN.
but should be in an upcoming {sf} update to CRAN.
Yes, 1.0-1 (1.0-0 is in the queue).