NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
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
cf-pointobsconvention archives: