Thanks for the comments Frank. I completely agree that the biggest
thing holding back GeoTools is an overzealous tendency to refactor.
We have gotten some new change procedures for getting things on trunk,
yet they've not really gotten on.
But I really don't know what to do, I've tried to be a voice of going
for more stability, but people keep throwing on new interfaces. And
it's not looking to stop any time soon, with new FM work (which I do
agree we need) and new 'DataAccess', which I am completely against on
principle, since it's yet another refactor.
My best idea is to call it GeoTools 3.0 when we get the new FM on, and
then follow real major/minor versioning change procedures, so an API
change means we have to go to 4.0
And then we have to document the API. A guy at location intelligence
had an idea of getting just a small developers handbook on the basics
published as an online pdf or something.
Chris
Jody Garnett wrote:
Thanks for the email Frank - your comments are spot on.
It often seems are run out of time and push something bad out the door -
and then spend years sorting out what is right. I kind of wish we would
do more gradual changes and set ourselves up to improve over time. It
often seems we struggle until we cannot take it anymore, and the people
that cannot take it anymore end up forking in order to do something that
should be "easy".
There are lots of examples - but this shapefile one is a good start.
Open Jump uses some shapefile code, that was forked off JUMP which was
forked off an early cut in GeoTools. It would of been more fun if
improvements (stability is an improvement) were fed back in.
Landon thanks for bringing this conversation to the GeoTools-devel list;
I will do my best to answer your questions. And if you have any
suggestions on how we can work together better please let me know. If
difference in FeatureModel is a trouble for you please let me know; I
would like to set things up so you can supply a factory to the shapefile
code to produce instances that are exactly to your liking.
Cheers,
Jody
Frank Warmerdam wrote:
Sunburned Surveyor wrote:
David (and other OpenJUMP developers),
I should add that the GeoTools folks did quickly respond to my inquiry
on their mailing list about the Shapefile code. One of their developers
mentioned that their are no current plans to Feature interface. They
also seem to be open to the idea of accepting documentation I prepare on
the use of the Shapefile code.
Perhaps the wise thing would be to develop and use the converter. This
would allow us to see what changes happen to the GeoToolsfeature model
API over the course of the next few months and would give us a chance to
see how OpenJUMPers and the GeoTools folks work together.
I'll wait on some input from the GeoTools developers, if they're
interested in the conversation. :]
Landon,
I feel a bit out of place participating in this thread, since I am neither
an OpenJUMP developer, nor a GeoTools developer nor really a user of either.
However, from the C/C++ open source geospatial community I have frequently
been amazed (in a negative way) at the failure of the OSGIS Java community
to gel around common libraries.
In the C/C++ world, components like GDAL/OGR, PROJ and GEOS are very widely
used in packages including GRASS, MapServer, MapGuide, OSSIM, OpenEV, and
Thuban. It seems to be accepted that re-inventing file format io, or
projections for each package is silly and a drain of resources from the
specific things that set these applications apart.
And yet, from my limited view, it seems that code sharing in the OS Java
world is not as ubiquitous. GeoServer and uDig are the obvious major
applications built on GeoTools. But major Java packages such as OpenJUMP,
deegree and gvSig seem to make only modest or no use of GeoTools - essentially
re-inventing all sorts of stuff from scratch.
Over the years I have kept a bit of an eye on GeoTools and the Java community
at large. I have been both amazed (in a positive way!) and also dismayed at
the enthusiasm for refactoring found in the GeoTools community. I think David
Zwiers is right to raise stability as a concern with regard to GeoTools. The
cardinal rule of GDAL/OGR is "I may get the interface wrong the first time,
but at least I don't change it!". Quite the opposite for GeoTools who seem
keen to revisit core interface design every major rev in the interest of
getting a cleaner or more general design.
But I think OpenJUMP and other teams interested in GeoTools can absolutely
have a positive effect on the GeoTools team in this regard. I think it is
important that you and others get involved and stress the importance of
stability rather than just giving up and duplicating things. I was keen on
GeoTools being an OSGeo project because I think the Java community needs a
strong library or set of libraries to build on. GeoTools seems the clear and
obvious choice for this role. Now what can we do to help it live up to that
role?
While I think there would be some benefits to actually changing out the
OpenJUMP feature model for the one in GeoTools, I can understand why that
would be a high risk step. In the meantime I'd like to strongly encourage
you build some sort of adapter so that any geotools feature source can be
used as an OpenJUMP feature source, even if there is a bit of extra
conversion between feature models always going on. And then stop work on
any data access code of your own, and throw in with GeoTools for this
functionality! Get involved, help out, etc. Just using parts of the low
level shapefile code on the other hand is essentially next to no cooperation
at all.
I don't know what OpenJUMP uses for coordinate system transformations, but
I will stress that GeoTools is quite sophisticated in this realm and this
would be another obvious aspect to take advantage of.
You mentioned the difference in GUI toolkits between OpenJUMP and
GeoTools (uDig?). I don't think you should focus on sharing GUI
components at this time. This is another whole ball of wax, and I'd
claim that the C/C++ world has shown that a huge amount of sharing
and leverage can be accomplished without sharing GUI components.
Anyways, this email is really my plea to OpenJUMP and indirectly to other
projects in the FOSS4G community to treat GeoTools as a building block,
to get involved and to provide strong feedback on the importance for
stability if that is important to you.
The Java world has a quite reasonable desire for "pure java" solutions,
but make that work I think it is important to share labour on a lot of
common low level components.
Best regards,
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
