Hi, I think you might start by downloading the US dump file, it is the largest. Description about what if contains is here: http://www.geonames.org/statistics/united-states.html Statistics say that there are points for 163.726 populated places in the USA and 172.008 schools, for example. -Jukka-
________________________________
Lähettäjä: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Puolesta Larry
Becker
Lähetetty: 4. lokakuuta 2007 16:44
Vastaanottaja: JUMP Users Discussion
Aihe: Re: [jump-users] Better Performence for point data
Hi Jukka,
Thanks for the link. I'm not familiar with this data and there seem
to be a lot of choices. Can you tell me which one might be closest to Arnd's
problem?
regards,
Larry
On 10/4/07, Rahkonen Jukka < [EMAIL PROTECTED] <mailto:[EMAIL
PROTECTED]> > wrote:
Hi Larry,
Perhaps Geonames database http://www.geonames.org/export/ has
enough points for testing.
-Jukka-
________________________________
Lähettäjä: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Puolesta Larry Becker
Lähetetty: 4. lokakuuta 2007 16:17
Vastaanottaja: JUMP Users Discussion
Aihe: Re: [jump-users] Better Performence for point data
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]> 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] >
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]>> 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]> >
>>> >
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
--
http://amusingprogrammer.blogspot.com/
--
http://amusingprogrammer.blogspot.com/
_______________________________________________
jump-users mailing list
[email protected]
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
