mhm.. this also reminds me on some internal group problems, when one of
our team tried to develop the webprocessing service interface to
transfer data but also supporting data structures such as TINs, graphs.
I currently don't know his last specifications but i think he will make
some documentation by october. So then i can come up with the doc and we
can also start to add the processing services plugin the openjump
download list. (mhm .. actually i can ask him also for the paper, that
should be published in a few month and is part of his thesis on map
generalization web services)
stefan
Sunburned Surveyor schrieb:
This has been a very interesting thread. I wanted to boil some of it
down so the conversation is not wasted. :]
It seems most of us can agree on the following:
[1] A text based file format is the best for data interchance.
[2] Having to mess with internals schemas for an exchange format is a
real pain in the butt.
[3] We don't really want to mess with the
Java-To-Some-Other-Programming language interface.
I really don't think that most of this is an OpenJUMP problem. It is
more like a "this is how our messed up civilization works" problem.
What we are really talking about here is a universal exhange format
for geospatial data. As was mentioned, GML tried to achieve this, but
failed. I think this failure was due to the flexibility of the format.
The format is so flexible you need a schema to understand it.
Shapefiles don't have the problem because they are less flexible. So
we are dealing with the flexibility <> Simplicity trade-off.
Here is what I suggest. Find out what import/export formats OGR2OGR
supports. Create a plug-in for OpenJUMP that will export to that
format. (I don't know much about OGR, so this might not be possible.)
On a related note, I have been trying to work with Paul and some gusy
from GeoTools on a "universal feature object" that could be read and
written by different Java programs. This "universal feature object" is
a really simple representation of a feature. The idea is that Java
programmers will be able to write a single parser/writer for a file
format, and then programs like UDig and OpenJUMP can simply worry
about the conversion from the universal format to their own feature
model. I'm not sure how all of this will work out, but maybe in a
couple years we will be a lot closer to solving this problem.
P.S. - I always thought the problem with GML could be fixed using an
XML standard that enforced a little more simplicity and embedded some
datatype information in the file itself. See the attahed file for an
example of what I am talking about. Would you need any external
information to parse this type of file? As long as you could
reasonably map the attribute types and geometry types to the
appropriate objects/data types in your programming language.
On 8/10/07, Paul Austin <[EMAIL PROTECTED]> wrote:
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
------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<Feature>
<identity>233660</identity>
<type>surveyPoint<type>
<attributes>
<attribute>
<name>SurveyedDate</Name>
<type>String</Type>
<value>2007/08/10</Value>
</attribute>
</attributes>
<geometry>
<point>
<northing>5633.23</northing>
<easting>10233.69</easting>
<elevation>522.01</elevation>
</point>
</geometry>
</feature>
------------------------------------------------------------------------
_______________________________________________
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
