My point is on the "On line activation / deactivation of plugins" for judicious utilization of memory by a user. KOSOMO has this. Why not in OpenJump? This will enhance the memory, based on the specific work area (CAPTURE,FORMAT-CONVERSIONS, EDITING, MANIPULATION, ANALYSIS, SYMBOLISATION and MAP COMPOSITION, DTP etc.) in working within the GIS. Hope this will be a plan in next major version to be on release. Thanks to the DEVELOPING GROUPS for their amazing work.
This will help in handling a very large dataset like that of Peninsular India. P.K.Sinha
A plugin manager would be great to have in OpenJUMP. Just added it in the roadmap, but we lack of developper ressources for such developments. Any contribution is welcome.
Not sure it would help for memory problems though. OpenJUMP core is very lightweight. The main problem we have with memory is that there is no option to read a disk-based dataset on demand. Every dataset is loaded in memory. Kosmo and most other soft have readers which can read data on disk. The drawback is that it is much slower for some processes.
My problem is that I cannot load more than 1420 mb copositional combination of spatial data and the software-launch memory requirements (nearly 30 mb). How should I set it up (OPENJUMP) to get a better size data load? I admire that 1400 mb it self is not a small size. But, why loading stops beyond that, and an alert come to the screen " MEMORY OUT OF ……". This happens on 4mb memory system. Please! P.K.Sinha
Unfortunately, there is not much you can do about that with OpenJUMP.
One solution is to split your dataset in smaller chunks.
The other solution is to use a 64 bit OS with more physical memory. 1500Mo is a limitation of java programs running on 32bit windows OS. If you have access to a 64 bit OS (either windows, mac or linux) on a box having several GB of physical memory, install a 64bits jvm and then you can set the memory to as much as you want (limited by available physical memory)
Log in to post a comment.