NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
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@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
cf-pointobsconvention archives: