Simone Giannecchini a écrit :
> 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.
Thanks. I forget to said that this 3D-Geographic special case is not a weird
design of mine, but is explicitly stated in ISO 19111. The reason is that
GeographicCRS + ellipsoidal height is the "pivot" (don't know the English name)
for most vertical operations.
> 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.
Just looked at getCRS2D usage and I think that some replacements could be done
on a case-by-case basis. There is one gotcha:
* When no 2D CRS is found, getCRS2D(...) throws an exception.
TransformException is not appropriate for that, but I choosed it anyway
because this method is typically used in contexts close to coordinates
transformations. Since this method is "internal" - not a public API -
we can be less strict about "being right".
* When no horizontal CRS is found, getHorizontalCRS returns null. So if
getCRS2D is replaced by getHorizontalCRS, we need to check the return
value and handle null.
Now there is the getCRS2D usage I found:
* CRS.getEnvelope
CRSUtilities.toWGS84String
--------------------------
Yes we want horizontal CRS here, since we are converting to or from
a GeographicCRS. We need to remember to handle null value.
* FeatureUtilities
CoverageUtilities
AbstractGridCoverage2DReader
----------------------------
I let you decide for those ones. But maybe they are subject to the same
remarks than "org.geotools.display" and "OperationJAI" below.
* org.geotools.display packages
-----------------------------
For those ones, I'm not sure. Maybe we really want getCRS2D. We are projecting
n-D objects to a 2-D surface (the screen) and the 2-D part doesn't need to be
horizontal. As an oceanographer, I want the ability to display (longitude,
depth) or (time, latitude) coverages among others. The less arbitrary way to
project a n-D object in a m-D space it to keep the m first dimensions without
trying to guess what the user wants. It is like a shadow on the wall.
* OperationJAI
------------
The same than "org.geotools.display" may applies. We want a rule that will not
surprise users. getCRS2D will returns a result identical to getHorizontalCRS
in the very common case where the horizontal dimensions are first. For more
sophesticated users having (longitude, depth, time) CRS for example, keeping
only the 2 first dimension like the "shadow" of an unknown 3D object may be
the most conservative approach.
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
