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
