flesh out tests for writing netcdf

[twhiteaker]

The unit tests for writing netcdf files could be fleshed out to make sure the various cases like point, polygon with hole, etc., are being written properly wrt attributes and variable arrays.

[dblodgett-usgs]

You might look at the test data over here: https://github.com/dblodgett-usgs/netcdf.dsg/tree/master/tests/testthat/data

It's all in .rds format (an R object serialization). I could dump all those out to whatever format is best for python testing.

[twhiteaker]

I like JSON for Python serialization.

Here are test cases I would eventually like to cover. In all cases, I would like to include two geometry instances, preferably with different node counts. I'd like to use these for the wiki examples.

• [ ] Two points with z -- shows use of z variable; shows xyz vars using instance dim
• [ ] A point and a multipoint -- xy now uses node dim; node_count var required
• [ ] Two lines -- node_count var required
• [ ] A line and a multiline -- part_node_count var required
• [ ] Two polygons
• [ ] A polygon and a polygon with a hole -- shows interior ring var
• [ ] A polygon and a multipolygon with a hole -- shows everything
• [ ] ** A polygon with a clockwise outer ring and anticlockwise inner ring, to make sure we orient the rings properly before writing to netCDF

** Just for testing. Does not make it to the wiki.

Eventually also:

• [ ] Two lines with someData and a crs
• [ ] Two lines with someData and a crs, with coordinates and grid_mapping on the container var.

Which of these cases does your sample data already cover?

[dblodgett-usgs]

Looking at this more closely, my data are mostly from the fixture json. See the top 20 lines here: https://github.com/dblodgett-usgs/netcdf.dsg/blob/master/tests/testthat/loadFixtureData.R

I just did it that way so the tests didn't require the rgeos dependency that was required (at the time) to read WKT.

There is a "Yahara_alb.zip" in there that has a shapefile that I used to test things. It brought in some interesting edge cases because it has "real" multipolygons and holes.

[twhiteaker]

I added the examples I had in mind to https://github.com/twhiteaker/netCDF-CF-simple-geometry/tree/master/data/simplified_examples

The WKT fixture was simple but only showed a single geometry, which might leave readers wondering how multiple geometries are implemented. Eventually I may remove the WKT fixture, but I'm tired after wrestling with Travis (Python 3) this afternoon. I live in 2.7 world here.

[dblodgett-usgs]

Cool! Since I wrote the R implementation, the R community has embraced a shiny new spatial library... I need to refactor that code to use the new library. In the process, I can also make the code read json directly. I'll adopt the test data from here. Would it make sense to publish these via github pages or something?

[twhiteaker]

Do you mean publish them for our unit tests? The JSON in the simplified_examples folder has artifacts I needed for Python, so instead of your R tests using those, I think we'd want to rework the test fixture JSON of WKTs to include WKTs for the geometries in the simplified_examples folder.

Can you elaborate on how we'd use GitHub Pages for this? If we just rework the test fixture JSON, that's a single file so your tests could link directly to it rather than scrape a GitHub Page.

[dblodgett-usgs]

I guess I was thinking we could publish a stand alone WKT for each test case that could get pulled in -- but that's probably overkill. Just sharing test requirements is probably fine.

Github pages is just a good way to publish web content from a repository...