Open ateucher opened 7 years ago
Not sure. I don't know my proj.4 inside and out. Is there a best practice to include (or not) the epsg codes? Might be good to have those included as we could write a functions that return the proj.4 for instance in the example above their might be a shortcut bc_albers() AND a epsg_3005() with the later being generated automatically.
I think they should be included. I know I've grepped for them before... and looking up a code is a lot easier than trying to figure out all of the other parameters in the string, which leave my head spinning!
I had the same thought of having an alias epsg_*()
for each of the named projections.
Like:
#' BC Albers Equal Area Projection proj.4 string
#'
#' Function that provides a proj.4 string for the BC Albers projection (EPSG code 3005).
#'
#' \href{http://epsg.io/3005}{BC Albers on epsg.io}
#'
#' @export
bc_albers <- function() {
"+init=epsg:3005 +proj=aea +lat_1=50 +lat_2=58.5 +lat_0=45 +lon_0=-126 +x_0=1000000 +y_0=0 +datum=NAD83 +units=m +no_defs +ellps=GRS80 +towgs84=0,0,0"
}
#' @rdname bc_albers
#' @export
epsg_3005 <- bc_albers
My (incomplete) understanding is that if you have EPSG, just use that since you can always look up its params with rgdal::CRSargs or sf::st_crs. PROJ.4 is good because you can construct custom projections with all required params arbitrarily. In general any PROJ.4 string won't have an EPSG code, because they are infinite in possible configurations and only so many codes have been registered. In practice many will correspond to a code though, because custom construction is pretty rare.
Have you explored rgdal's make_EPSG?
https://epsg.io provides a dead simple REST/JSON API to query projections by epsg ID. What's more it's open source https://github.com/klokantech/epsg.io. It might be worth while integrating this API with the package so that people can use it to look up many more proj4 defns. using just the epsg codes.
Something akin to
# Return the complete JSON
query_epsgio <- function(epsgCode, url='https://epsg.io/'){
res <- httr::GET(sprintf(
"%s?q=%s&format=json", url, epsgCode))
if(res$status_code==200) {
return(httr::content(res))
} else {
warning(sprintf(
"Error querying EPSG code %s, Server returned %d:%s",
epsgCode, res$status_code, httr::content(res)))
return(NULL)
}
}
# The proj4 string can be extracted
res <- query_epsgio('4326')
res$results[[1]]$proj4
Oh and wrap that function call with memoise::memoise
so as to avoid unnecessarily requerying the same code.
Thanks @bhaskarvk ! This is a nice solution. I'll wrap it in next chance I get. May add a bit to it and have it return the proj4 string instead of the GET response.
Cool, I also kinda like that the API returns the bbox, which I can take and use in leaflet::setBounds
. So may be haev a bit of flexibility in the function to return the whole JSON or a specific object like the proj4 string.
Maybe an argument to return the full JSON with default of string only...
Other idea is standalone epsgio package... Keep this as simple shortcuts that uses epsgio package to harvest the proj4 strings?
No hard preferences, whatever others feel is the best option.
Got a start (well a DESCRIPTION at least) over at https://github.com/jhollist/epsgio. Need to spend some time with the API to get a feel for all that it does, but looks useful enough to have it's own package. Added you as an author, @bhaskarvk. My time this summer to work on this will be very spotty (in the field!), but hey its a start!
Do you want to include the epsg codes as part of the string? E.g.:
"+init=epsg:3005 +proj=aea +lat_1=50 +lat_2=58.5 +lat_0=45 +lon_0=-126 +x_0=1000000 +y_0=0 +datum=NAD83 +units=m +no_defs +ellps=GRS80 +towgs84=0,0,0"
vs
"+proj=aea +lat_1=50 +lat_2=58.5 +lat_0=45 +lon_0=-126 +x_0=1000000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"
I find them useful...