Jeff,
Based on current experience it is far better to spend the effort to come
up with Java readers and writers for formats that to try and use third
party binary libraries and C code.
The reasons are this as follows.
* Believe it or not Java can be faster, I have a reader for the SAIF
format that can load and display 150,000 features in OpenJUMP in
about 10 seconds. Compare that with FME viewer which takes about
90 seconds on the same machine.
* Integrating JNI is a real pain, you have to deal with a whole
bunch on the C++ memory management. I've seen many cases where JNI
code leads to huge memory leaks.
* You'll have to convert from the model in C++ to Java which can
slow things down a hell of a lot.
* When using C++ or binary libraries you are stuck a bit if you find
a bug in their code, it can take longer to track it down than if
you have written the code yourself.
Of course as JUMP is plugin based if someone wanted to integrate one of
these libraries they are free to do so.
Paul
Jeff McKenna wrote:
I brought this up on this list before, (wishing jump could use
OGR/GDAL), I am a huge jump* fan and user, but the java guys shoot me
down each time.
--
jeff
Martin Davis wrote:
Martin Davis wrote:
One approach might be to emit a more standard GML file, along with a
schema, but add some attributes to the first record in the file
which JUMP would understand. This would allow providing simple
typing information, and could also indicate that the first record
was simply a dummy record, if the file was actually empty. Other
tools wouldn't understand this, but they could at least read the
file. JUMP could read and write these file quite happily.
By the way, there's good precedent for doing something like this. At
GeoWeb ESRI gave a talk on their version of GML, which involved
adding lots of extra information to basic GML to accomodate their
richer data model. Obviously other tools are very unlikely to be
able to write this format, but they should be able to at least read it.
I guess this would be the same situation (readable but not writable
by other tools) for my proposed "JML2". So maybe that only meets
half of the need. Sigh... It seems to me to be *very* difficult to
develop an full-blown GML reader for JUMP that can handle arbitrary
GML. (GeoTools apparently has one, though... deegree too maybe?)
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
