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
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
