<div dir="ltr">I agree that writing rules for determining if the chars should be interpreted as chars or a String based on the dimensions would be very difficult. I don't intend to even try. I just want to add <font face="monospace, monospace">data_type</font> as a strongly recommended way to specify how the chars should be interpreted (chars vs string) and <font face="monospace, monospace">charset</font> to specify the character encoding.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 1:01 AM, David Hassell <span dir="ltr"><<a href="mailto:david.hassell@ncas.ac.uk" target="_blank">david.hassell@ncas.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hello Bob,<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks for the example. I fully agree that this case is hard for humans as well as computers. Since  the timeseries variable has the same name as the timeseries dimension (and therefore also identifies it is a size 10 coordinate variable) it makes it very hard, even with the hint given by the cf_role attribute. There are examples elsewhere in  CF, of hard things made easier, such as the axis attribute for coordinates, and I think that this is a good case for another one.<br><br>The default interpretation of char arrays (section 2.2) would need tightening up, of course. It might be enough to say that an array of chars may be interpreted as strings if "the dimensions imply it", or if the data_type is set to string. <br><br></div><div class="gmail_default" style="font-family:monospace,monospace">It might, however, be hard to write down rules for "if the dimensions imply it". You could start with "if it is not a data variable and the its trailing dimension is not spanned the data variable which requires it", but life gets more complicated when you start with a DSG file, which may contain a char variable that spans a dimension which a data variable spans only implicitly (e.g. in your example the timeseries variable  spans the implied instance dimension of size 1).<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">David<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 February 2017 at 23:31, Bob Simons - NOAA Federal <span dir="ltr"><<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>You requested a sample file which demonstrates the need for a "data_type" attribute for char variables to distinguish Strings from true chars.,,<br></div><div><br></div><div>Here is a file that I was just given which is a good example.</div><div>It is a valid CF DSG file.</div><div>The cf_role=timeseries_id variable appears as char[10]. </div><div>So just looking at that variable: is it one string (with 10 characters), or an array with 10 values (each a char)?</div><div>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).</div><div><br></div><div>But if the timeseries variable had the proposed attribute</div><div>  :data_type="string"</div><div>it would be trivial for the software to know that this variable should be interpreted as one string (not 10 separate chars).</div><div><br></div><div>I hope that was what you were looking for. If not, please tell me why not and I'll find another example,</div><div><br></div><div>netcdf summary_allTB2007.nc {</div><div>  dimensions:</div><div>    timeseries = 10;</div><div>    time = 996;</div><div>  variables:</div><div>    char timeseries(timeseries=10);</div><div>      :cf_role = "timeseries_id";</div><div>      :long_name = "timeseries";</div><div><br></div><div>    double time(time=996);</div><div>      :units = "seconds since 1970-01-01T00:00:00Z";</div><div>      :standard_name = "time";</div><div>      :long_name = "time";</div><div>      :calendar = "gregorian";</div><div>      :axis = "T";</div><div><br></div><div>    double latitude;</div><div>      :valid_min = -90.0; // double</div><div>      :valid_max = 90.0; // double</div><div>      :axis = "Y";</div><div>      :long_name = "latitude";</div><div>      :standard_name = "latitude";</div><div>      :units = "degrees_north";</div><div><br></div><div>    double longitude;</div><div>      :valid_min = -180.0; // double</div><div>      :valid_max = 180.0; // double</div><div>      :axis = "X";</div><div>      :long_name = "longitude";</div><div>      :standard_name = "longitude";</div><div>      :units = "degrees_east";</div><div><br></div><div>    double depth;</div><div>      :positive = "down";</div><div>      :axis = "Z";</div><div>      :valid_min = 0.0; // double</div><div>      :valid_max = 10971.0; // double</div><div>      :long_name = "depth";</div><div>      :standard_name = "depth";</div><div>      :units = "m";</div><div><br></div><div>    char platform;</div><div>      :long_name = "MVCO ASIT";</div><div><br></div><div>    char instrument;</div><div>      :long_name = "Imaging FlowCytobot";</div><div><br></div><div>    double crs;</div><div>      :grid_mapping_name = "latitude_longitude";</div><div>      :longitude_of_prime_meridian = 0.0; // double</div><div>      :semi_major_axis = 6378137.0; // double</div><div>      :inverse_flattening = 298.257223563; // double</div><div>      :epsg_code = "EPSG:4326";</div><div><br></div><div>    double Asterionellopsis(time=996);</div><div>      :_FillValue = -9999.9; // double</div><div>      :long_name = "Asterionellopsis";</div><div>      :standard_name = "Asterionellopsis";</div><div>      :units = "1";</div><div>      :coordinates = "time depth latitude longitude";</div><div>      :grid_mapping = "crs";</div><div>      :platform = "platform";</div><div>      :instrument = "instrument";</div><div><br></div><div>    double Cerataulina(time=996);</div><div>      :_FillValue = -9999.9; // double</div><div>      :long_name = "Cerataulina";</div><div>      :standard_name = "Cerataulina";</div><div>      :units = "1";</div><div>      :coordinates = "time depth latitude longitude";</div><div>      :grid_mapping = "crs";</div><div>      :platform = "platform";</div><div>      :instrument = "instrument";</div><div><br></div><div>    double Ceratium(time=996);</div><div>      :_FillValue = -9999.9; // double</div><div>      :long_name = "Ceratium";</div><div>      :standard_name = "Ceratium";</div><div>      :units = "1";</div><div>      :coordinates = "time depth latitude longitude";</div><div>      :grid_mapping = "crs";</div><div>      :platform = "platform";</div><div>      :instrument = "instrument";</div><div><br></div><div>    double Chaetoceros(time=996);</div><div>      :_FillValue = -9999.9; // double</div><div>      :long_name = "Chaetoceros";</div><div>      :standard_name = "Chaetoceros";</div><div>      :units = "1";</div><div>      :coordinates = "time depth latitude longitude";</div><div>      :grid_mapping = "crs";</div><div>      :platform = "platform";</div><div>      :instrument = "instrument";</div><div><br></div><div>    double Corethron(time=996);</div><div>      :_FillValue = -9999.9; // double</div><div>      :long_name = "Corethron";</div><div>      :standard_name = "Corethron";</div><div>      :units = "1";</div><div>      :coordinates = "time depth latitude longitude";</div><div>      :grid_mapping = "crs";</div><div>      :platform = "platform";</div><div>      :instrument = "instrument";</div><div><br></div><div>    double Coscinodiscus(time=996);</div><div>      :_FillValue = -9999.9; // double</div><div>      :long_name = "Coscinodiscus";</div><div>      :standard_name = "Coscinodiscus";</div><div>      :units = "1";</div><div>      :coordinates = "time depth latitude longitude";</div><div>      :grid_mapping = "crs";</div><div>      :platform = "platform";</div><div>      :instrument = "instrument";</div></div><div><br></div><div><div>  // global attributes:</div><div>  :featureType = "timeSeries";</div><div>  :Conventions = "CF-1.6";</div><div>  :institution = "Obfuscated";<br></div><div>  :title = "Obfuscated";</div><div> data:</div><div>}</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Fri, 17 Feb 2017 17:46:45 +0000<br>
From: Jonathan Gregory <<a href="mailto:j.m.gregory@reading.ac.uk" target="_blank">j.m.gregory@reading.ac.uk</a>><br>
To: <a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.edu</a><br>
Subject: Re: [CF-metadata] Pre-proposal for "charset"<br>
Message-ID: <<a href="mailto:20170217174645.GA9244@met.reading.ac.uk" target="_blank">20170217174645.GA9244@met.rea<wbr>ding.ac.uk</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Dear Bob<br>
<br>
I agree that sometimes char data is characters and sometimes strings, and one<br>
can't tell which it is without knowing the intended use of the array concerned.<br>
When you do know the role of this array e.g. as a quality flag data variable,<br>
or a string-valued auxiliary coordinary variable, then you know also whether<br>
it's a string or an array of characters. Can you give an example where one<br>
needs to know how a char array should be interpreted but you *don't* know what<br>
its purpose is within the CF-netCDF file?<br>
<br>
Best wishes<br>
<br>
Jonathan<br>
<br>
----- Forwarded message from Bob Simons - NOAA Federal <<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>> -----<br>
<br>
> Date: Wed, 8 Feb 2017 10:00:32 -0800<br>
> From: Bob Simons - NOAA Federal <<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>><br>
> To: CF Metadata <<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a>><br>
> Subject: Re: [CF-metadata] Pre-proposal for "charset"<br>
><br>
> I think my original pre-proposal has a significant flaw and needs to be<br>
> revised.<br>
> The problem is: charset needs to be specifiable for all char arrays,<br>
> regardless of whether the values should be interpreted as Strings or<br>
> individual chars.<br>
><br>
> I see two basic solutions:<br>
><br>
> 1) Two attributes, but a given variable would only use one of them. The<br>
> first part of the attribute name specifies the data type:<br>
>   char_charset = "ISO-8859-1";   //identifies a char variable using<br>
> ISO-8859-1<br>
> or<br>
>   string_charset = "ISO-8859-1";   //identifies a String variable using<br>
> ISO-8859-1<br>
><br>
> 2) Two attributes that would both be specified for every char/String<br>
> variable, e.g.,<br>
>   charset = "ISO-8859-1";<br>
>   data_type = "String";             //or "char"<br>
><br>
> In either case, the charsets allowed for char (not String) data must be<br>
> restricted to single code page (e.g, "ISO-8859-1") because other encodings<br>
> (e.g., "UTF-8") need multiple bytes for some characters..<br>
><br>
> ---<br>
> I have a slight preference (2), because it is cleaner and might be better<br>
> in the future (I don't know the implications for nc4 and CF2).<br>
><br>
> Thoughts? Votes?<br>
><br>
><br>
><br>
><br>
> On Mon, Feb 6, 2017 at 3:08 PM, Bob Simons - NOAA Federal <<br>
> <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>> wrote:<br>
><br>
> > Before I make a formal CF proposal for a "charset" attribute, I would like<br>
> > to get comments and suggestions from all of you.<br>
> ><br>
> > This is a proposal to solve the problem of distinguishing strings from<br>
> > arrays of characters and the problem of identifying the string's character<br>
> > encoding. Presumably, it would be appended to section 2.2.<br>
> ><br>
> > An example of actual need is: Many/most current uses of multidimensional<br>
> > char arrays are intended to be interpreted as Strings. But some files,<br>
> > e.g., Argo profile float profiles, have single char data that are stored in<br>
> > char arrays.<br>
> ><br>
> > Another example, while most nc files just use 7-bit ASCII characters in<br>
> > strings, some use 8-bit characters. Some such files appear to use<br>
> > charset=Windows-1252, others use Mac OS Roman, others use ISO-8859-1, but<br>
> > the the charset is not specified and there is currently no official CF way<br>
> > to specify it.<br>
> ><br>
> > Another advantage of this proposal is that it provides a way to support<br>
> > Unicode (and thus all of the world's languages) via the UTF-8 encoding<br>
> > which is useful as we increasingly work with people from non-US,<br>
> > non-European countries.<br>
> ><br>
> > A possible extension of this is to allow a few special additional<br>
> > pseudo-charset names:<br>
> > * "HTML" - the chars are to be interpreted as an array of Strings with<br>
> > HTML content, using the ISO-8859-1 charset. Non-ISO-8859-1  must be encoded<br>
> > using the &#d; format where d is the decimal number of a Unicode character.<br>
> > * "XML" -  the chars are to be interpreted as a an array of Strings with<br>
> > XML content, using the ISO-8859-1 charset. Non-ISO-8859-1 characters must<br>
> > be encoded using the &#d; format where d is the decimal number of a Unicode<br>
> > character.<br>
> ><br>
> > Thank you for considering this.<br>
> ><br>
> ><br>
> > --- The Actual Pre-Proposal<br>
> > Use the "charset" attribute to indicate that a multidimensional<br>
> > char array should be interpreted as an array of Strings,<br>
> > not an array of individual characters.<br>
> > The value of "charset" also serves to specify the character set<br>
> > used to encode the strings<br>
> > and must be the name of one of the 8-bit encodings<br>
> > (since CF chars are 8-bits) listed at<br>
> > <a href="http://www.iana.org/assignments/character-sets/character-sets.xhtml" rel="noreferrer" target="_blank">http://www.iana.org/assignment<wbr>s/character-sets/character-set<wbr>s.xhtml</a> .<br>
> > Charset names are case-insensitive.<br>
> > The only charsets which are recommended are "ISO-8859-1" and "UTF-8".<br>
> > For backwards compatibility, if "charset" is not defined,<br>
> > it remains ambiguous whether a char array should be interpreted as<br>
> > holding an array of individual characters or an array of Strings.<br>
> ><br>
> ><br>
> > --- An Example: Encoding three Strings: "It", "Book", and "5 &euro;".<br>
> > The Unicode code point for the Euro symbol is 20AC (in hexadecimal),<br>
> > which is 8364 (in decimal).<br>
> > The Euro symbol is encoded in UTF-8 as 3 bytes: E2 82 AC (in hexadecimal).<br>
> > So a file would store these strings in a char array as:<br>
> >   dimensions<br>
> >     words = 3;<br>
> >     strLen = 5;<br>
> >   char myWords[words][strLen] = "It[0][0][0]", "Book[0]", "5 [E2][82][AC]";<br>
> >     charset = "UTF-8";<br>
> ><br>
> ><br>
> > --<br>
> > Sincerely,<br>
> ><br>
> > Bob Simons<br>
> > IT Specialist<br>
> > Environmental Research Division<br>
> > NOAA Southwest Fisheries Science Center<br>
> > 99 Pacific St., Suite 255A      (New!)<br>
> > Monterey, CA 93940               (New!)<br>
> > Phone: <a href="tel:(831)%20333-9878" value="+18313339878" target="_blank">(831)333-9878</a> <(831)%20333-9878>            (New!)<br>
> > Fax:   <a href="tel:(831)%20648-8440" value="+18316488440" target="_blank">(831)648-8440</a> <(831)%20648-8440><br>
> > Email: <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a><br>
> ><br>
> > The contents of this message are mine personally and<br>
> > do not necessarily reflect any position of the<br>
> > Government or the National Oceanic and Atmospheric Administration.<br>
> > <>< <>< <>< <>< <>< <>< <>< <>< <><<br>
> ><br>
> ><br>
><br>
><br>
> --<br>
> Sincerely,<br>
><br>
> Bob Simons<br>
> IT Specialist<br>
> Environmental Research Division<br>
> NOAA Southwest Fisheries Science Center<br>
> 99 Pacific St., Suite 255A      (New!)<br>
> Monterey, CA 93940               (New!)<br>
> Phone: <a href="tel:%28831%29333-9878" value="+18313339878" target="_blank">(831)333-9878</a>            (New!)<br>
> Fax:   <a href="tel:%28831%29648-8440" value="+18316488440" target="_blank">(831)648-8440</a><br>
> Email: <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a><br>
><br>
> The contents of this message are mine personally and<br>
> do not necessarily reflect any position of the<br>
> Government or the National Oceanic and Atmospheric Administration.<br>
> <>< <>< <>< <>< <>< <>< <>< <>< <><<br>
<br>
> ______________________________<wbr>_________________<br>
> CF-metadata mailing list<br>
> <a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a><br>
> <a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a><br>
<br>
<br>
----- End forwarded message -----<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 17 Feb 2017 13:22:29 -0600<br>
From: David Blodgett <<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a>><br>
To: CF Metadata <<a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.edu</a>><br>
Subject: Re: [CF-metadata] Extension of Discrete Sampling Geometries<br>
        for Simple Features<br>
Message-ID: <<a href="mailto:D53CABCC-2BEF-4D8C-8551-93A3D967B7CB@usgs.gov" target="_blank">D53CABCC-2BEF-4D8C-8551-93A3D<wbr>967B7CB@usgs.gov</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
All,<br>
<br>
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).<br>
<br>
<a href="http://doodle.com/poll/eikarnt35tdm7igd" rel="noreferrer" target="_blank">http://doodle.com/poll/eikarnt<wbr>35tdm7igd</a> <<a href="http://doodle.com/poll/eikarnt35tdm7igd" rel="noreferrer" target="_blank">http://doodle.com/poll/eikarn<wbr>t35tdm7igd</a>><br>
<br>
Will make a call once a few people have expressed interest and we have a clear day/time.<br>
<br>
Regards,<br>
<br>
- Dave<br>
<br>
> On Feb 6, 2017, at 11:29 AM, David Blodgett <<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a>> wrote:<br>
><br>
> Dear CF,<br>
><br>
> 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.<br>
><br>
> If we:<br>
> 1) don?t support node sharing, we can remove the complication of node - coordinate indexing / indirection, simplifying the proposal pretty significantly.<br>
> 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.<br>
> 3) use ?count? instead of a ?start pointer? approach, we are better aligned with the existing DSG contiguous ragged array approach.<br>
><br>
> Coming back to the three directions we could take this proposal from my cover letter on February 2nd.<br>
>> 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).<br>
>> 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.<br>
>> 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.<br>
> 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.<br>
><br>
> Jonathan has also suggested that: (these are in reaction to the CDL in my letter from February 2nd)<br>
> 1) Rename geom_coordinates as node_coordinates, for consistency with UGRID.<br>
> 2) Omit node_dimension. This is redundant, since the dimension can be found by<br>
> examining the node coordinate variables.<br>
> 3) Prescribe numerous ?codes? and assumptions in the specification instead of letting them be described with attribute values.<br>
> 4) It would be more consistent with CF and UGRID to use a single container variable to hang all the topology/geometry information from.<br>
><br>
> Which I, personally, am happy to accept if others don?t object.<br>
><br>
> A couple other suggestions from Jonathan I want to discuss a bit more:<br>
> 1) Rename geometry as topology and geom_type as topology_type.<br>
>       While I?d be open to something other than geom, topology is odd. If this is really ?node_collection_topology_type<wbr>? I guess I could be convinced, but would be curious how people react to this. (Especially in relation to UGRID)<br>
> 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.<br>
>       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.<br>
><br>
> This alternative starts to look like the CDL pasted below.<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
> Regards,<br>
><br>
> - Dave<br>
><br>
> netcdf multipolygon_example {<br>
> dimensions:<br>
>  node = 47 ;<br>
>  part = 9 ;<br>
>  instance = 3 ;<br>
>  time = 5 ;<br>
>  strlen = 5 ;<br>
> variables:<br>
>  char instance_name(instance, strlen) ;<br>
>    instance_name:cf_role = "timeseries_id" ;<br>
>  double someVariable(instance) ;<br>
>    someVariable:long_name = "a variable describing a single-valued attribute of a polygon" ;<br>
>    someVariable:coordinates = "sf" ; // or "instance_name"?<br>
>  int time(time) ;<br>
>    time:units = "days since 2000-01-01" ;<br>
>  double someData(instance, time) ;<br>
>    someData:coordinates = "time sf" ; // or "time instance_name"?<br>
>    someData:featureType = "timeSeries" ;<br>
>    someData:geometry="sf";<br>
>  int sf; // containing variable -- datatype irrelevant because no data<br>
>    sf:geom_type = "multipolygon" ; // could be node_topology_type?<br>
>    sf:node_count_variable="node_c<wbr>ount";<br>
>    sf:node_coordinates = "x y" ;<br>
>    sf:part_count = "part_node_count" ;<br>
>    sf:part_type = "part_type" ; // Note required unless polygons with holes present.<br>
>    sf:outer_ring_order = "anticlockwise" ; // not required if written in spec?<br>
>    sf:closure_convention = "last_node_equals_first" ; // not required if written in spec?<br>
>    sf:outer_type_code = 0 ; // not required if written in spec?<br>
>    sf:inner_type_code = 1 ; // not required if written in spec?<br>
>  int node_count(instance);<br>
>    node_count:long_name = ?count of coordinates in each instance geometry" ;<br>
>  int part_node_count(part) ;<br>
>    part_node_count:long_name = ?count of coordinates in each geometry part" ;<br>
>  int part_type(part) ;<br>
>    part_type:long_name = ?type of each geometry part" ;<br>
>  double x(node) ;<br>
>    x:units = "degrees_east" ;<br>
>    x:standard_name = "longitude" ; // or projection_x_coordinate<br>
>    X:cf_role = "geometry_x_node" ;<br>
>  double y(node) ;<br>
>    y:units = "degrees_north" ;<br>
>    y:standard_name = ?latitude? ; // or projection_y_coordinate<br>
>    y:cf_role = "geometry_y_node"<br>
> // global attributes:<br>
>     :Conventions = "CF-1.8" ;<br>
><br>
> data:<br>
><br>
>  instance_name =<br>
>   "flash",<br>
>   "bang",<br>
>   "pow" ;<br>
><br>
>  someVariable = 1, 2, 3 ;<br>
><br>
>  time = 1, 2, 3, 4, 5 ;<br>
><br>
>  someData =<br>
>   1, 2, 3, 4, 5,<br>
>   1, 2, 3, 4, 5,<br>
>   1, 2, 3, 4, 5 ;<br>
><br>
>  node_count = 25, 15, 7 ;<br>
><br>
>  part_node_count = 5, 4, 4, 4, 4, 8, 6, 8, 4 ;<br>
><br>
>  part_type = 0, 1, 1, 1, 0, 0, 0, 1, 0 ;<br>
><br>
>  x = 0, 20, 20, 0, 0, 1, 10, 19, 1, 5, 7, 9, 5, 11, 13, 15, 11, 5, 9, 7,<br>
>     5, 11, 15, 13, 11, -40, -20, -45, -40, -20, -10, -10, -30, -45, -20, -30, -20, -20, -30, 30,<br>
>     45, 10, 30, 25, 50, 30, 25 ;<br>
><br>
>  y = 0, 0, 20, 20, 0, 1, 5, 1, 1, 15, 19, 15, 15, 15, 19, 15, 15, 25, 25, 29,<br>
>     25, 25, 25, 29, 25, -40, -45, -30, -40, -35, -30, -10, -5, -20, -35, -20, -15, -25, -20, 20,<br>
>     40, 40, 20, 5, 10, 15, 5 ;<br>
> }<br>
><br>
><br>
><br>
>> On Feb 4, 2017, at 8:07 AM, David Blodgett <<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a> <mailto:<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a>>> wrote:<br>
>><br>
>> Dear Chris,<br>
>><br>
>> 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.<br>
>><br>
>> 1) how would you translate between netcdf geometries and, say geo JSON?<br>
>><br>
>> 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.<br>
>><br>
>> 2) Break Values<br>
>><br>
>> 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.<br>
>><br>
>> 3) Ragged Indexing<br>
>><br>
>> 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.<br>
>><br>
>> On to Bob?s comments.<br>
>><br>
>> Regarding aligning with other data models / encodings, I guess this needs to be unpacked a bit.<br>
>><br>
>> 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.<br>
>> 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.<br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.*.<br>
>><br>
>> Best Regards,<br>
>><br>
>> - Dave<br>
>><br>
>><br>
>>> On Feb 3, 2017, at 3:31 PM, Chris Barker <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a> <mailto:<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>><wbr>> wrote:<br>
>>><br>
>>> a few thoughts. First, I think there are three core "issues" that need to be resolved:<br>
>>><br>
>>> 1) Coordinate indexing (indirection)<br>
>>><br>
>>> the question of whether you have an array of "vertices" that the geomotry types index into to get thier data:<br>
>>><br>
>>> Advantages:<br>
>>>  - if a number of geometries share a lot of vertices, it can be more efficient<br>
>>>  - 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Disadvantages:<br>
>>>  -  if the geometries do not share many vertices, it is less efficient.<br>
>>>  -  there are additional code complications in "getting" the vertices of the given geometry<br>
>>>  - it does not match the OGC data model.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> One way to think about it -- how would you translate between netcdf geometries and, say geo JSON:<br>
>>>   - nc => geojson would lose the shared index info.<br>
>>>   - 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?<br>
>>><br>
>>> > > Break values<br>
>>><br>
>>> 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?)<br>
>>><br>
>>> > > Ragged indexing<br>
>>><br>
>>> There are two "natural" ways to represent a ragged array:<br>
>>><br>
>>> (a) store the length of each "row"<br>
>>> (b) store the index to the beginning (or end) or each "row"<br>
>>><br>
>>> CF already uses (a). However, working with it, I'm pretty convinced that it's the "wrong" choice:<br>
>>><br>
>>> 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)<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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:<br>
>>><br>
>>>  - 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)<br>
>>><br>
>>>  - 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.<br>
>>><br>
>>> So I'm for the "new" way of representing ragged arrays<br>
>>><br>
>>> -CHB<br>
>>><br>
>>><br>
>>> On Fri, Feb 3, 2017 at 11:41 AM, Bob Simons - NOAA Federal <<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a> <mailto:<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>>> wrote:<br>
>>> 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?<br>
>>><br>
>>> 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?<br>
>>><br>
>>> 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?<br>
>>><br>
>>> ---<br>
>>> Rather than just be a naysayer, let me suggest a very different alternative:<br>
>>><br>
>>> 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.<br>
>>> DSG solved this (5 different ways!), but only for DSG.<br>
>>> The Simple Features proposal seeks to solve the problem for Simple Features.<br>
>>> We still have no support for Unicode variable-length Strings.<br>
>>><br>
>>> 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?<br>
>>> The solution could be a simple variant of one of the DSG solutions, but generalized so that it could be used in different situations.<br>
>>> 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.<br>
>>> Some work on this is already done: I think the netcdf-java API already supports variable-length arrays when reading netcdf-4 files.<br>
>>> 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.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Fri, Feb 3, 2017 at 9:07 AM, <<a href="mailto:cf-metadata-request@cgd.ucar.edu" target="_blank">cf-metadata-request@cgd.ucar.<wbr>edu</a> <mailto:<a href="mailto:cf-metadata-request@cgd.ucar.edu" target="_blank">cf-metadata-request@cg<wbr>d.ucar.edu</a>>> wrote:<br>
>>> Date: Fri, 3 Feb 2017 11:07:00 -0600<br>
>>> From: David Blodgett <<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a> <mailto:<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a>>><br>
>>> To: Bob Simons - NOAA Federal <<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a> <mailto:<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>>><br>
>>> Cc: CF Metadata <<a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.edu</a> <mailto:<a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.e<wbr>du</a>>><br>
>>> Subject: Re: [CF-metadata] Extension of Discrete Sampling Geometries<br>
>>>         for Simple Features<br>
>>> Message-ID: <<a href="mailto:8EE85E65-2815-4720-90FC-13C72D3C7952@usgs.gov" target="_blank">8EE85E65-2815-4720-90FC-13C72<wbr>D3C7952@usgs.gov</a> <mailto:<a href="mailto:8EE85E65-2815-4720-90FC-13C72D3C7952@usgs.gov" target="_blank">8EE85E65-2815-4720-90F<wbr>C-13C72D3C7952@usgs.gov</a>>><br>
>>> Content-Type: text/plain; charset="utf-8"<br>
>>><br>
>>> Dear Bob,<br>
>>><br>
>>> I?ll just take these in line.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 3) The google doc linked in my response contains the encoding we are proposing as a starting point for conversation: <a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a>> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a>>> I want to stress, as a starting point for discussion. I expect that this proposal will change drastically before we?re done.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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).<br>
>>><br>
>>> Thanks for your questions, hopefully my answers close some gaps for you.<br>
>>><br>
>>> - Dave<br>
>>><br>
>>> > On Feb 3, 2017, at 10:47 AM, Bob Simons - NOAA Federal <<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a> <mailto:<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>>> wrote:<br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> > 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.<br>
>>> > 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)?<br>
>>> > Does your proposal deviate in any way from the standard's capabilities?<br>
>>> > Do you advocate following the entire WKT standard, e.g., supporting all the feature types that WKT supports?<br>
>>> ><br>
>>> > 3) Since you are not using the WKT encoding, but creating your own, where is the definition of the encoding system you are using?<br>
>>> ><br>
>>> > 4) This is a little out of CF scope, but:<br>
>>> > 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?<br>
>>> ><br>
>>> > 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?<br>
>>> ><br>
>>> > Thanks for answering these questions.<br>
>>> > Please forgive me if I missed parts of your proposal that answer these questions.<br>
>>> ><br>
>>> ><br>
>>> > On Thu, Feb 2, 2017 at 5:57 AM, <<a href="mailto:cf-metadata-request@cgd.ucar.edu" target="_blank">cf-metadata-request@cgd.ucar.<wbr>edu</a> <mailto:<a href="mailto:cf-metadata-request@cgd.ucar.edu" target="_blank">cf-metadata-request@cg<wbr>d.ucar.edu</a>> <mailto:<a href="mailto:cf-metadata-request@cgd.ucar.edu" target="_blank">cf-metadata-request@cg<wbr>d.ucar.edu</a> <mailto:<a href="mailto:cf-metadata-request@cgd.ucar.edu" target="_blank">cf-metadata-request@cg<wbr>d.ucar.edu</a>>>> wrote:<br>
>>> > Date: Thu, 2 Feb 2017 07:57:36 -0600<br>
>>> > From: David Blodgett <<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a> <mailto:<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a>> <mailto:<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a> <mailto:<a href="mailto:dblodgett@usgs.gov" target="_blank">dblodgett@usgs.gov</a>>>><br>
>>> > To: <<a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.edu</a> <mailto:<a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.e<wbr>du</a>> <mailto:<a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.e<wbr>du</a> <mailto:<a href="mailto:cf-metadata@cgd.ucar.edu" target="_blank">cf-metadata@cgd.ucar.e<wbr>du</a>>>><br>
>>> > Subject: [CF-metadata] Extension of Discrete Sampling Geometries for<br>
>>> >         Simple  Features<br>
>>> > Message-ID: <<a href="mailto:224C2828-7212-449F-8C2C-97D903F6BE1E@usgs.gov" target="_blank">224C2828-7212-449F-8C2C-97D90<wbr>3F6BE1E@usgs.gov</a> <mailto:<a href="mailto:224C2828-7212-449F-8C2C-97D903F6BE1E@usgs.gov" target="_blank">224C2828-7212-449F-8C2<wbr>C-97D903F6BE1E@usgs.gov</a>> <mailto:<a href="mailto:224C2828-7212-449F-8C2C-97D903F6BE1E@usgs.gov" target="_blank">224C2828-7212-449F-8C2<wbr>C-97D903F6BE1E@usgs.gov</a> <mailto:<a href="mailto:224C2828-7212-449F-8C2C-97D903F6BE1E@usgs.gov" target="_blank">224C2828-7212-449F-8C2<wbr>C-97D903F6BE1E@usgs.gov</a>>>><br>
>>> > Content-Type: text/plain; charset="utf-8"<br>
>>> ><br>
>>> > Dear CF Community,<br>
>>> ><br>
>>> > 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 <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a>> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a>>>> 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.<br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> > Thank you for your time and consideration.<br>
>>> ><br>
>>> > Best Regards,<br>
>>> ><br>
>>> > David Blodgett, Tim Whiteaker, and Ben Koziol<br>
>>> ><br>
>>> > Proposed Extension to NetCDF-CF for Simple Geometries<br>
>>> ><br>
>>> > Preface<br>
>>> ><br>
>>> > 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. <<a href="https://en.wikipedia.org/wiki/Simple_Features" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Simple_Features</a> <<a href="https://en.wikipedia.org/wiki/Simple_Features" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Simple_Features</a>> <<a href="https://en.wikipedia.org/wiki/Simple_Features" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Simple_Features</a> <<a href="https://en.wikipedia.org/wiki/Simple_Features" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Simple_Features</a>>>> 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.<br>
>>> ><br>
>>> > The other existing standard to mention is UGRID convention <<a href="http://ugrid-conventions.github.io/ugrid-conventions/" rel="noreferrer" target="_blank">http://ugrid-conventions.gith<wbr>ub.io/ugrid-conventions/</a> <<a href="http://ugrid-conventions.github.io/ugrid-conventions/" rel="noreferrer" target="_blank">http://ugrid-conventions.gith<wbr>ub.io/ugrid-conventions/</a>> <<a href="http://ugrid-conventions.github.io/ugrid-conventions/" rel="noreferrer" target="_blank">http://ugrid-conventions.gith<wbr>ub.io/ugrid-conventions/</a> <<a href="http://ugrid-conventions.github.io/ugrid-conventions/" rel="noreferrer" target="_blank">http://ugrid-conventions.gith<wbr>ub.io/ugrid-conventions/</a>>>>. 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.<br>
>>> ><br>
>>> > Terms and Definitions<br>
>>> ><br>
>>> > (Taken from OGC 06-103r4 OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture <<a href="http://www.opengeospatial.org/standards/sfa" rel="noreferrer" target="_blank">http://www.opengeospatial.org<wbr>/standards/sfa</a> <<a href="http://www.opengeospatial.org/standards/sfa" rel="noreferrer" target="_blank">http://www.opengeospatial.org<wbr>/standards/sfa</a>> <<a href="http://www.opengeospatial.org/standards/sfa" rel="noreferrer" target="_blank">http://www.opengeospatial.org<wbr>/standards/sfa</a> <<a href="http://www.opengeospatial.org/standards/sfa" rel="noreferrer" target="_blank">http://www.opengeospatial.org<wbr>/standards/sfa</a>>>>.)<br>
>>> ><br>
>>> > Feature: Abstraction of real world phenomena - typically a geospatial abstraction with associated descriptive attributes.<br>
>>> > Simple Feature: A feature with all geometric attributes described piecewise by straight line or planar interpolation between point sets.<br>
>>> > Geometry (geometric complex): A set of disjoint geometric primitives - one or more points, lines, or polygons that form the spatial representation of a feature.<br>
>>> > Introduction<br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> > Changes to Existing CF Specification<br>
>>> ><br>
>>> > In NetCDF-CF 1.7, Discrete Sampling Geometries separate dimensions and variables into two types ? instance and element <<a href="http://cfconventions.org/cf-conventions/cf-conventions.html#_collections_instances_and_elements" rel="noreferrer" target="_blank">http://cfconventions.org/cf-c<wbr>onventions/cf-conventions.html<wbr>#_collections_instances_and_el<wbr>ements</a> <<a href="http://cfconventions.org/cf-conventions/cf-conventions.html#_collections_instances_and_elements" rel="noreferrer" target="_blank">http://cfconventions.org/cf-c<wbr>onventions/cf-conventions.html<wbr>#_collections_instances_and_el<wbr>ements</a>> <<a href="http://cfconventions.org/cf-conventions/cf-conventions.html#_collections_instances_and_elements" rel="noreferrer" target="_blank">http://cfconventions.org/cf-c<wbr>onventions/cf-conventions.html<wbr>#_collections_instances_and_el<wbr>ements</a> <<a href="http://cfconventions.org/cf-conventions/cf-conventions.html#_collections_instances_and_elements" rel="noreferrer" target="_blank">http://cfconventions.org/cf-c<wbr>onventions/cf-conventions.html<wbr>#_collections_instances_and_el<wbr>ements</a>>>>. 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 <<a href="http://cfconventions.org/cf-conventions/cf-conventions.html#_features_and_feature_types" rel="noreferrer" target="_blank">http://cfconventions.org/cf-c<wbr>onventions/cf-conventions.html<wbr>#_features_and_feature_types</a> <<a href="http://cfcon" rel="noreferrer" target="_blank">http://cfcon</a><br>
 <a href="http://ventions.org/cf-conventions/cf-conventions.html#_features_and_feature_types" rel="noreferrer" target="_blank">ventions.org/cf-conventions/c<wbr>f-conventions.html#_features_a<wbr>nd_feature_types</a>> <<a href="http://cfconventions.org/cf-conventions/cf-conventions.html#_features_and_feature_types" rel="noreferrer" target="_blank">http://cfconventions.org/cf-c<wbr>onventions/cf-conventions.html<wbr>#_features_and_feature_types</a> <<a href="http://cfconventions.org/cf-conventions/cf-conventions.html#_features_and_feature_types" rel="noreferrer" target="_blank">http://cfconventions.org/cf-c<wbr>onventions/cf-conventions.html<wbr>#_features_and_feature_types</a>>><wbr>> such that the geospatial coordinates of the instances can be point, multi-point, line, multi-line, polygon, or multi-polyg<br>
>>>  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<br>
>>> >  s google doc for specific proposed changes. <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a>> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a> <<a href="http://goo.gl/Kq9ASq" rel="noreferrer" target="_blank">http://goo.gl/Kq9ASq</a>>>><br>
>>> > Motivation<br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> > Looking Forward<br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> > Three Alternative Approaches<br>
>>> ><br>
>>> > 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 <<a href="https://en.wikipedia.org/wiki/Well-known_text" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Well-known_text</a> <<a href="https://en.wikipedia.org/wiki/Well-known_text" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Well-known_text</a>> <<a href="https://en.wikipedia.org/wiki/Well-known_text" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Well-known_text</a> <<a href="https://en.wikipedia.org/wiki/Well-known_text" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Well-known_text</a>>>>. We considered three high level design approaches while developing this proposal.<br>
>>> ><br>
>>> > 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).<br>
>>> > 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.<br>
>>> > 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.<br>
>>> > Selected Approach<br>
>>> ><br>
>>> > 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:<br>
>>> ><br>
>>> > The second approach is just as or more human-readable than the third.<br>
>>> > Use of break values keeps geometries relatively atomic.<br>
>>> > Will be familiar to developers who are familiar with the WKT geometry format.<br>
>>> > Character arrays, which are needed for options one and three, are cumbersome to use in some programming languages in common use with NetCDF.<br>
>>> > 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.<br>
>>> > Example: Representation of WKT-Style Polygons in a NetCDF-3 timeSeriesfeatureType<br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> > The attribute contiguous_ragged_dimension with value of a dimension in the file.<br>
>>> > The geom_coordinates attribute with a value containing a space separated string of variable names.<br>
>>> > The cf_role geometry_x_node and geometry_y_node.<br>
>>> > 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.<br>
>>> ><br>
>>> > netcdf multipolygon_example {<br>
>>> > dimensions:<br>
>>> >   node = 47 ;<br>
>>> >   indices = 55 ;<br>
>>> >   instance = 3 ;<br>
>>> >   time = 5 ;<br>
>>> >   strlen = 5 ;<br>
>>> > variables:<br>
>>> >   char instance_name(instance, strlen) ;<br>
>>> >     instance_name:cf_role = "timeseries_id" ;<br>
>>> >   int coordinate_index(indices) ;<br>
>>> >     coordinate_index:geom_type = "multipolygon" ;<br>
>>> >     coordinate_index:geom_coordin<wbr>ates = "x y" ;<br>
>>> >     coordinate_index:multipart_br<wbr>eak_value = -1 ;<br>
>>> >     coordinate_index:hole_break_v<wbr>alue = -2 ;<br>
>>> >     coordinate_index:outer_ring_o<wbr>rder = "anticlockwise" ;<br>
>>> >     coordinate_index:closure_conv<wbr>ention = "last_node_equals_first" ;<br>
>>> >   int coordinate_index_start(instanc<wbr>e) ;<br>
>>> >     coordinate_index_start:long_n<wbr>ame = "index of first coordinate in each instance geometry" ;<br>
>>> >     coordinate_index_start:contig<wbr>uous_ragged_dimension = "indices" ;<br>
>>> >   double x(node) ;<br>
>>> >     x:units = "degrees_east" ;<br>
>>> >     x:standard_name = "longitude" ; // or projection_x_coordinate<br>
>>> >     X:cf_role = "geometry_x_node" ;<br>
>>> >   double y(node) ;<br>
>>> >     y:units = "degrees_north" ;<br>
>>> >     y:standard_name = ?latitude? ; // or projection_y_coordinate<br>
>>> >     y:cf_role = "geometry_y_node"<br>
>>> >   double someVariable(instance) ;<br>
>>> >     someVariable:long_name = "a variable describing a single-valued attribute of a polygon" ;<br>
>>> >   int time(time) ;<br>
>>> >     time:units = "days since 2000-01-01" ;<br>
>>> >   double someData(instance, time) ;<br>
>>> >     someData:coordinates = "time x y" ;<br>
>>> >     someData:featureType = "timeSeries" ;<br>
>>> > // global attributes:<br>
>>> >     :Conventions = "CF-1.8" ;<br>
>>> ><br>
>>> > data:<br>
>>> ><br>
>>> >  instance_name =<br>
>>> >   "flash",<br>
>>> >   "bang",<br>
>>> >   "pow" ;<br>
>>> ><br>
>>> >  coordinate_index = 0, 1, 2, 3, 4, -2, 5, 6, 7, 8, -2, 9, 10, 11, 12, -2, 13, 14, 15, 16,<br>
>>> >     -1, 17, 18, 19, 20, -1, 21, 22, 23, 24, 25, 26, 27, 28, -1, 29, 30, 31, 32, 33,<br>
>>> >     34, -2, 35, 36, 37, 38, 39, 40, 41, 42, -1, 43, 44, 45, 46 ;<br>
>>> ><br>
>>> >  coordinate_index_start = 0, 30, 46 ;<br>
>>> ><br>
>>> >  x = 0, 20, 20, 0, 0, 1, 10, 19, 1, 5, 7, 9, 5, 11, 13, 15, 11, 5, 9, 7,<br>
>>> >     5, 11, 15, 13, 11, -40, -20, -45, -40, -20, -10, -10, -30, -45, -20, -30, -20, -20, -30, 30,<br>
>>> >     45, 10, 30, 25, 50, 30, 25 ;<br>
>>> ><br>
>>> >  y = 0, 0, 20, 20, 0, 1, 5, 1, 1, 15, 19, 15, 15, 15, 19, 15, 15, 25, 25, 29,<br>
>>> >     25, 25, 25, 29, 25, -40, -45, -30, -40, -35, -30, -10, -5, -20, -35, -20, -15, -25, -20, 20,<br>
>>> >     40, 40, 20, 5, 10, 15, 5 ;<br>
>>> ><br>
>>> >  someVariable = 1, 2, 3 ;<br>
>>> ><br>
>>> >  time = 1, 2, 3, 4, 5 ;<br>
>>> ><br>
>>> >  someData =<br>
>>> >   1, 2, 3, 4, 5,<br>
>>> >   1, 2, 3, 4, 5,<br>
>>> >   1, 2, 3, 4, 5 ;<br>
>>> > }<br>
>>> > How To Interpret<br>
>>> ><br>
>>> > Starting from the timeSeries variables:<br>
>>> ><br>
>>> > See CF-1.8 conventions.<br>
>>> > See the timeSeries featureType.<br>
>>> > Find the timeseries_id cf_role.<br>
>>> > Find the coordinates attribute of data variables.<br>
>>> > 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.<br>
>>> > Find the coordinate index variable with geom_coordinates that point to the nodes.<br>
>>> > 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.<br>
>>> > Iterate over polygons, parsing out geometries using the contiguous ragged start variable and coordinate index variable to interpret the coordinate data variables.<br>
>>> > Or, without reference to timeSeries:<br>
>>> ><br>
>>> > See CF-1.8 conventions.<br>
>>> > See the geom_type of multipolygon.<br>
>>> > Find the variable with a contiguous_ragged_dimension matching the coordinate index variable?s dimension.<br>
>>> > See the geom_coordinates of x y.<br>
>>> > 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.<br>
>>> ><br>
>>> > -------------- next part --------------<br>
>>> > An HTML attachment was scrubbed...<br>
>>> > URL: <<a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170202/4ce5b42f/attachment.html" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/p<wbr>ipermail/cf-metadata/attachmen<wbr>ts/20170202/4ce5b42f/attachmen<wbr>t.html</a> <<a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170202/4ce5b42f/attachment.html" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/p<wbr>ipermail/cf-metadata/attachmen<wbr>ts/20170202/4ce5b42f/attachmen<wbr>t.html</a>> <<a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170202/4ce5b42f/attachment.html" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/p<wbr>ipermail/cf-metadata/attachmen<wbr>ts/20170202/4ce5b42f/attachmen<wbr>t.html</a> <<a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170202/4ce5b42f/attachment.html" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/p<wbr>ipermail/cf-metadata/attachmen<wbr>ts/20170202/4ce5b42f/attachmen<wbr>t.html</a>>>><br>
>>> ><br>
>>> > ------------------------------<br>
>>> ><br>
>>> > Subject: Digest Footer<br>
>>> ><br>
>>> > ______________________________<wbr>_________________<br>
>>> > CF-metadata mailing list<br>
>>> > <a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a> <mailto:<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.e<wbr>du</a>> <mailto:<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.e<wbr>du</a> <mailto:<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.e<wbr>du</a>>><br>
>>> > <a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a> <<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/m<wbr>ailman/listinfo/cf-metadata</a>> <<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/m<wbr>ailman/listinfo/cf-metadata</a> <<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/m<wbr>ailman/listinfo/cf-metadata</a>>><br>
>>> ><br>
>>> ><br>
>>> > ------------------------------<br>
>>> ><br>
>>> > End of CF-metadata Digest, Vol 166, Issue 3<br>
>>> > ******************************<wbr>*************<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > Sincerely,<br>
>>> ><br>
>>> > Bob Simons<br>
>>> > IT Specialist<br>
>>> > Environmental Research Division<br>
>>> > NOAA Southwest Fisheries Science Center<br>
>>> > 99 Pacific St., Suite 255A      (New!)<br>
>>> > Monterey, CA 93940               (New!)<br>
>>> > Phone: <a href="tel:(831)%20333-9878" value="+18313339878" target="_blank">(831)333-9878</a> <tel:%28831%29333-9878>            (New!)<br>
>>> > Fax:   <a href="tel:(831)%20648-8440" value="+18316488440" target="_blank">(831)648-8440</a> <tel:%28831%29648-8440><br>
>>> > Email: <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a> <mailto:<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>> <mailto:<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a> <mailto:<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>>><br>
>>> ><br>
>>> > The contents of this message are mine personally and<br>
>>> > do not necessarily reflect any position of the<br>
>>> > Government or the National Oceanic and Atmospheric Administration.<br>
>>> > <>< <>< <>< <>< <>< <>< <>< <>< <><<br>
>>> ><br>
>>> > ______________________________<wbr>_________________<br>
>>> > CF-metadata mailing list<br>
>>> > <a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a> <mailto:<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.e<wbr>du</a>><br>
>>> > <a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a> <<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/m<wbr>ailman/listinfo/cf-metadata</a>><br>
>>><br>
>>> -------------- next part --------------<br>
>>> An HTML attachment was scrubbed...<br>
>>> URL: <<a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170203/4ff55def/attachment.html" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/p<wbr>ipermail/cf-metadata/attachmen<wbr>ts/20170203/4ff55def/attachmen<wbr>t.html</a> <<a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170203/4ff55def/attachment.html" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/p<wbr>ipermail/cf-metadata/attachmen<wbr>ts/20170203/4ff55def/attachmen<wbr>t.html</a>>><br>
>>><br>
>>> ------------------------------<br>
>>><br>
>>> Subject: Digest Footer<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> CF-metadata mailing list<br>
>>> <a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a> <mailto:<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.e<wbr>du</a>><br>
>>> <a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a> <<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/m<wbr>ailman/listinfo/cf-metadata</a>><br>
>>><br>
>>><br>
>>> ------------------------------<br>
>>><br>
>>> End of CF-metadata Digest, Vol 166, Issue 5<br>
>>> ******************************<wbr>*************<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Sincerely,<br>
>>><br>
>>> Bob Simons<br>
>>> IT Specialist<br>
>>> Environmental Research Division<br>
>>> NOAA Southwest Fisheries Science Center<br>
>>> 99 Pacific St., Suite 255A      (New!)<br>
>>> Monterey, CA 93940               (New!)<br>
>>> Phone: <a href="tel:(831)%20333-9878" value="+18313339878" target="_blank">(831)333-9878</a> <tel:(831)%20333-9878>            (New!)<br>
>>> Fax:   <a href="tel:(831)%20648-8440" value="+18316488440" target="_blank">(831)648-8440</a> <tel:(831)%20648-8440><br>
>>> Email: <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a> <mailto:<a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a>><br>
>>><br>
>>> The contents of this message are mine personally and<br>
>>> do not necessarily reflect any position of the<br>
>>> Government or the National Oceanic and Atmospheric Administration.<br>
>>> <>< <>< <>< <>< <>< <>< <>< <>< <><<br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> CF-metadata mailing list<br>
>>> <a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a> <mailto:<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.e<wbr>du</a>><br>
>>> <a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a> <<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/m<wbr>ailman/listinfo/cf-metadata</a>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>> Christopher Barker, Ph.D.<br>
>>> Oceanographer<br>
>>><br>
>>> Emergency Response Division<br>
>>> NOAA/NOS/OR&R            <a href="tel:(206)%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a>   voice<br>
>>> 7600 Sand Point Way NE   <a href="tel:(206)%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a>   fax<br>
>>> Seattle, WA  98115       <a href="tel:(206)%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a>   main reception<br>
>>><br>
>>> <a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a> <mailto:<a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>><wbr>______________________________<wbr>_________________<br>
>>> CF-metadata mailing list<br>
>>> <a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a> <mailto:<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.e<wbr>du</a>><br>
>>> <a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a> <<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/m<wbr>ailman/listinfo/cf-metadata</a>><br>
>><br>
><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170217/b548709a/attachment.html" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/p<wbr>ipermail/cf-metadata/attachmen<wbr>ts/20170217/b548709a/attachmen<wbr>t.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
CF-metadata mailing list<br>
<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a><br>
<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a><br>
<br>
<br>
------------------------------<br>
<br>
End of CF-metadata Digest, Vol 166, Issue 15<br>
******************************<wbr>**************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_116818467641281697m_-2050441167202443296gmail_signature"><div dir="ltr">Sincerely,<br><br>Bob Simons<br>IT Specialist<br>Environmental Research Division<br>NOAA Southwest Fisheries Science Center <br>99 Pacific St., Suite 255A      (New!)<br>Monterey, CA 93940               (New!) <br>Phone: <a href="tel:(831)%20333-9878" value="+18313339878" target="_blank">(831)333-9878</a>            (New!<span style="font-size:13.3333px">)</span><div>Fax:   <a href="tel:(831)%20648-8440" value="+18316488440" target="_blank">(831)648-8440</a><br>Email: <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a><br><br>The contents of this message are mine personally and <br>do not necessarily reflect any position of the <br>Government or the National Oceanic and Atmospheric Administration.<br><>< <>< <>< <>< <>< <>< <>< <>< <>< <br><br></div></div></div>
</div></div>
<br>______________________________<wbr>_________________<br>
CF-metadata mailing list<br>
<a href="mailto:CF-metadata@cgd.ucar.edu" target="_blank">CF-metadata@cgd.ucar.edu</a><br>
<a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata" rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/ma<wbr>ilman/listinfo/cf-metadata</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div class="m_116818467641281697gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="font-family:monospace,monospace">David Hassell</span><span style="font-family:monospace,monospace"><br>National Centre for Atmospheric Science</span><span style="font-family:monospace,monospace"><br>Department of Meteorology, University of Reading,<br>Earley Gate, PO Box 243, Reading RG6 6BB<br>Tel: <a href="tel:+44%20118%20378%205613" value="+441183785613" target="_blank">+44 118 378 5613</a></span><span style="font-family:monospace,monospace"><br><a href="http://www.met.reading.ac.uk/" target="_blank">http://www.met.reading.ac.uk/</a></span><span style="font-family:monospace,monospace"></span> </div></div></div></div></div></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sincerely,<br><br>Bob Simons<br>IT Specialist<br>Environmental Research Division<br>NOAA Southwest Fisheries Science Center <br>99 Pacific St., Suite 255A      (New!)<br>Monterey, CA 93940               (New!) <br>Phone: (831)333-9878            (New!<span style="font-size:13.3333339691162px">)</span><div>Fax:   (831)648-8440<br>Email: <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a><br><br>The contents of this message are mine personally and <br>do not necessarily reflect any position of the <br>Government or the National Oceanic and Atmospheric Administration.<br><>< <>< <>< <>< <>< <>< <>< <>< <>< <br><br></div></div></div>
</div>