Hi Martin,
thank you for the feedbacks.
Some of our choices (choices of mine and Alessio) have been made while
extending/improving the MetadataAccessor class. Therefore, sometime we have
"reduced the complexity of/bypassed" some metadata nodes to reduce the
accessor's hierarchy.
Here below, some quick observations...
On Mon, Jun 30, 2008 at 5:41 PM, Martin Desruisseaux <
[EMAIL PROTECTED]> wrote:
> 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).
Not sure to fully understand this statement. Are there coverages having a
vertical/temporal crs definition without a 2d spatial extent defined?
>
> * 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.
See below my reply to your comment on Figure 9.
> * 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.
>
See below my reply to your comment on Figure 9.
>
>
> 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.
You are right. I don't know why I have used the "OR" term :)
>
> 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.
>
The main goal was to represent the base CRS using the SpatialCRS node and
define the Projected/Derived related item in this subnode.
Figure 8
> --------
> "OperationMethod" is in the wrong place. It should be "Conversion" (the
> class
> name) or "conversionFromBase"
Yes, I know. We have collapsed/skipped some nodes to reduce complexity of
metadata nodes and the involved MetadataAccessor.
> (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.
Same as before. However, if this seems too much distant from the
specifications we may improve the nodes hierarchy.
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)
>
How should be defined that Envelope? I mean... How to handle as an instance,
the vertical range or the temporal period validity of a 2D slice with an
Envelope item? Is the Envelope defined as a set of N coordinates?
Moreover, we have defined:
* VerticalExtent to rely as an instance on a coverage defined for a vertical
level defined as a symbolic quantity such as "Cloud top level" where the
related VerticalCRS has a VerticalDatum with type "OtherSurface" with custom
AxisAbbreviation/Direction/UnitID. That CRS will be defined in the
VerticalCRS top node.
* TemporalExtent allowing to handle ISO-8601 values by means of our "olds"
JodaTime's related classes which are changing to your new temporal work on
modules/unsupported/temporal.
>
> 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?)
We have simply used the attributes specified in the GML-JPEG2000
specification. As an instance,
<gml:origin>
<gml:Point gml:id="Pt0001" srsName="urn:ogc:def:crs:EPSG:6.6:32612">
<gml:pos>270372.375 270372.375</gml:pos>
</gml:Point>
</gml:origin>
Maybe, with the actual main schema, these attributes are unuseful/redundant.
> Figure 11
> ---------
> "Scale" and "Offset" are not what I call "calibration". To me, calibration
> as a
> whole different (and much more complex) topic.
We have adopted these names due to some HDF datasets having attributes
called scale_factor(_err)/add_offset(_err) referred in some guides as
calibration attributes.
> * 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).
>
On the basis of these observations, I have no problem to rename the node
since "calibration" has different meanings.
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).
Ok. We can adopt a lowerCase node naming convention and use "parameter".
Cheers,
Daniele
PS: I will setup a google document for collaborations. More comments
(especially on SpatialCRS/CRSs topics), afterwards.
>
>
> 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
>
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
-------------------------------------------------------------------------
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
