Hello Simone
Simone Giannecchini a écrit :
> I have checked around a bit and I have noticed that most part of the
> time the CRS.getHorizontalCRS method really means give the horizontal
> part of the crs, it does not seem to care much about having a derived
> crs. Do you think it could be possible to slightly change the
> behaviour of this method and avoid the unwrapping.
I just checked the getHorizontalCRS(...) code with more attention and I was
wrong (memory not good enough...). The getHorizontalCRS(...) method do not
returns a unwrapped CRS. It unwraps only in order to check if the if the CRS
derive from a GeographiCRS. If it does, the original CRS is returned, not the
unwrapped one.
So its look like that getHorizontalCRS(...) already do what we want :)
> About the 3D GeographicCRS can you be more precise about what we
> might need to do so that I can make some experiments with it.
Many 3D CRS are constructed as a CompoundCRS containing a horizontal CRS (either
ProjectedCRS, GeographicCRS or a DerivedCRS from the previous ones) together
with a VerticalCRS. This is true also for GeographicCRS having a geoidal height,
a "height above mean sea level" or any other kind of height except ellipsoidal
height (height above the ellipsoid).
The later is the only exception: GeographicCRS + "height above the ellipsoid"
(and only this kind of height, not "height above the geoid or any other one) is
the only 3D CRS (excluding geocentric) which is not constructed from
HorizontalCRS + VerticalCRS, but is rather constructed as a SingleCRS with an
underlying 3D CoordinateSystem (in this case, a 3D EllipsoidalCS). This is
because about every mathematical formulas (all projections, datum shifts, etc.)
works on ellipsoid, so ellipsoidal height are treated especially. Performing a
datum shift on a 3D coordinate like (long,lat,height above mean sea level)
implies transforming the z to ellipsoidal height, performs the datum shift, and
transform back the ellipsoidal height to height above mean sea level.
In its current state, the referencing module do not yet performs vertical
transformation. A work started in unsupported/referencing3D but is not finished.
In its current state, referencing3D defines a MathTransform performing "WGS 84
ellipsoid <--> WGS 84 geoid" transformations, but the next step (maybe the most
difficult one) is to get DefaultCoordinateOperationFactory to automatically
detect when it need to use it, and use it.
In summary, if you have a 3D GeographicCRS where the vertical height is anything
except ellipsoidal height, you have nothing to do; current code can trim it down
to a 2D CRS since it is an ordinary CompoundCRS. But if you have a 3D
GeographicCRS with ellipsoidal height, then the current code will fail to detect
this special case. It would not be very difficult to write a little bit of code
iterating over the 3 axis, ommiting the vertical one and creating a new
GeographicCRS with the two remaining ones. The very hard part is to get the
referencing module to really performs vertical transformations.
In its current state, the referencing module should be able to do the following:
3D-GeographicCRS --> 2D-GeographicCRS
3D-GeographicCRS with ellipsoidal height --> 3D-GeographicCRS with
ellipsoidal height (i.e. datum shift).
but we fail to do:
3D-GeographicCRS with any kind of height --> 3D-GeographicCRS with a
different kind of height.
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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
