Home for CRS objects?

[paleolimbot]

@edzer - Any chance I can convince you to house CRS objects here? I haven't quite gotten this to pass the CMD check (complains about .hpp files and missing sqlite3), but it compiles on my machine without errors or warnings. It has an internal copy of PROJ7, which might allow all platforms to access the latest and shiniest PROJ. I'd prefer to use your CRS object than make a new one with converters!

[edzer]

@paleolimbot I'm not sure that could work out, and whether you'd want that - sf interfaces with PROJ through GDAL; only GDAL can transform/convert simple features, PROJ has no knowledge of that. Also, we use PROJ as a system requirement, so you can work with systems that have a set of dynamic libraries shared with other spatial software (QGIS, PostGIS and so on). Only windows and OSX builds get the whole bunch built-in, statically linked, fool-proof.

[paleolimbot]

Got it! I'll keep this experimental.

[paleolimbot]

How about a standalone package maybe "crsdef"? That contains the CRS definition? This package would be more like an "engine" (sf would also be an engine).

[edzer]

Would that package only contain the crs definitions, or also do the transformations & conversions? One other thing to take into account is axis order, see e.g. https://www.r-spatial.org/r/2020/03/17/wkt.html#axis-order , but rgdal handles that at the PROJ level, I believe. Don't see this as discouragement - it would be great if not all packages using GDAL and PROJ would come with their own PROJ/GDAL/GEOS copies for win+osx CRAN binaries, as they now do, but getting there from where we are now may not be trivial.

[paleolimbot]

Just definitions, I think. Without a copy of PROJ or GDAL it wouldn't be able to completely validate, but it could probably at least validate the type/format. From the PR you referenced earlier it sounds like the new CRS object is just storing the user input and auto-generating the other info on the fly.

Off the top of my head, the functions crs_wkt(x, axis_order), crs_srid(x, axis_order), and crs_proj4(x, axis_order) seem like they might be useful without a copy of PROJ or GDAL.

I'm happy to write that up as a package if it seems like it's useful!

[edzer]

Where are these functions hosted?

PROJ is software around a central sqlite3 database, now in proj.db, on my system /usr/share/proj/proj.db - as long as you don't ship that, this package can't do much I'd say; that database may provide things like EPSG -> wkt mappings, but proj4string -> wkt are parameterized, so may need the PROJ the software too.

[paleolimbot]

I did some experimenting...I think quite a bit as possible without installing PROJ. You can cache the crs_view table and the result of projinfo -o for all the known authorities/code combos in a little less than 2MB (gzipped). See https://github.com/paleolimbot/geocrs#example for what might be possible.

(not offended if this is foolhardy or makes your implementation difficult, but I think that a zero-dependency package that just does CRSes is possible and might be nice if it can be done well)

[edzer]

Nice!! I see nothing against this if this is what users want / if this solves problems (whether yours or others'); do also look at the PROJ and proj4 packages on CRAN. I do see the potential issue of yet another stand-alone software+database package that can run (or be) out of sync with other R packages expecting to be in sync, or other non-R parts of your system (PostGIS, QGIS, ...) people work with.

[paleolimbot]

I envision these objects as communicating intent...resolving proj4 and WKT + partial validation and pretty error messages would mostly be about convincing maintainers to use them. In all cases, the input would be interpreted by the sfs, rasters, rgdals, and sps of the R universe.