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
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 wrote:
>
>
> --- On Tue, 5/26/09, Andreas Schmitz wrote:
>> Of course, the elevation values are lost anyway
>> when
--- On Tue, 5/26/09, Andreas Schmitz 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 have the elevation
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, An
Stefan Steiniger wrote:
Hi all,
> Wow.. I just read what plugins Andreas added as experimental for deeJUMP
> (gpx support and projection) - so I started now to consider the
> integration of the deegree libs.
people who read the commit logs ;-)
This was actually done in my spare time out of pe
Wow.. I just read what plugins Andreas added as experimental for deeJUMP
(gpx support and projection) - so I started now to consider the
integration of the deegree libs.
(Although the nice thing is that deeJUMP is in fact rather an extension
for those who need it ;). I guess we will do sooner
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
>
> 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.
-
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 integra
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 throu
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 Su
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, but
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 l
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
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 l
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 footprint
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
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
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
wrote:
> An
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
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 template in the example with a
> short
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 open
23 matches
Mail list logo