Dear Bob
Thnaks for the helpful example. Yes, I agree that on the basis of netCDF alone
you can't tell whether it's a string or a 10-char array. However, the cf_role
is a string-valued attribute, according to the CF convention, so it must be a
string. I expect that for contents of netCDF files that follow the CF con-
vention this ambiguity shouldn't arise - but if there are cases where it does
we should consider them.
Best wishes
Jonathan
----- Forwarded message from Bob Simons - NOAA Federal <bob.simons at noaa.gov> -----
> Date: Tue, 21 Feb 2017 15:31:11 -0800
> From: Bob Simons - NOAA Federal <bob.simons at noaa.gov>
> To: CF Metadata <cf-metadata at cgd.ucar.edu>
> Subject: Re: [CF-metadata] Pre-proposal for "charset"
>
> You requested a sample file which demonstrates the need for a "data_type"
> attribute for char variables to distinguish Strings from true chars.,,
>
> Here is a file that I was just given which is a good example.
> It is a valid CF DSG file.
> The cf_role=timeseries_id variable appears as char[10].
> So just looking at that variable: is it one string (with 10 characters), or
> an array with 10 values (each a char)?
> Yes, a human can think about the whole file and come to a conclusion of
> which it "must" be, but that is very, very hard or impossible for a
> computer program to figure out (I could be wrong).
>
> But if the timeseries variable had the proposed attribute
> :data_type="string"
> it would be trivial for the software to know that this variable should be
> interpreted as one string (not 10 separate chars).
>
> I hope that was what you were looking for. If not, please tell me why not
> and I'll find another example,
>
> netcdf summary_allTB2007.nc {
> dimensions:
> timeseries = 10;
> time = 996;
> variables:
> char timeseries(timeseries=10);
> :cf_role = "timeseries_id";
> :long_name = "timeseries";
>
> double time(time=996);
> :units = "seconds since 1970-01-01T00:00:00Z";
> :standard_name = "time";
> :long_name = "time";
> :calendar = "gregorian";
> :axis = "T";
>
> double latitude;
> :valid_min = -90.0; // double
> :valid_max = 90.0; // double
> :axis = "Y";
> :long_name = "latitude";
> :standard_name = "latitude";
> :units = "degrees_north";
>
> double longitude;
> :valid_min = -180.0; // double
> :valid_max = 180.0; // double
> :axis = "X";
> :long_name = "longitude";
> :standard_name = "longitude";
> :units = "degrees_east";
>
> double depth;
> :positive = "down";
> :axis = "Z";
> :valid_min = 0.0; // double
> :valid_max = 10971.0; // double
> :long_name = "depth";
> :standard_name = "depth";
> :units = "m";
>
> char platform;
> :long_name = "MVCO ASIT";
>
> char instrument;
> :long_name = "Imaging FlowCytobot";
>
> double crs;
> :grid_mapping_name = "latitude_longitude";
> :longitude_of_prime_meridian = 0.0; // double
> :semi_major_axis = 6378137.0; // double
> :inverse_flattening = 298.257223563; // double
> :epsg_code = "EPSG:4326";
>
> double Asterionellopsis(time=996);
> :_FillValue = -9999.9; // double
> :long_name = "Asterionellopsis";
> :standard_name = "Asterionellopsis";
> :units = "1";
> :coordinates = "time depth latitude longitude";
> :grid_mapping = "crs";
> :platform = "platform";
> :instrument = "instrument";
>
> double Cerataulina(time=996);
> :_FillValue = -9999.9; // double
> :long_name = "Cerataulina";
> :standard_name = "Cerataulina";
> :units = "1";
> :coordinates = "time depth latitude longitude";
> :grid_mapping = "crs";
> :platform = "platform";
> :instrument = "instrument";
>
> double Ceratium(time=996);
> :_FillValue = -9999.9; // double
> :long_name = "Ceratium";
> :standard_name = "Ceratium";
> :units = "1";
> :coordinates = "time depth latitude longitude";
> :grid_mapping = "crs";
> :platform = "platform";
> :instrument = "instrument";
>
> double Chaetoceros(time=996);
> :_FillValue = -9999.9; // double
> :long_name = "Chaetoceros";
> :standard_name = "Chaetoceros";
> :units = "1";
> :coordinates = "time depth latitude longitude";
> :grid_mapping = "crs";
> :platform = "platform";
> :instrument = "instrument";
>
> double Corethron(time=996);
> :_FillValue = -9999.9; // double
> :long_name = "Corethron";
> :standard_name = "Corethron";
> :units = "1";
> :coordinates = "time depth latitude longitude";
> :grid_mapping = "crs";
> :platform = "platform";
> :instrument = "instrument";
>
> double Coscinodiscus(time=996);
> :_FillValue = -9999.9; // double
> :long_name = "Coscinodiscus";
> :standard_name = "Coscinodiscus";
> :units = "1";
> :coordinates = "time depth latitude longitude";
> :grid_mapping = "crs";
> :platform = "platform";
> :instrument = "instrument";
>
> // global attributes:
> :featureType = "timeSeries";
> :Conventions = "CF-1.6";
> :institution = "Obfuscated";
> :title = "Obfuscated";
> data:
> }
>
>
> > Date: Fri, 17 Feb 2017 17:46:45 +0000
> > From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> > To: cf-metadata at cgd.ucar.edu
> > Subject: Re: [CF-metadata] Pre-proposal for "charset"
> > Message-ID: <20170217174645.GA9244 at met.reading.ac.uk>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Dear Bob
> >
> > I agree that sometimes char data is characters and sometimes strings, and
> > one
> > can't tell which it is without knowing the intended use of the array
> > concerned.
> > When you do know the role of this array e.g. as a quality flag data
> > variable,
> > or a string-valued auxiliary coordinary variable, then you know also
> > whether
> > it's a string or an array of characters. Can you give an example where one
> > needs to know how a char array should be interpreted but you *don't* know
> > what
> > its purpose is within the CF-netCDF file?
> >
> > Best wishes
> >
> > Jonathan
> >
> > ----- Forwarded message from Bob Simons - NOAA Federal <
> > bob.simons at noaa.gov> -----
> >
> > > Date: Wed, 8 Feb 2017 10:00:32 -0800
> > > From: Bob Simons - NOAA Federal <bob.simons at noaa.gov>
> > > To: CF Metadata <CF-metadata at cgd.ucar.edu>
> > > Subject: Re: [CF-metadata] Pre-proposal for "charset"
> > >
> > > I think my original pre-proposal has a significant flaw and needs to be
> > > revised.
> > > The problem is: charset needs to be specifiable for all char arrays,
> > > regardless of whether the values should be interpreted as Strings or
> > > individual chars.
> > >
> > > I see two basic solutions:
> > >
> > > 1) Two attributes, but a given variable would only use one of them. The
> > > first part of the attribute name specifies the data type:
> > > char_charset = "ISO-8859-1"; //identifies a char variable using
> > > ISO-8859-1
> > > or
> > > string_charset = "ISO-8859-1"; //identifies a String variable using
> > > ISO-8859-1
> > >
> > > 2) Two attributes that would both be specified for every char/String
> > > variable, e.g.,
> > > charset = "ISO-8859-1";
> > > data_type = "String"; //or "char"
> > >
> > > In either case, the charsets allowed for char (not String) data must be
> > > restricted to single code page (e.g, "ISO-8859-1") because other
> > encodings
> > > (e.g., "UTF-8") need multiple bytes for some characters..
> > >
> > > ---
> > > I have a slight preference (2), because it is cleaner and might be better
> > > in the future (I don't know the implications for nc4 and CF2).
> > >
> > > Thoughts? Votes?
> > >
> > >
> > >
> > >
> > > On Mon, Feb 6, 2017 at 3:08 PM, Bob Simons - NOAA Federal <
> > > bob.simons at noaa.gov> wrote:
> > >
> > > > Before I make a formal CF proposal for a "charset" attribute, I would
> > like
> > > > to get comments and suggestions from all of you.
> > > >
> > > > This is a proposal to solve the problem of distinguishing strings from
> > > > arrays of characters and the problem of identifying the string's
> > character
> > > > encoding. Presumably, it would be appended to section 2.2.
> > > >
> > > > An example of actual need is: Many/most current uses of
> > multidimensional
> > > > char arrays are intended to be interpreted as Strings. But some files,
> > > > e.g., Argo profile float profiles, have single char data that are
> > stored in
> > > > char arrays.
> > > >
> > > > Another example, while most nc files just use 7-bit ASCII characters in
> > > > strings, some use 8-bit characters. Some such files appear to use
> > > > charset=Windows-1252, others use Mac OS Roman, others use ISO-8859-1,
> > but
> > > > the the charset is not specified and there is currently no official CF
> > way
> > > > to specify it.
> > > >
> > > > Another advantage of this proposal is that it provides a way to support
> > > > Unicode (and thus all of the world's languages) via the UTF-8 encoding
> > > > which is useful as we increasingly work with people from non-US,
> > > > non-European countries.
> > > >
> > > > A possible extension of this is to allow a few special additional
> > > > pseudo-charset names:
> > > > * "HTML" - the chars are to be interpreted as an array of Strings with
> > > > HTML content, using the ISO-8859-1 charset. Non-ISO-8859-1 must be
> > encoded
> > > > using the &#d; format where d is the decimal number of a Unicode
> > character.
> > > > * "XML" - the chars are to be interpreted as a an array of Strings
> > with
> > > > XML content, using the ISO-8859-1 charset. Non-ISO-8859-1 characters
> > must
> > > > be encoded using the &#d; format where d is the decimal number of a
> > Unicode
> > > > character.
> > > >
> > > > Thank you for considering this.
> > > >
> > > >
> > > > --- The Actual Pre-Proposal
> > > > Use the "charset" attribute to indicate that a multidimensional
> > > > char array should be interpreted as an array of Strings,
> > > > not an array of individual characters.
> > > > The value of "charset" also serves to specify the character set
> > > > used to encode the strings
> > > > and must be the name of one of the 8-bit encodings
> > > > (since CF chars are 8-bits) listed at
> > > > http://www.iana.org/assignments/character-sets/character-sets.xhtml .
> > > > Charset names are case-insensitive.
> > > > The only charsets which are recommended are "ISO-8859-1" and "UTF-8".
> > > > For backwards compatibility, if "charset" is not defined,
> > > > it remains ambiguous whether a char array should be interpreted as
> > > > holding an array of individual characters or an array of Strings.
> > > >
> > > >
> > > > --- An Example: Encoding three Strings: "It", "Book", and "5 €".
> > > > The Unicode code point for the Euro symbol is 20AC (in hexadecimal),
> > > > which is 8364 (in decimal).
> > > > The Euro symbol is encoded in UTF-8 as 3 bytes: E2 82 AC (in
> > hexadecimal).
> > > > So a file would store these strings in a char array as:
> > > > dimensions
> > > > words = 3;
> > > > strLen = 5;
> > > > char myWords[words][strLen] = "It[0][0][0]", "Book[0]", "5
> > [E2][82][AC]";
> > > > charset = "UTF-8";
> > > >
> > > >
> > > > --
> > > > 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 <(831)%20333-9878> (New!)
> > > > Fax: (831)648-8440 <(831)%20648-8440>
> > > > Email: bob.simons at 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.
> > > > <>< <>< <>< <>< <>< <>< <>< <>< <><
> > > >
> > > >
> > >
> > >
> > > --
> > > 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 at 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.
> > > <>< <>< <>< <>< <>< <>< <>< <>< <><
> >
> > > _______________________________________________
> > > CF-metadata mailing list
> > > CF-metadata at cgd.ucar.edu
> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >
> > ----- End forwarded message -----
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 17 Feb 2017 13:22:29 -0600
> > From: David Blodgett <dblodgett at usgs.gov>
> > To: CF Metadata <cf-metadata at cgd.ucar.edu>
> > Subject: Re: [CF-metadata] Extension of Discrete Sampling Geometries
> > for Simple Features
> > Message-ID: <D53CABCC-2BEF-4D8C-8551-93A3D967B7CB at usgs.gov>
> > Content-Type: text/plain; charset="utf-8"
> >
> > All,
> >
> > I haven?t heard much follow up, but here?s a doodle to coordinate a phone
> > conversation about this. I think we have west-coast US participants and EU
> > participants, so I chose times mid to late morning for me (midwest US).
> >
> > http://doodle.com/poll/eikarnt35tdm7igd <http://doodle.com/poll/
> > eikarnt35tdm7igd>
> >
> > Will make a call once a few people have expressed interest and we have a
> > clear day/time.
> >
> > Regards,
> >
> > - Dave
> >
> > > On Feb 6, 2017, at 11:29 AM, David Blodgett <dblodgett at usgs.gov> wrote:
> > >
> > > Dear CF,
> > >
> > > I want to follow up on the conversation here with an alternative
> > approach suggested off list primarily between Jonathan and I. For this, I?m
> > going to focus on use cases satisfied and simplification of the proposal
> > allowed by not supporting those use cases. The changes below are largely
> > driven by a desire to better align this proposal with the technical details
> > of the prior art that is CF.
> > >
> > > If we:
> > > 1) don?t support node sharing, we can remove the complication of node -
> > coordinate indexing / indirection, simplifying the proposal pretty
> > significantly.
> > > 2) don?t use ?break values? to indicate the separation between
> > multi-part geometries and polygon holes, we end up with a data model with
> > an extra dimension, but the NetCDF dimensions align with the natural
> > dimensions of the data.
> > > 3) use ?count? instead of a ?start pointer? approach, we are better
> > aligned with the existing DSG contiguous ragged array approach.
> > >
> > > Coming back to the three directions we could take this proposal from my
> > cover letter on February 2nd.
> > >> Direct use of Well-Known Text (WKT). In this approach, well known text
> > strings would be encoded using character arrays following a contiguous
> > ragged array approach to index the character array by geometry (or instance
> > in DSG parlance).
> > >> Implement the WKT approach using a NetCDF binary array. In this
> > approach, well known text separators (brackets, commas and spaces) for
> > multipoint, multiline, multipolygon, and polygon holes, would be encoded as
> > break type separator values like -1 for multiparts and -2 for holes.
> > >> Implement the fundamental dimensions of geometry data in NetCDF. In
> > this approach, additional dimensions and variables along those dimensions
> > would be introduced to represent geometries, geometry parts, geometry
> > nodes, and unique (potentially shared) coordinate locations for nodes to
> > reference.
> > > The alternative I?m outlining here moves in the direction of 3. We had
> > originally discounted it because it becomes very verbose and seems overly
> > complicated if support for coordinate sharing is a requirement. If the
> > three simplifications described above are used, then the third approach
> > seems more tenable.
> > >
> > > Jonathan has also suggested that: (these are in reaction to the CDL in
> > my letter from February 2nd)
> > > 1) Rename geom_coordinates as node_coordinates, for consistency with
> > UGRID.
> > > 2) Omit node_dimension. This is redundant, since the dimension can be
> > found by
> > > examining the node coordinate variables.
> > > 3) Prescribe numerous ?codes? and assumptions in the specification
> > instead of letting them be described with attribute values.
> > > 4) It would be more consistent with CF and UGRID to use a single
> > container variable to hang all the topology/geometry information from.
> > >
> > > Which I, personally, am happy to accept if others don?t object.
> > >
> > > A couple other suggestions from Jonathan I want to discuss a bit more:
> > > 1) Rename geometry as topology and geom_type as topology_type.
> > > While I?d be open to something other than geom, topology is odd.
> > If this is really ?node_collection_topology_type? I guess I could be
> > convinced, but would be curious how people react to this. (Especially in
> > relation to UGRID)
> > > 2) This extension is more appropriate as an extension to the concept of
> > cell bounds than the addition of a complex time-invariate type of discrete
> > sampling geometry.
> > > Having just re-read the cell bounds chapter, I think it would over
> > complicate the cell bounds to include this material. My basic issue here is
> > that these geometries do not necessarily have a reference location. They
> > are, rather, first order entities that need to be treated as such. That
> > said, it makes sense that these geometries are not necessarily a good fit
> > for the original intent of Discrete Sampling Geometries. Jonathan suggested
> > they may belong in their own chapter, which may be a good alternative? MY
> > suggested CDL below might lead us in the direction of this being a special
> > type of auxiliary coordinate variable.
> > >
> > > This alternative starts to look like the CDL pasted below.
> > >
> > > Note that the issue of coordinates is sticking out like a sore thumb.
> > Below, I?ve attempted to reconcile Jonathan?s ideas regarding coordinates
> > with my thoughts about how these geometries are ?first order entities? that
> > don?t have a single representative x and y. The spatial coordinates can be
> > said to reside in the system of geometries described in the ?sf? container
> > variable? I realize this goes against the idea of coordinates a bit, but I
> > think it is holding with the spirit of the attribute?
> > >
> > > Finally, I?m glad to continue answering questions and debating things
> > via the list to a point, but I think it would be in our interest to arrange
> > a telecom to discuss this stuff further with a list of interested parties.
> > Feel free to follow up on list, but for decision making, let?s not let this
> > rabbit hole go too deep. I?ll plan on letting this and the other recent
> > action on this proposal settle with people for a week or two then start to
> > bring together a conference call (or calls depending on time zones). Please
> > respond to me off list if you are interested in being part of a call to
> > discuss.
> > >
> > > Regards,
> > >
> > > - Dave
> > >
> > > netcdf multipolygon_example {
> > > dimensions:
> > > node = 47 ;
> > > part = 9 ;
> > > instance = 3 ;
> > > time = 5 ;
> > > strlen = 5 ;
> > > variables:
> > > char instance_name(instance, strlen) ;
> > > instance_name:cf_role = "timeseries_id" ;
> > > double someVariable(instance) ;
> > > someVariable:long_name = "a variable describing a single-valued
> > attribute of a polygon" ;
> > > someVariable:coordinates = "sf" ; // or "instance_name"?
> > > int time(time) ;
> > > time:units = "days since 2000-01-01" ;
> > > double someData(instance, time) ;
> > > someData:coordinates = "time sf" ; // or "time instance_name"?
> > > someData:featureType = "timeSeries" ;
> > > someData:geometry="sf";
> > > int sf; // containing variable -- datatype irrelevant because no data
> > > sf:geom_type = "multipolygon" ; // could be node_topology_type?
> > > sf:node_count_variable="node_count";
> > > sf:node_coordinates = "x y" ;
> > > sf:part_count = "part_node_count" ;
> > > sf:part_type = "part_type" ; // Note required unless polygons with
> > holes present.
> > > sf:outer_ring_order = "anticlockwise" ; // not required if written in
> > spec?
> > > sf:closure_convention = "last_node_equals_first" ; // not required if
> > written in spec?
> > > sf:outer_type_code = 0 ; // not required if written in spec?
> > > sf:inner_type_code = 1 ; // not required if written in spec?
> > > int node_count(instance);
> > > node_count:long_name = ?count of coordinates in each instance
> > geometry" ;
> > > int part_node_count(part) ;
> > > part_node_count:long_name = ?count of coordinates in each geometry
> > part" ;
> > > int part_type(part) ;
> > > part_type:long_name = ?type of each geometry part" ;
> > > double x(node) ;
> > > x:units = "degrees_east" ;
> > > x:standard_name = "longitude" ; // or projection_x_coordinate
> > > X:cf_role = "geometry_x_node" ;
> > > double y(node) ;
> > > y:units = "degrees_north" ;
> > > y:standard_name = ?latitude? ; // or projection_y_coordinate
> > > y:cf_role = "geometry_y_node"
> > > // global attributes:
> > > :Conventions = "CF-1.8" ;
> > >
> > > data:
> > >
> > > instance_name =
> > > "flash",
> > > "bang",
> > > "pow" ;
> > >
> > > someVariable = 1, 2, 3 ;
> > >
> > > time = 1, 2, 3, 4, 5 ;
> > >
> > > someData =
> > > 1, 2, 3, 4, 5,
> > > 1, 2, 3, 4, 5,
> > > 1, 2, 3, 4, 5 ;
> > >
> > > node_count = 25, 15, 7 ;
> > >
> > > part_node_count = 5, 4, 4, 4, 4, 8, 6, 8, 4 ;
> > >
> > > part_type = 0, 1, 1, 1, 0, 0, 0, 1, 0 ;
> > >
> > > x = 0, 20, 20, 0, 0, 1, 10, 19, 1, 5, 7, 9, 5, 11, 13, 15, 11, 5, 9, 7,
> > > 5, 11, 15, 13, 11, -40, -20, -45, -40, -20, -10, -10, -30, -45, -20,
> > -30, -20, -20, -30, 30,
> > > 45, 10, 30, 25, 50, 30, 25 ;
> > >
> > > y = 0, 0, 20, 20, 0, 1, 5, 1, 1, 15, 19, 15, 15, 15, 19, 15, 15, 25,
> > 25, 29,
> > > 25, 25, 25, 29, 25, -40, -45, -30, -40, -35, -30, -10, -5, -20, -35,
> > -20, -15, -25, -20, 20,
> > > 40, 40, 20, 5, 10, 15, 5 ;
> > > }
> > >
> > >
> > >
> > >> On Feb 4, 2017, at 8:07 AM, David Blodgett <dblodgett at usgs.gov <mailto:
> > dblodgett at usgs.gov>> wrote:
> > >>
> > >> Dear Chris,
> > >>
> > >> Thanks for your thorough treatment of these issues. We have gone
> > through a similar thought process to arrive at the proposal we came up
> > with. I?ll answer as briefly as I can.
> > >>
> > >> 1) how would you translate between netcdf geometries and, say geo JSON?
> > >>
> > >> The thinking is that node coordinate sharing is optional. If the writer
> > wants to check or already knows that nodes share coordinates, then it?s
> > possible. Otherwise, it doesn?t have to be used. I?ve always felt that this
> > was important, but maybe not critical for a core NetCDF-CF data model. Some
> > offline conversation has led to an example that does not use it that may be
> > a good alternative, more on that later.
> > >>
> > >> 2) Break Values
> > >>
> > >> You really do have to hold your nose on the break values. The issue is
> > that you have to store that information somehow and it is almost worse to
> > create new variables to store the multi-part and hole/not hole information.
> > The alternative approach that?s forming up as mentioned above does break
> > the information out into additional variables but simplifies things
> > otherwise. In that case it doesn?t feel overly complex to me? so stay tuned
> > for more on this front.
> > >>
> > >> 3) Ragged Indexing
> > >>
> > >> Your thought process follows ours exactly. The key is that you either
> > have to create the ?pointer? array as a first order of business or loop
> > over the counts ad nauseam. I?m actually leaning toward the counts for two
> > reasons. First, the counts approach is already in CF so is a natural fit
> > and will be familiar to developers in this space. Second, the issue of 0 vs
> > 1 indexing is annoying. In our proposal, we settled on 0 indexing because
> > it aligns with the idea of an offset, but it is still annoying and some
> > applications would always have to adjust that pointer array as a first
> > order of business.
> > >>
> > >> On to Bob?s comments.
> > >>
> > >> Regarding aligning with other data models / encodings, I guess this
> > needs to be unpacked a bit.
> > >>
> > >> 1) In this setting, simple features is a data model, not an encoding.
> > An encoding can implement part or all of a data model as is needed by the
> > use case(s) at hand. There is no problem with partial implementations you
> > still get interoperability for the intended use cases.
> > >> 2) Attempting to align with other encoding standards UGRID and
> > NetCDF-CF are the primary ones here, is simply to keep the implementation
> > patterns similar and familiar. This may be a fools errand, but is
> > presumably good for adoptability and consistency.
> > >> So, I don?t see a problem with implementing important simple features
> > types in a way that aligns with the way the existing community standards
> > work.
> > >>
> > >> I don?t see this as ignoring existing standards at all. There is no
> > open community standard for binary encoding of geometries and related data
> > that passes the CF requirements of human readability and self-description.
> > We are adopting the appropriate data model and suggesting a new encoding
> > that will solve a lot of problems in the environmental modeling space.
> > >>
> > >> As we?ve discussed before, your "different approach? sounds great, but
> > seems like an exercise for a future effort that doesn?t attempt to align
> > with CF 1.7. Maybe what you suggest is a path forward for variable length
> > arrays in the CF 2.0 ?vision in the mist?, but I don?t see it as a tenable
> > solution for CF 1.*.
> > >>
> > >> Best Regards,
> > >>
> > >> - Dave
> > >>
> > >>
> > >>> On Feb 3, 2017, at 3:31 PM, Chris Barker <chris.barker at noaa.gov
> > <mailto:chris.barker at noaa.gov>> wrote:
> > >>>
> > >>> a few thoughts. First, I think there are three core "issues" that need
> > to be resolved:
> > >>>
> > >>> 1) Coordinate indexing (indirection)
> > >>>
> > >>> the question of whether you have an array of "vertices" that the
> > geomotry types index into to get thier data:
> > >>>
> > >>> Advantages:
> > >>> - if a number of geometries share a lot of vertices, it can be more
> > efficient
> > >>> - the relationship between geometries that share vertices (i.e.
> > polygons that share a boundary) etc. is well defined. you dopnt need to
> > check for closeness, and maybe have a tolerance, etc.
> > >>>
> > >>> These were absolutely critical for UGRID for example -- a UGRID mesh
> > is a single thing", NOT a collection of polygons that happen to share some
> > vertices.
> > >>>
> > >>> Disadvantages:
> > >>> - if the geometries do not share many vertices, it is less efficient.
> > >>> - there are additional code complications in "getting" the vertices
> > of the given geometry
> > >>> - it does not match the OGC data model.
> > >>>
> > >>> My 0.02 -- given my use cases, I tend to want teh advantages -- but I
> > don't know that that's a typical use case. And I think it's a really good
> > idea to keep with the OGS data model where possible -- i.e. e able to
> > translate from netcdf to, say, geoJSON as losslessly as possible. Given
> > that I think it's probably a better idea not to have the indirection.
> > >>>
> > >>> However (to equivocate) perhaps the types of information people are
> > likely to want to store in netcdf are a subset of what the OGC standards
> > are designed for -- and for those use-cases, maybe shared vertices are
> > critical.
> > >>>
> > >>> One way to think about it -- how would you translate between netcdf
> > geometries and, say geo JSON:
> > >>> - nc => geojson would lose the shared index info.
> > >>> - geojson => nc -- would you try to reconstruct the shared
> > vertices?? I"m thinking that would be a bit dangerous in the general case,
> > because you are adding information that you don't know is true -- are these
> > a shared vertex or two that just happen to be at the same location?
> > >>>
> > >>> > > Break values
> > >>>
> > >>> I don't really like break values as an approach, but with netcdf any
> > option will be ugly one way or another. So keeping with the WKT approach
> > makes sense to me. Either way you'll need custom code to unpack it. (BTW --
> > what does WellKnownBinary do?)
> > >>>
> > >>> > > Ragged indexing
> > >>>
> > >>> There are two "natural" ways to represent a ragged array:
> > >>>
> > >>> (a) store the length of each "row"
> > >>> (b) store the index to the beginning (or end) or each "row"
> > >>>
> > >>> CF already uses (a). However, working with it, I'm pretty convinced
> > that it's the "wrong" choice:
> > >>>
> > >>> If you want to know how long a given row is, that is really easy with
> > (a), and almost as easy with (b) (involves two indexes and a subtraction)
> > >>>
> > >>> However, if you want to extract a particular row: (b) makes this
> > really easy -- you simply access the slice of the array you want. with (a)
> > you need to loop through the entire "length_of_rows" array (up to the row
> > of interest) and add up the values to find the slice you need. not a huge
> > issue, but it is an issue. In fact, in my code to read ragged arrays in
> > netcdf, the first thing I do is pre-compute the index-to-each-row, so I can
> > then use that to access individual rows for future access -- if you are
> > accessing via OpenDAP -- that's particular helpful.
> > >>>
> > >>> So -- (b) is clearly (to me) the "best" way to do it -- but is it
> > worth introducing a second way to handle ragged arrays in CF? I would think
> > yes, but that would be offset if:
> > >>>
> > >>> - There is a bunch of existing library code that transparently
> > handles ragged arrays in netcdf (does netcdfJava have something? I'm pretty
> > sure Python doesn't -- certainly not in netCDF4)
> > >>>
> > >>> - That that existing lib code would be advantageous to leverage for
> > code reading features: I suspect that there will have to be enough custom
> > code that the ragged array bits are going to be the least of it.
> > >>>
> > >>> So I'm for the "new" way of representing ragged arrays
> > >>>
> > >>> -CHB
> > >>>
> > >>>
> > >>> On Fri, Feb 3, 2017 at 11:41 AM, Bob Simons - NOAA Federal <
> > bob.simons at noaa.gov <mailto:bob.simons at noaa.gov>> wrote:
> > >>> Then, isn't this proposal just the first step in the creation of a new
> > model and a new encoding of Simple Features, one that is "align[ed] ...
> > with as many other encoding standards in this space as is practical"? In
> > other words, yet another standard for Simple Features?
> > >>>
> > >>> If so, it seems risky to me to take just the first (easy?) step "to
> > support the use cases that have a compelling need today" and not solve the
> > entire problem. I know the CF way is to just solve real, current needs, but
> > in this case it seems to risk a head slap moment in the future when we
> > realize that, in order to deal with some new simple feature variant, we
> > should have done things differently from the beginning?
> > >>>
> > >>> And it seems odd to reject existing standards that have been so
> > painstakingly hammered out, in favor of starting the process all over
> > again. We follow existing standards for other things (e.g., IEEE-754 for
> > representing floating point numbers in binary files), why can't we follow
> > an existing Simple Features standard?
> > >>>
> > >>> ---
> > >>> Rather than just be a naysayer, let me suggest a very different
> > alternative:
> > >>>
> > >>> There are several projects in the CF realm (e.g., this Simple Features
> > project, Discrete Sampling Geometry (DSG), true variable-length Strings,
> > ugrid(?)) which share a common underlying problem: how to deal with
> > variable-length multidimensional arrays: a[b][c], where the length of the c
> > dimension may be different for different b indices.
> > >>> DSG solved this (5 different ways!), but only for DSG.
> > >>> The Simple Features proposal seeks to solve the problem for Simple
> > Features.
> > >>> We still have no support for Unicode variable-length Strings.
> > >>>
> > >>> Instead of continuing to solve the variable-length problem a different
> > way every time we confront it, shouldn't we solve it once, with one small
> > addition to the standard, and then use that solution repeatedly?
> > >>> The solution could be a simple variant of one of the DSG solutions,
> > but generalized so that it could be used in different situations.
> > >>> An encoding standard and built-in support for variable-length data
> > arrays in netcdf-java/c would solve a lot of problems, now and in the
> > future.
> > >>> Some work on this is already done: I think the netcdf-java API already
> > supports variable-length arrays when reading netcdf-4 files.
> > >>> For Simple Features, the problem would reduce to: store the feature
> > (using some specified existing standard like WKT or WKB) in a
> > variable-length array.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Feb 3, 2017 at 9:07 AM, <cf-metadata-request at cgd.ucar.edu
> > <mailto:cf-metadata-request at cgd.ucar.edu>> wrote:
> > >>> Date: Fri, 3 Feb 2017 11:07:00 -0600
> > >>> From: David Blodgett <dblodgett at usgs.gov <mailto:dblodgett at usgs.gov>>
> > >>> To: Bob Simons - NOAA Federal <bob.simons at noaa.gov <mailto:
> > bob.simons at noaa.gov>>
> > >>> Cc: CF Metadata <cf-metadata at cgd.ucar.edu <mailto:
> > cf-metadata at cgd.ucar.edu>>
> > >>> Subject: Re: [CF-metadata] Extension of Discrete Sampling Geometries
> > >>> for Simple Features
> > >>> Message-ID: <8EE85E65-2815-4720-90FC-13C72D3C7952 at usgs.gov <mailto:
> > 8EE85E65-2815-4720-90FC-13C72D3C7952 at usgs.gov>>
> > >>> Content-Type: text/plain; charset="utf-8"
> > >>>
> > >>> Dear Bob,
> > >>>
> > >>> I?ll just take these in line.
> > >>>
> > >>> 1) noted. We have been trying to figure out what to do with the point
> > featureType and I think leaving it more or less alone is a viable path
> > forward.
> > >>>
> > >>> 2) This is not an exact replica of WKT, but rather a similar approach
> > to WKT. As I stated, we have followed the ISO simple features data model
> > and well known text feature types in concept, but have not used the same
> > standardization formalisms. We aren?t advocating for supporting ?all of?
> > any standard but are rather attempting to support the use cases that have a
> > compelling need today while aligning this with as many other encoding
> > standards in this space as is practical. Hopefully that answers your
> > question, sorry if it?s vague.
> > >>>
> > >>> 3) The google doc linked in my response contains the encoding we are
> > proposing as a starting point for conversation: http://goo.gl/Kq9ASq <
> > http://goo.gl/Kq9ASq> <http://goo.gl/Kq9ASq <http://goo.gl/Kq9ASq>> I
> > want to stress, as a starting point for discussion. I expect that this
> > proposal will change drastically before we?re done.
> > >>>
> > >>> 4) Absolutely envision tools doing what you say, convert to/from
> > standard spatial formats and NetCDF-CF geometries. We intend to introduce
> > an R and a Python implementation that does exactly as you say along with
> > whatever form this standard takes in the end. R and Python were chosen as
> > the team that brought this together are familiar with those two languages,
> > additional implementations would be more than welcome.
> > >>>
> > >>> 5) We do include a ?geometry? featureType similar to the ?point?
> > featureType. Thus our difficulty with what to do with the ?point?
> > featureType. You are correct, there are lots of non timeSeries applications
> > to be solved and this proposal does intend to support them (within the
> > existing DSG constructs).
> > >>>
> > >>> Thanks for your questions, hopefully my answers close some gaps for
> > you.
> > >>>
> > >>> - Dave
> > >>>
> > >>> > On Feb 3, 2017, at 10:47 AM, Bob Simons - NOAA Federal <
> > bob.simons at noaa.gov <mailto:bob.simons at noaa.gov>> wrote:
> > >>> >
> > >>> > 1) There is a vague comment in the proposal about possibly changing
> > the point featureType. Please don't, unless the changes don't affect
> > current uses of Point. There are already 1000's of files that use it. If
> > this new system offers an alternative, then fine, it's an alternative. One
> > of the most important and useful features of a good standard is backwards
> > compatibility.
> > >>> >
> > >>> > 2) You advocate "Implement the WKT approach using a NetCDF binary
> > array." Is this system then an exact encoding of WKT, neither a subset nor
> > a superset? "Simple Features" are often not simple.
> > >>> > If it is WKT (or something else), what is the standard you are
> > following to describe the Simple Features (e.g., ISO/IEC 13249-3:2016 and
> > ISO 19162:2015)?
> > >>> > Does your proposal deviate in any way from the standard's
> > capabilities?
> > >>> > Do you advocate following the entire WKT standard, e.g., supporting
> > all the feature types that WKT supports?
> > >>> >
> > >>> > 3) Since you are not using the WKT encoding, but creating your own,
> > where is the definition of the encoding system you are using?
> > >>> >
> > >>> > 4) This is a little out of CF scope, but:
> > >>> > Do you envision tools, notably, netcdf-c/java, having a writer
> > function that takes in WKT and encodes the information in a file, and
> > having a reader function that reads the file and returns WKT? Or is it your
> > plan that the encoding/ decoding is left to the user?
> > >>> >
> > >>> > 5) This proposal is for "Simple Features plus Time Series" (my
> > phrase not yours). But aren't there lots of other uses of Simple Features?
> > Will there be other proposals in the future for "Simple Features plus X"
> > and "Simple Features plus Y"? If so, will CF eventually become a massive
> > document where Simple Features are defined over and over again, but in
> > different contexts? If so, wouldn't a better solution be to deal with
> > Simple Features separately (as Postgres does by making a geometric data
> > type?), and then add "Simple Features plus Time Series" as the first use of
> > it?
> > >>> >
> > >>> > Thanks for answering these questions.
> > >>> > Please forgive me if I missed parts of your proposal that answer
> > these questions.
> > >>> >
> > >>> >
> > >>> > On Thu, Feb 2, 2017 at 5:57 AM, <cf-metadata-request at cgd.ucar.edu
> > <mailto:cf-metadata-request at cgd.ucar.edu> <mailto:cf-metadata-request_at_
> > cgd.ucar.edu <mailto:cf-metadata-request at cgd.ucar.edu>>> wrote:
> > >>> > Date: Thu, 2 Feb 2017 07:57:36 -0600
> > >>> > From: David Blodgett <dblodgett at usgs.gov <mailto:dblodgett at usgs.gov>
> > <mailto:dblodgett at usgs.gov <mailto:dblodgett at usgs.gov>>>
> > >>> > To: <cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
> > <mailto:cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>>>
> > >>> > Subject: [CF-metadata] Extension of Discrete Sampling Geometries for
> > >>> > Simple Features
> > >>> > Message-ID: <224C2828-7212-449F-8C2C-97D903F6BE1E at usgs.gov <mailto:
> > 224C2828-7212-449F-8C2C-97D903F6BE1E at usgs.gov> <mailto:224C2828-7212-449F-
> > 8C2C-97D903F6BE1E at usgs.gov <mailto:224C2828-7212-449F-
> > 8C2C-97D903F6BE1E at usgs.gov>>>
> > >>> > Content-Type: text/plain; charset="utf-8"
> > >>> >
> > >>> > Dear CF Community,
> > >>> >
> > >>> > We are pleased to submit this proposal for your consideration and
> > review. The cover letter we've prepared below provides some background and
> > explanation for the proposed approach. The google doc here <
> > http://goo.gl/Kq9ASq <http://goo.gl/Kq9ASq> <http://goo.gl/Kq9ASq <
> > http://goo.gl/Kq9ASq>>> is an excerpt of the CF specification with track
> > changes turned on. Permissions for the document allow any google user to
> > comment, so feel free to comment and ask questions in line.
> > >>> >
> > >>> > Note that I?m sharing this with you with one issue unresolved. What
> > to do with the point featureType? Our draft suggests that it is part of a
> > new geometry featureType, but it could be that we leave it alone and
> > introduce a geometry featureType. This may be a minor point of discussion,
> > but we need to be clear that this is an issue that still needs to be
> > resolved in the proposal.
> > >>> >
> > >>> > Thank you for your time and consideration.
> > >>> >
> > >>> > Best Regards,
> > >>> >
> > >>> > David Blodgett, Tim Whiteaker, and Ben Koziol
> > >>> >
> > >>> > Proposed Extension to NetCDF-CF for Simple Geometries
> > >>> >
> > >>> > Preface
> > >>> >
> > >>> > The proposed addition to NetCDF-CF introduced below is inspired by a
> > pre-existing data model governed by OGC and ISO as ISO 19125-1. More
> > information on Simple Features may be found here. <
> > https://en.wikipedia.org/wiki/Simple_Features <https://en.wikipedia.org/
> > wiki/Simple_Features> <https://en.wikipedia.org/wiki/Simple_Features <
> > https://en.wikipedia.org/wiki/Simple_Features>>> To the knowledge of the
> > authors, it is consistent with ISO 19125-1 but has not been specified using
> > the formalisms of OGC or ISO. Language used attempts to hold true to
> > NetCDF-CF semantics while not conflicting with the existing standards
> > baseline. While this proposal does not support the entire scope of the the
> > simple features ecosystem, it does support the core data types in most
> > common use around the community.
> > >>> >
> > >>> > The other existing standard to mention is UGRID convention <
> > http://ugrid-conventions.github.io/ugrid-conventions/ <
> > http://ugrid-conventions.github.io/ugrid-conventions/> <
> > http://ugrid-conventions.github.io/ugrid-conventions/ <
> > http://ugrid-conventions.github.io/ugrid-conventions/>>>. The authors
> > have experience reading and writing UGRID and have designed the proposed
> > structure in a way that is inspired by and consistent with it.
> > >>> >
> > >>> > Terms and Definitions
> > >>> >
> > >>> > (Taken from OGC 06-103r4 OpenGIS Implementation Specification for
> > Geographic information - Simple feature access - Part 1: Common
> > architecture <http://www.opengeospatial.org/standards/sfa <
> > http://www.opengeospatial.org/standards/sfa> <http://www.opengeospatial.
> > org/standards/sfa <http://www.opengeospatial.org/standards/sfa>>>.)
> > >>> >
> > >>> > Feature: Abstraction of real world phenomena - typically a
> > geospatial abstraction with associated descriptive attributes.
> > >>> > Simple Feature: A feature with all geometric attributes described
> > piecewise by straight line or planar interpolation between point sets.
> > >>> > Geometry (geometric complex): A set of disjoint geometric primitives
> > - one or more points, lines, or polygons that form the spatial
> > representation of a feature.
> > >>> > Introduction
> > >>> >
> > >>> > Discrete Sampling Geometries (DSGs) handle data from one (or a
> > collection of) timeSeries (point), Trajectory, Profile, TrajectoryProfile
> > or timeSeriesProfile geometries. Measurements are from a point (timeSeries
> > and Profile) or points along a trajectory. In this proposal, we reuse the
> > core DSG timeSeries type which provides support for basic time series use
> > cases e.g., a timeSerieswhich is measured (or modeled) at a given point.
> > >>> >
> > >>> > Changes to Existing CF Specification
> > >>> >
> > >>> > In NetCDF-CF 1.7, Discrete Sampling Geometries separate dimensions
> > and variables into two types ? instance and element <
> > http://cfconventions.org/cf-conventions/cf-conventions.
> > html#_collections_instances_and_elements <http://cfconventions.org/cf-
> > conventions/cf-conventions.html#_collections_instances_and_elements> <
> > http://cfconventions.org/cf-conventions/cf-conventions.
> > html#_collections_instances_and_elements <http://cfconventions.org/cf-
> > conventions/cf-conventions.html#_collections_instances_and_elements>>>.
> > Instance refers to individual points, trajectories, profiles, etc. These
> > would sometimes be referred to as features given that they are identified
> > entities that can have associated attributes and be related to other
> > entities. Element dimensions describe temporal or other dimensions to
> > describe data on a per-instance basis. This proposal extends the DSG
> > timeSeries featuretype <http://cfconventions.org/cf-
> > conventions/cf-conventions.html#_features_and_feature_types <http://cfcon
> > ventions.org/cf-conventions/cf-conventions.html#_features_
> > and_feature_types> <http://cfconventions.org/cf-
> > conventions/cf-conventions.html#_features_and_feature_types <
> > http://cfconventions.org/cf-conventions/cf-conventions.
> > html#_features_and_feature_types>>> such that the geospatial coordinates
> > of the instances can be point, multi-point, line, multi-line, polygon, or
> > multi-polyg
> > >>> on geometries. Rather than overload the DSG contiguous ragged array
> > encoding, designed with timeseries in mind, a geometry ragged array
> > encoding is introduced in a new section 9.3.5. See thi
> > >>> > s google doc for specific proposed changes. <http://goo.gl/Kq9ASq <
> > http://goo.gl/Kq9ASq> <http://goo.gl/Kq9ASq <http://goo.gl/Kq9ASq>>>
> > >>> > Motivation
> > >>> >
> > >>> > DSGs have no system to define a geometry (polyline, polygon, etc.,
> > other than point) and an association with a time series that applies over
> > that entire geometry e.g., The expected rainfall in this watershed polygon
> > for some period of time is 10 mm. As suggested in the last paragraph of
> > section 9.1, current practice is to assign a representative point or just
> > use an ID and forgo spatial information within a NetCDF-CF file. In order
> > to satisfy a number of environmental modeling use cases, we need a way to
> > encode a geometry (point, line, polygon, multi-point, multi-line, or
> > multi-polygon) that is the static spatial feature representation to which
> > one or more timeSeries can be associated. In this proposal, we provide an
> > encoding to define collections of simple feature geometries. It interfaces
> > cleanly with the existing DSG specification, enabling DSGs and Simple
> > Geometries to be used concurrently.
> > >>> >
> > >>> > Looking Forward
> > >>> >
> > >>> > This proposal is a compromise solution that attempts to stay
> > consisten to CF ideals and fit within the structure of the existing
> > specification with minimal disruption. Line and polygon data types often
> > require variable length arrays. Development of this proposal has brought to
> > light the need for a general abstraction for variable length arrays in
> > NetCDF-CF. Such a general abstraction would necessarily be reusable for
> > character arrays, ragged arrays of time series, and ragged arrays of
> > geometry nodes, as well as any other ragged data structures that may come
> > up in the future. This proposal does not introduce such a general ragged
> > array abstraction but does not preclude such a development in the future.
> > >>> >
> > >>> > Three Alternative Approaches
> > >>> >
> > >>> > Respecting the human readability ideal of NetCDF-CF, the development
> > of this proposal started from a human readable format for geometries known
> > as Well Known Text <https://en.wikipedia.org/wiki/Well-known_text <
> > https://en.wikipedia.org/wiki/Well-known_text> <https://en.wikipedia.org/
> > wiki/Well-known_text <https://en.wikipedia.org/wiki/Well-known_text>>>.
> > We considered three high level design approaches while developing this
> > proposal.
> > >>> >
> > >>> > Direct use of Well-Known Text (WKT). In this approach, well known
> > text strings would be encoded using character arrays following a contiguous
> > ragged array approach to index the character array by geometry (or instance
> > in DSG parlance).
> > >>> > Implement the WKT approach using a NetCDF binary array. In this
> > approach, well known text separators (brackets, commas and spaces) for
> > multipoint, multiline, multipolygon, and polygon holes, would be encoded as
> > break type separator values like -1 for multiparts and -2 for holes.
> > >>> > Implement the fundamental dimensions of geometry data in NetCDF. In
> > this approach, additional dimensions and variables along those dimensions
> > would be introduced to represent geometries, geometry parts, geometry
> > nodes, and unique (potentially shared) coordinate locations for nodes to
> > reference.
> > >>> > Selected Approach
> > >>> >
> > >>> > The first approach was seen as too opaque to stay true to the CF
> > ideal of complete self-description. The third approach seemed needlessly
> > verbose and difficult to implement. The second approach was selected for
> > the following reasons:
> > >>> >
> > >>> > The second approach is just as or more human-readable than the third.
> > >>> > Use of break values keeps geometries relatively atomic.
> > >>> > Will be familiar to developers who are familiar with the WKT
> > geometry format.
> > >>> > Character arrays, which are needed for options one and three, are
> > cumbersome to use in some programming languages in common use with NetCDF.
> > >>> > Break values replace the need for extraneous variables related to
> > multi-part and polygon holes (interiors). Multi-part geometries are
> > generally an exception and excessive instrumentation to support them should
> > be discounted.
> > >>> > Example: Representation of WKT-Style Polygons in a NetCDF-3
> > timeSeriesfeatureType
> > >>> >
> > >>> > Below is sample CDL demonstrating how polygons are encoded in
> > NetCDF-3 using a continuous ragged array-like encoding. There are three
> > details to note in the example below.
> > >>> >
> > >>> > The attribute contiguous_ragged_dimension with value of a dimension
> > in the file.
> > >>> > The geom_coordinates attribute with a value containing a space
> > separated string of variable names.
> > >>> > The cf_role geometry_x_node and geometry_y_node.
> > >>> > These three attributes form a system to fully describe collections
> > of multi-polygon feature geometries. Any variable that has the
> > continuous_ragged_dimension attribute contains integers that indicate the
> > 0-indexed starting position of each geometry along the instance dimension.
> > Any variable that uses the dimension referenced in the
> > continuous_ragged_dimension attribute can be interpreted using the values
> > in the variable containing the contiguous_ragged_dimension attribute. The
> > variables referenced in the geom_coordinates attribute describe spatial
> > coordinates of geometries. These variables can also be identified by the
> > cf_roles geometry_x_node and geometry_y_node. Note that the example below
> > also includes a mechanism to handle multi-polygon features that also
> > contain holes.
> > >>> >
> > >>> > netcdf multipolygon_example {
> > >>> > dimensions:
> > >>> > node = 47 ;
> > >>> > indices = 55 ;
> > >>> > instance = 3 ;
> > >>> > time = 5 ;
> > >>> > strlen = 5 ;
> > >>> > variables:
> > >>> > char instance_name(instance, strlen) ;
> > >>> > instance_name:cf_role = "timeseries_id" ;
> > >>> > int coordinate_index(indices) ;
> > >>> > coordinate_index:geom_type = "multipolygon" ;
> > >>> > coordinate_index:geom_coordinates = "x y" ;
> > >>> > coordinate_index:multipart_break_value = -1 ;
> > >>> > coordinate_index:hole_break_value = -2 ;
> > >>> > coordinate_index:outer_ring_order = "anticlockwise" ;
> > >>> > coordinate_index:closure_convention = "last_node_equals_first" ;
> > >>> > int coordinate_index_start(instance) ;
> > >>> > coordinate_index_start:long_name = "index of first coordinate
> > in each instance geometry" ;
> > >>> > coordinate_index_start:contiguous_ragged_dimension = "indices" ;
> > >>> > double x(node) ;
> > >>> > x:units = "degrees_east" ;
> > >>> > x:standard_name = "longitude" ; // or projection_x_coordinate
> > >>> > X:cf_role = "geometry_x_node" ;
> > >>> > double y(node) ;
> > >>> > y:units = "degrees_north" ;
> > >>> > y:standard_name = ?latitude? ; // or projection_y_coordinate
> > >>> > y:cf_role = "geometry_y_node"
> > >>> > double someVariable(instance) ;
> > >>> > someVariable:long_name = "a variable describing a single-valued
> > attribute of a polygon" ;
> > >>> > int time(time) ;
> > >>> > time:units = "days since 2000-01-01" ;
> > >>> > double someData(instance, time) ;
> > >>> > someData:coordinates = "time x y" ;
> > >>> > someData:featureType = "timeSeries" ;
> > >>> > // global attributes:
> > >>> > :Conventions = "CF-1.8" ;
> > >>> >
> > >>> > data:
> > >>> >
> > >>> > instance_name =
> > >>> > "flash",
> > >>> > "bang",
> > >>> > "pow" ;
> > >>> >
> > >>> > coordinate_index = 0, 1, 2, 3, 4, -2, 5, 6, 7, 8, -2, 9, 10, 11,
> > 12, -2, 13, 14, 15, 16,
> > >>> > -1, 17, 18, 19, 20, -1, 21, 22, 23, 24, 25, 26, 27, 28, -1, 29,
> > 30, 31, 32, 33,
> > >>> > 34, -2, 35, 36, 37, 38, 39, 40, 41, 42, -1, 43, 44, 45, 46 ;
> > >>> >
> > >>> > coordinate_index_start = 0, 30, 46 ;
> > >>> >
> > >>> > x = 0, 20, 20, 0, 0, 1, 10, 19, 1, 5, 7, 9, 5, 11, 13, 15, 11, 5,
> > 9, 7,
> > >>> > 5, 11, 15, 13, 11, -40, -20, -45, -40, -20, -10, -10, -30, -45,
> > -20, -30, -20, -20, -30, 30,
> > >>> > 45, 10, 30, 25, 50, 30, 25 ;
> > >>> >
> > >>> > y = 0, 0, 20, 20, 0, 1, 5, 1, 1, 15, 19, 15, 15, 15, 19, 15, 15,
> > 25, 25, 29,
> > >>> > 25, 25, 25, 29, 25, -40, -45, -30, -40, -35, -30, -10, -5, -20,
> > -35, -20, -15, -25, -20, 20,
> > >>> > 40, 40, 20, 5, 10, 15, 5 ;
> > >>> >
> > >>> > someVariable = 1, 2, 3 ;
> > >>> >
> > >>> > time = 1, 2, 3, 4, 5 ;
> > >>> >
> > >>> > someData =
> > >>> > 1, 2, 3, 4, 5,
> > >>> > 1, 2, 3, 4, 5,
> > >>> > 1, 2, 3, 4, 5 ;
> > >>> > }
> > >>> > How To Interpret
> > >>> >
> > >>> > Starting from the timeSeries variables:
> > >>> >
> > >>> > See CF-1.8 conventions.
> > >>> > See the timeSeries featureType.
> > >>> > Find the timeseries_id cf_role.
> > >>> > Find the coordinates attribute of data variables.
> > >>> > See that the variables indicated by the coordinates attribute have a
> > cf_role geometry_x_nodeand geometry_y_node to determine that these are
> > geometries according to this new specification.
> > >>> > Find the coordinate index variable with geom_coordinates that point
> > to the nodes.
> > >>> > Find the variable with contiguous_ragged_dimension pointing to the
> > dimension of the coordinate index variable to determine how to index into
> > the coordinate index.
> > >>> > Iterate over polygons, parsing out geometries using the contiguous
> > ragged start variable and coordinate index variable to interpret the
> > coordinate data variables.
> > >>> > Or, without reference to timeSeries:
> > >>> >
> > >>> > See CF-1.8 conventions.
> > >>> > See the geom_type of multipolygon.
> > >>> > Find the variable with a contiguous_ragged_dimension matching the
> > coordinate index variable?s dimension.
> > >>> > See the geom_coordinates of x y.
> > >>> > Using the contiguous ragged start variable found in 3 and the
> > coordinate index variable found in 2, geometries can be parsed out of the
> > coordinate index variable and parsed using the hole and break values in it.
> > >>> >
> > >>> > -------------- next part --------------
> > >>> > An HTML attachment was scrubbed...
> > >>> > URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> > attachments/20170202/4ce5b42f/attachment.html <
> > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> > attachments/20170202/4ce5b42f/attachment.html> <
> > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> > attachments/20170202/4ce5b42f/attachment.html <
> > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> > attachments/20170202/4ce5b42f/attachment.html>>>
> > >>> >
> > >>> > ------------------------------
> > >>> >
> > >>> > Subject: Digest Footer
> > >>> >
> > >>> > _______________________________________________
> > >>> > CF-metadata mailing list
> > >>> > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu> <mailto:
> > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>>
> > >>> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata <
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> <
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata <
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>>
> > >>> >
> > >>> >
> > >>> > ------------------------------
> > >>> >
> > >>> > End of CF-metadata Digest, Vol 166, Issue 3
> > >>> > *******************************************
> > >>> >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > 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 <tel:%28831%29333-9878> (New!)
> > >>> > Fax: (831)648-8440 <tel:%28831%29648-8440>
> > >>> > Email: bob.simons at noaa.gov <mailto:bob.simons at noaa.gov> <mailto:
> > bob.simons at noaa.gov <mailto:bob.simons at 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.
> > >>> > <>< <>< <>< <>< <>< <>< <>< <>< <><
> > >>> >
> > >>> > _______________________________________________
> > >>> > CF-metadata mailing list
> > >>> > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> > >>> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata <
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> > >>>
> > >>> -------------- next part --------------
> > >>> An HTML attachment was scrubbed...
> > >>> URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> > attachments/20170203/4ff55def/attachment.html <
> > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> > attachments/20170203/4ff55def/attachment.html>>
> > >>>
> > >>> ------------------------------
> > >>>
> > >>> Subject: Digest Footer
> > >>>
> > >>> _______________________________________________
> > >>> CF-metadata mailing list
> > >>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> > >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata <
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> > >>>
> > >>>
> > >>> ------------------------------
> > >>>
> > >>> End of CF-metadata Digest, Vol 166, Issue 5
> > >>> *******************************************
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> 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 <tel:(831)%20333-9878> (New!)
> > >>> Fax: (831)648-8440 <tel:(831)%20648-8440>
> > >>> Email: bob.simons at noaa.gov <mailto:bob.simons at 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.
> > >>> <>< <>< <>< <>< <>< <>< <>< <>< <><
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> CF-metadata mailing list
> > >>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> > >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata <
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> Christopher Barker, Ph.D.
> > >>> Oceanographer
> > >>>
> > >>> Emergency Response Division
> > >>> NOAA/NOS/OR&R (206) 526-6959 voice
> > >>> 7600 Sand Point Way NE (206) 526-6329 fax
> > >>> Seattle, WA 98115 (206) 526-6317 main reception
> > >>>
> > >>> Chris.Barker at noaa.gov <mailto:Chris.Barker at noaa.gov>
> > _______________________________________________
> > >>> CF-metadata mailing list
> > >>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> > >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata <
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> > >>
> > >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> > attachments/20170217/b548709a/attachment.html>
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >
> > ------------------------------
> >
> > End of CF-metadata Digest, Vol 166, Issue 15
> > ********************************************
> >
>
>
>
> --
> 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 at 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.
> <>< <>< <>< <>< <>< <>< <>< <>< <><
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Wed Feb 22 2017 - 11:15:46 GMT
