> Sunburned Surveyor a ?crit :
> > I agree with the need for simplicity. In my example, you only dealt
> > with one object, the object implementing the transformation interface.
> > In the example from GeoAPI that Martin posted, you have to deal with
> > at least four (4) objects:
> >
> > [1] CoordinateReferenceSystem
> > [2] CRSFactory
> > [3] MathTransform
> > [4] CoordinateOperationFactory
> >
> > I think all of this could take place behind the scenes, in the class
> > implementing the interface.
>
> Yes it could take place behind the scene by your proposal, which would be
> a convenience class as stated in previous emails.
> [...]
> But there is cases were the user will need to work with those above GeoAPI
> objects rather than the convenience class. For example when wanting an
> estimation of transformation accuracy, or when wanting to know in which
> geographic area a CRS or a transform is valid.
I completely agree with Martin on this topic:
1. The GeoAPI interfaces do their job and allow for a wide range of coordinate
transformations, CRS creation and and CRS metadata retrieval, as used f.e. in
my CRS selection widgets. Moreover it is an ISO standard.
Therefore the GeoAPI interfaces cannot and should not seriously be hidden
behind a facade for most serious GIS applications.
2. For those users that think they really only need a simple coordinate
transformation a static utility class would do the job of hiding the complexity
without touching GeoAPI interfaces. This utilitiy class could then implement
the simple interface proposed earlier. I doubt the simple transformation method
proposed by Landon will satisfy all but the most simple use cases, but it is
worth a try.
The interface should imho live in GeoTools, not GeoAPI, because it has nothing
to do with any official standard.
3. Using WKT for this convenience class sounds like a bad idea to me. Besides
the problems pointed out by Martin simply the idea of having to parse a WKT (or
whatever) String to create a CRS object just in order to transform ONE single
coordinate at a time sounds so awfully inefficient to me that I cannot
seriously consider it.
The shortest useful code 'd come up with is
CRSFactory crsFactory = ...
CoordinateReferenceSystem sourceCRS = crsFactory.createFromWKT("...");
CoordinateReferenceSystem targetCRS = crsFactory.createFromWKT("...");
double[] dstCoords = CRSUtility.transform(srcCoords, sourceCRS, targetCRS)
and for multiple coordinates:
double[][] dstCoords = CRSUtility.transform(srcCoords[], sourceCRS, targetCRS)
This keeps the flexibility of creating the CRS objects in any way you like and
reuse them, but it saves just one line of code compared to the interfaces we
already have, so is it really worth this?
--
Matthias Basler
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
