[GRASS-dev] v.digit replacement [was: Modules]

[Hamish]

Maciej Sieczka wrote:
..
> Issues:
..
> 4. Region is now handled differently than it used to in v.digit.
> Previously, the backdrop maps AND the currently digitized map where
> displayed trimmed to zoom box shape (region_former.png). After your
> patch, only the backdrop is, while the map being digitized is not
> (region_patched.png). IMO a solution is to either revert the previous
> behaviour, or, preferably, make v.digit ignore the region extent, and
> let it fill the window at maximum (I think this is preffered in case
> of v.digit - when one is digitising, he wants to see the maximum of
> it).

My feeling is that vector maps have no association with g.region and
WIND, so the vector digitizer should not either.

> There is an issue still that zooming and panning in v.digit changes
> region settings. One could maybe live with v.digit changing the region
> extent (it has it's uses, though propably most users won't appreciate
> it), but changing the resolution should be not allowed I think.

(it should emulate "d.zoom -p")

For the record, it does reset to the original region settings when you
exit (the old) v.digit, to at least confine the problem within v.digit.


> BTW, not a question to Glynn really: I never understood the "Boundary
> (1 area)" and "Boundary (2 areas)" explanations for color settings in
> the Symbology tab. Eg., you can have one area, but it will be rendered
> with color assigned to "Boundary (2 areas)" (light green, by default).
> I suggest replacing "Boundary (1 area)" with "Boundary (broken area)"
> and "Boundary (2 areas)" with "Boundary (valid area)". Anybody minds I
> change this in CVS?

General plea to all devels: *If you don't understand something, please
don't mess with it*.

If you can only guess what it was meaning to say/do, and guess wrong,
and then change the code to reflect your bad guess, the next person who
has to try and fix it will be totally lost. Helpful but wrong is a lot
worse than no action at all.

Before asking if it is ok to change in CVS we must fully clarify what
the answer is so we can know that the change is appropriate. i.e. I do
mind very much changes going into CVS which are not fully understood by
the commiting devel!</plea>

In this case, see the attached screenshots.

"no,1,2" supplies more information than "no,broken,valid".
(what does "broken" mean? the orange is really a "valid" boundary with
an invalid dangle outside it; it's not "broken", but only has a valid
area on one side of it)

in the breakage screenshot there is a small green line showing "Boundary
(between 2 valid areas)"; and orange "Boundary (between 1 complete
area and one not good area)"; and grey "Boundary (which doesn't form an
area)".

note "the rest of the universe" acts as the 2nd good area for a closed
polygon island.

if looking at the vector code consider areas to the left and right as
you follow the boundary verticies CW or CCW around the centroid.

Of course you are right that "no,1,2" should be improved. But those have
exact meanings which should not be blurred in the process.



Hamish

ps- it is important to keep the order of feature rendering the same.
that way bad nodes are drawn on top of good nodes and not hidden.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdig_badarea.png
Type: image/png
Size: 6313 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070226/15f66a0f/vdig_badarea.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdig_goodarea.png
Type: image/png
Size: 5658 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070226/15f66a0f/vdig_goodarea.png