Ciao Martin, for the moment I will try to leave with the 3D limitation we have. In case it becomes too hard to live with it I will try to spare some time for helping to finish the referencing3D work.
As of the getHorizontalCRS I have, as an experiment, substituted most (if not all) uses of CRSUtilities.getCRS2D with it and then rebuilt all. Everything worked fine hence I would like to commit this to trunk because as you said CRSUtilities is uncommitted API hence we should try and stick to getHorizontalCRS. Thx, Simone. On Jan 7, 2008 7:18 PM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > 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 > -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 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://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
