On Mon, Sep 22, 2014 at 10:11 AM, Bert Jagers <Bert.Jagers at deltares.nl>
wrote:
>
>
>> I also have some Python code for converting polygons from a watersheds
>> shapefile into the UGRID format (
>> https://github.com/ugrid-conventions/ugrid-conventions/blob/v0.9.0/ugrid-conventions.md#2d-flexible-mesh-mixed-triangles-quadrilaterals-etc-topology).
>> The major limitation here is that UGRID expects no gaps between the "faces"
>> which limits its ability to store multi-geometries (i.e. Hawaii).
>>
>
> It also expects each "face" to have the same number of vertices, more or
> less.But it's a good idea to leverage that -- let's keep things as
> consistent as possible.
>
> I wouldn't say that we expect every "face" to have about the same number
> of vertices,
>
well, I said "More or less" ;-)
What I meant is that the use case we designed it for is usntructured meshes
for models -- sophisticated models can have elements with different numbers
of vertices, but usually (always) they are the same order of magnitude --
i.e hexagons and traingles in teh smae mesh, but not traingles and
hundred-edge elements...
>
> HDF5/NetCDF4 can help to reduce the problem on disk, but you may have a
> temporary memory issue.
>
Right -- that's why (other than "purity") I like the ragged array approach
better if you really do have ragged arrays....
> We used the fill approach because it seemed most consistent with the CF
> bounds polygons at the time.
>
Also because it fit the data model pretty well -- and the "all elements are
the same number of vertices" is the really common case...
I don't know how different the ragged approach actually is. If you read and
> write multiple polygon, you may still have the same issues. The linearly
> indexed example that you gave:
>
if you want to change the polygons in the middle, it would et ugly, yes.
YOu'd want to consider the array immutable with respect to the number of
vertices. But netCDF / CF is generally a storage/transmission format, so
altering in place isn't too key.
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#Example%20H.2.4.1
>
> would map to an efficient storage in memory as well, so that looks pretty
> attractive to me. Maybe we could also consider it as an alternative for
> UGRID storage.
>
It's kind of a pain to work with, though -- not sure it would be helpful
for the UGRID case.
I wouldn't go for the boundary_node_connectivity since those were
> introduced to specifically refer to boundaries.
>
well, in this case, this is the boundary of the polygons -- not sure it's
so bad. But I guess no reason not to use edge-node_connectivity in this
case -- as these ARE the only edges defined. But there is more of an
expectation that boundaries have attributes that define what type they are,
which wold be used to specify with polygon was which --not sure I'd expect
that with the edge_node case -- though edges also often have properties.
And edge_face_connectivity would get really ugly -- so hopefully no one
would try to construct that!
Before anything else I would check with Ben Domenico and Stefano Nativi
> since they (and possibly others) have been looking at mapping OGC and
> netCDF data models. I guess that this question should have come up in that
> context.
>
good idea, yes.
-CHB
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140922/03a7fed5/attachment-0001.html>
Received on Mon Sep 22 2014 - 13:33:34 BST
