[cf-pointobsconvention] Draft 2

[Ted Habermann]

John,

John forwarded this to me and I am glad to hear that you are interested. 
I thought that I might provide a slightly different perspective to 
explain why I think this is such a forward-looking idea.

The organization of this thought process seems to distinguish between 
points, profiles, trajectories, and other types of spatial features with 
an apparent goal of deciding on a file structure for each of these . 
This makes this sound like a whole series of decisions need to be made 
about a bunch of "different" data types (I could be completely wrong on 
this). Luckily for us, the geospatial community has figured this one out 
and all of them actually have agreed on a compact representation for all 
of these types, and a bunch of others (multi-points, multi-lines, and 
polygons, ...).

Seems to me that if this group recasts their framework to something more 
like: how do we store spatial features (other than grids) and associated 
attributes in a netCDF file, it allows you to jump forward by taking 
advantage of years of work and success in the geospatial community. 
After all, there are no point-shape files or line-shape files, or 
polygon-shape files, there are only shape files. I think it would be 
great if that were also true of netCDF. It also makes the connection 
between netCDF and spatial databases ridiculously straight-forward.

Ted

John Cartwright wrote:
> 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/
>>   

-- 
==== Ted Habermann ===========================
     Enterprise Data Systems Group Leader
     NOAA, National Geophysical Data Center
     V: 303.497.6472   F: 303.497.6513
     "People are much more likely to act their
      way into a new way of thinking than to
      think their way into a new way of acting"
      Richard Tanner Pascale and Jerry Sternin
==== Ted.Habermann at noaa.gov ==================