> I would vote for having converters in and out of the GT
> Feature model as
> required. It's only really needed for I/O, right? For other
> functionality, use the raw functionality provided by GT (such as
> coordinate transformations) and develop a JUMP-specific API
> on top of it.
>
> One
> [1] Modify OpenJUMP to adopt the GeoTools Feature interface and Feature model.
> [2] Design and use a "converter" that can change GeoTools Feature objects
> into JUMP Feature objects and back again.
> [3] Develop and maintain the JUMP Feature interface and feature model
> independently of GeoTo
I feel like I have opened Pandora's Box with my blog post on the challenges
of adopting the GeoTools Feature Model in OpenJUMP. This has made me realize
how powerful, and dangerous, a single blog post can be.
Still, I believe an important issue has been raised. I am now trying to
grapple with h
Hi Edgar,
>
> PS: aren't there projects using geotools libraries? how do they handle
> interface changes etc.?
In GeoServer, we always make sure our "stable" branch is on a geotools
"stable" branch. For example, GeoServer 1.5.x is based on Geotools
2.3.x. We do not allow any changes to api on s
Justin,
Your comments will be very helpful to me. I think it would be prudent to
stick with the stable version of GeoTools for my work on a converter between
OpenJUMP and GeoTools feature.
The Sunburned Surveyor
On 4/20/07, Justin Deoliveira <[EMAIL PROTECTED]> wrote:
Hi Edgar,
>
> PS: aren'
