v.build.polylines options aren't working

[hellik]

from the user ML

​http://lists.osgeo.org/pipermail/grass-user/2014-December/071385.html

>But I’ve tried using cat=first and it continues to assign multiple cats to
the segments. 

tested here on my side.

from the manual:

    cats=no - No category number is assigned to a polyline. Also attributes
tables linked to the input vector map are not copied to the output vector
map.
    cats=first - Assign to a polyline category number of the first line. All
linked attributes tables are copied to the output vector map.
    cats=multi - If the lines that make up a polyline have different
category numbers then v.build.polylines will set the multiple catetory
numbers to a polyline. Also all linked attributes tables are copied to the
output vector map.

none of this options seems to work, as always all cats are copied to the
attribute table.

bug in v.build.polylines?

[mmetz]

Replying to hellik:

cats=no was indeed not working, fixed in r63321,2 (trunk, relbr70).

v.build.polylines is indeed copying all attribute tables as is from input to output, but the categories are processed according to the cats option. This means that the attribute table(s) can contain spurious entries that do not match any output feature. Other (not all) modules also copy attribute tables from input to output as is, without filtering. Usually, this does not harm and is not even noticeable.

[neteler]

Replying to mmetz:

Replying to hellik:

cats=no was indeed not working, fixed in r63321,2 (trunk, relbr70).

Should this go also into GRASS 6?

v.build.polylines is indeed copying all attribute tables as is from input to output, but the categories are processed according to the cats option. This means that the attribute table(s) can contain spurious entries that do not match any output feature. Other (not all) modules also copy attribute tables from input to output as is, without filtering. Usually, this does not harm and is not even noticeable.

Is this ticket solved?

[hellik]

Replying to neteler:

Replying to mmetz:

Replying to hellik:

cats=no was indeed not working, fixed in r63321,2 (trunk, relbr70).

confirmed cats=no is working now

Should this go also into GRASS 6?

v.build.polylines is indeed copying all attribute tables as is from input to output, but the categories are processed according to the cats option. This means that the attribute table(s) can contain spurious entries that do not match any output feature. Other (not all) modules also copy attribute tables from input to output as is, without filtering. Usually, this does not harm and is not even noticeable.

above should go into the manual.

Is this ticket solved?

downgrading priority; closing ticket when manual is extended.

[hellik]

Replying to hellik:

Replying to neteler:

Is this ticket solved?

downgrading priority; closing ticket when manual is extended.

some notes added to manual: r63781 (trunk), r63782 (relbranch7)

[mlennert]

Can we close this ?

[neteler]

Replying to neteler:

Replying to mmetz:

Replying to hellik:

cats=no was indeed not working, fixed in r63321,r63322 (trunk, relbr70).

Should this go also into GRASS 6?

Still unclear.

[mlennert]

Replying to neteler:

Replying to neteler:

Replying to mmetz:

Replying to hellik:

cats=no was indeed not working, fixed in r63321,r63322 (trunk, relbr70).

Should this go also into GRASS 6?

Still unclear.

What is actually unclear for me is what the problem was.

With a simple test line, when I comment out the line added in r63321 I get the same results as when I leave it active, both in grass64_release and in trunk. Both results being as expected. I have a vague memory that I could reproduce the bug at the time, but can't remember the details.

Does someone have a more relevant test case ?

Then again, r63321 seems sufficiently non-invasive that it could probably just be backported.

Moritz

[wenzeslaus]

Replying to mlennert:

What is actually unclear for me is what the problem was.

That's why every ticket and/or commit should have a formalized test.

So, let me encourage everybody to provide tests as ​gunittest Python test, ​Bash script, or at least as steps to reproduce in command line with easily available data, preferably NC SPM or generated. Having the test it would be clear what was the problem, how to reproduce it, and what the commit is trying to fix or implement (and if it is successful). And it would be clear not only at the time of reporting or writing but also half year later (which is the current age of the ticket).

[hellik]

Replying to mlennert:

Replying to neteler:

Replying to neteler:

Replying to mmetz:

Replying to hellik:

cats=no was indeed not working, fixed in r63321,r63322 (trunk, relbr70).

Should this go also into GRASS 6?

Still unclear.

What is actually unclear for me is what the problem was.

as mentioned above:

cats=no was indeed not working, fixed in r63321,2 (trunk, relbr70).

some tests (testvector testlinetopolyline for nc sample dataset attached later):

v.report map=testlinetopolyline@testvpolylines option=length                    
cat|length
1|3687.50148595
2|2416.07670918
3|3679.17100439

v.build.polylines --verbose input=testlinetopolyline@testvpolylines output=catsmulti cats=multi

v.report map=catsmulti@testvpolylines option=length                             
cat|length
1|9782.74919952
2|9782.74919952
3|9782.74919952

v.build.polylines --verbose input=testlinetopolyline@testvpolylines output=catsfirst cats=first

v.report map=catsfirst@testvpolylines option=length                             
cat|length
1|9782.74919952

v.build.polylines --verbose input=testlinetopolyline@testvpolylines output=catsno

v.report map=catsno@testvpolylines option=length                                
cat|length
Lese Objekte...

cats=no is now working (not tested in grass6.x).

the second issue:

some notes added to manual: r63781 (trunk), r63782 (relbranch7)

tested with

GRASS Version: 7.0.0                                                            
GRASS SVN Revision: 64706                                                       
Erstellungsdatum: 2015-01-20                                                    
Build Platform: i686-pc-mingw32                                                 
GDAL/OGR: 1.11.2                                                                
PROJ.4: 4.8.0                                                                   
GEOS: 3.4.2                                                                     
SQLite: 3.7.17                                                                  
Python: 2.7.4                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) 

[hellik]

test vector (ascii format) for nc sample dataset

[mlennert]

Replying to hellik:

Replying to mlennert:

Replying to neteler:

Replying to neteler:

Replying to mmetz:

Replying to hellik:

cats=no was indeed not working, fixed in r63321,r63322 (trunk, relbr70).

Should this go also into GRASS 6?

Still unclear.

What is actually unclear for me is what the problem was.

as mentioned above:

cats=no was indeed not working, fixed in r63321,2 (trunk, relbr70).

I understand what the declared issue was and saw the fix, but what is weird is that using current trunk, when I undo the fix by commenting out the 'Vect_reset_cats(Cats);' call that was added, v.build.polyline still works as expected with your test data. And everything works as expected for me in grass64release as well, without the fix.

So I'm not sure that the "fix" actually solved the problem.

Moritz

[hellik]

Replying to mlennert:

Replying to hellik:

Replying to mlennert:

Replying to neteler:

Replying to neteler:

Replying to mmetz:

Replying to hellik:

cats=no was indeed not working, fixed in r63321,r63322 (trunk, relbr70).

Should this go also into GRASS 6?

Still unclear.

What is actually unclear for me is what the problem was.

as mentioned above:

cats=no was indeed not working, fixed in r63321,2 (trunk, relbr70).

I understand what the declared issue was and saw the fix, but what is weird is that using current trunk, when I undo the fix by commenting out the 'Vect_reset_cats(Cats);' call that was added, v.build.polyline still works as expected with your test data. And everything works as expected for me in grass64release as well, without the fix.

So I'm not sure that the "fix" actually solved the problem.

Moritz

a few months ago some issues with v.build.polylines were reported in the MLs.

at that time I've tested a lot, cats=no didn't work in any case.

as my C knowledge is about zero, I can't judge if the fix mentioned in the ticket or any other commit 'fixed' this; but it is fixed now which was tested in the last days.

taken from the ML at that time:

>But I’ve tried using cat=first and it continues to assign multiple cats to
the segments. 

there may be hidden some more issues...

in quick summary in order to get solution to this ticket:

• cats=first, cats=multi, cats=no: tested here with g7 and trunk => works now as expected

• no filtering database entries (see above) => manual in g7 and trunk was expanded

• v.build.polylines seems to work as expected in the g6-series

as all seems to be fixed or working as normal, I suggest to close the ticket. feel free to reopen the ticket.

Helmut