CDL examples for simple geometries

[bekozi]

Example using netCDF4 with ragged arrays:

• [ ] Point
• [ ] MultiPoint
• [ ] LineString
• [ ] MultiLineString
• [ ] Polygon
• [ ] MultiPolygon
• [ ] Polygon w/ Holes
• [ ] MultiPolygon w/ Holes

Example using netCDF3 rectangular arrays:

• [ ] Polygon

Example using netCDF3 contiguous ragged arrays (?):

• [ ] Polygon

Examples can be generated easily once we have code to write netCDF data from a geometry collection.

[bekozi]

All: Should we use the test fixture WKT for the CDL examples? Should we focus the CDL examples on, say, a hydrologic use case? @twhiteaker / @dblodgett-usgs had some good example data I think?

We are getting close with the Python reference implementation, and I think it would be good to start thinking about how we'll generate these examples!

[twhiteaker]

I think the test fixture WKT is good for the CDL examples. This will help the complete CDL including data to be human readable since the examples would be simple enough to include the coordinates. This helps train users in what we're doing.

We should also implement the two use cases, but more so as a demonstration of how our work can be used rather than teaching the format itself. And of course if our use cases break our design, then oops.

[twhiteaker]

By the way, the example data are in the use_cases folder, and if you click the json file for each use case in your browser, GitHub will show a map of the geojson data.

[bekozi]

By the way, the example data are in the use_cases folder, and if you click the json file for each use case in your browser, GitHub will show a map of the geojson data.

That's pretty nice.

I think the test fixture WKT is good for the CDL examples. This will help the complete CDL including data to be human readable since the examples would be simple enough to include the coordinates. This helps train users in what we're doing.

I agree. The very simple examples are much easier to keep in your brain.

We should also implement the two use cases, but more so as a demonstration of how our work can be used rather than teaching the format itself.

Sounds good. It would be nice to have a use case that includes points, lines, and polygons in a single file. A hydrologic use case would be good for this.

And of course if our use cases break our design, then oops.

Better for us to break it indeed.

[bekozi]

Initial examples located here: https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/Examples---VLen-Ragged-Arrays. This is only for VLen. CRA is still in progress. The examples cover all the WKTs in the test fixture file. This generation is scripted. I hope to commit that script shortly.

[bekozi]

Here is the script for the markdown creation: https://github.com/bekozi/netCDF-CF-simple-geometry/blob/master/misc/create_cdl_examples.py.

[dblodgett-usgs]

Now that I have things serially complete (but not done) I was able to dump the fixture out to cdl using the contiguous ragged array format. https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/Examples:-Contiguous-Ragged-Arrays I can redo this from code as we change things too. https://github.com/dblodgett-usgs/NCDFSG/blob/master/tests/testthat/loadFixtureData.R Woot!

[bekozi]

Looking good. Thanks @dblodgett-usgs.

A couple comments:

• What is the purpose of cdm_data_type? Is this something related to this spec? I don't think we should use a global definition for the file geometry in the interest of multiple geometry types in a single file.
• I'm still skeptical of using featureType = "timeSeries". I likely don't fully understand it. Must it always be used? What does it mean if all data variables in the file have no time? I guess it would be good to know what is gained by using the timeSeries feature type. Right now, I don't see the advantage!

[dblodgett-usgs]

I shouldn't have left cdm_data_type in there. It's a remnant of some previous work...

featureType = "timeSeries" references the DSG spec. http://cfconventions.org/cf-conventions/cf-conventions.html#_features_and_feature_types if there is no time data in the file then I suppose it would be more like 'point' feature type. In that case I think we would be proposing a 'polygon' and 'line' featuretype. This is included so we are consistent with the existing DSG specification. Some would debate the utility of a global attribute declaring a featureType, but that ship sailed when DSG was adopted a while ago.

I made some updates.

[bekozi]

I shouldn't have left cdm_data_type in there. It's a remnant of some previous work...

Got it.

Some would debate the utility of a global attribute declaring a featureType, but that ship sailed when DSG was adopted a while ago.

Global feature types are likely a no go with this simple geometry approach unless we can use a more generic feature type like simple_geometry or geometry. I also think the spec should be flexible enough to add geometries to files containing grids wherein global attributes would get confusing.

[dblodgett-usgs]

Agreed. I think we should allow the DSG style feature types though so we come in where CF is. So, in the case that a file has simple geometries linked to time series, it's a timeSeries feature type. We atleast want to do that, not sure it's worth extending the non time series featureType to include more than point. It would be consistent with the existing standard and would be the obvious way to encode a plain shapefile-like file.

[bekozi]

Right on. Makes sense to me.

[dblodgett-usgs]

These should be good to go for people who come looking after AGU.