I don't see any reason why we couldn't work more with Z values. It
just hasn't been done extensively to date.
The Sunburned Surveyor
On Tue, May 26, 2009 at 10:53 AM, Christopher infinitye...@yahoo.com wrote:
--- On Tue, 5/26/09, Andreas Schmitz schm...@lat-lon.de wrote:
Of course, the
Sunburned Surveyor wrote:
Hi,
I don't see any reason why we couldn't work more with Z values. It
just hasn't been done extensively to date.
yes, I agree. In principle, it should not be so difficult. But my quick research
showed that the deegree conversion process that creates JTS geometries
Sunburned Surveyor wrote:
Hi Landon,
What type of GPX support does Andreas have for deeJUMP? The code I
have in Geotools (and the plug-in I made for OpenJUMP) only reads GPX
files, and I would be interested in adding write support.
Perhaps there is a way to merge the code?
I have code
What type of GPX support does Andreas have for deeJUMP? The code I
have in Geotools (and the plug-in I made for OpenJUMP) only reads GPX
files, and I would be interested in adding write support.
Perhaps there is a way to merge the code?
The Sunburned Surveyor
On Mon, May 25, 2009 at 10:26 PM,
--- On Tue, 5/26/09, Andreas Schmitz schm...@lat-lon.de wrote:
Of course, the elevation values are lost anyway
when read in
OpenJUMP...
Does it need to be that way? JTS includes the ability to specify XYZ
coordinates, it's just that most of the spatial operations only use XY. But if
you
Stefan Steiniger wrote:
Michaël Michaud wrote:
Hi,
Here are my thoughts about the question :
- Andreas is one of the main contributors of the project, so his own
advice about what is good for OpenJUMP is much welcome
thanks, although I don't feel like I've been contributing much
Has anyone looked at the GeoTools GML reader, to see if it's a
reasonable thing to include with OJ?
Writing GML readers is not a trivial task - that was why we went with
the template idea (so as to push the complexity back onto the human).
There might be some simpler approaches that could be
I understand the concern about adding a big library to OpenJUMP. I do
plan on adding CRS capability to OpenJUMP (sometime this year?) and I
have already started putting together the dependencies for the CRS
code.
I wouldn't be against just splitting out the packages we need to use
from the bigger
I've looked at this problem, and I think it would be possible to write
a fairly simple GML parser that didn't need a schema, as long as the
GML file only contained features of one type. It would be possible to
write the same type of parser for GML files that contain features of
different types,
Landon,
Have you looked into the StAX API for XML pull-parsing? I'm using it to
parse KML, and it makes for fairly easy parser implementation (e.g.
recursive descent, which is the simplest for us humans to code up).
http://en.wikipedia.org/wiki/StAX
http://woodstox.codehaus.org/
Sunburned
Martin,
I have looked at StAX and planned on using Sun's implementation. My
code allows you to take information provided by the StAX parser to
build in memory representations of an element and its content. The
idea is you only put into RAM what you need. So, for our GML 2
example, I'll move
My KML parsing code is a bit rudimentary at the moment - it supports
getting the Geometry, and a few attributes like name, description, and
style name. But it should be fairly easy to hack into OJ. It will need
a StAX API available - I'm using Woodstock right now.
If you'd like to try
P.S. - Is your KML parsing code something we could hack to support KML
in OpenJUMP?
there is KML support in SkyJUMP .. just do copy this...
but, OJ doesn't have projection support - so loading kml data is kind of
senseless.
I agree KML loading witout projection support is not great, but it could
load as lat/lon. BTW, SkyJUMP's KML reader is kind of a hack - no attribute
support. OGR's is pretty good (for non-Java). Martin's sounds promising.
While we're on the subject. John Clark and I have implemeted a Java GUI
Hi,
well, if it's generally agreed that we want deegree + libs in OpenJUMP, I'm
sure
I can find the time to integrate the deeJUMP plugin + deegree + libs. That'd
give you some time to concentrate on other things (maybe the CRS code in
deegree?) ;-)
But first I'd like to know what the
Yep, Michael summarizes it very well.
I'm also a hesitating to add a big lib of which we may use only a few
things. Although deegree may offer a lot of functionality for the future
(GML and CRS wise and the extended feature model?).
Does it actually make a difference in terms of memory
Hi,
Once again I tried, with no success, to make an input template for
reading in data in GML 2.0 format by following the instructions from
http://openjump.org/wiki/show/Working+with+GML
Could it be possible to link the input template in the example with a
short GML file that could really be
Andreas Schmitz wrote:
Rahkonen Jukka wrote:
Hi,
Once again I tried, with no success, to make an input template for
reading in data in GML 2.0 format by following the
instructions from
http://openjump.org/wiki/show/Working+with+GML
Could it be possible to link the input
This issue of integrating deegree libraries with OpenJUMP is one I
need to champion. I'm busy the next couple of days preparing for and
covering the Where 2.0 conference, but I will put this item on my to
do list.
The Sunburned Surveyor
On Mon, May 18, 2009 at 4:44 AM, Rahkonen Jukka
Sunburned Surveyor wrote:
Hi,
This issue of integrating deegree libraries with OpenJUMP is one I
need to champion. I'm busy the next couple of days preparing for and
covering the Where 2.0 conference, but I will put this item on my to
do list.
well, if it's generally agreed that we want
20 matches
Mail list logo
