[R-sig-Geo] general GDAL engagement

[Michael Sumner]

Hello,

I just want to send a general note of encouragement to R folks to engage
more closely with the GDAL development project.

GDAL is used heavily in terra and sf and vapour and gdalcubes. It provides
read and write access to many many file and url and database formats,
amongst many other facilities.

Sometimes, there are features in R that can be made redundant because of
changes in GDAL, an example is this file mentioned in the related github
issue:

If you've got useful information about files that could be used to improve
GDAL, please share it on the gdal-dev mailing list, or as bug reports on
the GDAL issues on github. If you need assistance or aren't sure I'm very
happy to help too.

Here's two examples.

1)

In R, terra knows this file is longitude/latitude because it has internal
heuristics (the data projection metadata is not set, but the data lives
with longitudes -180, 360 and latitudes -90, 90 (or near enough):

terra::crs(terra::rast("NetCDF:oisst-avhrr-v02r01.20220218.nc:sst"))
[1] "GEOGCRS[\"WGS 84 (CRS84)\",\n    DATUM[\"World G

In sf and stars, it's not known because sf is more faithful to what GDAL
provides (this file is non compliant to whatever convention, it's a very
common situation because some domains assume "longlat" is just obvious).

sf::gdal_read("NetCDF:oisst-avhrr-v02r01.20220218.nc:sst", read_data =
F)$crs
Coordinate Reference System: NA

In GDAL 3.7.0 when that rolls out across R, both sf and terra will get the
same valid crs information from GDAL if the
option GDAL_NETCDF_ASSUME_LONGLAT=YES is set.


2) GRIB is a wild and wonderful format, and when it uses map projections
sometimes the metadata is completely screwed up  - for too long I worked
around this in R, but a simple bug report on thegithub issues saves a whole
of of pain and extra code on the R side:

https://github.com/OSGeo/gdal/issues/7298


These examples represent one of many tiny details that users encounter in
many places. Please take the time to report these issues to GDAL, sometimes
effort that goes into downstream packages on CRAN won't make it further up
the chain, which is a shame - because, it might be fixed in R, but if it
were fixed in GDAL it'll also be fixed in Python, QGIS, and many other
applications.

There are many ways to contribute beyond simply sharing files and output of
course, improving the documentation, fixing bugs - if you're interested in
this and want to discuss I'm also happy to help.

The file I used in the example above is posted in the related GDAL PR (pull
request):

https://github.com/OSGeo/gdal/issues/6195

All the best!

Mike


-- 
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner using gmail.com

	[[alternative HTML version deleted]]