Ciao Martin, please, read below... On Jan 8, 2008 11:19 AM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > 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. >
Yep, all these questions come from the fact that I was reviewing the iso 19111 for some work I have been asked to do :-). About pivot, we use the french word in italian as well :-) > > > 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". > Cool. > * 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. > Got it. > 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. > K. > * 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. > I would probably go as follows: <FeatureUtilities> Features are usually flat 2D and also this method is used by the StreamingRenderer (well by MapLayer to be precise..) hence I guess we can go ahead and substitue. <CoverageUtilities> I would leave this method as it is but I would probably add a similar method called getHroizontalCRS to distinguish te two cases. <AbstractGridCoverage2DReader> Most part of the time it really means give me the horizontal crs hence I guess we can go ahead. > * 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. > K. > * 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 > sophsticated 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. > I would say, le't leave it like that and then see if we run into some strange behaviour with time. Note however, that I found a few more places where the getCRS2D method is used, here you have the list: * JTS#getEnvelope2D ------------ I would say we can substitute with no problem this one since for JTS 2D == spatial for sure. * RendererUtilities#calculateScale * RendererUtilities#createMapEnvelope * RendererUtilities#worldToScreenTransform * GridCoverageRenderer# ------------ Given the fact that these classes are helper classes for the StreamingRenderer which basically does 2D spatial I guess we can do the substitution. I am going to apply the changes locally and do a full build. Then If you agree I can commit to trunk and if you want you can review the changes. Simone. > 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
