[jump-users] Better Performence for point data

Stefan Steiniger sstein at geo.uzh.ch
Wed Oct 10 02:41:37 PDT 2007


> delete 624000 and rebuild the layer view   after 01:30 "Java heap space"
>
mhm.. maybe it is the "undo" function that consumes further time and space.
So one would need to introduce an option for disabling undo.

just a thought

stefan

> After that I closed OJ and set now 1536 (1024 + 512) in the 
> openjump:bat and restart OJ to test the last task again
>
> task    used time[mm:ss]   used memory after task[MB]
> select 624000   01:25   402
> delete 624000 and rebuild the layer view   after 45:00 I stopped the 
> task withour any result
>
> Conclusion from my point of view:
> The performence after Larrys modification increased clearly!! 
> Congratulation and many thanks for that!! But to do more than viewing 
> or make a colour theming (also OK is calculating new attributes, under 
> 02:00) with such big datasets such as interpolating the modification 
> is not sufficient at the moment. I have no experiences whether and how 
> fast other GIS software can do all these tasks. It will be very great 
> if there could be further potential for higher performence in the 
> future developments.
>
> Thank You again Larry!!
>
> Kindly regards
> Arnd
>
>
>
> Larry Becker schrieb:
>
>> To follow up:
>>
>> I downloaded the nightly build (20071009) and retested with Arnd's 
>> XYZ-data.
>>
>> To select 624,000 points it took 40 seconds, plus an additional 50 to 
>> render the handles.
>>
>> It took 3 seconds for the menu to appear after a right click on the 
>> layer view.  Same for the Edit menu.  The Layer context menu 
>> responded immediately.
>>
>> Committed memory went up to 586 MB.
>>
>> It would appear that the performance for selecting points and drawing 
>> handles has improved by a factor of 2.  The GUI responsiveness 
>> problem has been fixed.  It is now possible to select all million 
>> points without an out of memory error (in 750MB).
>>
>> I will wait for Arnd to do his own tests and see if OpenJump is now 
>> suitable for working with large point datasets.
>>
>> regards,
>> Larry Becker
>>
>> On 10/8/07, * Larry Becker* <becker.larry at gmail.com 
>> <mailto:becker.larry at gmail.com>> wrote:
>>
>>     Hi Stefan,
>>
>>       Actually since the selection handle is slightly larger than a
>>     point, I just skipped rendering the point.  I don't know if you
>>     noticed, but when something is selected, JUMP renderes it again so
>>     that selected items will be "on top" of the other features.  For
>>     linestrings and polygons, this is nice, but for points it is     
>> redundant.
>>
>>     Larry
>>
>>
>>     On 10/8/07, *Stefan Steiniger* < sstein at geo.uzh.ch
>>     <mailto:sstein at geo.uzh.ch>> wrote:
>>
>>         Hei Larry,
>>
>>         thank you for making the changes to the source :)
>>         And I am glad you did it, as you are more familar with the
>>         code then I am.
>>
>>         Just one question on the change in the
>>         AbstractSelectionRenderer. What
>>         is meant with "obscured" handle? Is that you look if already a
>>         selection-point is drawn nearby and you check if it is
>>         obscured using
>>         the screen resultion?
>>
>>         stefan
>>
>>         Stefan Steiniger wrote:
>>
>>         >
>>         >> All we have to do is save a few class variables (like
>>         numberSelected)
>>         >> and all of those computations and memory use go away.  We
>>         update the
>>         >> variables each time the selection really changes.  New
>>         methods like
>>         >> countSelectedItems() will replace getSelectedItems() in the
>>         >> EnableChecks.
>>         >
>>         >
>>         > this sounds reasonable - great work Larry
>>         > stefan
>>         >
>>         >>
>>         >> regards,
>>         >> Larry
>>         >>
>>         >> On 10/5/07, *Stefan Steiniger* <sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch>
>>         >> <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>> 
>> wrote:
>>         >>
>>         >>     well done!
>>         >>
>>         >>     i am not sure if this makes sense, but for drawing 
>> alone one
>>         >> could use a
>>         >>     "skip n points" mechanism or use an indexing scheme ( 
>> e.g.
>>         >> quadtrees with
>>         >>     skipping the lower(?) levels to show). I guess this
>>         would need some
>>         >>     testing to identify the number of points that should be
>>         drawn
>>         >> maximally
>>         >>     and that need to be drawn. But for the selection this is
>>         not
>>         >> possible
>>         >>     (except the drawing). Not sure if modifying "enable
>>         check" is a
>>         >>     solution
>>         >>
>>         >>     I guess Martin has some nice thoughts on that ;)
>>         >>     stefan
>>         >>
>>         >>     btw: @Martin: is you FOSS4G - DTM-TIN paper available?
>>         (I read he
>>         >> used
>>         >>     also massive data - millions of heigh points - with 
>> postgis)
>>         >>
>>         >>     PS: have you seen this presentation on high res image
>>         browsing,
>>         >> which
>>         >>     comes quite close to our problem, although a it is bit
>>         different
>>         >> domain:
>>         >>             http://www.ted.com/index.php/talks/view/id/129
>>         <http://www.ted.com/index.php/talks/view/id/129>
>>         >>     (sorry don't want to hijack this topic but it is related)
>>         >>
>>         >>     Larry Becker schrieb:
>>         >>      > I'm retesting with Arnd's new XYZ-data which
>>         contained a 62MB
>>         >>     shape file
>>         >>      > and a 33MB dbf file.
>>         >>      >
>>         >>      > 1. OJ loaded the file in 15 seconds and finished
>>         drawing it in 55
>>         >>      > seconds.  335MB committed memory.
>>         >>      >
>>         >>      > 2.  Finished selecting about 2/3 of the points in 75
>>         seconds
>>         >> Finished
>>         >>      > drawing the selection handles in another two
>>         minutes.  Up to
>>         >> 452MB of
>>         >>      > committed memory.  Right clicked on the view and it
>>         took about 2
>>         >>     minutes
>>         >>      > to respond.
>>         >>      >
>>         >>      > Clearly the selection of 600000+ objects is causing
>>         havoc in
>>         >> the UI
>>         >>      > EnableChecks.  Also, the selection handle rendering
>>         optimization
>>         >>     that I
>>         >>      > made is not effective for points, so it must draw
>>         600000 tiny
>>         >> yellow
>>         >>      > rectangles each redraw.
>>         >>      >
>>         >>      > So is it about memory?  I increased OJ's memory
>>         allocation to
>>         >>     750MB and
>>         >>      > reloaded.  Same load and redraw stats.
>>         >>      >
>>         >>      > 3.  I used the Edit->Select layer items.  It took 2
>>         minutes to
>>         >>     display
>>         >>      > the selected items message (1000000) on the status
>>         bar.  While
>>         >>     selection
>>         >>      > handles were drawing, committed memory cycled between
>>         650 and
>>         >> 700 MB.
>>         >>      > Clearly, frequent pauses in drawing were caused by
>>         the JVM
>>         >> garbage
>>         >>      > collector.  I waited for the handles to finish
>>         drawing so that I
>>         >>     could
>>         >>      > test the menu response time.  Finally, it
>>         finished.  I clicked
>>         >> on the
>>         >>      > Edit menu.  After a few seconds the workbench window
>>         went totally
>>         >>     blank
>>         >>      > for 3 minutes, then came back.  I didn't try it again.
>>         >>      >
>>         >>      > Conclusion:  I concur with Arnd that OpenJump is
>>         unworkable
>>         >> for point
>>         >>      > files in excess of 500000.  The redraw of a million
>>         points is
>>         >> bad,
>>         >>      > redraw of a million selection handles is worse, and
>>         the UI is
>>         >> totally
>>         >>      > unresponsive with large numbers of objects selected.
>>         >>      >
>>         >>      > I believe that we may have reached the design limits
>>         of the UI
>>         >>     feedback
>>         >>      > mechanisms.  In particular EnableCheck class 
>> methods make
>>         >> multiple
>>         >>      > references to the number of features.  The selection
>>         feedback
>>         >> on the
>>         >>      > status bar even computes the number of points
>>         (requiring a
>>         >> million
>>         >>      > iterations for each access).
>>         >>      >
>>         >>      > I repeated the experiment with JUMP 1.2 (750MB
>>         memory) which
>>         >> does not
>>         >>      > have some of the UI enhancements like the status bar
>>         display of
>>         >>     number
>>         >>      > of selected items and points.  The first thing I
>>         noticed is that
>>         >>     JUMP
>>         >>      > renders much slower than OpenJump.  No way am I going
>>         to wait for
>>         >>     it to
>>         >>      > finish.  I did a drag select around the whole view 
>> (since
>>         >> there is no
>>         >>      > select layer items on the Edit menu).  It is taking a
>>         long
>>         >>     time.  I'm
>>         >>      > not timing any of this since the only thing I'm
>>         interested in
>>         >> is the
>>         >>      > menu response time.  I found that an easy test to see
>>         if the
>>         >> UI is
>>         >>      > responsive is to mouse over a toolbar icon and see 
>> if it
>>         >> highlights.
>>         >>      > Oops, JUMP just gave an Out of Memory Error.  End 
>> of that
>>         >> experiment.
>>         >>      >
>>         >>      > I still believe the main problem is the UI
>>         checks.  The UI is
>>         >> totally
>>         >>      > responsive until you make a large selection.  Then it
>>         gets
>>         >>     progressively
>>         >>      > slower proportional to the size of the
>>         selection.  Fixing this
>>         >> is the
>>         >>      > number one priority.
>>         >>      >
>>         >>      > I loaded the file in SkyJUMP which has metrics for 
>> screen
>>         >> redraw.  It
>>         >>      > rendered the million points in 50 seconds. There is
>>         room for
>>         >>     improvement
>>         >>      > here, but this is not really the main problem.  Any
>>         optimization
>>         >>     done to
>>         >>      > optimize point drawing would also apply to selection
>>         handles.
>>         >> Fixing
>>         >>      > this is the number two priority.
>>         >>      >
>>         >>      > regards,
>>         >>      > Larry
>>         >>      >
>>         >>      >
>>         >>      >
>>         >>      >
>>         >>      >
>>         >>      >
>>         >>      >
>>         >>      > On 10/4/07, *Larry Becker* <becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>
>>         >>     <mailto: becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>>
>>         >>      > <mailto: becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com> <mailto:
>>         becker.larry at gmail.com <mailto:becker.larry at gmail.com>>>>
>>         >>     wrote:
>>         >>      >
>>         >>      >     OK, for my PC (P4 3.2Ghz with OJ set to use
>>         256MB) it takes 5
>>         >>      >     seconds to load your 351k points u1 layer, and 17
>>         seconds to
>>         >>     draw.
>>         >>      >     Pretty bad draw performance compared with other
>>         geometry
>>         >>     types, but
>>         >>      >     not really relevant to the discussion since
>>         waiting for the
>>         >>     redraw
>>         >>      >     is not necessary.
>>         >>      >
>>         >>      >     1. I managed to copy and paste about 100k of
>>         these to a new
>>         >>     layer in
>>         >>      >     about 10 seconds.  Replicate gives similar 
>> results.
>>         >>      >
>>         >>      >     2. Selecting about 1/3 of the points takes about
>>         5 seconds
>>         >> to do,
>>         >>      >     and about 8 more to render the handles, 
>> although as I
>>         >> mentioned
>>         >>      >     before, you can proceed as soon as the the 
>> status bar
>>         >>     indicates the
>>         >>      >     number selected.
>>         >>      >
>>         >>      >     3. Selecting all points takes about 20 seconds, 
>> and
>>         >> another 30 to
>>         >>      >     render.
>>         >>      >
>>         >>      >     Preliminary results for 350000 points: slow but
>>         definitely
>>         >>     workable.
>>         >>      >
>>         >>      >     I loaded 3 copies of the u1 layer giving a total
>>         of over 1
>>         >>     million
>>         >>      >     points.  Memory usage is at 200 MB committed.  I
>>         suspect it
>>         >>     would be
>>         >>      >     quite a bit more if Stefan's data had any 
>> attributes.
>>         >>      >
>>         >>      >     4. Redraw is now about 45 seconds, but just
>>         ignoring it works
>>         >>     for me.
>>         >>      >
>>         >>      >     5. Selecting about 1/3 failed after 90 seconds and
>>         >> resulted in an
>>         >>      >     Out of Memory Error.
>>         >>      >
>>         >>      >     After allocating 512MB of memory to OJ, I
>>         restarted.  390000
>>         >>     points
>>         >>      >     selected after 20 seconds.  The selection handles
>>         finished
>>         >>     rendering
>>         >>      >     40 seconds later. 388MB in use.
>>         >>      >
>>         >>      >     6. Right clicking on the selection takes about 5
>>         seconds to
>>         >>     bring up
>>         >>      >     the menu.
>>         >>      >
>>         >>      >     7.  Replicate took about 20 seconds to replicate
>>         to a new
>>         >> layer.
>>         >>      >
>>         >>      >     These are my current findings.  I'll update the
>>         post when
>>         >> I test
>>         >>      >     with Arnd's data.  So far I don't see anything too
>>         >>     bad.  About what
>>         >>      >     you might expect really.  The rendering code is 
>> not
>>         >> optimized for
>>         >>      >     points, and the selection code is dealing with
>>         its worst case
>>         >>     since
>>         >>      >     the bounding box for points is a point.
>>         >>      >
>>         >>      >     Larry
>>         >>      >
>>         >>      >     On 10/4/07, *Stefan Steiniger* <
>>         sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>
>>         >>     <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>
>>         >>      >     <mailto:sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch> <mailto: sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch>>>> wrote:
>>         >>      >
>>         >>      >         oha..
>>         >>      >         that is interesting. Accidentaly i stored the
>>         points as
>>         >>     multipoints.
>>         >>      >         Now i updated my jump @office and stored the
>>         points as
>>         >> point
>>         >>      >         (and wrote
>>         >>      >         the file again to the ftp). The file size is
>>         now already
>>         >>     a bit
>>         >>      >         smaller,
>>         >>      >         and also the commited memory...
>>         >>      >
>>         >>      >         stefan
>>         >>      >
>>         >>      >         Stefan Steiniger wrote:
>>         >>      >
>>         >>      >         >  Good if Arnd provides the data, but here
>>         the link to
>>         >>     my data
>>         >>      >         in case
>>         >>      >         >  it fails:
>>         >>      >         >          
>> ftp://ftp.geo.uzh.ch/pub/sstein/data/u1_points.zip
>>         <ftp://ftp.geo.uzh.ch/pub/sstein/data/u1_points.zip>
>>         >>      >         >
>>         >>      >         >  an option to get one million points is to
>>         copy the
>>         >>     350k points and
>>         >>      >         >  then to move them (if that works ;).
>>         >>      >         >  Btw. the lascers can data have no
>>         attributes (may be
>>         >>     therefore
>>         >>      >         smaller
>>         >>      >         >  than Arnd's; the covered area is
>>         relatively small <
>>         >> 200m)
>>         >>      >         >  (shapefile size is 30mb and zip xyz-ascii
>>         was 15mb)
>>         >>      >         >
>>         >>      >         >  stefan
>>         >>      >         >
>>         >>      >         >  Arnd Kielhorn wrote:
>>         >>      >         >
>>         >>      >         > > Hello Larry,
>>         >>      >         > >
>>         >>      >         > > first of all, thank You very much!
>>         >>      >         > >
>>         >>      >         > > I work with delaunay triangulation and
>>         building a
>>         >>     3D-Model
>>         >>      >         with our
>>         >>      >         > > plugin.
>>         >>      >         > >
>>         >>      >         > > If we both could make a direct connection
>>         (via FTP or
>>         >>     a free
>>         >>      >         tool
>>         >>      >         > > called teamviewer) I could sent You one
>>         file with
>>         >>      >         laserscanning data
>>         >>      >         > > with 1 million points (XYZ). It is about
>>         30 MB in the
>>         >>     PIROL-CSV
>>         >>      >         > > format or about 100 MB as shape file.
>>         >>      >         > >
>>         >>      >         > > Kindly regards
>>         >>      >         > > Arnd
>>         >>      >         > >
>>         >>      >         > > Larry Becker schrieb:
>>         >>      >         > >
>>         >>      >         > >> 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* <
>>         becker.larry at gmail.com <mailto:becker.larry at gmail.com>
>>         >>     <mailto: becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>>
>>         >>      >         <mailto:becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>
>>         >>     <mailto: becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>>>
>>         >>      >         > >> <mailto: becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>
>>         >>     <mailto: becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>>
>>         >>      >         <mailto:becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>
>>         >>     <mailto: becker.larry at gmail.com
>>         <mailto:becker.larry at gmail.com>>>>> 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
>>         >>     <http://imaptools.com/download-software.html
>>         <http://imaptools.com/download-software.html>>
>>         >>      >         > >>
>>         >>      >         > >>     regards,
>>         >>      >         > >>     Larry
>>         >>      >         > >>
>>         >>      >         > >>
>>         >>      >         > >>     On 10/2/07, *Arnd Kielhorn* <
>>         a.kielhorn at gmx.de <mailto:a.kielhorn at gmx.de>
>>         >>     <mailto: a.kielhorn at gmx.de <mailto:a.kielhorn at gmx.de>>
>>         >>      >         <mailto: a.kielhorn at gmx.de
>>         <mailto:a.kielhorn at gmx.de> <mailto:a.kielhorn at gmx.de
>>         <mailto:a.kielhorn at gmx.de>>>
>>         >>      >         > >>     <mailto: a.kielhorn at gmx.de
>>         <mailto:a.kielhorn at gmx.de>
>>         >>     <mailto: a.kielhorn at gmx.de <mailto:a.kielhorn at gmx.de>>
>>         <mailto: a.kielhorn at gmx.de <mailto:a.kielhorn at gmx.de>
>>         >>     <mailto:a.kielhorn at gmx.de <mailto:a.kielhorn at gmx.de>>>>>
>>         >>      >         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* <
>>         >>      >         sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>
>>         <mailto:sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>
>>         >>     <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>
>>         <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>>
>>         >>      >         > >>         <mailto: sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch>
>>         >>     <mailto:sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>
>>         <mailto:sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>
>>         >>     <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>>>
>>         >>      >         > >>         >>> <mailto: sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch>
>>         >>     <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>
>>         >>      >         <mailto: sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch> <mailto:sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch>>>
>>         >>     <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>
>>         <mailto: sstein at geo.uzh.ch <mailto:sstein at geo.uzh.ch>>
>>         >>      >         <mailto: sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch> <mailto: sstein at geo.uzh.ch
>>         <mailto:sstein at geo.uzh.ch>>>>>>
>>         >>      >         > >> 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
>>         jump-users at lists.jump-project.org
>>         <mailto:jump-users at lists.jump-project.org>
>>         http://lists.refractions.net/mailman/listinfo/jump-users
>>
>> _______________________________________________
>> jump-users mailing list
>> jump-users at lists.jump-project.org
>> http://lists.refractions.net/mailman/listinfo/jump-users
>>   
>
>
> _______________________________________________
> jump-users mailing list
> jump-users at lists.jump-project.org
> http://lists.refractions.net/mailman/listinfo/jump-users
>
>



More information about the jump-users mailing list