Hello Paul,
thank You for the tip with the z-value, but how I can use it as a
z-value on the point itself?
The file fomrat is txt, csv (from PIROL CSV-Format) like following example
$Rechts Hoch heigh
$grad grad m
$double double double
3434000.00 5800000.00 93.78
3434001.00 5800000.00 93.84
... ... ...
or the ESRI ascii grid format asc (reading plugin from SIGLE).
The most files I got have 1 million points and such csv files have about
30 MB.
In my start file for OJ I got 768 MB, because I have 1 GB RAM.
Kindly regards
Arnd
Paul Austin schrieb:
Arnd,
What file format are you using?
As JUMP loads the whole file into memory I would recommend setting the
heap size on the JAVA VM to be -Xmx512M if you are dealing with large
datasets.
You mentioned that the height is an attribute on the feature, if you use
the height as a z-value on the point itself there will be some memory
savings.
Paul
Arnd Kielhorn wrote:
Hello Larry,
as in the further discussion just named the main problema are (for
example I just have to work with point layers with only a heigh
attribute but with 1 million points; but also e.g. 300,000 points are
enough):
- (re)drawing of the points
- strongly restricted or impossible operation (e.g. deleting some
points/vertices after marking them; e.g. copying hundreds or a few
thousand in a new layer to have layer with lesser points)
Very often OJ hangs on and I have to restart it.
I use such point layers for creating a digital terrain maps.
Kindly regards
Arnd
Larry Becker schrieb:
Hi Arnd,
I haven't worked with large point datasets much. What it is
exactly that is slow? Is it redraw time? Or perhaps the particular
operation that you are doing?
I know that point layers do not benefit from the recent decimation
optimization, so they take longer to draw than equivalent polygons
and polyline layers. I think Michaël tried a point decimation
optimization, but wasn't satisfied with the results.
regards,
Larry Becker
On 10/1/07, *Stefan Steiniger* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
mhm
from my point of view it is both OJ and JRE. It would be probably
better
when the points are stored and processes in a database.
stefan
Arnd Kielhorn schrieb:
> Hello,
>
> yes I know, first of all OJ is a GIS for vector data. But the
> functionality is also very good for point datasets. But working
with
> great point datasets (more 500,000 points) bring problems with the
> memory and the garbage collector works not satisfied. Every
command take
> a lot of time or could not carried out. (CPU P4 2.4 GHz, 1 GB RAM)
> Is it only a thing of the JRE or also from OJ?
> So, it is useful to know if there is a chance to increase the
> performence of OJ in this case and what could be the possible
milestones
> to reach this aim?
> I am very eager to read everyones opion.
>
> Kindly regards
> Arnd
> _______________________________________________
> jump-users mailing list
> [email protected]
<mailto:[email protected]>
> http://lists.refractions.net/mailman/listinfo/jump-users
>
>
_______________________________________________
jump-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.refractions.net/mailman/listinfo/jump-users
<http://lists.refractions.net/mailman/listinfo/jump-users>
--
http://amusingprogrammer.blogspot.com/
------------------------------------------------------------------------
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
