Dear Veer,
please write such emails to the jpp-developer list. For such purposes we
have it! If people know a solution or have some ideas they will respond
to you.
Furthermore.. i think you simply should study exitings code (so look for
example in *OpenJumpConfiguration.java* how plugins are i
I completely agree.
The Sunburned Surveyor
On 8/29/07, Martin Davis <[EMAIL PROTECTED]> wrote:
> I just read over the spec for the GML Simple Features Profile. It does
> define a severely restricted schema format, so that's a good thing. But
> it still requires parsing a schema file, and it sti
Martin,
If we decide to support a restricted form of GML 2 we could build our
reader and writer on top of the XML Pull Parser from Sun. This would
help us to avoid memory problems when reading in large files.
https://sjsxp.dev.java.net/
Just a thought.
The Sunburned Surveyor
--
Agreed the pull parser is the only way to go for large XML files
Paul
Sunburned Surveyor wrote:
> Martin,
>
> If we decide to support a restricted form of GML 2 we could build our
> reader and writer on top of the XML Pull Parser from Sun. This would
> help us to avoid memory problems when readin
Yup. It makes you wonder why they didn't use pull parsers from the
very beginning, doesn't it.
SS
On 8/30/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> Agreed the pull parser is the only way to go for large XML files
>
> Paul
>
> Sunburned Surveyor wrote:
> > Martin,
> >
> > If we decide to suppor
It isn't the parser that takes up the memory except temporarily), but
the memory resident dataset after loading. This will still limit the
size.
Larry
On 8/30/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> Yup. It makes you wonder why they didn't use pull parsers from the
> very beginning,
Hi Larry,
You are correct that the resulting data set will take up a lot of memory
at the end, the advantage with the pull parser is that you don't take up
a whole bunch of extra memory for the XML DOM structures which typically
get loaded into memory for the whole document. So with the pull parse
Martin,
I have made some small modifications to your sample SGF (Simple GML
Format?) file.
My changes were as follows:
- I added a "name" attribute to the start tag of the featureCollection
element. This would allow an SGF file to contain multiple
featureCollection elements. OpenJUMP or the pars
Paul is correct. The pull parser does not reduce the memory of the
parsing results, but it does reduce the memory used during the parsing
process. That is because an in-memory representation of the entire XML
document is not constructed.
One advantage of this is using the parser to select only dat
True, if you have the case of one very large GML layer for your whole
map, but this is far from normal GIS.
Larry
On 8/30/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> Paul is correct. The pull parser does not reduce the memory of the
> parsing results, but it does reduce the memory used du
The nightly build of OpenJump hasn't been updated since the 27th
although the source folder has. Does this indicate that the build is
broken?
Larry
--
http://amusingprogrammer.blogspot.com/
-
This SF.net email is sponsored
Roger that Larry. I was just mentioning a possible scenario in which a
pull parser might be an advantage over a SAX/DOM parser.
SS
On 8/30/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> True, if you have the case of one very large GML layer for your whole
> map, but this is far from normal GIS.
>
I agree with both Paul and Larry!
Another good reason for having a pull parser (or in general a streaming
parser) is that it increases it's reusability for clients which can
operate in a streaming fashion. This isn't OJ (at least currently), but
I have other applications for which this was a n
This would be especially important if you had multiple
FeatureCollections stored in one file, and you wanted to load only one
of them.
Sunburned Surveyor wrote:
> Paul is correct. The pull parser does not reduce the memory of the
> parsing results, but it does reduce the memory used during the p
Hi,
I would prefer not to have a need for one data exchange format for small
datasets, and some other for big ones :)
I suppose that it is just this high memory consumption during parsing that is
limiting the size of WFS request in OpenJUMP. The memory is freed once the
parsing is done, but t
Comments:
Instead of the name attribute, I would just use instead of the
tag. GML allows this, and the parser can easily
decide that the first element seen is the name of the dataset. See the
attached...
Ditto for the feature type attribute. Define that the elements nested
below the fe
>At one point I actually rewrote the Shapefile parser to be streaming as well...
I guess I hadn't actually realized it wasn't until now. Do you
remember what happened to the code, or why you didn't stay with the
streaming version? A very large shape file seems like a more likely
scenario that I
Larry,
I don't know if it is of interest to you, but GeoTools has a streaming
ESRI Shapefile parser. They actually have the ability to randomly
access an indexed Shapefile. I plan on using their Shapefile code in
my FeatureCache. The idea is to use the GeoTools code to access one
Feature at a time
Yes, I have looked at the various newer versions of the GeoTools
Shapefile readers. They seemed to be too complicated to be a drop in
replacement for our older GeoTools version (which also has the
capability to randomly read, but that is useless in OJ's
implementation).
Larry
On 8/30/07, Sunbur
Yup. GeoTools is a nightmare to use and understand. It makes me wonder
how they ever built something as functional as UDig on top of it.
However, the alternative was to write a new Shapefile parser from
scratch, and that seemed like an awful lot of work. I have no doubt I
could do it, but it is pr
Landon,
I have one that is based on an iterator approach to reading, I could
adapt it to work with the new DataObject implementation
Paul
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to f
That would be totally awesome!
SS
On 8/30/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> Landon,
>
> I have one that is based on an iterator approach to reading, I could
> adapt it to work with the new DataObject implementation
>
> Paul
>
> --
Hi,
I just checkout the whole trunk and compiled with the included build
without any problem (I mean with only 134 warnings...)
Can someone who knows how the nighlty build is created check what happens ?
Michael
Larry Becker a écrit :
>The nightly build of OpenJump hasn't been updated since t
Thanks Michaël. I guess that is Jon.
Larry
On 8/30/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I just checkout the whole trunk and compiled with the included build
> without any problem (I mean with only 134 warnings...)
>
> Can someone who knows how the nighlty build is created che
Larry Becker wrote:
> I guess I hadn't actually realized it wasn't until now. Do you
> remember what happened to the code, or why you didn't stay with the
> streaming version? A very large shape file seems like a more likely
> scenario that I actually care about.
>
> Larry
>
>
Yes, the co
Martin,
If you could provide the code to Paul and I it would be greatly
appreciated. I will post it on the SurveyOS Sourceforge SVN
Repository, unless someone thinks it is appropriate to host on the JPP
Repository.
Thank you very much for your help.
The Sunburned Surveyor
On 8/30/07, Martin Dav
Hei Michael and Larry,
it doesn't have to be broken. A couple of weeks before I realized the
same problem. I could built at my home computer while the nightly built
did not work - and 3 days later it shipded 2 builts on one day. Maybe we
wait 3-4 days?
stefan
(btw.. to much of message floatin
I suppose this is a little over due.
Jody Garnett and Andrea Aime from GeoTools and Paul Austin and I from
the JPP have been talking some and coding a little to solve a
challenge we see in the open source Java GIS community. The basic
problem is that we find it difficult to share input/output or
r
What C++ library solves this problem? If it's good, can it be copied?
Sunburned Surveyor wrote:
> One of the main reasons for this challenge is that we lack a common
> feature model, or way to represent features in Java. It seems like our
> peers in the C/C++ world don't have this problem, at lea
Just for grins, I coded up a simple example of YAML for tabular
geospatial data.
Seems like this might be another direction to go in. YAML has solved a
lot of the tricky little issues you get into when serializing data to a
text format.
The one thing they don't have AFAICS is a way of encod
without reading your email - just a hint:
Did you had a look on GDBMS (see sourceforge) by the gvSIG people? ...
it should be similar to OGR...
if this is what you are talking about
stefan
-
This SF.net email is sponsored b
Ran the script and got an svn propfind error of some sort.
Ran the script again and it was fine.
I'll check to see if it fails tomorrow.
Jon
-Original Message-
From: Larry Becker [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 30, 2007 11:29 AM
To: List for discussion of JPP develop
Sunburned Surveyor wrote:
Hi,
> I wonder if Deegree or Kosmo is using a streaming Shapefile parser?
deegree has two different shape file readers, and IIRC none of those
can do streaming. It should not be very difficult, though, to adapt
one of them to use streaming.
However, SHP is a very simpl
33 matches
Mail list logo
