Re: [GRASS-dev] Individual vector feature processing: v.clump?

[Markus Metz]

On Thu, Dec 4, 2014 at 8:34 AM, Markus Neteler  wrote:
> On Wed, Dec 3, 2014 at 9:47 PM, Markus Metz
>  wrote:
>> On Wed, Dec 3, 2014 at 5:51 PM, Markus Neteler  wrote:
>>> Hi,
>>>
>>> for a calculation I need to loop over all vector features in a map in
>>> order to perform individually a computation. For that I cannot use the
>>> category information since it may be used as 1:n link.
>>>
>>> I wonder if a new v.clump command would make sense or the addition of
>>> a new method in v.category to simplify this task?
>>
>> Adding unique categories to a new layer for the features in question
>> with v.category (take care of the type option) does not work in this
>> case?
>
> Likely it does (I am asking on behalf on another person not subscribed here).
> I wonder how to make it more obvious.  And, if there is a best
> practice example written in Python/PyGRASS?

For Python, you can have a look at g.gui.rlisetup for an example about
how to cycle through all vector features of a given type.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addons dependencies

[Martin Landa]

Hi,

2014-12-04 8:36 GMT+01:00 Markus Neteler :
> To me that sounds a bit misleading since we don't need to update
> v.in.ogr. How about
>
> WARNING: Please update the usage of : option  has been
> renamed to 

right, it's seems to be better, done in r63367. I can backport it to
relbr70 if it's OK for you.

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Individual vector feature processing: v.clump?

[Pietro]

Hi Markus,

On Thu, Dec 4, 2014 at 8:34 AM, Markus Neteler  wrote:
> On Wed, Dec 3, 2014 at 9:47 PM, Markus Metz
>> Adding unique categories to a new layer for the features in question
>> with v.category (take care of the type option) does not work in this
>> case?
>
> Likely it does (I am asking on behalf on another person not subscribed here).
> I wonder how to make it more obvious.  And, if there is a best
> practice example written in Python/PyGRASS?


with pygrass at the moment the pseudo code is something like:

{{{
with VectorTopo('yourvectormap', mode='r') as vect:
for line in vect.viter('lines'):
# do something with line
pass
for area in vect.viter('areas'):
# do something with area
pass
}}}

but I'm thinking to change how to iter between vector features to make
the distinction between topological and not topological features
clearer, something like:

{{{
with VectorTopo('yourvectormap', mode='r') as vect:
for line in vect.features.lines:
# do something with line
pass
for area in vect.topo.areas:  # nodes, centroid, etc.
# do something with area
pass
}}}

But I'm still thinking on it...

Best regards

Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] temporal framework currently not working on windows

[Sören Gebbert]

Hi Glynn,
thanks a lot for this excellent explanation.

Best regards
Soeren

2014-11-27 18:59 GMT+01:00 Glynn Clements :
>
> Sören Gebbert wrote:
>
>> > I would like to better understand, this point...
>> > Why the decorator must_be_open  it seems to work so far?
>> > which is the difference between @must_be_open[0] and @mdebug[1]?
>> > Any Ideas?
>>
>> Unfortunately i have no idea. I did not found good information about
>> when and how exactly these decorators are processed.
>>
>> So my guess was that (because of the backtrace) the decorator function
>> is somehow analyzed at import time and the messenger process gets
>> started.
>
> A function used as a decorator is invoked when the decorated function
> is defined, which is usually at import time.
>
> The code:
>
> @decorator
> def foo():
> pass
>
> is equivalent to
>
> def foo():
> pass
> foo = decorator(foo)
>
> Whether this poses a problem depends upon exactly *what* the decorator
> does.
>
> Typical decorators simply return a closure, i.e. a local function
> which, when called, calls the function being decorated. This situation
> is usually harmless, as nothing significant happens until the
> decorated function is actually invoked.
>
> As a general rule, modules shouldn't do anything substantial on
> import. If you're using decorators, this typically means that the
> decorators shouldn't do anything substantial, as they'll be called on
> import. Any work should be deferred until the decorated function is
> called (i.e. it goes inside the local function, not in the body of the
> decorator).
>
> --
> Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by huhabla):

 Replying to [comment:96 martinl]:
 > Replying to [comment:95 helena]:
 > > > -1 for voxel, than we could rename 'raster' to 'pixel' ;-)
 > > >
 > > > I am still not sure we need to rename than all modules from `r3` to
 `vo`...
 > >
 > > so is there also an agreement to rename all r3.* commands to vo.*
 commands and changing all manuals accordingly? If yes, this will require
 several weeks of focused testing and
 >
 > not at all, personally I don't like to stick with shortened element
 names (rast, rast3d) just because it makes our life easier. Taking in
 account a real world it seems to me that the reasonable is to rename `rast
 -> raster` and `rast3d -> raster3d` and to modify the parser to understand
 also shortened element names.

 This would be absolutely my favorite solution.

 IMHO renaming all 3D raster and STR3DS modules using "volume" name
 approach will result in a lot of unnecessary work and inconsistency. As a
 result all documentation in code and manual pages, the module help,
 examples and tests must be updated/modified as well. Not speaking about
 the confusion with wording in already published scientific papers and
 books ... .

 I don't think this is worth the effort.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:99 huhabla]:
 > > not at all, personally I don't like to stick with shortened element
 names (rast, rast3d) just because it makes our life easier. Taking in
 account a real world it seems to me that the reasonable is to rename `rast
 -> raster` and `rast3d -> raster3d` and to modify the parser to understand
 also shortened element names.
 >
 > This would be absolutely my favorite solution.

 please could you try attachment:raster3d.diff. Does it make sense to you?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addons dependencies

[Markus Neteler]

On Thu, Dec 4, 2014 at 9:20 AM, Martin Landa  wrote:
> 2014-12-04 8:36 GMT+01:00 Markus Neteler :
>> To me that sounds a bit misleading since we don't need to update
>> v.in.ogr. How about
>>
>> WARNING: Please update the usage of : option  has been
>> renamed to 
>
> right, it's seems to be better, done in r63367. I can backport it to
> relbr70 if it's OK for you.

Yes. We can further finetune if needed.

thanks
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addons dependencies

[Moritz Lennert]

On 04/12/14 13:08, Markus Neteler wrote:

On Thu, Dec 4, 2014 at 9:20 AM, Martin Landa  wrote:

2014-12-04 8:36 GMT+01:00 Markus Neteler :

To me that sounds a bit misleading since we don't need to update
v.in.ogr. How about

WARNING: Please update the usage of : option  has been
renamed to 


right, it's seems to be better, done in r63367. I can backport it to
relbr70 if it's OK for you.


Yes. We can further finetune if needed.


+1

Thanks !

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2503: wxdigit: wrong undo & redo

[GRASS GIS]

#2503: wxdigit: wrong undo & redo
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  digitizer|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [comment:9 mmetz]:
 > Replying to [comment:8 mlennert]:
 > > Replying to [comment:7 mmetz]:
 > > > The list of updated lines as returned by the vector lib was
 incomplete. Fixed in r63349,50 (trunk, relbr70), please test.
 > >
 > > Still not quite:
 [http://tomahawk.ulb.ac.be/moritz/wxdigit_undo_redo4.ogv].
 > >
 > > If you need more explanation, I can write some, but right now I have
 to go.
 >
 > Got it. This bug (yet another one) should be fixed in r63364,5 (trunk
 only).

 Wow, great detective work there ! As of now I haven't been able to find
 any other bugs linked to undo/redo. This fix should be backported to
 grass7release and then I think we can close this bug for now.

 Thanks a lot for the fixes !

 Moritz

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] check on GRASS revision number

[Michael Barton]

That’s very good to know.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Dec 2, 2014, at 1:37 PM, Markus Neteler  wrote:

> Hi,
> 
> just for the record, by chance it happened to me today and how I
> solved it easily:
> 
> GRASS 7.0.0svn (nc_spm_08_grass7):~ > r.stream.order
> stream_rast=streams@user1 direction=direction@user1
> elevation=elevation@PERMANENT accumulation=accum@user1
> stream_vect=streams horton=horton
> ERROR: Module built against version $Revision: 62395 $ but trying to use
>   version $Revision: 63222 $. You need to rebuild GRASS GIS or
>   untangle multiple installations.
> 
> 
> # Now simply re-run g.extension:
> GRASS 7.0.0svn (nc_spm_08_grass7):~ > g.extension r.stream.order
> WARNING: Extension  already installed. Re-installing...
> Fetching  from GRASS-Addons SVN repository (be patient)...
> Compiling...
> Installing...
> Updating metadata file...
> Installation of  successfully finished
> 
> # enjoy:
> GRASS 7.0.0svn (nc_spm_08_grass7):~ > r.stream.order
> stream_rast=streams@user1 direction=direction@user1
> elevation=elevation@PERMANENT accumulation=accum@user1
> stream_vect=streams horton=horton
> All in RAM calculation...
> Reading raster map ...
> 100%
> Reading raster map ...
> 100%
> Finding nodes...
> Finding longest streams...
> Calculating Strahler's stream order...
> Calculating Hortons's stream order...
> Calculating Shreve's stream magnitude, Scheidegger's consistent integer and
> Drwal's streams hierarchy (old style)...
> Calculating Hack's main streams and topological dimension...
> Building topology for vector map ...
> ...
> Writing outpout raster maps...
> 
> Hope this helps,
> Markus

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by cmbarton):

 So multiple patches are needed for different modules? Different for GRASS
 7.0 and 7.1 or the same?

 Michael

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Replying to [comment:14 cmbarton]:
 > So multiple patches are needed for different modules? Different for
 GRASS 7.0 and 7.1 or the same?

 The same patch will work in 7.0 and 7.1.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by cmbarton):

 So just a patch for each module that uses this then.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addons dependencies

[Moskovitz, Bob@DOC]

FYI, the QGIS Processing plugin does not work when accessing GRASS 7 tools 
because of the error shown below.


Robert Moskovitz
California Geological Survey
Seismic Hazards Zonation Program


CONFIDENTIALITY NOTICE: This communication is intended only for the use of the 
individual or entity to which it is addressed. This message contains 
information from the State of California, California Geological Survey, which 
may be privileged, confidential and exempt from disclosure under applicable 
law, including the Electronic Communications Privacy Act. If the reader of this 
communication is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited.



-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus Neteler
Sent: Wednesday, December 3, 2014 11:37 PM
To: Martin Landa
Cc: GRASS developers list
Subject: Re: [GRASS-dev] addons dependencies

On Wed, Dec 3, 2014 at 7:17 PM, Martin Landa  wrote:
> 2014-12-03 19:07 GMT+01:00 Moritz Lennert :
>> v.in.wfs2 url= http://geoserver.gis.irisnet.be/ows layers=urbis:URB_A_MZ
>> output=urbis srs=31370
>> Downloading data from WFS server...
>> Reprojecting data...
>> Importing vector map into GRASS...
>> WARNING: Please update the interface of the module: option  has been
>> renamed to 
>
> please try out r63362.
>
> WARNING: Please update the user interface of : option 
> has been renamed to 


To me that sounds a bit misleading since we don't need to update
v.in.ogr. How about

WARNING: Please update the usage of : option  has been
renamed to 
?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:100 martinl]:
 > Does it make sense to you?

 Not really. I'd much prefer a general solution, i.e. if an abbreviation
 matches multiple options, and one of them is a prefix of all of the
 others, the abbreviation should be deemed to unambiguously refer to the
 prefix option.

 So e.g. if a module has "raster" and "raster_3d" options, "r", "rast" and
 "raster" would all be deemed to unambiguously refer to "raster", while any
 abbreviation intended to refer to "raster_3d" would have to include the
 "3" (e.g. "r3", "r3d", "rast3", "rast3d", ...) to ensure that it cannot
 also match "raster".

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addons dependencies

[Markus Neteler]

On Thu, Dec 4, 2014 at 6:30 PM, Moskovitz, Bob@DOC
 wrote:
> FYI, the QGIS Processing plugin does not work when accessing GRASS 7 tools 
> because of the error shown below.

I have now suggested a fix as per
https://github.com/qgis/QGIS/pull/1720

Ideally someone would use our lookup table at
http://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/renamed_options
and just update all the QGIS Processing plugin description automatically.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1686: v.mkgrid should offer breaks option for vertical lines too

[GRASS GIS]

#1686: v.mkgrid should offer breaks option for vertical lines too
--+-
  Reporter:  marisn   |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Vector   | Version:  svn-releasebranch70  
Resolution:  fixed|Keywords:  v.mkgrid 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by neteler):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 All implemented, working fine. Closing.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Replying to [comment:99 huhabla]:
 > Replying to [comment:96 martinl]:
 > > Replying to [comment:95 helena]:
 > > > > -1 for voxel, than we could rename 'raster' to 'pixel' ;-)
 > > > >
 > > > > I am still not sure we need to rename than all modules from `r3`
 to `vo`...
 > > >
 > > > so is there also an agreement to rename all r3.* commands to vo.*
 commands and changing all manuals accordingly? If yes, this will require
 several weeks of focused testing and
 > >
 > > not at all, personally I don't like to stick with shortened element
 names (rast, rast3d) just because it makes our life easier. Taking in
 account a real world it seems to me that the reasonable is to rename `rast
 -> raster` and `rast3d -> raster3d` and to modify the parser to understand
 also shortened element names.
 >
 > This would be absolutely my favorite solution.

 I like `raster` and `raster3d`.

 For example, there will be no need to change `grass.script.raster3d`
 (which would end up as `grass.script._3draster` in the other case). From
 this point of view `raster_3d` is also not good because underscore should
 not be in the name of a Python module if possible and moreover I don't
 like `raster_3d` in general. Shortening possibilities are not as important
 to me as name without underscore.

 What about the module names? Are we changing that? Or is `raster3d` just
 `rast3d` in module names?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS71 development packages for Ubuntu 13.10 and 14.04

[maning sambale]

GRASS71 binaries at launchpad's grass/grass-devel is only for Ubuntu 12.04.1.
Any chance to get one for 13.10 and 14.04.  Maybe from other repo?

-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS71 development packages for Ubuntu 13.10 and 14.04

[Vaclav Petras]

On Thu, Dec 4, 2014 at 9:36 PM, maning sambale 
wrote:

> GRASS71 binaries at launchpad's grass/grass-devel is only for Ubuntu
> 12.04.1.
> Any chance to get one for 13.10 and 14.04.  Maybe from other repo?
>
> Sorry to hear that they are not available but if you want the most recent
stuff it is quite easy to compile it yourself on Ubuntu. But note that 71
is trunk -- the most unstable version. If you want something quite recent
but stable go for release branch 70.

Vaclav

http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu


> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> wiki: http://esambale.wikispaces.com/
> blog: http://epsg4253.wordpress.com/
> --
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2503: wxdigit: wrong undo & redo

[GRASS GIS]

#2503: wxdigit: wrong undo & redo
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  digitizer|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 Replying to [comment:10 mlennert]:
 > Replying to [comment:9 mmetz]:
 > > Replying to [comment:8 mlennert]:
 > > > Replying to [comment:7 mmetz]:
 > > > > The list of updated lines as returned by the vector lib was
 incomplete. Fixed in r63349,50 (trunk, relbr70), please test.
 > > >
 > > > Still not quite:
 [http://tomahawk.ulb.ac.be/moritz/wxdigit_undo_redo4.ogv].
 > > >
 > > > If you need more explanation, I can write some, but right now I have
 to go.
 > >
 > > Got it. This bug (yet another one) should be fixed in r63364,5 (trunk
 only).
 >
 > Wow, great detective work there ! As of now I haven't been able to find
 any other bugs linked to undo/redo. This fix should be backported to
 grass7release and then I think we can close this bug for now.

 I do not fully understand 1) why the fix is needed, 2) why the fix is
 working. The GRASS vector library usually employs Copy On Write (COW) when
 a feature is modified. Sometimes a feature is modified in place,
 overwriting the previous version. The digitizer's undo/redo mechanism
 relies on COW, but the move tool seems to replace an older version of the
 feature, thus undo/redo should not work with the move tool (and maybe
 other tools, too).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev