Hi Sunburned,
I don't have a lot of time to study your problem, but I note that there is
code in OpenJump that Stefan put in for Ole to support PIROL's image layer
renderer (a plugin, right?). I've seen the code (just search for "Ole" in
the source), but I haven't seen how PIROL uses it. It ma
Thanks Larry.
I think I've come up with a solution. I'm going to give it a try and I'll
report back to the list.
The Sunburned Surveyor
On 3/29/07, Larry Becker <[EMAIL PROTECTED]> wrote:
Hi Sunburned,
I don't have a lot of time to study your problem, but I note that there
is code in Open
Thanks for reporting these problems Geoffrey. Hopefully we can get someone
to look at what might be causing these problems. If these bugs don't exist
in JUMP it must be some changes we've made to the styling in OpenJUMP.
Can anyone comment on this?
Thanks,
The Sunburned Surveyor
On 3/28/07, G
I've been working on a solution to the problem of working with very large
datasets in OpenJUMP at home the past couple of weeks. (For those of you
that don't know, OpenJUMP reads all features in from a data source into
memory. This isn't a problem until you start working with some very large
datas
Hi Sunburned,
Currently, in my laboratory we are working on this problem. We are studying
two solutions :
- use GML such as a native format (eg TAB in MapInfo),
- create a specific binary format for OJ.
When we have some results, I send a mail to the OJ team.
Cheers.
R1.
On 3/29/07, Sunburn
Erwan,
Can I ask why you would create a custom binary format instead of using the
standard Java serialization format? I'm interested in the performance
differences between a text-based storage format and a binary storage format.
I would be very interested in the results of your labratory. Perhaps
Hi sunburned,
I think that a light-weight feature class or FeatureOnDemand is a good
solution, as well as a FeatureCache.
I already tested Agile's scalable shapefile driver, and I'm currently
implementing something similar for GeoConcept format(a commercial gis).
It can save a lot of memory (bu
Michael,
Your comments were very helpful. Please see my responses below.
You wrote: "I think that a light-weight feature class or FeatureOnDemand is
a good
solution, as well as a FeatureCache."
I'm glad you think so. I like the term "FeatureOnDemand". Do you mind if I
use it as the name of the
Sunburned Surveyor,
> I'm glad you think so. I like the term "FeatureOnDemand". Do you mind
> if I use it as the name of the light-weight feature class?
I guess I read this term from Agile's code. I don't mind who uses it and
hope alvaro zabala, the original developer of agile doesn't mind too.
