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 how to digest everyone's responses and come up with a good
decision. I especially value the opinion of Martin Davis and David Zwiers.
They have both worked with GeoTools and OpenJUMP. I think it was especially
insightful when Martin pointed out the danger in the instability of the
GeoTools API. He had a knowledge of JUMP that far surpasses mine, and I
would have expected him to have spoken differently now that he has moved to
Refractions Research and I imagine will be more involved in GeoTools
development as part of UDig. To his credit, he remained honest about
GeoTools current status, for which I am grateful.
Frank Wammerdam's comments are also valuable to me, because he views our
community from a very objective perspective, and I think he gives us all
some needed chastisement or counsel. I think his advice against a
private fork of GeoTools is good advice. If we're going to have an influence
in creating a more slowly developed and stable GeoTools we need to be
contributors to the library, not just users of it. Writing this converter
will give me a chance to fill that role, even if I'm only fleshing out
Javadoc comments and adding some tutorials to the wiki.
Jody also mentioned a great suggestion about the GeoAPI. This made me
realize I may be putting the "cart before the horse". I will subscribe to
the GeoAPI list as soon as possible, and will make an effort to represent
the OpenJUMP community there.
I have decided, for the time being, to develop some code that will allow us
to convert between the GeoTools and JUMP Feature models. I will do this with
the eventual goal of having OpenJUMP and UDig utilizing a common feature
model provided by the GeoTools library. I'll release all of my
conversion code through the SurveyOS SourceForge Project.
I realize this falls short of adopting the GeoTools Feature Model outright,
but I am afraid that involves too much risk for our project and too much
work for one part-time, rookie code slinger. Let all parties at the "table"
in the open source Java GIS community look at this as OpenJUMP's way of
making an effort to improve our relationships with GeoTools and the GeoAPI.
I hope this effort, small and meager as it may be, will not go unnoticed. I
think the reality is that it takes effort and compromise from all groups to
work together. I will need support from the other members of the community
to make this first step the first step of a long walk. OpenJUMP is a
democracy (sort-of) and I have little control over its direction. I also
have no control at all over what happens with JUMP. In order to make this
move a success the other members of the JUMP/OpenJUMP community will need to
see that the benefits of this type of collaboration are worth the cost. This
will be no easy task.
I don't think we need to pretend that Vivid Solutions and Refractions
Research are best friends, they're not. In fact, they're competitors. This
is a reality that will affect the relationship between UDig, OpenJUMP, and
GeoTools. At OpenJUMP I'm trying to find a way to dance among these two
companies in so that we can benefit from the hard work that both companies
development teams are doing. I have to be honest at this point and admit
that as JUMP goes, OpenJUMP goes. We depend greatly on Vivid Solutions for
expertise and advice on the code that makes OpenJUMP run, although this may
not be so strongly the case now that Martin Davis has left the company.
Still, it would be foolish to allow OpenJUMP's code base to deviate a great
deal from Vivid's JUMP. In the end, OpenJUMP gives us a degree of
independence from Vivid's decisions about JUMP. But for practical reasons
this is only a small degree of independence, not total independence.
I'm afraid that my decision will not make everyone happy. There are too many
groups involved, and too many opnions. I don't want to have the folks at
Deegree think I don't value their work. This is not the case at all. I need
to do a better job of working closely with them, and Ugo has been around
from the very beginning of the JPP. (I am subscribed to their mailing list.)
:] I encourage their team to join my efforts to become more active in GeoAPI
and GeoTools. I think together we will have a much stronger voice in the
decisions that are made. If the folks producing Kosmo join us we could
accomplish even more together.
In conclusion let me ask for everyone's patience. I'm not an expert
programmer, nor am I a great leader or a great diplomat. I'm a land
surveyor, and the only bridges I'm used to building go over rivers and
canyons. Please remember that I will make mistakes, and sometimes bad
decisions. Give me some time to work with the folks at GeoTools before we
decide that this decision was one of the bad decisions. :]
The Sunburned Surveyor
-------------------------------------------------------------------------
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/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
