Hi guys,
I have uploaded the document to google docs. I have invited some of you as
co-workers.
Some observations:
- As stated before, the actual document contains some figures and notes
which come from a previous version. The interesting part is about the
Metadata structure.
- I have cut away the table of contents since in the uploaded docs there are
no numbered pages and the related references in the TOC are not sensed.
cheers,
Daniele
On Tue, Jul 1, 2008 at 10:07 AM, Daniele Romagnoli <
[EMAIL PROTECTED]> wrote:
> 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
>
> -------------------------------------------------------
>
--
-------------------------------------------------------
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
