Change the mapping to the grid variable to something that is model agnostic

[ocefpaf]

We can identify the edge1_coordinates coordinates with sgrid.edge1_coordinates, but the actual data is associated with the original model name (in ROMS case sgrid.lon_u).

Unless I am missing something if someone wants to create a "generic" grid reader we must do:

from netCDF4 import Dataset
nc = Dataset(url)
sgrid = pyugrid.UGrid.from_nc_dataset(nc)

edges = [nc[var] for var in sgrid.edge1_coordinates]

@ayan-usgs Is that correct? Maybe instead of sgrid.lon_u and sgrid.lon_v we should have a sgrid.edges.

@rsignell-usgs Are you using pysgrid in production? How do you read your grids?

[rsignell-usgs]

@ocefpaf, your argument for sgrid.edges makes sense to me.

But I'd like to get @kwilcox opinion also.

The only application I know of that is using pysgrid right now is sci-wms, which I believe @kwilcox is focusing on this week. You could check out this routine:
https://github.com/sci-wms/sci-wms/blob/master/wms/models/datasets/sgrid.py

[ocefpaf]

If I get what @kwilcox is doing he puts all edge variables into the grid center using pysgrid.processing_2d. Which is a good decision since sci-wms focus is to serve a visualization layer.

My concern is to provide a low level API to analyse variables at the edges. Some modelers do desire that feature. See this quote from the ROMS forum:

It is more physical to draw vectors at PSI-points. It will be consistent with the physical boundaries of the domain. It will also show the behavior around Land/Sea masking, if any.

[ayan-usgs]

@ocefpaf,

Your assessment is correct. I think having sgrid.edges is a splendid idea.