Hello Daniele and all
There is my comments about the latest Geographic metadata document from
Geosolution (http://www.geo-solutions.it/doc/nd-metadata-doc.odt):
Figure 5
--------
This figure splits the CRS into 3 compenents: SpatialCRS, VerticalCRS and
TemporalCRS. I suggest to remove all of those and keep a plain CRS instead.
Rational:
(note: I noticed after writing the points below that the document defines
"TemporalCRS" and "VerticalCRS" as redundant nodes in case the SpatialCRS is
not
compound. If this is the intend, then I suggest to remove this redundancy
completly and rename "SpatialCRS" as "CRS" since it is not restricted to
spatial
dimensions)
* The figure sets SpatialCRS as mandatory and VerticalCRS / TemporalCRS
as optional. There is no reason for that. Some coverage in oceanography
are (depth, time) coverages (e.g. the output of current-meters using
Dopler effects).
* Splitting SpatialCRS and VerticalCRS in two independant is assuming
that horizontal and vertical CRS are always independant, e.g. there is
never coverage on inclined planes. Again this is not always the case
(e.g. raster modelising the flow of some substance, water/ice/mud...).
* Furthermore the term "spatial" is problematic. Isn't vertical CRS
spatial?
* This split introduces an other split between Envelope, VerticalExtent
and TemporalExtent. We have a little bit of inconsistency here. The
Extent are defined in ISO 19115 while the Envelope is defined in
ISO 19107. They have a quite different hierarchy. A more consistent
approach would be to have either an Envelope alone, of an ISO 19115
Extent (which is itself built of GeographicExtent, VerticalExtent
and TemporalExtent) rather than mixing them.
* If we were to keep the split, we would need to remove at least the
VerticalDatum and TemporalDatum from the list of datum allowed for
a SpatialCRS in the figure. What to do about EngineeringDatum and
ImageDatum? (they are not necessarly spatial).
Given all the reasons above and given that this split is not in a specification
I'm aware of, I recommand to remove this split and stick to a single Envelope
with a single CRS. It is more generic and would simplify a lot the metadata. A
user can extract the vertical and temporal components from the Envelope and CRS
if they are present.
Table 1
-------
Documentation said "It is also worth to point out that the Geodetic Datum needs
at least an Ellipsoid or the Prime Meridian description in order to be fully
described". It needs both an ellipsoid *and* a prime meridian.
Figure 5 (continuing) and figure 8
----------------------------------
Why ProjectedCRS and DerivedCRS are under the "SpatialCRS" node? (on side of
various Datum)? If the goal is to represent the base CRS, it would be more in
ISO 19111 spirit to have an explicit "baseCRS" node for them.
Figure 8
--------
"OperationMethod" is in the wrong place. It should be "Conversion" (the class
name) or "conversionFromBase" (the property name - I suggest the later name;
see
may last comment in the "generic comment" section) with two child nodes:
"method" (the name of the property associated to an "OperationMethod") and
"usesValue" (lets find a more Java-friendly name; I suggest "parameters"). I
suggest to *not* details the parameter descriptors under "OperationMethod"
(this
is what you did with the "usesParameters" child node) - they are descriptors,
not actual values. The parameter values are rather under the "parameters" node
under the "conversionFromBase" node.
Figure 9
--------
See the comment for figure 5. I suggest to remove the VerticalExtent and
TemporalExtent and rely to a simple Envelope instead. Having redudancy will
make
usage of the metadata more complicated (any client of those metadata will now
need to check for vertical range in two places. If we want to be really safe,
we
would need to make sure thay are consistent)
Figure 10
---------
Why "srsName" and "id" attribute for the origin point? I think that the srs
should be the CRS given above in figure 5. Allowing a different CRS for the
point will make the job more difficult for metadata clients (need to parse an
other srs) and introduce ambiguity (which CRS should be applicable to offset
vectors? The one in figure 5 or the one associated to the origin?)
Figure 11
---------
"Scale" and "Offset" are not what I call "calibration". To me, calibration as a
whole different (and much more complex) topic.
* Calibration are used for transforming the sensor output to geophysics units,
taking in account the uncertanties. The purpose of "scale" and "offset" is
*not* to transform sensor output. It is only an encoding for more compact
data transfert (typically *after* the calibration coefficient has been
applied).
* In some case calibration involves more than one band at once. In oceanography
the computation if Sea Surface Temperature involves two or three bands and
the
result appears in a single band.
* Calibration are usually of higher order (typically at least cubic).
* Calibration needs a calibration date.
If you want a calibration section in metadata, I'm 100% for that - this is
really important and relevant information. But we should not confuse
calibration
and data encoding. Scale and offset are for encoding. Calibration is an other
topic which should have its own section.
So I suggest to:
* Rename "calibration" to something else, and keep the "calibration" name
for real calibration informations (lets revisit that later).
* Remove the "error" attribute because they apply to calibration,
not to data encoding.
* Move "scale" and "offset" to one of the following (at your choice):
- As category attributes (more powerful and generic)
- As SampleDimension attributes (more consistent with current
location of nodataValues).
Generic comment
---------------
There is a mix of node name begining with lower case and upper case. In my
understanding of XML schema defined by OGC:
- Nodes begining by lower case are property names
- Nodes begining by upper case are class names
- There is always an alternance lower-upper-lower-upper-...
Current schema has more variations. In our GeographicMetadata class that we
started to implement in the unsupported/coverageio module, we choosed the
following policy:
- Always put nodes for properties, never for the class
(the later is redundant and is rely a departure from
XML usage; I don't know why OGC do that).
- Records the class name in the property node (for now
only in comments, later in the code), so we can insert
back the class name at runtime if we wish.
So using those rules every nodes beging with a lower case (as we usually do in
XML). In figure 11 "Categories" become "categories" and "Category" become
"category" (because in those cases the property name is the same than the class
name). In figure 8 "ParameterValue" become "includesValue" (the ISO 19111 name
for the ParameterValues.values() method) or "value" or "parameter" if we want
to
stay more Java-like (I vote for "parameter" for consistency with the
"parameters" name suggested in the Figure 8 comments).
Regards,
Martin
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
