error running v.what.vect under Windows/Osgeo4w

[lutra]

Hi,

I'm testing GRASS (6.4.2rc148715m) under Windows/Osgeo4w.

v.what.vect fails with

v.what.vect vector=dtm_points@PERMANENT =point layer=1 column=amostra4 qvector=fregue@PERMANENT =area layer=1 qcolumn=NOME_COM
Option  does not accept multiple answers

Description:
 Uploads vector values at positions of vector points to the table.

Keywords:
 vector, database, attribute table

Usage:
 v.what.vect vector=name [layer=value] column=string qvector=name
   [qlayer=value] qcolumn=string [dmax=value] [--verbose] [--quiet]

Flags:
 --v   Verbose module output
 --q   Quiet module output

Parameters:
   vector   Vector map to modify
    layer   Layer in the vector to be modified
            default: 1
   column   Column to be updated with the query result
  qvector   Vector map to be queried
   qlayer   Layer of the query vector containing data
            default: 1
  qcolumn   Column to be queried
     dmax   Maximum query distance in map units
            default: 0.0
Finished with error

under Linux the same operation, with the same vectors it works fine.

[lutra]

complete command

v.what.vect vector=dtm_points@PERMANENT =point layer=1 column=amostra4 qvector=fregue@PERMANENT =area layer=1 qcolumn=NOME_COM
Option  does not accept multiple answers

[neteler]

This looks strange;

v.what.vect vector=dtm_points@PERMANENT =point ...

=point should not be there.

[martinl]

Replying to lutra:

complete command

> v.what.vect vector=dtm_points@PERMANENT =point layer=1 column=amostra4 qvector=fregue@PERMANENT =area layer=1 qcolumn=NOME_COM
> Option  does not accept multiple answers
> 

there are some bogus, =point =area is a nonsense. How you get this command? From wxGUI?

[lutra]

there are some bogus, =point =area is a nonsense. How you get this command? From wxGUI?

I'm using the QGIS plugin, but I can try the wxGUI and let you know asap.

Did v.what.vect changed since 6.4.1? On linux works fine with GRASS 6.4.1, so an explanation may be the module have been modified and the QGIS module GUI has not been updated.

[lutra]

Did v.what.vect changed since 6.4.1?

Hi, can you please help me understand where is the problem? I made a few tests using the same dataset/vectors and using both the wxpyhton GUI and the QGIS/GRASS interface.

GRASS 6.4.2, Windows wxpython -> works, command is:

v.what.vect vector=pontos@mapset_agueda column=puppa qvector=freguesias@mapset_agueda qcolumn=NOME_ITA

GRASS 6.4.1, Windows wxpython -> works, command is:

v.what.vect vector=pontos@mapset_agueda column=puppa qvector=freguesias@mapset_agueda qcolumn=NOME_ITA

GRASS 6.4.2, Windows QGIS/GRASS -> doesn't work, command is:

v.what.vect vector=pontos@mapset_agueda =point layer=1 column=puppa qvector=freguesias@mapset_agueda =area layer=1 qcolumn=NOME_ITA

the culprit does not seems to be the "=area" or "=point", as issuing the following trough the QGIS/GRASS CLI it works

v.what.vect vector=pontos@mapset_agueda =point column=puppa qvector=freguesias@mapset_agueda =area qcolumn=NOME_ITA

GRASS 6.4.1, Linux QGIS/GRASS -> works, command is:

v.what.vect vector=pontos@mapset_agueda =point layer=1 column=puppa qvector=freguesias@mapset_agueda =area layer=1 qcolumn=NOME_ITA

Thanks in advance

[martinl]

Replying to lutra:

GRASS 6.4.2, Windows QGIS/GRASS -> doesn't work, command is:

v.what.vect vector=pontos@mapset_agueda =point layer=1 column=puppa qvector=freguesias@mapset_agueda =area layer=1 qcolumn=NOME_ITA

the culprit does not seems to be the "=area" or "=point", as issuing the following trough the QGIS/GRASS CLI it works

This is a QGIS (or better to say GRASS plugin) bug. You should report it in QGIS tracker.

[lutra]

This is a QGIS (or better to say GRASS plugin) bug. You should report it in QGIS tracker.

yes, I understand is a qgis grass plugin problem.

[lutra]

This is a QGIS (or better to say GRASS plugin) bug. You should report it in QGIS tracker.

Probably is not true.

I made a few further tests, using various QGIS standalone installers, that were all made using osgeo4w packages. Every installer was shipped with his own copy/version of GRASS. I obtain the GRASS version by issuing g.version from the GRASS shell.

From QGIS 1.5 to 1.7 it all works fine. Things got broken with QGIS 1.7.1 which ships GRASS 6.4.2

The command I tested were

v.what.vect vector=pontos@mapset_agueda =point layer=1 column=puppa
qvector=freguesias@mapset_agueda =area layer=1 qcolumn=NOME_COM

v.generalize input=provincias@mapset_agueda type=area layer=1 -c
type=boundary method=douglas threshold=100 look_ahead=7 reduction=50
slide=0.5 angle_thresh=3 degree_thresh=0 closeness_thresh=0
betweeness_thresh=0 alpha=1.0 beta=1.0 iterations=1 layer=1 output=puppa

They works ok with

QGIS 1.5 GRASS 6.4.0svn (2010)

QGIS 1.6 GRASS 6.4.0 (2010)

QGIS 1.7 GRASS 6.4.1 (2011)

They don't work with

QGIS 1.7.1 GRASS 6.4.2RC148715M (2011)

The QGIS/GRASS plugin hasn't changed between QGIS 1.7 and 1.7.1

[neteler]

Could you please try QGIS 1.7 (not 1.7.1) with GRASS 6.4.2RC148715M (2011)? Otherwise two versions are changed in parallel and we don't know where it goes wrong.

[neteler]

Since v.what.vect is simply a wrapper for v.distance, it would be essential to add shell debugging (add -x in the first line) to v.what.vect to understand how v.distance is called.

[mmetz]

Replying to neteler:

Since v.what.vect is simply a wrapper for v.distance, it would be essential to add shell debugging (add -x in the first line) to v.what.vect to understand how v.distance is called.

I'm pretty sure the reason why all the above commands no longer work with 6.4.2 is the bug fix for #1444. AFAICT, this fix is correct and causes the parser to be a bit more unforgivable for invalid options. As stated in comment:6, this is a QGIS/GRASS plugin problem. This plugin should produce valid commands because it can parse the interface description and use this information to construct a valid command, just like the GRASS GUIs do. Are there no maintainers for the QGIS/GRASS plugin?

Markus M

[lutra]

Are there no maintainers for the QGIS/GRASS plugin?

The problem is not only the lack of full time maintainers for the plugin (a void that we -Faunalia- somehow fill), but also the lack of communication between the two teams, QGIS and GRASS. When something changes in GRASS (a module, or as in this case an important core feature) it would be better to drop a line to the qgis-dev mailing list, so we can catch up. ;) cheers

[martinl]

Replying to lutra:

The problem is not only the lack of full time maintainers for the plugin (a void that we -Faunalia- somehow fill), but also the lack of communication between the two teams, QGIS and

Well, the lack of maintainer is a main problem ... I am afraid that such maintainer needs to be found in QGIS community.

GRASS. When something changes in GRASS (a module, or as in this case an important core feature) it would be better to drop a line to the qgis-dev mailing list, so we can catch up. ;) cheers

Please bear in mind that in GRASS 6 there should be no changes which brakes backward compatibility. So you can hardly expect such announcements even in grass-dev ML.

[lutra]

Well, the lack of maintainer is a main problem ... I am afraid that such maintainer needs to be found in QGIS community.

Yes, we know. Is also for this reason that probably the best choice will be to move GRASS into the new processing/analytical framework, and after the porting to deprecate the plugin. But until then we need to keep alive the plugin because -as it is obvious- who needs to make GIS analysis within QGIS needs most of the times to use also GRASS.

Please bear in mind that in GRASS 6 there should be no changes which brakes backward compatibility. So you can hardly expect such announcements even in grass-dev ML.

Ok. But at least a few modules have changed (ex: v.generalize) and we realized it just when we used the module after QGIS have been recompiled against the new GRASS release. Then we had to change the module GUI in the plugin, and had to tell users to use trunk/master instead of the stable release... not a big deal, but not straightforward.

[lutra]

The problem was indeed in the plugin, but it wasn't that straightforward. In fact along the road it was discovered a bug in the GRASS parser of the 6.4.2Rc1 release.