suggestion: include sinusoidal binning scheme

[mdsumner]

I wonder if you'd be interested to include the binning scheme used by the ocean colour group for L3?

This scheme is described here: http://oceancolor.gsfc.nasa.gov/cms/L3Bins.html

I've implemented it in simple form here, but I didn't finish the rounding out like you have in this package:
https://github.com/mdsumner/roc/blob/master/R/bins.R

It would be easy to use your grid-table approach to make these easier to work with, so that's something I'll try anyway - but it might be one to include here?

I've put the format in as a feature request to GDAL, it could be simply read in as a non-spatial table: https://trac.osgeo.org/gdal/ticket/6551 (programming the NetCDF for this format is painful but the GDAL tools are almost doing all the work already)

[r-barnes]

Since this seems to be a standardized dgg format, it seems as though we should be able to include it.

That said, I'll need to make some adaptations to the library for that to happen smoothly.

Questions:
*Does the grid only have one size of cells? If not, we would need functions to relate area, intercell spacing, and/or cls back to particular resolutions.

*Is there a way to generate the outlines of the cells? It's not the end of the world if it isn't, since statistics can still happen, but visualization is desirable.

[mdsumner]

The cell size is a function of the number of "rows", i.e. the number of latitude intervals from north to south. Typical numbers are 4320, 2160, 1080 - as in finer than you would usually plot for world scale, but you can also have much smaller numbers.

You can generate the outlines of the cells, and get area/spacing etc. The basic tools are there in my script, but I've learnt a lot recently how to do it better, and I'm keen to provide the functions needed. Glad that you're interested to include it!

[r-barnes]

Indeed, the conversion and drawing functions do seem to be there, and can be verified against the code on the OceanColor web page.

There don't seem to be functions for converting area/spacing into grid resolutions, though.

This would either need to be built or an argument made that they are not useful in practise to those who would use this kind of grid.

If such functions were built, a look-up table may be an appropriate way of handling things. However, we would need to decide what intercell spacing even means in a projection where that seems to vary considerably.

[r-barnes]

Bump.

[r-barnes]

Dang, I was just looking into this again today and the NASA website is gone.

[mdsumner]

It's here now: https://oceancolor.gsfc.nasa.gov/docs/format/l3bins/

(phew)

I'm getting back to this, I'm using rhdf5 from Bioconductor to read the compound types as data frames (so much better).

sosoc/croc#5 (comment)

I was a bit stalled as our sync-tools weren't working for ocean colour, but it turns out to just be the change to SSL afaics. We now have ready access to these files on our systems.

I've been thinking about having a generalized transform to store with tables of values, so that the cell index value passes off to whatever transform is needed, in this case a rather specialist one. Other cases could be the standard affine ones, and the raster package is awesome for driving those but it should be isolated out, and others like 1D-rectilinear and 2D-curvilinear are fairly obvious.

We could also have "rigid row-sets" that have a transform applied but no need to store an explicit index, this would work for fully-populated grids and some sparse models as well.

I think we need that abstraction rather than storing coordinates in one big table, so that visualization and binning can hold off from the fully geometry until it's really needed. At any rate I just had to push this aside for a while, but I'm keen to explore dggridR again.

Very interested to discuss this more generally.