Re: [udig-devel] Problems with uDIG Table View and Rendering

[Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>]

Opps - yep PostGIS will suck without an index. I am actually *really* 
happy it worked at all this time without an index. Greating testing ....

Moving on - you need to create a spatial index for your geometry. Doing 
so will making things wonderful in terms of rendering.  I am not 
familiar enough with the TableView code to know if it will be effected 
by an index yet.

As mentioned earlier OpenJump and gcSig are sucking back the geometry 
into memory (from which point on they will feel the same). uDig leaves 
it on disk (well database in this case), so you should see better 
performance as you zoom in. At the resolution where editing occurs uDig 
should be snappy, and you should not be able to "max out" uDig as 
happens with OpenJUMP.

Cheers.
Jody
PS. I am sure we can match the OpenJUMP and gvSig table functionality - 
we are always looking for volunteers.
> Hello Jody,
>
> my postgis database runs on the same computer. I haven't used an index yet. For which attributes should i generate an index? The geometry or ogc_fid?
>
> I don't know if can use an index because the table gets more and more point features inserted from outside.
>
> I'm using the same postgis table in uDIG, OpenJUMP and gvSIG. OpenJUMP und gvSIG rendering "feels" to be the same. It responds fast enough. But when i use uDIG then the rendering "feels" slow. When i do a Zoom Operation with a Zoom-Box, the Zoom-Box is drawn slowly and it seams to take longer to show all my layers.
>
> Someone told me that the current swt table implementation is very simple, the JFace table should be better. Why is the OpenJUMP and gvSIG Table capable to handle 100000 of features without problems? 
>
> Cheers 
> Carsten
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>