Hello Alessio
[EMAIL PROTECTED] a écrit :
> The first question I would ask to you is why you have
> choosen to attach the SampleDimensions to the Format which,
> if I'm not misunderstanding, represents the MIME type of the
> coverage series in your vision. Why not link the
> SampleDimensions directly to the Series instead? It would be
> possibile to have two series with the same Format but with
> different SampleDimensions?
If SampleDimensions were linked directly to Series, then if two Series use the
same SampleDimensions (for example one series for daily Sea Surface Temperature
(SST) and an other series for Monthly Average of those daily SST - they have
exactly the same format, color palette, sample to geophysics conversion, etc.),
then we would have to duplicate the SampleDimensions and their Categories for
each Series.
If two series use the same MIME type but different SampleDimensions, we just
need two distincts entries in the Format table. The Format table is actually
not
the MIME type alone, but rather "MIME type" + "SampleDimensions" on the basis
that because SampleDimensions describes the encoding of sample values in the
file, they could be seen as part of the file format description.
However if "Format" is a confusing name for this table, I'm totally open to
renaming it :).
I should also point out that I plan to replace the "MIME" column by a
"JavaFormat" (or something like that) column, which would contains the Java
Format name rather than the MIME type. The MIME type would be inferred from the
Java Format name using Java ImageIO API. The rational is that some formats
(especially RAW files) have no MIME type, while every format are required to
have a Java format name as of Java Image I/O specification.
> Another question I would like to ask is the following. What
> is, in your opinion, the best way to represent coverage
> overviews in PostGrid schema?
In the current schema, just add an entry in the GridCoverage table with exactly
the same "startTime", "endTime" and a geographic extent that correspond to the
same bounding box (even if the affine transform coefficients are different).
You
don't need to declare explicitly that a coverage is an overview of an other
one.
You could if you wish (an advantage of using a database is that nothing prevent
you from adding whatever column you want in whatever table you want - those
additional informations will just be ignored by postgrid). Postgrid is designed
is such a way that if two GridCoverage entries are "identical" (in the sense of
same series, same time range and same geographic area) for a given request,
then
PostGrid selects the one which is the less expensive to load while good enough
for the requested resolution. So the overviews can be handled that way.
Similar idea applies to "mosaic + overviews" (just declare the tiles in the
database, at different overview level if you wish). However while "overviews"
alone should work, "mosaic + overviews" is more complicated and is a work in
progress which rely extensively on org.geotools.image.io.mosaic package under
development right now into the unsupported/coverageio module. You may notice
that this module has some non-trivial code for creating "mosaic + overviews"
only from a set of image Dimension + AffineTransform coefficients, with
rotations allowed. This module is clearly created with Postgrid in mind, more
specifically with the goal of creating "mosaic + overviews" together from any
table like the postgrid GridGeometries table.
Finally, lets note that a fair amount of code currently in GridCoverageEntry
and
FormatEntry would be better suited in some Geotools GridCoverageReader class,
but this is a long term goal (it depends on image I/O metadata again, and I'm
not good at working on too many tasks in same time - I urgently need to finish
"mosaic + overviews" first).
Last note: we are currently considering assigning the seagis coypyright to
either OSGEO of FSF in order to make it very clear that it will stay open
source. Vincent is looking at that issue.
Best regards,
Martin
P.S.: I'm not yet registered to the geoshaver mailing list because I have not
yet asked for a Google account, so this reply is likely to not be accepted by
the geoshaver mailing list. Feel free to forward if you wish.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
