From: Daniele R. <dan...@ge...> - 2008-07-01 08:07:19
|
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 < mar...@ge...> 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 > Geo...@li... > 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 ------------------------------------------------------- |