Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[Markus Metz]

Glynn Clements wrote:

Markus Metz wrote:

Considering this, rather use e.g. raster_min - 1 as default nodata value 
for GDAL floating point datatypes?


If fabs(raster_min) is large, raster_min - 1 won't be exactly
representable, and may be rounded to raster_min. You would need to
subtract a value which depends upon the exponent.

Also, the input data may contain -DBL_MAX. For FCELL, if the map is
large enough, it's possible that *all* finite values occur in the
data.

I was (honestly! I was listening to you:-)) thinking about something like

if (raster_min > type_min) {
unsigned int i = 0;
while ((float)(raster_min - ++i) == raster_min);
nodata = raster_min - i;
}
else if (raster_max < type_max) {
unsigned int i = 0;
while ((float)(raster_max + ++i) == raster_max);
nodata = raster_max + i;
}
else
nodata = 0; /* or whatever fallback */

for GDT_Float32 but did not want to go into so much detail.


The question is: is GDAL's no-data value allowed to be any FP value,
or must it be finite? I'm guessing that the GDAL documentation doesn't
say (similarly, I don't think it's documented whether GRASS
FCELL/DCELL values are allowed to be infinite).

Actually, this may depend upon the format. If a format supports FP,
the format's specification may dictate whether or not NaN and/or
inifinities are considered valid.
Hmm. I thought the point of using GDAL is that r.out.gdal does *not* 
have to bother about the format's specifications. IMHO, if there is 
reason to assume that NaN and/or infinities are not valid for any of the 
formats supporting FP, r.out.gdal should not use NaN and/or infinities. 
OTOH, NaN and infinities are described in the IEEE FP standard. I would 
avoid format-specific code in r.out.gdal, considering the large number 
of supported formats and the number of creation options for each format 
(for each format sometimes differing between datatypes, e.g. GeoTIFF).


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

[GRASS-dev] Re: [GRASS GIS] #569: grass compilation error due to freetype

[GRASS GIS]

#569: grass compilation error due to freetype
--+-
  Reporter:  neuba|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  6.5.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  x86-32   
--+-
Comment (by glynn):

 Replying to [ticket:569 neuba]:
 > I got this error in grass 6.5 svn and their is the following error, in
 the v.label.sa directory:

 A couple of notes about submitting bug reports:

 1. All build output should be in the C locale; use e.g. "LC_ALL=C make
 ..." when compiling. Output from running GRASS programs should be in the C
 locale unless the report specifically relates to a localisation issue, or
 if you need to post the original text because you can't reproduce the
 error.

 2. Any blocks of literal text, e.g. program output, should be enclosed in
 triple braces to preserve formatting; see the WikiFormatting link above
 the comment box for details.

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

Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[Glynn Clements]

Markus Metz wrote:

> Considering this, rather use e.g. raster_min - 1 as default nodata value 
> for GDAL floating point datatypes?

If fabs(raster_min) is large, raster_min - 1 won't be exactly
representable, and may be rounded to raster_min. You would need to
subtract a value which depends upon the exponent.

Also, the input data may contain -DBL_MAX. For FCELL, if the map is
large enough, it's possible that *all* finite values occur in the
data.

The question is: is GDAL's no-data value allowed to be any FP value,
or must it be finite? I'm guessing that the GDAL documentation doesn't
say (similarly, I don't think it's documented whether GRASS
FCELL/DCELL values are allowed to be infinite).

Actually, this may depend upon the format. If a format supports FP,
the format's specification may dictate whether or not NaN and/or
inifinities are considered valid.

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

[GRASS-dev] [GRASS GIS] #569: grass compilation error due to freetype

[GRASS GIS]

#569: grass compilation error due to freetype
-+--
 Reporter:  neuba|   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.5.0
Component:  default  | Version:  svn-trunk
 Keywords:   |Platform:  Linux
  Cpu:  x86-32   |  
-+--
 I got this error in grass 6.5 svn and their is the following error, in the
 v.label.sa directory:
 gcc -I/home/danho/gis_soft/grass6_devel/dist.i686-pc-linux-gnu/include  -g
 -O2-I/usr/include/gdal/-DPACKAGE=\""grassmods"\"
 -I/home/danho/gis_soft/grass6_devel/dist.i686-pc-linux-gnu/include -o OBJ.
 i686-pc-linux-gnu/annealing.o -c annealing.c
 Dans le fichier inclus à partir de annealing.c:15:
 labels.h:20:22: erreur: ft2build.h : Aucun fichier ou dossier de ce type
 labels.h:21:10: erreur: #include attend "NOM_DE_FICHIER" ou
 
 labels.h:22:10: erreur: #include attend "NOM_DE_FICHIER" ou
 
 make: *** [OBJ.i686-pc-linux-gnu/annealing.o] Erreur 1

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

[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[GRASS GIS]

#73: r.out.gdal tiff output does not work
--+-
  Reporter:  helena   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  critical |   Milestone:  6.4.0
 Component:  Raster   | Version:  svn-trunk
Resolution:   |Keywords:  r.out.gdal, tiff 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by mmetz):

 Trying to summarize the suggestions and discussions for a new design:

  * before actual export new precision test for each band
- FCELL/DCELL to be exported as some GDAL integer type -> warning
- CELL exported as GDT_FLOAT32 and raster_min < -2^24^ or raster_max >
 2^24^ -> warning
- DCELL exported as GDT_Float32 -> warning

  * before actual export new range test for each band
- if raster_min >= type_min and raster_max =< type_max -> fine, proceed
- else if raster_min > type_max or raster_max < type_min -> complete
 data loss, error
- else there is a partial data range overlap -> check data range during
 actual export

  * before actual export, get a reasonable default nodata value if none
 given
- NaN for all GDAL floating point datatypes. Is NaN constructed with
 0.0/0.0 ok?
- GDAL signed int types: first try minimum in potential range, if
 raster_min <= type_min, try maximum in potential range, if raster_max >=
 type_max, use minimum (would be (GInt32) 0x8000 for GDT_Int32). This
 can re-use results of range check above.
- GDAL unsigned int types: first try maximum in potential range, if
 raster_max >= type_max, try minimum in potential range, if raster_min <=
 type_min, use maximum. This can re-use results of range check above.
- no warnings or errors at this stage because it is yet unknown if
 there are any NULL cells in the (with g.region selected part of the)
 raster maps to be exported

  * before actual export, in case of custom nodata make sure the metadata
 nodata value and the raster nodata value are identical
- if (nodata != (double) (GDAL datatype) nodata) -> warning and nodata
 = (double) (GDAL datatype) nodata
- This would give feedback to the user about what GDAL has to do later
 for the selected export datatype and nodata value. And the metadata nodata
 value would always be identical to the value replacing NULL cells.

  * during actual export, check for presence of cells with nodata value
- NULL cells present: message about nodata value used to replace NULLs
- if there are cells == nodata value and NULL cells were assigned that
 nodata value -> -f flag and user nodata value: warning, else error

  * during actual export, check actual raster range against range of GDAL
 datatype if needed (depends on result of range check above)
- raster_min < type_min or raster_max > type_max -> data loss, error

 as in previous C versions of r.out.gdal, only write GDAL nodata to
 metadata if NULLs were encountered. It seems that GDAL metadata nodata is
 raster band specific, not globally set for the whole file; r.out.gdal
 behaves accordingly.

 All warnings and errors should clearly explain what is the problem and
 give tips on how it can be solved.

 Hamish, what exactly should this compatibility flag do? There is all sorts
 of software with all sorts of different deficiencies out there...

 I hope I didn't forget something

 Markus M

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

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Markus Neteler]

On Thu, Apr 23, 2009 at 4:30 PM, Paolo Cavallini  wrote:
> Hamish ha scritto:
>>> Hamish ha scritto:
 no? what is the exact error message?
>>
>> Paolo:
>>> option d not recognized
>>
>>
>> Using grep I can not find any trace of that message in the latest qgis
>> trunk/ SVN or GRASS's libgis. Has it been retranslated?
>
> Sorry, it may be slightly different: I do not have a qgis1.x+grass64
> machine at hand now, so I cannot check.

I have:


http://mrcc.com/qgisgrassmodule.dtd";>







 r.surf.fractal output=name [dimension=value] [number=value]
   [--overwrite] [--verbose] [--quiet]

Looks fine.

BUT: I can reproduce the error. I *feel* that it is a parsing problem
in QGIS that might expect full names. If so it should not do so.
?

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

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Paolo Cavallini]

Hamish ha scritto:
>> Hamish ha scritto:
>>> no? what is the exact error message?
> 
> Paolo:
>> option d not recognized
> 
> 
> Using grep I can not find any trace of that message in the latest qgis
> trunk/ SVN or GRASS's libgis. Has it been retranslated?

Sorry, it may be slightly different: I do not have a qgis1.x+grass64
machine at hand now, so I cannot check.

> does QGIS's grass toolbox double-check the module options using the 'g.module 
> --interface-description' or does it just try to run what the programmer/user 
> threw at it and see what happens? 

Dunno. When a module is called, if an option is not present, it throws
an error, so it seems the first of the two options.
Thanks.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Hamish]

> Hamish ha scritto:
> > no? what is the exact error message?

Paolo:
> option d not recognized


Using grep I can not find any trace of that message in the latest qgis
trunk/ SVN or GRASS's libgis. Has it been retranslated?

does QGIS's grass toolbox double-check the module options using the 'g.module 
--interface-description' or does it just try to run what the programmer/user 
threw at it and see what happens? 


??
Hamish

(I have cc'd grass-dev ML in the bug ticket to avoid all this cross posting)



  

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

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Paolo Cavallini]

Hamish ha scritto:
> no? what is the exact error message?

option d not recognized
Thanks.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Hamish]

Hamish:
> > So names can be lengthened without worry.
> > Does it not work??

Paolo:
> It does not, at least through the QGIS plugin.


no? what is the exact error message?


H





  

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

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Paolo Cavallini]

Hamish ha scritto:

> So names can be lengthened without worry.
> Does it not work??

It does not, at least through the QGIS plugin.
All the best.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Hamish]

> Paolo wrote:
> > Same thing happens for r.surf.fractal (option d=float has been changed
> > in option dimension=float). Could this also be fixed?
> 
> it shouldn't need to be. the parser will accept shortened names as long
> as they do not conflict. Therefore a call to 'r.surf.fractal d=' will
> work the same in grass 6.3 as it will in 6.4.
> So names can be lengthened without worry.

see  http://grass.osgeo.org/wiki/Module_command_line_parser


H



  

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

Re: [GRASS-dev] r.surf.fractal [was: v.buffer]

[Hamish]

Hamish ha scritto:
> > in devbr6 and relbr6_4 I have added backwards compatibility aliases
> > for the removed options. so all should be ok again.

Paolo wrote:
> Thanks for this.
> Same thing happens for r.surf.fractal (option d=float has been changed
> in option dimension=float). Could this also be fixed?

it shouldn't need to be. the parser will accept shortened names as long
as they do not conflict. Therefore a call to 'r.surf.fractal d=' will
work the same in grass 6.3 as it will in 6.4.
So names can be lengthened without worry.
Does it not work??


> More generally: is there a list of changed options, so we
> can try and fix them all?

I don't know of an automatic way of testing for that, but there should
not be any.

maybe r.terraflow's STREAM_DIR option?, but we should fix whatever the
new caps option bug is in the parser and leave that in caps for 6.x.



Hamish



  

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

[GRASS-dev] r.surf.fractal [was: v.buffer]

[Paolo Cavallini]

Hamish ha scritto:

> in devbr6 and relbr6_4 I have added backwards compatibility aliases for
> the removed options. so all should be ok again.

Thanks for this.
Same thing happens for r.surf.fractal (option d=float has been changed
in option dimension=float). Could this also be fixed?
More generally: is there a list of changed options, so we can try and
fix them all?
Thanks.

-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: #73: r.out.gdal tiff output does not work

[Hamish]

Markus Metz wrote:
> ESRI ArcMap 9.2: display ok for nodata=0, not ok when using
> NaN, NaN displayed like value 0.0, and cell query gives NaN
> instead of nodata
> 
> Considering this, rather use e.g. raster_min - 1 as default
> nodata value for GDAL floating point datatypes?


I would prefer that we default to something sensible (NaN) and add a
compatibility flag if the user wishes to export to deficient software.
Eventually the other software will get fixed, sooner if we don't
pander to their bugs.


good point about G_*range_min_max() not picking up zoomed outputs.
for range check stuff we could test at the start if there is no overlap
at all (e.g. spearfish elevation is all >1000m, so no part will fit in
a 0-255 Byte output), then have it test each cell as it goes. that is
not an expensive check, and Glynn sped up the NULL check so that should
be quick now too. If it finds something out of range drop a fatal error.

Fancy heuristics, trying to be really smart and solve the problem for
the user, and allowing to write broken output data are all going to
hurt the user in the end. Better to drop an error* and clearly explain
why, so the user can learn something from it.

"map range is .., type range is .., nodata=..  something there doesn't fit."

[*] important to explain why in the error message so they don't get
 frustrated, as obviously this stuff is a bit arcane.


Hamish



  

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

Re: [GRASS-dev] v.buffer

[Hamish]

me:
> in devbr6 and relbr6_4 I have added backwards compatibility
> aliases for the removed options. so all should be ok again.


(please test)


H



  

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

Re: [GRASS-dev] v.buffer

[Hamish]

> > This is bad.

> I think that the second option would be better. Users might

[will]

> have scripts which use the old syntax. Aren't we supposed to be more
> or less backwards compatible within a major version?

yes

> However distance is a more "proper" name for the parameter IMHO.
> So keep it as distance in 7 maybe?

in devbr6 and relbr6_4 I have added backwards compatibility aliases for
the removed options. so all should be ok again.


Hamish




  

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

Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[Markus Metz]

Glynn Clements wrote:

Markus Metz wrote:

  

   - all floating point: IEEE's NaN
  
Problem with NaN? According to IEEE 754, x == y is always FALSE if 
either x or y or both are NaN. Assuming (nodata = 
GDALGetRasterNoDataValue()) == NaN,
Sorry, should have been nodata = GDALGetRasterNoDataValue() and 
isnan(nodata)
 then going through all cells if 
(cell == nodata) will always be FALSE, nodata cells may not be detected? 
Depends on each implementation of nodata detection? Can be solved for 
GRASS, but how is this done in all other GIS applications?



if (x == nodata || isnan(nodata) && isnan(x))

isnan() is C99 and POSIX, or it can be defined as e.g.:

#define ISNAN(x) ((x) != (x))
As previously in ticket #73, I created a MASK and then exported 
elevation from nc_spm_08 as FLOAT32, once with nodata=0 and once with 
default nodata value NaN for GDT_Float32.

GRASS 7 r.in.gdal: all ok
GRASS 7 r.external: all ok

Other GIS applications:
QGIS 1.0.0: all ok
gvSIG 1.1.2: doesn't support the nodata concept, and NaN is displayed 
like 0.0
SAGA 2.0.3: display ok for NaN, but cell query gives 0.0 instead of NaN 
or nodata, and NoData info says 0
ESRI ArcMap 9.2: display ok for nodata=0, not ok when using NaN, NaN 
displayed like value 0.0, and cell query gives NaN instead of nodata


Considering this, rather use e.g. raster_min - 1 as default nodata value 
for GDAL floating point datatypes?

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

Re: [GRASS-dev] problem with required variables (shell script / grass6.4)

[Hamish]

roberto marzocchi wrote:
> I have a problem with a script, that
> I've  written for GRASS 6.3
> When I use it in GRASS 6.4, the script don't start,
> because it don't recognize 3 of 4 required inputs.
> 
> This is the error message:
> "ERROR: Required parameter  not
> set:"
> 
> But the input is correctly set.
> 
> Anyone understand the reason?


there is some problem in the newer code that the parser is rejecting
upper case options names. I don't know why, but we should fix that.


Hamish



  

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

[GRASS-dev] problem with required variables (shell script / grass6.4)

[roberto marzocchi]

I have a problem with a script, that I've  written for GRASS 6.3
When I use it in GRASS 6.4, the script don't start, because it don't
recognize 3 of 4 required inputs.

This is the error message:
"ERROR: Required parameter  not set:"
But the input is correctly set.

Anyone understand the reason?

Thanks in advanced
Roberto





-- 
Please consider the environment before printing this mail note!
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.buffer

[Martin Landa]

Hi,

2009/4/23 Wolf Bergenheim :
> backwards compatible within a major version? However distance is a more
> "proper" name for the parameter IMHO. So keep it as distance in 7 maybe?

+1 for 'distance' in GRASS7.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.buffer

[Wolf Bergenheim]

On 23.04.2009 10:53, Markus Neteler wrote:

> This is bad.
> 
> Options:
> - QGIS updates its toolbox XML file to rename the parameter
> - GRASS 6.4+ renames back "distance" to "buffer"

I think that the second option would be better. Users might have scripts
which use the old syntax. Aren't we supposed to be more or less
backwards compatible within a major version? However distance is a more
"proper" name for the parameter IMHO. So keep it as distance in 7 maybe?

--Wolf

-- 

<:3 ) Wolf Bergenheim ( 8:>

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

[GRASS-dev] Re: [GRASS GIS] #546: r.external support for SpatiaLite

[GRASS GIS]

#546: r.external support for SpatiaLite
--+-
  Reporter:  pcav |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  unspecified  
Resolution:   |Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by martinl):

 Replying to [comment:4 pcav]:
 > Martin, you're right: raster functions have been presented by Sandro to
 a recent GFOSS meeting in Italy, but are not yet documented on the web
 page. Sandro, you there? :)

 Great news! Looking forward the implementation of raster support in
 SpatiaLite. Martin

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

Re: [GRASS-dev] PostGreSQL functionality in GRASS.

[Moritz Lennert]

On 23/04/09 06:19, kavitesh.si...@wipro.com wrote:

Hi All,

 

It is a novice question, I want to know how is the PostGreSQL used in 
GRASS. My initial thought was that it stores the map attributes and 
spatial information in PostGreSQL or similar databases. On the other 
hand I also feel the dataset which GRASS uses to store map information 
(raster/vector) has all the spatial information. I can use a dataset and 
use in on any other system installation without copying anything from 
database.


GRASS stores the geometries (i.e. the "spatial" information) internally 
with an identifier (called category). You can then link these geometries 
to attributes which can be stored in any of the supported DB backends, 
i.e. DBF files, SQLite, PostgreSQL, MySQL or any database accessible via 
ODBC.


Please read http://grass.itc.it/grass63/manuals/html63_user/vectorintro.html
and
http://grass.itc.it/grass63/manuals/html63_user/sql.html

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

Re: [GRASS-dev] v.buffer

[Paolo Cavallini]

Markus Neteler ha scritto:

> This is bad.
> 
> Options:
> - QGIS updates its toolbox XML file to rename the parameter
> - GRASS 6.4+ renames back "distance" to "buffer"

I would suggest the second, as it is simpler and keeps compatibility,
not only with QGIS.
Please let me know how you intend to proceed, so I can take the right
action.
All the best, and thanks.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.buffer

[Markus Neteler]

On Thu, Apr 23, 2009 at 8:50 AM, Paolo Cavallini  wrote:
> Hi all.
> AFAIK, v.buffer has been deprecated, and replaced by v.buffer2.

Yes.

> As a result, the qgis-plugin-grass cannot use the command anymore.
> Of course it is possible and esy to replace the command, but care should be 
> taken
> when linking to different grass versions. Wouldnì't it be easier/more
> robust to either change the name of the new module back to v.buffer, or
> to ln?

This is the case:

cat vector/v.buffer2/Makefile
MODULE_TOPDIR = ../..
PGM = v.buffer
...

The new version is called v.buffer as before (obviously).

> See: https://trac.osgeo.org/qgis/ticket/1629

OK, I found the problem:
# GRASS 6.3, http://grass.osgeo.org/grass63/manuals/html63_user/v.buffer.html:
buffer=float
Buffer distance in map units

# GRASS 6.4, http://grass.osgeo.org/grass64/manuals/html64_user/v.buffer.html:
distance=float
Buffer distance along major axis in map units

This is bad.

Options:
- QGIS updates its toolbox XML file to rename the parameter
- GRASS 6.4+ renames back "distance" to "buffer"

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