I'm going to start investigating the point performance problem as
soon as I get some test data. I have been trying to locate a large
point dataset on the web, but no luck. Perhaps the best approach
might be to add a new item to the Generate menu, "Random Points".
@Arnd: One thing that people often forget about JUMP is that
rendering is a background process. You don't have to wait for it to
finish to start the next operation.
What kind of terrain maps are you generating? Are you generating
contour lines from a grid of points? You mentioned deleting selected
points being impossibly slow. I don't see why this should be so. If
I can duplicate the problem, it should be an easy fix.
regards,
Larry
On 10/2/07, *Larry Becker* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
HI Arnd,
Would it be helpful to work around the problem by saving the
points as a shapefile and using a utility like shp2tile to break
the point data up into multiple files?
see: http://imaptools.com/download-software.html
regards,
Larry
On 10/2/07, *Arnd Kielhorn* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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]>
>>> <mailto: [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]>
>>> <mailto: [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
