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
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
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
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
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
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,
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
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
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
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
13 matches
Mail list logo
