* The only thing new in "coverageio" and "coverageio-netcdf" unsupported
modules at this time is the XML schema for geographic metadata in rasters,
in the spirit of "GML in JPEG 2000" OGC specification. There is no new
Java API at this time. There is a bunch of support classes for
implementors, but anyone is free to ignore them.
* I already posted an email about this "geographic metadata" stuff a
few weeks ago and got no comments. Prolably my email didn't gave
enough details. I will post an other one soon.
Sorry I didnt respond, I didnt recognise the subject in the deluge of
emails I filter every day ;-)
My thought, and it was confirmed in some discussions with Bryce and also
some private conversations with people involved in the DEWS project that
was looking at NetCDF, is that metadata is what you get when you take a
Feature view of a coverage.
ISO19123 specifies a coverage as a subclass of Feature, so this is
simple enough conceptually.
We should IMHO avoid creating new interfaces when the issue is simply
that we have previously crippled Feature to implement the SimpleFeature
profile. I.e., the solution is simply to support the General Feature,
and then define the operations and common metadata for a Coverage
Feature, and bind in the logic to create the metadata from the data
store configuration, and the operations to access the metadata as required.
I've been wondering about how the ISO19115 object libaries you have been
creating behave. I've had success getting the gtxml parser to
successfully parse a GML 3.1 version of ISO19139, and create an internal
feature model I can populate via the complex-ds mapping strategy. I'm
currently waiting for a handle on the new feature implementation work
Justin is doing to be able to do regression tests for this. Perhaps you
have more business logic tied into these - there is certainly a case for
a ProfilingAPI for schemas in general, with methods to bind concrete
(potentially) complex types into untyped elements of the schema.
Can we find a better topic for this thread?
Rob A
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
