Ciao Martin, thx for the valuable info. I have added a few thoughts/questions here below...
On Jan 3, 2008 6:03 PM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > Hello Simone > > Simone Giannecchini a écrit : > > 1>In case I have a general CRS which can be compound but I want to use > > the horizontal part of it which method I can use to get the latter? I > > see CRS#getHorizontalCRS and CRSUtiilites#getCRS2D, which one is the > > best? Is there a better option? > > It depends what you want to do: I would say that there are various uses cases that I can think about. One of interest could be receiving a request for a multidim cube that spans not only over the usual horizontal spatial space but which also contains time and depth/elevation. I would like to be able to get the horizontal part of this request, i.e. the Envelope2D along with its CRS 2D in order to do some optimizations like picking overviews up and doing subsampling. To be more specific, I am doing some experiments in order to make the scale operations inside the coverage processing package more robust (step 1) and the in order to promote them as subclasses of OperationJAI. This operations are inherently 2D but I would like to be prepared to handle more generic GridCoverage2Ds which may come from a spatiotemporal coverage comprehending time and depth/altitude (sounds like CoverageStack huh ? :-) ) > > * getCRS2D returns the 2 first dimensions, no matter what they are. It could > be (vertical, temporal) dimensions. This is uncommited API (everything in > "org.geotools.resource" is uncommited) because I'm not sure that it is a > right thing to do, so I apply Joshua Bloch's precaution principle: "in case > of doubt, leave it out" (at least from public API). I have done a quick search for places where this method is used an I found a few places where it used indeed but where it seems you explicitly want to get the Horizontal crs. I will report them tomorrow. We should probably replace these pieces of code by a method like getHorizontalCRS (or an improved version of it) that guarantees us to give the horizontal crs. > > * getHorizontalCRS returns the GeographicCRS or ProjectecCRS part that apply > to the Earth's surface, so at the difference of 'getCRS2D' it has a real > geophysics meaning and for this reason is a commited API. Note however that > if you have a DerivedCRS, this method will unwrap it up to the underyling > GeographicCRS or ProjectedCRS, which may not be what you want (it depends > what you want to do). Note also that current implementation will fail for > 3D GeographicCRS with ellipsoidal height. It seems that this would be the right method to use for most of m needs but I am wondering about what we could do about the cases you mention here where the method would fail. I have not looked at the method's code yet, do you think it would be hard/ possible to fix them? > > * If you want that in the context of GridCoverage2D work, it may be better to > rely to GridGeometry2D.getCoordinateReference2D() method, which performs a > much more sophesticated work. Actually GridCoverage2D already accepts n-D > CRS > provided that every dimensions except 2 are exactly 1 pixel width. For > example > imagine a (x,y,z,t) coverage of size (400 x 500 x 1 x 1). GridCoverage2D > will > accepts such size with its associated 4D-CRS because the data can be stocked > in 2D PlanarImage without any special trick, since only the x,y dimensions > need to be stocked. That's one of the things I am playing with :-). > However GridCoverage2D will not accept a coverage of size > (400 x 500 x 2 x 1) for example; this one would require a real > GridCoverage3D. > > The 2D part don't need to be first. GridCoverage2D will accepts > (1x300x100x1) > as well. GridGeometry2D as many methods ending in "2D" which do the same > than > the nD methods, but using only the relevant dimensions. For example there is > a getEnvelope2D() method, getGridToCRS2D(), etc. > > GridCoverage2D.getGridGeometry() always returns an instance of > GridGeometry2D. > On Geotools 2.4, you need to cast the return value. On GeoTools 2.5, this is > not needed anymore thanks to Java 5 covariant return type. > > > > 2>Same as above for GeneralEnvelope. Let's say I have a > > GeneralEnvelope for a compound crs, Which is the best way to get the > > 2D part out of it in your opinion? > > If it is in the context of GridCoverage2D, I suggest > GridGeometry2D.getEnvelope2D(). If it is in other context, the safest way (if > performance is not an issue - but it is usually not unless you have thousands > of > Envelope to reduce) is to first get your 2D CRS using the above, then invokes > CRS.transform(MathTransform, Envelope). > > Cool. Thx, Simone. > > Hope it help, > > 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 ------------------------------------------------------- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
