i think you are right :)
Martin Davis schrieb:
Stefan,
If I understood the original email correctly, the need is not to be able
to call ogr2ogr from JUMP, but to be able to produce a rich data format
which OGR can read & write. I presume the idea is that ogr2ogr can
then be used to translate to lots of other formats.
Stefan Steiniger wrote:
my 2cent:
about ogr2ogr:
would be a nice option to use, but it is written in C++, thus it is
platform dependend. And i am trying to avoid any of non-java libs in
x.JUMP.
The best option for editing data however is to use a database it
manages all the nasty storage, query and update mechanisms for you.
There has been some talk in the GeoTools areana of adding spatial
extensions to one of the embedded Java databases so that you can use
it to manage a binary file based feature storage mechanism. This
would have the advantage in single user environments of not requiring
a database instance.
mhm.. i am wondering where Erwans Group is heading to...
they were working on an "H2" spatial extension:
http://geosysin.iict.ch/irstv-trac/wiki/H2spatial/Why
stefan
Paul
Martin Davis wrote:
Well, this is the holy grail of spatial formats. GML was (is)
supposed to fill this need, but as you have observed it's pretty
complicated to actually use in practice. The JUMP-GML format is a
bit of a hack alright (although no worse than the FME-GML format,
IMO). The right way to do GML in JUMP is probably to emit a
simple-profile GML file generated automatically off the layer schema
(e.g. using attribute names as element names). But in order for
other tools to read this I believe that an XML-Schema file would
have to be produced as well. Also, JUMP would have to be able to
read GML Schemas as well - thus making everything much more
complicated.
Can you propose some other simple, well-known format? Or maybe ask
the OGR people what they would recommend?
Personally, I'm in favour of a text format, since it's easier to
understand. Although, it does tend to lose fidelity of the numeric
(coordinate) information. Maybe a simple binary format would be
better (or a text format with WKB-Hex encoded geometry.
I have had some thoughts about designing a *very* simple text format
looking something like this:
---------------------------------
Geometry: POINT (0 0)
Attribute1: "Some string value"
Attribute2: 123.456
Attribute3: false
Geometry: POINT(1 1)
etc...
---------------------------------
This is easy to read, generate, and parse. It's much easier to read
than GML, IMO. Another advantage is that it's very easy to generate
this as output from other applications, which is a major use case
for me.
Other alternatives would be CSV, JSON, YAML...
Martin
Rahkonen Jukka wrote:
Hi,
It would be really nice if OpenJUMP had, in addition to shapefiles,
some
data format that could be used both for input and output, and that
could
be recognised by other software as well. Ogr2ogr conversion utility is
in my mind right now.
- Shapefiles can be used for input and output, but they can hold just
one type of features and you may need to split your data to points,
lines and polygons first. That is not very handy.
- FME-GML output is OK. One file can hold all the features and ogr2ogr
reads them fine. Unfortunately ogr2ogr does not write out FME
format so
you need to convert data to shapefiles in order to get it back to
JUMP.
Not very handy either.
- JUMP-GML is recognised only by JUMP so it is not an exchange format.
- GML 2.0 input-output is only a theoretical alternative for me,
because
I have never figured out how I should make the templates needed.
Some time ago Sunburned was making plans for JUMP binary format. That
sounds good for me. Or could it be possible to co-operate with
gdal/ogr
folks so that JUMP-GML could be used both for input/output? And is it
impossible to make reading/writing of GML 2.0 more simple in JUMP?
-Jukka Rahkonen-
_______________________________________________
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
_______________________________________________
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
