[cf-pointobsconvention] Draft 2

John Cartwright John.C.Cartwright at noaa.gov
Thu Oct 11 12:05:35 MDT 2007


Thanks for your prompt reply John.  I was thinking that keeping an 
individual geometry as an "atomic" unit would simplify life. 

The structure of a WKB blob is pretty simple and I don't think would 
require an external library, but using WKB for storage is really just an 
optimization. If the binary storage is a concern, the corresponding 
"Well Known Text" format is an String representation of the same 
geometry model.

e.g.   "POINT (10 10)",  "LINESTRING (10 10 , 20 20, 30 40 )"

-- john

John Caron wrote:
> 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 at unidata.ucar.edu
>> For list information or to unsubscribe,  visit: http://www.unidata.ucar.edu/mailing_lists/ 
>>     
> _______________________________________________
> cf-pointobsconvention mailing list
> cf-pointobsconvention at unidata.ucar.edu
> For list information or to unsubscribe,  visit: http://www.unidata.ucar.edu/mailing_lists/ 
>
>   



More information about the cf-pointobsconvention mailing list