<div dir="ltr">A couple quick comments:<div><br></div><div>I think we're close here, so that's good. I'm not that clear on where tehre are decisions left to be made, but I'll highlight two:</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><div>... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Your aim is to<br>
describe the network alone.<br></blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> a collection of timeseries is stored as a<br>
data variable with a single dimension of time and a single dimension of space.<br></blockquote><div><br></div><div>I don't see a conflict here -- if you can describe the network (geometry) then you can associate data with it (UGRID used indexes into cells, nodes, etc, this should be equally applicable)</div><div><br></div><div> > You would like to have SOMETHING alone in the file, just to</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
describe the network itself. CF doesn't do this at present (domain without<br>
data),</blockquote><div><br></div><div>isn't a set of coordinate variables essentially do that? i.e. you can define a rectangular grid -- even if there is no data on it. And you can certainly do that with UGRID, which is another standard, but I don't think it conflicts with CF.</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">Taking your previous comments into account (I'll come back to them below), as<br>
a modified version of what I suggested before, here's a possible way to handle<br>
this case, for a small number (3) of linestrings:<br></blockquote><div><br></div><div>That looks good to me, I think...</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">   <br>
  data:<br>
    SOMETHING=2, 4, 3;<br>
    lon=0, 1,  0, -1, -2, -3,  2, 3, 4;<br>
    lat=51, 52,  51, 50, 50, 49,  55, 55, 56;<br></blockquote><div><br></div><div>I'm confused about what this is.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">These simple geometries can be regarded as a more complex alternative to cells<br>
bounds - each timeseries has a complicated geometry of nodes and lines, but<br>
logically it's still a single "cell".</blockquote><div><br></div><div>yup.</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"> For the sake of applications which can<br>
read CF but don't understand simple geometries, it might be a good idea in<br>
addition to provide a "representative" location for each timeseries, as<br>
representive_lat(station) and representative_lon(station), which could for<br>
instance be the mean of the node coordinates for each geometry.</blockquote><div><br></div><div>We do that in UGRID, too -- I think it's even required (and called coordinates, actually). It may make little sense with complex geometries, but it can be handy.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>> You propose the index variable in order for the convention to be like<br>
> ugrid. However this still seems to me to be an unnecessary complexity and<br>
> use of space if you aren’t going to have many shared nodes.</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To be frank, I'm not convinced by either argument. Regarding the first, in your<br>
example you don't reuse any points at all. Can you give an example where there<br>
is a lot of reuse?</blockquote><div><br></div><div>The stream network example would be a good one. also things like political boundaries -- they tend to be complex polygons with shared vertices.</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"> Regarding the second, I agree that it is a nuisance and<br>
unreliable to have to make comparisons with tolerance between floating-point<br>
numbers to determine equality. However, when you write a file, I suppose you<br>
can and would write exactly the same numbers for the coordinates of a node if<br>
it appears several times, wouldn't you? Thus the coincidence of nodes can be<br>
tested by *exact* equality of coordinates - no tolerance needed.<br></blockquote><div><br></div><div>you still don't know fo sure if the vertices are the SAME or if the Happen to be the same.</div><div><br></div><div>This is a tough one -- the "normal" GIS data model does not have shared nodes (that I know of) so perhaps we should follow that. But this lack of shared nodes is actually a substantial pain for GIS systems and uses -- there is a lot of complex "snapping" that needs to be done.  So I'm on the fence about this -- I'm pretty convinced shared nodes are a better model, but if we want to interact seamlessly with other GIS formats, we may be better off matching that data model.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In my example above, I assumed the polygons have no holes in them, so I've<br>
omitted the inside/outside information. If needed, this information could also<br>
be an attribute e.g. SOMETHING:inout="OIIIOOOOIOO", with as many elements as<br>
there are polygons in total. Thinking again about it, I wonder whether this<br>
information is really needed. If you draw all the polygons, isn't it apparent<br>
which ones are inside anyway? When would you use this information?<br></blockquote><div><br></div><div>it's not always clear. if there is a hole in a polygon, you can figure it out, but if there is a lake in a land polygon, and a island in the lake, then it gets pretty tricky.</div><div><br></div><div>I think shapefiles use clockwise vs anti-clockwise to indicate inside-outside, but IIUC, they are pretty limited with nested polygons, too.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My scheme avoids the use of break values, which you're not very keen on your-<br>
selves, it sounds like. </blockquote><div><br></div><div>I don't like break values either.</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">You wrote > - It is more difficult to extract a single geometry using this<br>
approach.  It's not hard, though, and the same comment would apply to the CF<br>
contiguous ragged array representation.</blockquote><div><br></div><div>yes -- you can represent a ragged array by either specifying the start-index of each "row", or by specifying the size of each row. CF specifies the size of each row. I think that's a worse way to  do it -- it's similar if you are looping through  from the start, but much harder to get an arbitrary row in the middle -- but I"ve gone with the the CF way for other stuff [1] because it's better not to have two ways to do the same thing. So we might as well stick with it here, too.</div><div><br></div><div>-CHB</div><div><br></div><div>[1] a netcdf format for particle tracking model output:</div><div><br></div><div><a href="https://github.com/NOAA-ORR-ERD/nc_particles">https://github.com/NOAA-ORR-ERD/nc_particles</a><br></div><div><br></div><div><br></div></div><div><br></div>-- <br><div class="gmail-m_-8811215592156542489gmail_signature"><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></div>
</div></div>