Opened 10 years ago
Closed 9 years ago
#2505 closed defect (fixed)
v.build.polylines options aren't working
| Reported by: | hellik | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 6.4.5 |
| Component: | Vector | Version: | svn-releasebranch64 |
| Keywords: | v.build.polylines | Cc: | |
| CPU: | Unspecified | Platform: | All |
Description
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?
Attachments (1)
Change History (14)
follow-up: 2 comment:1 by , 10 years ago
follow-ups: 3 6 comment:2 by , 10 years ago
Replying to mmetz:
Replying to hellik:
cats=nowas indeed not working, fixed in r63321,2 (trunk, relbr70).
Should this go also into GRASS 6?
v.build.polylinesis 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?
follow-up: 4 comment:3 by , 10 years ago
| Priority: | critical → major |
|---|
Replying to neteler:
Replying to mmetz:
Replying to hellik:
cats=nowas indeed not working, fixed in r63321,2 (trunk, relbr70).
confirmed cats=no is working now
Should this go also into GRASS 6?
v.build.polylinesis 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.
comment:4 by , 10 years ago
follow-up: 7 comment:6 by , 9 years ago
follow-ups: 9 10 comment:7 by , 9 years ago
Replying to neteler:
Replying to neteler:
Replying to mmetz:
Replying to hellik:
cats=nowas 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
comment:8 by , 9 years ago
| Milestone: | 7.0.0 → 6.4.5 |
|---|---|
| Version: | svn-releasebranch70 → svn-releasebranch64 |
comment:9 by , 9 years ago
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).
follow-up: 11 comment:10 by , 9 years ago
Replying to mlennert:
Replying to neteler:
Replying to neteler:
Replying to mmetz:
Replying to hellik:
cats=nowas 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)
by , 9 years ago
| Attachment: | testlinetopolyline.txt added |
|---|
test vector (ascii format) for nc sample dataset
follow-up: 12 comment:11 by , 9 years ago
Replying to hellik:
Replying to mlennert:
Replying to neteler:
Replying to neteler:
Replying to mmetz:
Replying to hellik:
cats=nowas 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
comment:12 by , 9 years ago
Replying to mlennert:
Replying to hellik:
Replying to mlennert:
Replying to neteler:
Replying to neteler:
Replying to mmetz:
Replying to hellik:
cats=nowas 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
comment:13 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Replying to hellik:
cats=nowas indeed not working, fixed in r63321,2 (trunk, relbr70).v.build.polylinesis 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.