[Gvsig_english] "RE:Re: (no subject)"

[Benjamin Ducke]

I would not support that advise!

GvSIG 1.9 has a lot of critical bug fixes and is
certainly much more stable than 1.1.2.

Also SEXTANTE updates are no longer possible for 1.1.2,
because:
1) GvSIG 1.1.2 was never completely ported to Java 1.6
2) The SEXTANTE bindings have changed in the transition
to 1.9.

And anyway, the issue was about PostGIS database layers,
not images. The PostGIS interface has been improved a
lot since 1.1.2.

No reasons whatsoever in my opinion to stick with buggy
old 1.1.2. 10 million polygons are a lot of data.
Allow the gvSIG developers the time they need to scale
up to such extreme needs. I am sure they'll manage.

@Holger:
Maybe you could also consider dedicating some development
time yourself, once 2.0 comes out? You seem to know what
you are looking for and where to look for it, so how
about contributing directly? In my experience, it's fun!

Cheers,

Ben

----- Original Message -----
From: rma11654 at wanadoo.es
To: "Francisco José Peñarrubia" <fpenarru at gmail.com>, "Users and Developers mailing list" <gvsig_internacional at listserv.gva.es>
Sent: Wednesday, March 3, 2010 7:52:44 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [Gvsig_english] "RE:Re:  (no subject)"


At the moment, the best choice is the GVSIG 112 release, while I´m waiting for a stable GV 2.0. 
Its easier update sextante and work with large images. 
Is my choice 
Roberto 
---Mensaje original--- 

Hi Holger.

I think this behaviour is different in gvSIG 2.0. The reason is in 2.0 
release, the random access is not needed like in 1.9 release.

So, you only have 2 options, wait for 2.0 release, or use a where clause 
in the layer creation. I think you can define your "working area" from 
the dialog of postgis layer loading (in 1.9).

Best regards.

Fran.

Holger Jaekel escribió:
> Dear gvSIG developers,
>
> when we add a layer from PostGIS to gvSIG 1.9, we can see that two ressource intensive operations are performed on the database:
>
> 1. A database cursor is created for this layer in PostGisDriver.setData(IConnection, DBLayerDefinition), which selects all objects from the table
> 2. A Hashtable is filled in PostGisDriver.doRelateID_FID(), which contains one entry for each object from our layer.
>
> We have to work with layers that contain more than 10,000,000 polygons. In that case, the cursor allocates many ressources on the database side, so this solution does not scale very well for many users. In the second step, gvSIG tries to create a Hashtable with >10,000,000 entries, which will create an OutOfMemoryException. This will also happen if we use "maxScale" for this layer.
>
> Any hints how gvSIG can handle large layers?
>
> Thank you very much for your help,
>   Holger
>
>   

_______________________________________________
Gvsig_internacional mailing list
Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional 

Cuenta NARANJA 3%TAE. Un 3%TAE los 4 primeros meses. Y tu dinero siempre disponible. 
_______________________________________________
Gvsig_internacional mailing list
Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional


------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.