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. Your proposal could land in
GeoAPI "example" module as an example of a way a user could create a convenience
class for himself on top of GeoAPI interfaces. It could also be put in an other
project, as people wish.
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.
Because different users have different needs, there is good chances that
different users will tweak the convience class in their own way in order to
expose more or less functionalities provided by GeoAPI interfaces.
Martin
-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
