Hello, UDIG architects and developers!
While working with "UDIG framework" (it is a really good framework for
client GIS solutions) and the time being I would like to share some
issues
and probably solutions.
1)
From observation and testing the catalog is a persistent entity. But
problems appear while closing and opening UDIG. Especially when the
remote
connection is not valid anymore (WMS servers, database connections) -
starting UDIG leads to "hanging" while it tries to restore these
connections. Or in database cases getting metadata (that is a first
step as
I suppose) is a long-running process. Even WMS GetCapabilities
request takes
time. But what if there were 10 WMS connections during previous UDIG
session
in catalog?
Sure it is an obvious issue, does anybody has a solution, probably not
implemented but is supposed to be implemented to establish full
lazy-loading
behavior for the Catalog? Let's have fully remote-independent
stubs/descriptors/whatever - just to have a label in catalog and the
opportunity to restore real connection when it is first-time accessed.
In my case of just one database connection persisted through catalog
leads
to 30-40 seconds of restoring it during starting UDIG (just example
of slow
db connection).
2)
Selection tool.
The behavior is simple and sufficient for most of cases for users:
selection
tool just sets filter for the layer and somehow highlights selected
features.
Problem: for the developers using UDIG as a framework with custom
extended
functionality more customizable behavior of selection tool is needed.
Writing own custom selection tool solves the problem but only half of
them.
Try to explain.
The semantic of selection in GIS is the same as in other applications,
Photoshop, for example. If something is selected and I select another
entity
- the old selection disappears (if it is not special case of modifying
current selection). There can be different selection tools with
different
functionality, but it is necessary to easy integrate them into the
platform
and behavior of all selection tools should be heterogeneous.
The example: in my project I developed multi-selection tool for defining
let's call "Area of Interest". The tool just selects polygonal
geometries
making geometric predicates (union, cutting, etc) if needed forming
"Area of
Interest".. (AOI is used with arbitrary purposes later).
I expect that if filter is defined by default selection tool and
there is
that yellow graphic rendered on the map - it should be cleared and
graphic
of AOI selection tool is rendererd - "substitution" behavior.
The same "substitution" policy can be used in other places for the
flexibility and extendibility of the platform. Now selection tool is
strongly integrated and there is no possibility to add custom
functionality
with "selection" behavior without changing "net.refractions.*" code
that is
bad approach from my point of view.
3) Rendering
Continuing to propagate "substitution" behavior of selection tools.
Selection on another layer kills selection on the previous. Why each
layer
has the peer layer - SelectionLayer? If there are 10 layers - means
there
are 20 rendering jobs and at least 9 of them renders nothing.
What if there is one special SelectionLayer and one SelectionRenderer
for it
where all selection graphics is rendered.. Selection tools just send
commands somehow to render something custom on this layer..
This approach can be extended for adding any special graphics layers
using
special extension point for example - not only for rendering
selection masks
and graphics for selection tools.
Rendering can be organized in a same way as ViewportPainter draws
graphics
above all maps - using commands.
SelectionLayer has a special Renderer that has the same architecture as
ViewportPainter
All selection tools send two kinds of commands to that renderer: 1)
just to
start redrawing; 2) special drawing commands that have long
life-cycle in a
same way as in ViewportPainter. The second type of commands has a
"substitution" behavior: each next command substitutes the old one.
This idea outlines what do I mean - "substitutional" behavior in similar
group of tools from other developers: such framework lets add new
tools with
new functionality but visual behavior among all tools from this
"semantic"
group in application remains the same.
4) Rendering optimization.
Lets call features rendered on the layer - long-running graphics and for
example bounding box when I drag mouse while selecting features -
"temporary graphics".
The second type is rendered using command approach in
ViewportPainter, the
first one is rendered using Renderer API and cached by buffered images.
First impression from new editing tools - very good and thought-out
architecture but no optimization for rendering.
"temporary graphics" drawing commands are sent from commands with
business-logic. The last are executed in special thread by
CommandManager..
So we have the following sequence: mouse has moved -> tool gets event
and
sends command with business-logic into thread of CommandManager -> in
this
thread CommandManager executes command -> somewhere during execution the
drawing command is sent to ViewportPainter or repaint() method is
called..
Because of synchronization and thread stuff this repaint() call is
sent with
delay - I see terrible slide-show of painting "temporary graphics" while
dragging vertex of the feature, for example, by mouse..
Great optimization that I used in developing custom tools for UDIG -
when
the event comes from mouse in the beginning all commands responsible
for the
"temporary painting" are sent to ViewportPainter and repaint() is called
directly from tool class, then business logic command is sent to
CommandManager thread to do something. repaint() method is
asynchronous by
its nature- no problem to call it anywhere.. of course there can be
complex
chains of operations to be performed by tools and commands but such
rendering optimization of "temporary graphics" is important and can be
widely applied.
Any comments, questions? I really would like to discuss and help to make
UDIG the best open source GIS platform in future:)
Vitali.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel