NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Chris, You are correct that this is not a sparse matrix at this point in the discussion. I began thinking of my data as on a (lon,lat) grid but only a few percent of the total grid cells were occupied. Since then I've changed my mental representation and the file structure on disk, but not the subject of this thread. -k. On Mon, Mar 25, 2019 at 9:24 AM Chris Barker - NOAA Federal < chris.barker@xxxxxxxx> wrote: > I’m a bit confused about exactly how this data is structured— you used the > word “sparse”, but I don’t think it’s sparse in the sense of “sparse > matrix” — that would be data on a rectangular grid, where most of the > values are zero. If that is the case, than storing it as a full array and > compressing it would be a good way to go. (Other than compression, I don’t > know if s standard say to store sparse arrays— maybe there should be one? > > But, if rather than a regular grid with missing or zero values, what you > have is data at essentially arbitrary locations, then “discrete geometries” > may make sense. But another option is to consider the data as an > unstructured grid, and use the UGRID convention: > > > https://github.com/ugrid-conventions/ugrid-conventions/blob/master/README.md#ugrid-conventions > > Note that you can use it with only points— it doesn’t need to specify the > mesh itself. > > This would make sense if you have: > > A time series of data at each point — that is the locations are constant > in time. Ideally, the data would be at the same times at all locations. > That is, structured in time, but not in space. > > In that case, your locations would be the nodes, and you’d have a time > coordinate, and then the data itself would be in a (time, node_num) indexed > array. > > HTH, > > Chris > > On Mar 25, 2019, at 8:17 AM, Ken Mankoff <mankoff@xxxxxxxxx> wrote: > > Hi Robert! > > I hope all is well at GISS. > > On 2019-03-18 at 20:30 -0700, Schmunk, Robert B. (GISS-611.0)[SciSpace > LLC] <robert.b.schmunk@xxxxxxxx> wrote... > > Pursuant to Dave’s suggestion, check out the CF convention for netCDF > > metadata. In particular see section 9 on discrete sampling geometries, > > and its discussion of the timeSeries featureType at multiple > > locations. > > > Appendix H.2.1 shows example CDL notation for an case that sounds > > fairly similar to what you are looking for. > > > Yes, I had found that and am modeling my data format after H2.1: > > > http://cfconventions.org/cf-conventions/cf-conventions.html#_orthogonal_multidimensional_array_representation_of_time_series > > But I have a Panoply-specific question related to this data. When open the > file I'm creating in Panoply, runoff variable type is "2D" and dimension > are "cat" and "time", and the Panoply-displayed info is: > > double runoff(time=365, cat=31240); > :units = "m3 s-1"; > :long_name = "RACMO runoff"; > :standard_name = "water_volume_transport_in_river_channel"; > :description = "..." > :_ChunkSizes = 1U, 31240U; // uint > > I'd like to also be able to plot data on (lon,lat). If I add > > :coordinates = "lon lat" > > then the data is "Geo2D", but I can only make a "longitude-time" > georeferenced plot (and again cat v. time 2D plot). I've been trying and > searching for what attributes I need to add to help your software display > the results on a (lon,lat) grid/map. Can you offer any suggestions? > > Thanks, > > -k. > > _______________________________________________ > NOTE: All exchanges posted to Unidata maintained email lists are > recorded in the Unidata inquiry tracking system and made publicly > available through the web. Users who post to any of the lists we > maintain are reminded to remove any personal information that they > do not want to be made public. > > > netcdfgroup mailing list > netcdfgroup@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > >
netcdfgroup archives: