A little note: On Tue, Nov 1, 2016 at 9:43 AM, Chris Barker <[email protected]> wrote:
> I'm on shakier ground about when you want to use a GeometryCollection vs a > FeatureCollection, but I _think_ that the point of a geometrycollection is > that you can group different types of geometry -- but still want them to be > treated as a single entity. > some quick googling led me to this discussion: https://github.com/topojson/topojson/issues/37 which indicates that a GeometryCollection is generally treated as a single entity. -CHB > I've dealt with all this trying to jam data that fits well into netcdf > into geoJSON, or GIS_oriented systems -- it's quite hard to be efficient > about it :-) - i.e there is really no way to associate an array of data > with an array of geometries -- it sure looks like you could do it with > GeometryCollections, but the systems aren't expecting that. > > Of course, CF doesn't need to follow this data model, but it's a good idea > to be informed by it. > > >> Nonetheless in both cases the geometries have to be described. I think the >> difference is how we attach this description to the data or coordinates, >> rather >> than how the description is constructed. >> > > indeed. > > >> You propose the index variable in order for the convention to be like >> ugrid. >> However this still seems to me to be an unnecessary complexity and use of >> space >> if you aren't going to have many shared nodes. > > > In the GIS data model, nodes are not shared between geometries, and you > are quite right that keeping nodes separate with geometries indexing nto it > is an added complication and would not be space-efficient. > > However, there is another reason to do it -- it makes it definitive that > two (or more) geometries share the exact same node, rather than them being > distinct points that happened to be at the same location (Or worse, with FP > error and all, two points that are very close)e > > This is actually a major limitation in the standard GIS model. > > >> I think the case for having >> another convention, distinct from ugrid, is stronger if it is *unlike* >> ugrid >> in this respect, and therefore simpler as well. >> > > I still think that it should be separate from UGRID -- it really is a > different use case, though they should still share whatever they can, and > it could turn out that UGRID is a special case of geometries? > > -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] > -- 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
