Hi,
a second proposal we'd like to push forward is the ability to look under
the hood of a grid reader that does mosaicking of information (either
spatial, temporal or along other dimensions) and get to know the pieces
making it up:
http://docs.codehaus.org/display/GEOTOOLS/Structured+grid+coverage+readers
The first obvious candidate for this is image mosaic.
ImageMosaicJDBC could be another one, if there is interest in extending it.
A side benefit of this proposal is that it would allow applications to be
more flexible in terms of what dimensions they offer, instead of having to
accept a time dimension that the reader is proposing, they could inspect
the date attributes in the granules schema and pick one of their choosing
(and then send down a Filter when doing the readCoverage request to select
the bits they want), and also, it would allow us to work against large
domains more efficiently, since we would not need to convert them to
strings and back anymore (a limitation that comes with the reader metadata
map being string oriented).
Also, with this proposal, along with the previous one, we'd be able to
commit also the NetCDF reader as a community module.
The NetCDF reader we have been developing supports multiple coverages per
NetCDF file (e.g., Polyphemus files have 3 coverages inside), supports
multiple dimensions, and has multi-level indexing to allow fast access to a
certain coverage/time/elevation combiantion (we basically move directly to
the offset in the netcdf file containing the information we want).
The NetCDF reader is also the first example of the Grid coverage api to
come, one that mimics 1-1 the datastores api: it's basically built on it,
and then adapted to the existing GridCoverageReader one.
The reason for this is that we don't know exactly when we'll be able to
push the new api so that all readers can adopt it, that is significant work
that we are not likely to accomplish in the next 6 months, so these two
proposals are stepping stones towards it (regardless, even when we do the
switch we'll need wrappers towards the old api to allow a transition period
and an API deprecation cycle).
But at least, it would mean the new coverage api gets from spike, where it
has been sitting for a few years now, to unsupported land.
If you haven't followed the discussion a few years ago, the coverage-api
that we're talking about is here:
https://github.com/geosolutions-it/geotools/tree/multidim/modules/unsupported/coverage-experiment/coverage-api
and the NetCDF provider is here:
https://github.com/geosolutions-it/geotools/tree/multidim/modules/unsupported/coverage-experiment/netcdf
Cheers
Andrea
--
==
GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
