[Java-collab] GeoTools moving forward

Sunburned Surveyor sunburned.surveyor at gmail.com
Fri Oct 10 17:21:50 EDT 2008


Roger that Martin. This all makes good sense.

I'm talking about a facade for your module, not a replacement.

Landon

On Fri, Oct 10, 2008 at 1:07 PM, Martin Desruisseaux
<martin.desruisseaux at geomatys.fr> wrote:
> 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
>


More information about the Java-collab mailing list