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: [email protected] To: "Francisco José Peñarrubia" <[email protected]>, "Users and Developers mailing list" <[email protected]> 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 [email protected] 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 [email protected] 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. _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
