[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Zoom & Catalog discussion
|
Thanks Paul & Andrea - this is exactly the kind of discussion I want us
to be having :-)
Paul gave us some of this feedback ealier - and the issues brought up
did make it into our documents from the recent milestone.
http://docs.codehaus.org/display/UDIG/Milestone+2+Deliverables
Indeed a lot of the ideas going int cleaning up DataAccess are
documented and stem from difficulties in setting up a sane system for
Catalog.
As an example: Local Registry is to be renamed Catalog :-)
about its size later. I think it should be a nice thing to have, but maybe
something to have when you're pressing some key while zooming (CTRL.,
SHIFT, whatever).... it's just that I've never used something that worked
like this, so my first thougth was that it was broken.
Strangly enought the Control and Alt keys already do something.
Control - acts as a right click (ie Zoom out by a fixed amount)
Alt - combined with dragging sideways opperates similar to the Zoom
wheel (ie direct control of scale).
When we started we saw many different Zoom schemes:
- most were of the click in the top left, and drag to the bottom right
(application would then do a best fit to the current visiable area)
- one CAD based system had a box that surrounded the cursor, the box was
of the same aspect ratio as the currently Map display area. Keys
controlled the scale (represented as the size of the box on screen).
The one nice thing about this system was that you had a visual
representation on screen of what would happen next.
- zoom in and zoom out buttons on the toolbar (just opperate as a change
of scale)
- JUMP has a slider that just performes a change of scale (MapQuest has
something similar)
One thing I am sure of is we need an extention point for our top five tools:
- Zoom - zoom box, zoom rectangle (traditional)
- Selection - select rectangle, select feature, magic wand.
- Info - what is this, query, etc...
One thing that troubles me is that Tools *need* a keyboard shortcut, but
we have an open ended system allowing people to add tools into the
framework. The above suggestions takes some of the scalability bite out
of the problem. Just the 5 catagories need a Key binding, Holding
SHFT-Key advanved tool in a category, Holding Control-Key could bring up
the menu where the tool can be chosen from the list.
Example:
z - selects the "Zoom" tool
Z - selects the next Zoom tool.
control-z - lets the user choose the Zoom tool with the arrow keys.
("z" would be localized)
When UDIG is bundled up for a specific application a developer has the
option of only including one Zoom tool. Indeed if selection is not
needed for their application they can leave it out entirely.
different states held into different subfolders. If I understand it right (I
hope not) and every file gets listed as a flat list, this would soon become
a bit of a mess.
This does present a problem, DataStores are supposed to be singletons
(and that is ment to be under application control), It seems taht for
the next round of UDIG we should remove the Catalog from the default
perspective (it is not needed as part of a File Open or Fie DnD workflow).
Its main purpose is to allow user's to discver available data. Indeed a
TreeViewer of the current Catalog appears as part of the New Map Layer
process.
It is ment to be searched - something I cannot really take on until
DataStores get around to supporting Metadata. I don't think any amount
of making the Catalog deep (either by Data Source category, File System
Directory) will be sufficent.
That said we can divide this up by: Server, Directory, or Type easily
enough. But long term we need a single "Search" box where the user can
enter some text, hit return, and see a list of matches.
On a related note we are currently storing our Singeton DataStores by
the parameters used to create them - this is not really good enough
(Shapefile url=C:\data\road.shp memorymapped=true should really be the
same thing as Shapefile url=C:\data\road.shp memorymapped=false). Does
this mean we need to divide up parameters into deinition, and
opperation? I suppose opperation parameters could be considered Hints on
FeatureSource opperation ....
Also, I'm not sure about it, but I hope the registry contents are per-project,
since different projects may have to work with very different set of files.
Once again Catalog is the tool that keeps us from duplicating
DataStores. If two projects both use the same shapefile we *need* them
to use the same instance (or things will go wrong). The TreeView widget
currently used has a nice Filter API. I think Filtering the Catalog to
the current Project is the way to go here.
Some of the registry contents may be general enough to be always there,
but as a user I would not be happy to see all of my datastores and shapefiles
always there. Just my opinion ;-)
And valued.
Jody
