On Mon, Sep 22, 2014 at 10:11 AM, Bert Jagers <[email protected]> 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 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
