[Java-collab] Re: [Geotools-devel] GeoTools moving forward

[Sunburned Surveyor]

It's good to see that this idea has some merit.

Justin wrote: "So in my mind the first step would be to find the
middle ground. Come up with interfaces both "useful enough" and
"simple enough"."

I think it is important to remember that use of high-level objects
causes some problems with integration. As an example, one projection
library may have a Coordinate object that looks a lot different from a
Coordinate object in another library. But is we try to stick to
primitive types, like doubles and Strings, wider adoption of the
interface will be possible. You can always put the code that wraps and
unwraps the primitives into utility packages.


Paul wrote: "I think the best way to identify a coordinate system is a
CoordinateSystem object which models the WKT CoordinateSystem."

I don't see a problem with that. But I think we should stick to String
objects as the actual identifier, and avoid using a high-level object.
Pass the WKT definition as a String and put the CoordinateSystem
object in a utility package. (I bet we can use an existing
CoordinateSystem object that Martin, deegree, or Paul has.)

If we have some consensus that this is a good idea could we move
forward with a GeoTools module to contain the interface? (Or do we
need more discussion?) I think we can start the module with a simple
interface like the one described, an interface that performs
coordinate transformations of ordinate values (doubles). We can build
from there. Perhaps by integrating Martin's, Paul's, or deegree's
existing code base as an backend implementation of the interface.

I would love to see a simple interface that provided a crs
transformation service I could plug into OpenJUMP. I would really,
really, love it...

I'm willing to code up the interface if one of the GeoTools developers
can start up a module. Does Martin have any comments? Would he support
our efforts to plug-in his existing code to such an interface?

Landon

P.S. - Thanks for copying the Java collab list. I thought about doing
that, but worried this might be a conversation that needed to stay
internal to GeoTools.



On Fri, Oct 10, 2008 at 8:58 AM, Justin Deoliveira <jdeolive at opengeo.org> wrote:
> Hi Landon,
>
> I agree, this situation would be ideal. I actually thought a little bit
> about what this might look like a while back. More from the angle of how a
> unified Geotools / proj interface might look like:
>
> I think Geotools and Proj represent two ends of the spectrum. On the one end
> proj has a very straight forward and simple api. However perhaps not rich or
> complex enough to model every single case you want. And on the other end of
> the spectrum is GeoTools/GeoAPI which is rich enough to model every case you
> want to, however is too complex to practically implement and serve as
> interfaces for interoperability among toolkits.
>
> So in my mind the first step would be to find the middle ground. Come up
> with interfaces both "useful enough" and "simple enough".
>
> 2c,
>
> -Justin
>
> Sunburned Surveyor wrote:
>>
>> GeoTools Developers,
>>
>> I'd like to share some thoughts on the referencing module. I'm
>> wondering if this new situation that has developed would be an
>> opportunity to introduce a common interface that could be used for
>> coordinate transformations. After all, from a client code
>> persepective, the process can be very simple. The client code gives
>> the interface a source crs, a destination crs, and 2 double values for
>> the x any y coordinate being transformed, and the interface returns 2
>> new double values representing the transformed coordinate.
>>
>> We could then implement the interface using Martin's code in GeoTidy,
>> but would also be able to plug-in other crs transformation code as
>> needed.
>>
>> For this interface to be the most flexible, I would suggest we stay
>> away from high-level objects, and instead used basic data types and
>> simple objects whenever possible. Since there are a lot of different
>> ways you can identify a CRS we could pass this information to the
>> interface as a String, and allow the interface implementation to
>> define the crs identifier formats that are supported.
>>
>> Maybe there is already an interface like this in GeoAPI?
>>
>> I was thinking it might look like the following:
>>
>> public abstract void setSourceCrs(String argSourceCrs);
>>
>> public abstract void setDestinationCrs(String argDestinationCrs);
>>
>> public abstract double[] transformCoordinate(double[] coordinate);
>>
>> Using this approach would free Martin to pursue whatever modifications
>> he wished, while allowing the the rest of the GeoTools programmers the
>> freedom to provide their own implementation of the interface (I might
>> be interested in a deegree implementation) and would also allow them
>> to choose the implementation that best fits their needs.
>>
>> I'd be willing to maintain a module with such an interface, and to
>> work with Martin (if he was willing) to provide an implementation of
>> this interface that was plumbed to his GeoTidy code.
>>
>> The Sunburned Survyeor
>> _______________________________________________
>> Java-collab mailing list
>> Java-collab at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/java-collab
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>