[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] RC2 Rendering Problem UDIG-391 and GEOT-156 the complete message
|
Tony Kennedy wrote:
Hi RC2 seems to have developed a rendering problem:
!MESSAGE java.lang.Exception: Exception rendering layer
org.geotools.map.DefaultMapLayer@50d7c5
net.refractions.udig.project.render.RenderException:
java.lang.Exception: Exception rendering layer
org.geotools.map.DefaultMapLayer@50d7c5
Caused by: java.io.IOException: Not enough storage is available to
process this command
at sun.nio.ch.FileChannelImpl.map0(Native Method)
when zooming in on Victoria on Geobase - National Road Network, Canada BC
Hi Tony thanks for the details,
OK on RC1 sorry I take that back, the test was on a 64 bit Sun box,
this problem was originally reported in UDIG-391 and in GEOT-156 where
I think the proposed fix was to change the point at which the loader
changed from memory mapped to virtual, is this the way to go? . In 32
bit Windows you have 4G of virtual space per process half of which
taken up by the OS. The remaining is reduced by the VM and the
application. If you set your heap to 1 GB or more, running out of
address space is inevitable, when the heap size plus the mapped file
size exceeds 1.5 GB you will get a | Not enough storage is available
to process this command| exception, Using the techniques as coded the
only solution would be to use a 64-bit processor and operating system.
GEOT-391 was right on the money, GEOT-156 was concerning relative
pathnames in project files.
I have assigned this issue to myself and marked it critical. One of the
advantages to our architecture is scalability and I don't want to
release with scalability compromised on the most popular file format
I wonder what a good threshold should be? I will set up a preference
page, but still a sensible default should be chosen. And of course we
will see a different set of trade offs when we switch to using indexed
shapefiles.
We are currently working on this and associated rendering speed
problems, using our own databuffering and bytebuffering techniques,
and in a separate work stream a swt opengl solution, the code is
functional but incomplete at the moment, but we can currently render
both shape and GML files for the Canadian road network (from Geobase)
in approx 4 to 6 sec for the complex files NRNC1_BC, NRNC1_AB,
NRNC1_SK, NRNC1_MB, and can load and render the complete Canadian road
network on a Toshiba.Qosmio Laptop with 512 memory. This puts uDig
within range of the commercial opposition and cures one of the main
complaints of our user groups.
That is wonderful,
If you look back at our earlier technological reports we did consider
I'd like you to decide this finally: Englisch page names everywhere or not?
---------------------------------------------------------------------------
To the other topics:
I can set up another user group "translators" and give them extra
permissions over the help system pages. We could allow confluence-users
the ability to comment on a page (but not edit it), during the weeks
leading up to a release?
Is it really necessary to create an extra group? I believe locking would do, if
it is/were possible to comment locked pages.
Jody wrote:
> [...] the export function doesn't work for me.
I noticed that although the file was produced the webserver is not set
up to allow download access?
That sounds like being the reason. P.S.: Please notify us when this is supposed
to work again.
Matthias Basler
c9bama@xxxxxxxxxxx
----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de
