Hello Daniele
Daniele Romagnoli a écrit :
> Not sure to fully understand this statement. Are there coverages having a
> vertical/temporal crs definition without a 2d spatial extent defined?
Yes. An example in the oceanography field (I'm supposed to be an oceanographer
:) ) are the images produced by Acoustic Doppler Current Profilers (ADCP). The
output looks like that (I just pickup a random image on Google):
http://www.mumm.ac.be/Assets/Pages/ADCPstroomprofiel.jpg
This is a vertical slice. We typically have "depth" as the vertical axis of the
raster, and "time" as the horizontal axis of the raster. Raster values are
speed
in m/s.
>> 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.
It may be misleading since I would expect the SpatialCRS node to be the actual
CRS of the raster. With the current design, sometime it is and sometime it is
not... We have to check if there is a DerivedCRS child node, and if there is
one
the child is the actual CRS, not the parent node.
Furthermore since the child is actually the CRS of interest, we need to define
its axis, which may not be the same than the parent node (the DerivedCRS may
apply a rotation). So we are not reducing the verbosity.
So current layout:
* is a deviation from ISO 19111 (peoples used to ISO may be surprised);
* may be error-prone since the raster CRS is not necessarly SpatialCRS,
but rather whatever child SpatialCRS may have.
* do not reduce verbosity since the child must declare its axis. Quite
the opposite; it would be less problematic if the "baseCRS" was a
child and we ommited the axis of that baseCRS.
>> "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.
Thats fine (I agree with collapsing some node). But in this case the class to
keep should be "Conversion" (which contains parameter values), not
"OperationMethod" (which do not contains parameter values; only a description
of
them). If we apply the policy of using the method name rather than class name,
the node should be "conversionFromBase".
>> I suggest to remove the VerticalExtent and
>> TemporalExtent and rely to a simple Envelope instead.
>
> 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?
The envelope is N-Dimensional. If you have a 2D-Slice with a vertical range and
a temporal period of validity, then (assuming the CRS have (x,y,z,t) axis):
* The Envelope given in the "boundedBy" node is 4-dimensional.
Envelope.getLowerCorner() returns the minimal (x,y,z,t) values and
Envelope.getUpperCorner() returns the maximal (x,y,z,t) values.
The temporal period of validity is given by the minimal and maximal
t values in that envelope.
* The GridEnvelope given in the "limits" node is 4-dimensional as
well, but in the case of a 2D-slice only 2 dimensions can span
more than 1 cell. For a typical BufferedImage:
GridEnvelope.getLow() returns (0,0,0,0)
GridEnvelope.getHigh() returns (width, height, 1, 1)
Compare with ISO 19107 geometries: A surface (which is a 2-dimensional
geometry)
can be specified in a 3-dimensional space (and really associated to a 3-D CRS).
For example the surface of a sphere.
If you think of a 3-D raster as a cube where each cell is a "voxel" (instead of
"pixel" in the 2-D case), a 2-D slice of that cube can be think as if we pick
up
just the voxel on the surface (for example). So we still have voxels, but the
depth of the 2D-slice is only 1 voxel (while height and width have many
voxels).
If I ask "what is the center of that particular cell in my 2D-slice", the
center
can still be computed in 3-D coordinates. So as you see, 3-D and 4-D envelopes
still applicable to 2D-slices, like 3-D CRS are still applicable to 2-D
surfaces
in ISO 19107 (for surface of sphere, etc).
The GeoTools coverage module is already implemented that way, and we use it
through PostGrid for 5 years - so this approach is already tested.
> 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.
It can be defined in the VerticalCRS top node, but doesn't need to. It could
appears in a CompoundCRS as well.
>> Why "srsName" and "id" attribute for the origin point?
>
> 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.
I don't see a use case for them right now. If we see one later, we can add them
back later. In the main time, I would suggest to apply what I call Joshua's
principle: "in case of doubt, leave it out".
> 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.
Yes, maybe they are refering to real calibration. The "scale" and "offset" that
appears in OGC 01-004 "SampleDimension" rather describe the way data are
encoded. It may or may not be the same than calibration. Calibration are
different for each instruments, while encoding are often frozen for a data
series as a whole. So it could be the same sometime, but not necessarly.
If we venture in the land of calibration, we should probably take a look at
SensorML. But given the amount of work it may involve, we may be safer to leave
calibration out for now.
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
