Hi John:
It sounds like a good idea to add support for the "OGC's Well-Known
Binary format" into the CDM by writing an IOSP. That probably should
be seperate from this proposal, which focuses on a netcdf encoding
that doesnt require further libraries to understand.
John Cartwright wrote:
Hello All,
I'd like to suggest a somewhat different approach - what about storing
the geometries according to OGC's Simple Feature Specification
(http://www.opengeospatial.org/standards/sfa)?
As many of you know, this a way of representing points, lines (profiles,
trajectories), and polygons that has gained wide acceptance w/in the GIS
community. These geometries could be stored in OGC's Well-Known Binary
format for which there is again wide-spread support (Java Topology
Suite, GEOS, PostGIS, Oracle Spatial, etc.)
Perhaps an dimension of geometries could be stored that could be
referenced by the records in a many-to-one manner? Clients accessing
the data via the CDM would be unaware of the storage specifics and would
see only scientific data types while those accessing the netcdf file
directly would have access to the WKB blobs and have established
libraries to deal w/ them.
I admit to being vague as to the specifics of storing "blobs" of binary
data w/in the netcdf file and associating them w/ records, but it seems
similar to the parent-child table concept put forward in Draft 2.
-- john
_______________________________________________
cf-pointobsconvention mailing list
cf-pointobsconvention@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
