Hi Martin,
On Tue, Jul 1, 2008 at 11:13 AM, Martin Desruisseaux <
[EMAIL PROTECTED]> wrote:
> 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.
Ok, thanks for the clarification.
>
>
> >> 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.
>
Ok. I have understood the problem.
>
>
> >> "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).
Yes, I know that. We were misunderstood. :)
My doubt was about how to specifies symbolic vertical levels or time values
of a 2D slice within the N coordinates of the envelope.
I will get more info on this topic.
>
>
> 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.
I agree with this.
>
> Martin
>
> <https://lists.sourceforge.net/lists/listinfo/geotools-devel>
>
Daniele
--
-------------------------------------------------------
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
