Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] Problems with uDIG Table View and Rendering
Well, I know :) I live on UDIG trunk and I am impressed by progress that has been made. We needed a GIS client for a project and didn't have the resources for a full solution, so we used JUMP as an appropriate application of worse is better principle ;)
It turned out that users only wanted to edit things they see (features in viewport). Table view in JUMP is a simple swing table model over snapshot of its feature collection. So, when someone opens a table view, it shows all features in the viewport and updates these features as they are added/removed. In other words, visible features always fit into memory.
(There were also other requirements which seemed easier to hack into JUMP than into Geotools. For example: tables had triggers and rules, so a feature had to be synchronized to database state after update through updateable result set).
If I had to do a more complete solution in UDIG, I would load the feature keys in full and all other attributes on demand. Maintaining selection and sort order would be straightforward, while still being relatively light on memory. Lazy loading of feature keys into some kind of sparse collection which would maintain sort order and selection would be the next step. 

Jesse Eichar wrote:
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


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

Back to the top