compatibilidad de sf::st_crs() con diferentes versiones de PROJ

Question

Estoy dando soporte a un paquete que sirve objetos {sf} usando EPSG:4326 como proyección por defecto; tengo poco control sobre la configuración que tienen mis usuarios (algunos confían en los valores por defecto, otros compilan desde el código fuente).

Me he encontrado con un problema en el que EPSG:4326 interpretado en el contexto de PROJ 4.9.3 (el estándar cuando se utilizan binarios de Windows) se ve de forma diferente a la misma proyección en el contexto de versiones superiores de PROJ.

La versión PROJ 4.9.3 de un objeto crs es

Coordinate Reference System:
  User input: EPSG:4326 
  wkt:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]

mientras que la versión PROJ 6.3.0 es ligeramente diferente:

Coordinate Reference System:
  User input: EPSG:4326 
  wkt:
GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]],
    ID["EPSG",4326]]

Esto crea todo tipo de inconvenientes ya que el st_crs(x) == st_crs(y) is not TRUE es propenso a fallar para un objeto importado de un entorno PROJ diferente.

¿Existe una forma de servir a los SIR de manera que se interprete de forma fiable lo mismo? Desconfío de reproyectar todo por razones de rendimiento.

Answer 1

Posiblemente si el CRS de un objeto tiene una no-NA $epsg entonces las dos CRS deben ser idénticas y entonces se puede asignar una a la otra si una función se queja de que la CRS de x no es la misma que la CRS de y.

En caso contrario, si la comparación de cadenas (del WKT o del proj4string) devuelve FALSE y la comparación de objetos CRS devuelve FALSE, entonces creo que estás atascado porque la comparación de objetos hace un poco de normalización con la representación de la cadena primero.

En su ejemplo anterior, ambos objetos CRS deben tener un $epsg que es 4326, por lo que se puede asignar con seguridad el CRS de uno a otro (sin reproyectar) para que tengan idéntico CRS para satisfacer cualquier prueba en una de las funciones de intersección/superposición.

Answer 2

Después de algunos ajustes descubrí que {sf} con el backend PROJ 6.3.0 aceptará objetos creados con el backend PROJ 4.9.3 sin lanzar el st_crs(x) == st_crs(y) is not TRUE (una versión inferior de PROJ arrojará este error al manejar objetos originados en una versión superior).

Así que la solución inmediata a mi problema resultó ser asegurarse de que todos los objetos compartidos se crean a través de la versión más baja de PROJ. Lo que es una especie de molestia, pero funciona.