Hi guys,
here at GeoSolutions are thinking right now (and we have almost done) to an
XML schema for ImageIO Metadata to describe coverages structure.
As Martin rigthly stated in the previous mail, we need those metadata
describing as good as possible the Coverages structure, as we then need to
build image indexes in order to satisfy any kind of high level request that
may contain spatial, band and time constraints.
We absolutely need also time ... so basically we are coming out with a
structure similar to "GML in JP2K", which covers almost all our needs, plus
the temporal domain description, which is similar to the WCS specs one.
In fact IMHO "GML in JPEG 2000" is very good but not enough for all our
needs.
However I like very much their approach, describing the several metadata
parts as a set of feature collections.
On 8/5/07, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
>
> Rob Atkinson a écrit :
> > If my understanding is right, you are proposing a basic building block
> > for coverage implementations to allow a configurable metadata handler
> > through an XML schema.
>
> Yes. The "interface" (in the sense of XML schema) that we have to agree
> upon is
> the IIOMetadataFormat implementation. Everything else (in current stage)
> is
> helper classes that developpers can use or ignore at their choice:
>
> Below is an example dumped from a NetCDF file we are working on. The
> "standard"
> we have to agree on is the structure of the tree and the name of the
> nodes. The
> helper classes in unsupported/coverageio just provides methods for parsing
> and
> formatting node values at the appropriate places in the tree.
>
> Current tree structure do not yet complies to the "GML in JPEG 2000"
> standard
> (http://www.opengeospatial.org/standards/gmljp2), but this is where I
> would like
> to go. For example according "GML in JPEG 2000", the
> "GridGeometry/Envelope"
> node below should be renamed (and structured slightly differently) as
> "gml:rectifiedGridDomain/gml:RectifiedGrid/gml:limits/gml:GridEnvelope",
> but the
> idea is the same.
>
> geotools_coverage_1.0
> ├───CoordinateReferenceSystem
> │ ├───type="geographic3D"
> │ ├───Datum
> │ └───CoordinateSystem
> │ ├───name="time depth latitude longitude"
> │ ├───type="ellipsoidal"
> │ ├───Axis
> │ │ ├───name="longitude"
> │ │ ├───direction="east"
> │ │ └───units="degree"
> │ ├───Axis
> │ │ ├───name="latitude"
> │ │ ├───direction="north"
> │ │ └───units="degree"
> │ ├───Axis
> │ │ ├───name="depth"
> │ │ ├───direction="down"
> │ │ └───units="m"
> │ └───Axis
> │ ├───name="time"
> │ ├───direction="FUTURE"
> │ ├───origin="1950-01-01 00:00:00"
> │ └───units="days"
> ├───GridGeometry
> │ ├───pixelOrientation="center"
> │ ├───Envelope
> │ │ ├───CoordinateValues
> │ │ │ ├───minimum="-179.5"
> │ │ │ └───maximum="180.0"
> │ │ ├───CoordinateValues
> │ │ │ ├───minimum="-77.0104751586914"
> │ │ │ └───maximum="77.0104751586914"
> │ │ ├───CoordinateValues
> │ │ │ ├───minimum="5.0"
> │ │ │ └───maximum="1950.0"
> │ │ └───CoordinateValues
> │ │ ├───minimum="0.0"
> │ │ └───maximum="0.0"
> │ └───GridRange
> │ ├───IndexRange
> │ │ ├───minimum="0"
> │ │ └───maximum="719"
> │ ├───IndexRange
> │ │ ├───minimum="0"
> │ │ └───maximum="498"
> │ ├───IndexRange
> │ │ ├───minimum="0"
> │ │ └───maximum="58"
> │ └───IndexRange
> │ ├───minimum="0"
> │ └───maximum="0"
> └───SampleDimensions
> ├───type="packed"
> └───SampleDimension
> ├───name="Temperature"
> ├───scale="0.0010"
> ├───offset="20.0"
> ├───minValue="-23000"
> ├───maxValue="20000"
> └───fillValues="32767"
>
> Those informations are often provided as plain text in image file header.
> The
> idea is that ImageReaders would not attempt to create geographic objects
> (CoordinateReferenceSystem, Feature...) from those informations, but would
> just
> copies them as plain text in some pre-defined places. I would be up to
> builders
> (Feature or Coverage builder) to exploit those informations in order to
> create
> the appropriate geographic objects. Builders just need to know where to
> look for
> those informations.
>
> The javax.imageio package provides a mechanism for doing exactly that
> (storing
> image metadata as plain text in some predefined places): IIOMetadata.
>
> The only thing we need to do is to define the IIOMetadata tree structure
> (this
> definition is provided as a IIOMetadataFormat object). The OGC "GML in
> JPEG
> 2000" standard is exactly a description of such a structure.
>
>
> > Can you confirm or deny my feeling is that WCS capabilities is
> > insufficient to expose most of the metadata you would need to actually
> > process or formulate WCS requests - i.e. you would need client knowledge
> > of most of this metadata in order to use the service.
>
> I think that WCS play on an other ground. IIOMetadata is more "low-level"
> and is
> not oriented toward diffusion on the web - it is just a mechanism for
> communication between ImageReader and Feature/Coverage builders. Maybe
> "WCS
> capabilities" could be considered as a replacement for "GML in JPEG 2000"
> in XML
> schema definition, but I don't know if it can give enough informations. It
> is
> not what WCS was designed for, while "GML in JPEG 2000" seems to have be
> designed exactly for this kind of job...
>
> Martin
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
http://www.geo-solutions.it
-------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
