A little note:
On Tue, Nov 1, 2016 at 9:43 AM, Chris Barker <chris.barker at noaa.gov> 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
>
> Chris.Barker at noaa.gov
>
--
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/20161101/f83e4d19/attachment.html>
Received on Tue Nov 01 2016 - 13:13:16 GMT
