On page 17, we can read (talking about IIOMetadataFormat constraints):
> For our purposes we will try to respect as much as possible these rules, but
> we might need to
> violate some of them to produce a useful metadata structure. It is worth to
> point out that ImageIO
> would not complain about violating the latter rules.
Could you point us to the place where the IIOMetadataFormat contract had
to be violated?
I believe that it is possible to stick strictly to IIOMetadataFormat
constraints and still have usefull metadata. The question is how much
departure from "GML in JPEG 2000" we accept.
Generally speaking, it would be very nice if the schemas or the tables
in the document could tell us which elements come from "GML in JPEG
2000" and which one do not. For example we could use box of different
colors in the schemas.
> We will try to simplify the XML three as much as possible in order to have a
> simpler
> document structure, even if sometimes this may introduce a discrepancy with
> the OGC
> standards.
Would it be possible to provides an example of simplification done.
One possible simplification I could see (I'm not sure if this is the one
you are talking about) is that OGC XML schema seems to often follow this
pattern:
<ClassName>
<attributeName>
<ClassName>
<attributeName>
<ClassName>
etc...
example:
<RectifiedGridCoverage>
<rectifiedGridDomain>
<RectifiedGrid>
<limits>
<GridEnvelope>
<low>...</low>
<high>...</high>
Some time the Class is fixed for a given attribute. For example I don't
think that <limits> in <RectifiedGrid> can be anything else than
<GridEnvelope> (but we would need to check). So I suspect that we could
drop the class name in many cases. They can easily be spotted in OGC
schemas: their name begin with a uppercase letter.
-------------------------------------------------------------------------
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
