Thanks Martin, excellent explanation.
I'm very comfortable with what you propose - and I hope this explanation
makes it clearer for everyone - I suspect not many would have had the
time or motivation to try to see basic the implications.
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.
At some later date, Feature builders would exploit this to create
Features derived from Coverage in order to expose that metadata as a
service. Some of it may be exposed via the WCS capabilities in the
short term.
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.
Rob
I agree to avoid creating new interfaces when existing ones can fit, and
actually this "geographic metadata for raster" topic is not about new interface.
It is about providing an implementation of this standard Java Image I/O interface:
http://java.sun.com/javase/6/docs/api/javax/imageio/metadata/IIOMetadataFormat.html
A single "standard" implementation could be provided for the whole Geotools
library and act as a bridge between the standard Java Image I/O framework and
the Geotools Feature, Coverage or whatever interface we use on our side. The
choice of a standard IIOMetadataFormat implementation is significant because it
determine how every javax.imageio.ImageReader implementations shall expose their
metadata to Feature or Coverage builders. It is significant for ImageReader and
for Feature/Coverage _builders_ (it is really a link between them); it doesn't
impact Feature or Coverage interfaces themself.
It is a more appropriate to see this topic as "choosing a XML schema" than
introducing Java API, since IIOMetadataFormat job (in standard Java Image I/O
mechanism) it to describe a XML schema for metadata exchange between ImageReader
and Factory/Coverage builders. The "GML in JPEG 2000" specification way be the
XML schema we are looking for.
I've been wondering about how the ISO19115 object libaries you have been
creating behave.
Users can use them (if they wish), as well as some ISO 19111 constructs.
javax.imageio.metadata.IIOMetadataFormat is a way to said "put the geographic
envelope there" where "there" is somewhere in javax.imageio.metadata constructs
(which is why we need to define where we put the envelope, since Image I/O is
not aware about geographic informations). It doesn't define a new interface for
this geographic envelope.
I will try to tomorrow a figure showing the proposed IIOMetadataFormat
definition as a tree.
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
begin:vcard
fn:Rob Atkinson
n:Atkinson;Rob
org:Social Change Online
email;internet:[EMAIL PROTECTED]
title:Principal Consultant
tel;work:+61 2 42265490
tel;cell:0419 202 973
x-mozilla-html:TRUE
url:http://online.socialchange.net.au
version:2.1
end:vcard
-------------------------------------------------------------------------
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
