G'Day :-)
I think Jesse is gradually turning much of this email into Jira items. I
was going to pick on a couple of them
where my thoughts are clear.
1) Rendering.
Rendering seems to finally going through a code collapse - my main
concerns are around the balance of responsibility
between framework and renderer implementation.
4)"Selection" policy
There are various selection tools like box selection or feature selection.
Again, the user expects the similar behavior of all "selection" tools.
Selection is done in context of layer and map.
Selection is also done in a "mode", usually representative by tool category.
I am a "stupid" user, I expect a kind of "substitution" policy. I select
features
by "Box selection" tool - the selection is highlighted. I select one feature by
"Feature
selection" tool, the previous selection is cleared, or "substituted" by the
new one how I call it.
To facilitate this we should allow switches between map mode (ie between
tools) have a chance to preserve the user's context.
Assuming tools are consistent in storing their "selection" on the layer
blackboard, a tool could produce it's selection based
on the selection from the previous tool.
- So an "Edit" tool could check the "Selection" tool's filter and work
on the first feature.
- A Pojo tool could use the feature ID to look up the corresponding POJO
I am unsure if this should *just* be done on mode changes, or if trying
to keep the various selection models in sync would be preferable?
(It makes sense to do this as needed when switching between tools, but
views that want to work off the selection may want the selection
model's maintained in sync)
One layer is always selected, or active. Selection tools perform selection
in current layer, while all previous selections in other layers in context
of current Map must be cleared.
Currently this is not the case (to allow for operations between layers),
I understand other applications do these kind of things with
a combination of wizard + tools...
Only one map, one selected active layer always, selection being performed by
selection tools substituting
any other selections in any layer of the current map.
As a developer I would like to have a kind of special GeoSelectionService
that is a singleton object in Map instance. All selections are made through
GeoSelectionService and wrapped into IGeoSelection interface. Tools create
selections through GeoSelectionService by passing selected objects wrapped
into IGeoSelection , like ISelection works.
This seems like a good approach, there is a choice between being using
IGeoSelection as the the
workbench selection (when using a tool that works with IGeoSelection)
and/or storing this on the
Map blackboard (for retrieval by tools or views that care).
The advantage to use workbench selection would be to allow query results
(InfoView, TableView, LocationView)
to maintain a IGeoSelection. Also some of these (like LocationView) may
not have a current layer.
//Just iterates through set of objects like in IStructuredSelection
Iterator iterator();
May have a conflict between what objects? Are you expecting Features here?
Why would I like that improvement? Something that is selected on the map is
a kind of persistent selection during switching over workbench parts.
You may also consider it persistent on the same map during switching
between different tools. Ie InfoTool
works with a selection that is a single location, Distance tools works
with a selection that is a linestring, etc...
Eclipse workbench selection service is a general solution and not
appropriate here because depending on part, tool, viewers we have different
selection providers but what I wrap into IGeoSelection is something
persistent and present on the map (Filter-based selection, or other
approaches).
Thinking about that, you can have multiple concepts of selection for
your map (depending on tool or use)
as an example DivaGIS has a GridBBox selection which they use for
analysis. Filter is really just a special
case, I would like to see it "demoted" to a helper method that simply
looks up a filter stored on the layer
blackboard. Of course for the next round of geotools Filter will be
more useful and could be used to select
content other then Features.
Imagine we have good SelectionEditor of the UDIG of the future :) that can
edit one feature, or set of attribute values from multiple features defined
selected by Filter (we are working with that kind of editor now). It can
listen GeoSelectionService and always get IGeoSelection with necessary
information when selection is changed by any selection tool (that are going
to work through singleton GeoSelectionService to perform selections).
The tool made a new selection, SelectionEditor got changes, MapEditor is
changed -> SelectionService listens MapEditor activation and gets current
selection and sends as an event to update listeners like SelectionEditor.
What you describe is pretty common? It is the same approach used by
other tools is it not?
If you look in the original design for uDig we had specified a
"SelectionManager" that plays the same role you
describe.
- separates out selection from layers
- reset the selection state in response to Issues (replace the
selections for all the layers in one go)
- hold the selection state for selection tools
The only differences now:
- we stored the filter on the layer, and hope to distance them again by
putting filter on the layer blackboard
- issues have taken responsibility for setting layer selection state
directly.
We solve lots of problems. Substitution policy and unified behavior for
tools. Updating selection graphics and clearing the old ones is easy because
everything goes through one point - GeoSelectionService (now
ContextModel.select(..)
is a kind of such point, but not extendable.. standalone service is preferable).
Agreed, the only difficulty is respecting "modes", your examples thus
far have been based on Feature
selection and Editing. I think I would like to see a SelectionManager
(or SelectionService) created as needed
and stored on the map blackboard by tools or services that intend to use
it..
Only one IPartListener in GeoSelectionService to update selection from
activated MapEditor in its
listeners - more clear architecture, less chances to create a listeners hell.
There does seem to be a gab between design and practice here, do you
have any documentation on this proposal (you say you
are working on it already?) it would be interesting to compare to the
original uDig design, and compare with best practice from
divaGIS, yourself and others.
IGeoSelection - something that is created on the map with "selection" semantics.
5)Feature editor.
We are implementing feature editor based on new TabbedPropertySheetPage and
its framework.
Woot!
IGeoSelection can wrap just one feature and editor can create
UI for attibutes editing like it is now. Also IGeoSelection can wrap just a
filter of the layer and the editor will create UI to set values for
appropriate attribute types and then perform batch updating through
FetaureStore.modifyFeatures(AttributeType[], Object[], Filter).
Very nice.
We have selection tools that provide IGeoSelection to GeoSelectionService.
We have editor that listens GeoSelectionService and creates necessary UI for
the particular contents of IGeoSelection.
So if we store this on the map blackboard, and make sure things are
"model" we have something that fits
into my design. That layer.getFilter() stuff is only to facilitate work
like what you have done (allows you
ask for visualization of large content that you cannot realistically
store and/or allows you to save filters for
abuse by tools and or editors).
7)Catalog
Catalog is not friendly at lot. It is simple and brutal. But is a core thing
like ArcCatalog..
I am reasonably happy with the implementation, although recent
experience has shown some areas that need
improvement. I would really like to see a perspective constructed around
"data wrangling" and see views
produced that are more specific (and more useful).
- a kind of central geographical resources repository. Resources must be
lazily activated. Is IService interface good enough to be a kind of
lightweight descriptor for the data source?
Yes, but we currently do not cache anything. It would be nice to cache
the basic information (like title, or
capabilities file) so we can get further without contacting the resource
directly. I would like to move to a
local catalog backed by hsql or h2.
for shapefiles contained in Catalog. Seems something tries to load data
source to create label, whatever, not lazy now.. (debugging has shown that
CatalogPlugin.title() methods causes loading resources in Catalog during
opening the application when there is no opened editors..
CatalogPlugin.title method tries to make up the best label based on the
*Info objects, by holding just
metadata from when the resources was added we could eliminate this need.
9) what else... Friends! it is not a complain but an attempt to clear Augean
stables, make a Plan.
That is a critical for the following development. I am glad to discuss
problems and collaborate to repair them, concentrate on really important
thing and the day will come when we will be able to implement custom
functionality in our projects, not endless fighting with basics..
If possible I would love to see any design documents you have produced -
we are setting up uDig as a
platform for custom functionality, but communicating at the detailed
level of code often leaves a gap in
the bigger picture.
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
