SS,
I read briefly over your blog, and noticed that you have not taken
stability or product maturity into account. In my opinion GT does not
have either of these components, as can be seen by the rapidly changing
API (version 2.1 is not even a drop-in for version 2.0!). I am only
making this
David,
I really value your input on this, since you have a lot more knowledge of
GeoTools than I do. I was going to ask you about this directly, but I know
that you are busy.
I'm leaning towards the solution of using a GeoTools-To-JUMP Featuer
converter. It's really a question of what will take
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
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
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
Hello Frank, Jody, Landon and all ...
this is exactly what my problem was back in 2004! .. imagine an
impressible powerful graphic user interface for editing (jump) but not
using the all the power of geotools ... still things were/are not that
different, for my thesis i wrote a (simple)
Edgar wrote: wonder why Vivid Solutions .. and other contributors too
(since 2004!
when i got involved into osgis) are not using the readily available
power of geotools2 to implement useful features like reprojection or
geotools datasource modules ... why is that so?
I think the reason for
I thought of another possible solution to working with the two different
feature models in GeoTools and OpenJUMP. We could have an object that
implements both Feature interfaces. We could call the class ExchangeFeature
or something like that. This would eliminate the need for a converter, but
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 of JUMP's big
Well, perhaps you're right, Frank. These days a few meg one way or the
other doesn't make much difference. At least GDAL has a nice stable
API, which encourages people to commit to depending on it.
Certainly the idea of having One core API to rule them all is
appealing. Perhaps someone will
10 matches
Mail list logo
