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
