[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] uDig 1.1.M2 (Feature Complete Release)
|
Hi,
I'm not ignoring you. I'm just now back from holiday and am checking my
email.
Stepan RYBAR wrote:
Jesse,
probably You will kill me, send me somewhere or simply ignore me, but... So I am sending it to You, not to uDIG ;-) But You can repost it.
4) Vertex handling. Tools to add, delete and move vertex. Today only move
vertex is i uDIG, but with strange behavior (see above). Handling with vertex
is crucial for any kind of mouse editing. See Jump for this functionality.
Perhaps I have simply hidden this workflow too well. If you use one of the
tools (Select tool, polygon tool, line tool, etc...) you can add a vertex on a
line by clicking on it. The mouse cursor does not change to indicate this so it
is not intuitive. You think I should have a separate add vertex tool?
For delete just select a vertex and use the Edit>Delete menu item. (I still
need to hook up the delete key but that will delete also).
...Yes, I would like to have separate "insert", "move" and "delete" vertex tool. So I think about editing workflow as follows:
I can do this.
a) Enable layer for editing. This needs to be done to prevent unwanted editing by mouse or on-hand. Floatable edit toolbox is active (visible) only when editable layer is active layer.
Editability of a layer can be turned off but by default is on. You
think by default it should be off. Anyone else have an opinion on
this? I'm undecided on this one. If editibility is on by default then
the user can start editing right away. Remember that changes can both
be undone and rolledback if a mistake is made.
Edit toolbox has (at least) following tools: insert vertex, move vertex, delete vertex, snapping preferences (for this layer), enable/disable snapping, draw Polygon, draw PolygonHole, draw LineString, draw Point, draw MultiPoint, draw Free-Hand, multi~select Geometries, join selected (by multi~select tool) Geometries into one MultiGeometry, split selected (by multi~select tool) one MultiGeometry into independent Geometries, start editing transaction, commit editing transaction, make local backup (snapshot).
In future another tools can be added as: move Geometry, rotate Geometry, constrained editing of vertex or Geometry, etc.
I'm going to create a few Jira tasks to outline these suggestions. With
regards to the toolbox. We are considering having a toolbar below the
main toolbar that will list all the tools in a category. This would
replace the drop down list of tools. For example if you have the edit
tool category active the second toolbar would list all the edit tools.
This would allow quicker switching between tools probably be more
comfortable for JUMP users as it is closer to the toolbox idea. I like
the idea also because all the tools are lists all the time so it should
require less time to learn how to use the application. Finally I think
it is an improve ment over the toolbox because it doesn't occasionally
disappear on you, which really bothered me while I was learning JUMP.
Following tools from edit toolbox have keyboard shortucut with temporary functionality (tool is active just when key is pressed down, other previous tool is active): insert vertex, delete vertex, move vertex, switch snapping mode (temporary snapping or unsnapping), multi~select Geometries.
I agree with this but I don't think it will make this version. An
excellent example is the PAN tool. It would be useful to be able to
hold down the alt button and the pan tool is activated temporarily.
b) Start editing transaction. Each transaction is isolated for given editable layer. UnDo and ReDo is avaiable only within transaction per each layer.
... This is a hard issue. My gut feeling is that this isn't a good
idea. You may have a good point about undo and redo being tied to the
transaction. I am pretty sure that you can't undo past a rollback or a
commit.
c) Edit layer using edit toolbox.
d) Commit editing transaction. Before commiting question to make local backup (without editing steps) is fired to user.
Interesting idea here. I'm going to mull on this point for a while.
e) Repeating point b, c and d.
f) Disable layer for editing.
Maybe actual tool can be indicated as text in the Eclipse status bar.
5) Snapping. Let user to define snapping tolerance in pixels (or meteres or
deegrees?). Let user to select to what should be snapping counted. Possible
choices are vertex of edited layer, edges of edited layer, vertex of user
selected layer, edges of user defined layer (if layer is LineString or
Polygon type), all exclusively. See Jump for snapping tolerance
functionality.
...Snapping should be defined for each layer independently to enable snapping to vertexes or edges of another layer.
6) In-hand editing of vertex. Let user allow to manualy add, change or delete
vertex in, let say, WKT or extended WKT format. See Jump for this
functionality.
Excellent point. This is completely ready but I had to be temporarily
...Window for editing Geometry should be resizable, maybe floatable.
I take from this that WKT is a nice form to work with? You can copy a feature
and paste it as a GML feature into a text document. But you would like the
Feature editor to have a WKT field for editing the Geometry?
...Yes. WKT is much more easy for fast editing than GML. For me, at least.
...Well, now I recognised, that there can be two kinds of editing coordinates in-hand. One is to select vertex and edit its coordinates (for just one selected vertex). It allows "only" move of vertex. Another one is to have all coordinates of one selected Geometry. It allows full (insert, delete, move) operations with vertexes. Both are welcome for me.
Thanks, ;-)
Stepan
