Thank you Andrea for your answer. I was away from this office at the beginning of the week and just received it.
> I think you could develop yourself a custom class that builds the > chain and still makes it implement > the Projection interface, if you do you can develop a > DerivedProjectedCRS on top of it. Do you have any indication on how to do it? I have started to implement a DerivedProjectionCRS class that implements ProjectedCRS. This class contains a private DefaultDerivedCRS field that I use as a delegate to implement most of the ProjectedCRS methods. The only methods that cannot be directly delegated to the DefaultDerivedCRS field are: - GeographicCRS getBaseCRS() (DefaultDerivedCRS returns a CoordinatesReferenceSystem) - Projection getConversionFromBase() (DefaultDerivedCRS returns a Conversion) - CartesianCS getCoordinateSystem() (DefaultDerivedCRS returns a CoordinateSystem) - GeodeticDatum getDatum() (DefaultDerivedCRS returns a Datum) And here, my problem is the lack of clear documentation of geotools. Of course, there are the API docs, but they are not very easy to understand. > Though generally speaking it's better if you don't make any assumption > on the nature of the > CoordinateReferenceSystem in your code... This is something I don't really understand in the geotools: in real life, I have data that are defined as longitudes and latitudes on a reference spheroid. To display it on a map, I have to convert these coordinates to meters on the projection. There are two different spaces: the geodetic one and the projected one and the difference is quite clear (degrees on spheroid against meters on projection). In geotools, CoordinatesReferenceSystems might be either of them. When you use the default renderer, geotools deals with it transparently. However, I use my own renderer (the performance of the default renderer does not meet my needs) and I use the geotools to convert the data from one space to another. Thus I like to understand what I am dealing with (geodetic data on one side and projected data on the other). Of course I could use CoordinatesReferenceSystems everywhere, but it's quite confusing for the reader and I end up doing casts (which is ugly). A few months ago, Michael asked what in the geotools API was not clear or could be improved and I this that the way the CRS are handled is not very easy to understand (the DataStores are another difficult point, but that's another story). Kind regards, Ben On 19/03/2011 08:57, Andrea Aime wrote: > > If you look at the api and javadoc for the two classes it should be > clear why the two cannot be the same: > DerivedCRS is a superclass of ProjectedCRS, it has less restrictions > and requirements than its subclass. > > There is support in geotools to have a DerivedCRS be at the same time > ProjectedCRS, because the > getConversionFromBase returns a plain Projection, not a chain or > Projection and AffineTransform. > > I think you could develop yourself a custom class that builds the > chain and still makes it implement > the Projection interface, if you do you can develop a > DerivedProjectedCRS on top of it. > > Though generally speaking it's better if you don't make any assumption > on the nature of the > CoordinateReferenceSystem in your code... anyways, you have a choice, > either fix your code or build > the missing support classes that allow you to keep the code in place > > Cheers > Andrea > ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
