Justin wrote: "A question for Martin: Are there any plans to make
GeoAPI more modular in nature, so that people can pick and choose from
parts of the interfaces they wish to use?"
Worst case scenario: We move the interfaces we need from GeoAPI to a
GeoTools module.
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. Then, if I was using OpenJUMP (for
example), I could do something like this.
Coordinate toTransform = new Coordinate(5000.0, 1000.0);
double[] oldOrdinateValues = new double[2];
oldOrdinateValues[0] = toTransform.x;
oldOrdinateValues[1] = toTransform.y;
double[] newOrdinateValues =
someNewTransformationInterfaceImplementation.transform("CRS1", "CRS2",
oldOrdinateValues);
There is one method call to one object to perform the transformation
of the coordinate. That's it. All the other black magic happens behind
the scenes.
Landon
On Fri, Oct 10, 2008 at 12:20 PM, Justin Deoliveira
<[EMAIL PROTECTED]> wrote:
> I would prefer not if all this will be is another layer of abstraction on
> top of geoapi. In my opinion things are already as abstract enough and it
> makes it hard to follow. Now I will fully admit when it comes to referencing
> systems i am a layman to be sure, but I understand the basics, so I don't
> think it is unreasonable to ask for a library/api that i can use that is
> *simple* and keeps abstractions to a minimum.
>
> I also think that perhaps depending on geoapi is a bit of an issue since its
> a large number of interfaces, many of which have nothing to do with
> referencing.
>
> A question for Martin: Are there any plans to make GeoAPI more modular in
> nature, so that people can pick and choose from parts of the interfaces they
> wish to use?
>
> -Justin
>
> Martin Desruisseaux wrote:
>>
>> Sunburned Surveyor a écrit :
>>>
>>> If we have some consensus that this is a good idea could we move
>>> forward with a GeoTools module to contain the interface?
>>
>> I'm neutral on this one. From a GeoTools point of view, it would be
>> nothing more
>> than a convenience class delegating to a few GeoAPI calls. It is not even
>> GeoTools-specific; the same convenience class would work with any GeoAPI
>> implementations and could live totally outside the GeoTools project, as
>> people wish.
>>
>> Martin
>> _______________________________________________
>> Java-collab mailing list
>> [EMAIL PROTECTED]
>> http://lists.osgeo.org/mailman/listinfo/java-collab
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
-------------------------------------------------------------------------
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
