Skip to content
Prev 28579 / 29559 Next

Not perfect match between the bounding box for a EPSG when projected (st_bbox from sf)

On Thu, 25 Mar 2021, Manuel Sp?nola wrote:

            
No. Firstly, epsg.io is not an EPSG service. Secondly, two different 
definitions are offered. I think that this works (sf 0.9-8):

pts1 <- st_sfc(list(st_point(c(-90.45, 2.15)), st_point(c(-81.43,
  11.77))), crs="OGC:CRS84")
st_transform(pts1, "EPSG:5367")
# POINT (-218962 239233.5)
# POINT (780173.7 1302793)
o <- sf_proj_pipelines("OGC:CRS84", "EPSG:5367")
o$definition
st_transform(pts1, "EPSG:5367", pipeline = o$definition[1])
# POINT (-218962 239233.5)
# POINT (780173.7 1302793)
# Costa Rica - onshore and offshore, accuracy 1.0 m, code 8969 [grid] 
st_transform(pts1, "EPSG:5367", pipeline = o$definition[2])
# POINT (-218963 239235.1)
# POINT (780173.6 1302794)
# Costa Rica - onshore and offshore, accuracy 1.0 m, code 5376 (default) 
# [grid]

So, as in https://github.com/r-spatial/sf/issues/1634, treating epsg.io as 
authoritative (especially when there are different transformation 
pipelines in play) may be unhelpful.sf/PROJ chooses a different pipeline 
as default than epsg.io.

This roundtrips:

st_transform(st_transform(pts1, "EPSG:5367"), "OGC:CRS84")
# POINT (-90.45 2.15)
# POINT (-81.43 11.77)
# Costa Rica - onshore and offshore, accuracy 1.0 m, code 8969 [grid]

but for epsg.io's default, one needs to intervene manually to choose 
pipelines both ways that are not sf's default choices.

Of course, here I am not using the bounding box polygon, because its 
projected version is not a rectangle, so its bounding box expands the 
range, especially further from the equator.

Hope this clarifies,

Roger