[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Problems with uDIG Table View and Rendering
|
FYI. uDig is much more stable since you last looked (or at least
sent an email to the list :) ).
But I'm interested in how you made the table that backs onto
PostGIS. I gather that you aren't using paging? Take this example:
I open the table. The first few features load (I'm guessing). Next
I want to scroll 1/2 of the way down the table. Then I scroll back
up to maybe the 100th feature (not in the first page). How would
this work?
I'm guessing that the number of features in the table are counted so
that you know how many rows to make in your table (so the scrollbar
works correctly). Next I'd guess that first the first few features
would be loaded (just the ones being displayed). Then you scroll
down. When the use stops then new features are loaded? And the same
thing happens when the table is scrolled back to the top. Correct?
So a few questions.
- How is selection handled. Suppose I select features 100-50000. Or
I select all features that intersect a given bounding box.
- How do you handle sorting of the table efficiently? For example if
you sort by an attribute then scroll down how to you render that
efficiently?
- Related to both of the previous points. Suppose you select some
features then sort the table by an attribute how is that selection
maintained (or is it?)
I don't mean to harrass you I'm just curious because I would love to
improve the table view.
Jesse
On 30-Jan-07, at 5:07 AM, Aleksander Bandelj wrote:
Well, this has changed lately. OpenJump now has a postgis
(datastore) layer, which renders directly from database (with
optional caching of features in the viewport). It's a bit of a
hack, but works well. We added editing to it (still another hack
which worked rather well) and were quite satisfied with performance
and scalability on large datasets (10^6 geometries).
We would prefer to use UDIG for that project, but we had to choose
JUMP because of a) editing tools b) stability c) its simplicity
(which unfortunately comes with significant loss of generality).
Jesse Eichar wrote:
At least with open JUMP (I don't know about gvSIG) the features
are kept in memory. So openJump is very fast but it is also not
very scalable.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
