Updated readme per conversation.

[dblodgett-usgs]

The first cut at the readme was from memory away from internet. I've updated it to reflect what's going on here: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/cf-conventions.html#representations-features

I think this should make more sense now. Sorry for the confusion.

[dblodgett-usgs]

@BobSimons @bekozi - Does this PR help clarify things?

[twhiteaker]

I just started looking at it and will provide feedback today.

[BobSimons]

Sorry, no. I still don't understand why index_start_stop's size is 2 or 3, and not 1 or 2. So I still don't understand what is in polyIndex.

And I don't think this ragged array system is very much like the DSG Indexed Ragged Array, which only stores the number of items for each timeSeries (which isn't ideal, because then the client has to do a cumulative sum of the array in order to find the stop index for each timeSeries feature, and go back one to find the start index).

I still believe: This proposal is a ton of work and added complexity to CF for one very specific use case. Is this really the only use case for Simple Geometries in a CF file? CF needs a standardized system for ragged arrays. That needs to be a separate proposal. This proposal needs to just handle storing Simple Geometries in a CF standard ragged array, and not be tied to TimeSeries. It would be vastly better if we pursued two very general proposals/solutions (standardized ragged arrays and storing simple geometries) which would meet the needs of this project and so so many more. Pursuing very specific proposals like this (as it currently is) is what leads (over time) to complex, bloated standards filled with dozens or hundreds of sections covering all the special cases.

On Tue, Jun 7, 2016 at 11:33 AM, David Blodgett notifications@github.com wrote:

@BobSimons https://github.com/BobSimons @bekozi https://github.com/bekozi - Does this PR help clarify things?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bekozi/netCDF-CF-simple-geometry/pull/13#issuecomment-224372667, or mute the thread https://github.com/notifications/unsubscribe/ABarOKInwBxl2hcSBHXFhHpQ9_BG33Jfks5qJbljgaJpZM4IuIL1 .

Sincerely,

Bob Simons IT Specialist Environmental Research Division NOAA Southwest Fisheries Science Center 99 Pacific St., Suite 255A (New!) Monterey, CA 93940 (New!) Phone: (831)333-9878 (New!) Fax: (831)648-8440 Email: bob.simons@noaa.gov

The contents of this message are mine personally and do not necessarily reflect any position of the Government or the National Oceanic and Atmospheric Administration. <>< <>< <>< <>< <>< <>< <>< <>< <><

[dblodgett-usgs]

@BobSimons you are right, I screwed up the polyIndex. It should be of length polygons. Will fix.

[dblodgett-usgs]

@BobSimons - In this description, I'm attempting to show how one would use the existing contiguous ragged array format, not the indexed ragged array. Sorry I messed up the dimension on polyIndex. This should correspond to 9.3.3 here: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/cf-conventions.html#representations-features If it doesn't I'm missing something.

What will get done, and what Ben and Tim have been working on is the rules for putting polygon nodes into NetCDF variables rather than time series or some other phenomena. The readme content here is an attempt to show how this is going to get encoded holistically using existing NetCDF3 formats (however poorly - thanks for your review!).

[BobSimons]

Sorry. I misspoke. I meant Contiguous Ragged Array.

The DSG CRA just stores the size of each feature. http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#_contiguous_ragged_array_representation If we used that system here, polyIndex would be just polyIndex(timeSeries). The start and stop indexes have to be calculated by the client from that information. (I'm not a fan of this detail. It is what it is.)

---

Thanks for clarifying that this proposal isn't tied to Time Series.

On Tue, Jun 7, 2016 at 12:35 PM, David Blodgett notifications@github.com wrote:

@BobSimons https://github.com/BobSimons - In this description, I'm attempting to show how one would use the existing contiguous ragged array format, not the indexed ragged array. Sorry I messed up the dimension on polyIndex. This should correspond to 9.3.3 here: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/cf-conventions.html#representations-features If it doesn't I'm missing something.

What will get done, and what Ben and Tim have been working on is the rules for putting polygon nodes into NetCDF variables rather than time series or some other phenomena. The readme content here is an attempt to show how this is going to get encoded holistically using existing NetCDF3 formats (however poorly - thanks for your review!).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bekozi/netCDF-CF-simple-geometry/pull/13#issuecomment-224389740, or mute the thread https://github.com/notifications/unsubscribe/ABarODNn396d2mFJxvQ4zJNCqRRfIHPiks5qJcfugaJpZM4IuIL1 .

Sincerely,

Bob Simons IT Specialist Environmental Research Division NOAA Southwest Fisheries Science Center 99 Pacific St., Suite 255A (New!) Monterey, CA 93940 (New!) Phone: (831)333-9878 (New!) Fax: (831)648-8440 Email: bob.simons@noaa.gov

The contents of this message are mine personally and do not necessarily reflect any position of the Government or the National Oceanic and Atmospheric Administration. <>< <>< <>< <>< <>< <>< <>< <>< <><

[twhiteaker]

This proposal needs to just handle storing Simple Geometries in a CF standard ragged array, and not be tied to TimeSeries.

@BobSimons I agree that our core proposal shouldn't require this to be tied to timeSeries, though I do like the idea of demonstrating how we could use polygon geometry with timeSeries data. Indeed, our Bull Creek use case is not a time series but rather a snapshot in time.

[dblodgett-usgs]

I've moved the basic WKT-like representation about the timeSeries featuretype section to increase focus on it.

[bekozi]

I think this looks good :+1:. It is nice to have the section for the timeSeries feature type broken out. We need to get some CDL examples up for each of the simple geometry types. Ticket created: #17.