Opened 10 years ago
Last modified 6 years ago
#2649 new defect
r.to.vect diagonals defect fixed
| Reported by: | byronbest | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.6.2 |
| Component: | Raster | Version: | unspecified |
| Keywords: | r.to.vect | Cc: | |
| CPU: | x86-64 | Platform: | All |
Description
fails to break lines when value changes along diagonals
patch for 7.0.0 attached
tested in 6.4.3 on Amazon
Attachments (11)
Change History (25)
by , 10 years ago
| Attachment: | lines.c.patch added |
|---|
comment:1 by , 10 years ago
| Component: | Default → Raster |
|---|---|
| Platform: | Unspecified → All |
comment:2 by , 10 years ago
| Keywords: | r.to.vect added |
|---|
Can you please post a test case/screenshot to better understand the problem?
by , 10 years ago
| Attachment: | wrong_class_2.tiff added |
|---|
draining top right to bottom left. The diagonal should be green
by , 10 years ago
| Attachment: | wrong_class_2a.tiff added |
|---|
stepping over the corner. The segment needs to be three
by , 10 years ago
| Attachment: | right_class_2.tiff added |
|---|
now r.to.vect notices another point is needed before leaving green
by , 10 years ago
| Attachment: | right_class_2a.tiff added |
|---|
now r.to.vect correctly adds points at the edges of value changes
comment:3 by , 10 years ago
Consider the result of r.drain, which is an already-thinned line of pixel centres, obviously in "runs" of x,y moving +/- 1 in x and/or y. We'd like for the runs be "collapsed" into only the corners where the direction changes. Further, we'd like that running the stream on another grid respect that we also need the corners where the color or value on the resulting line changes. The segments will be given the color of the pixel under the second of every pair. r.to.vect already handles these runs when they are straight in the x or y, but not in diagonals where both x and y change. The attached before/after screen shots show where this has become a visible defect.
comment:4 by , 10 years ago
All the tiff attachments seem to be broken (I tried two browsers), please use PNG format for screenshots.
by , 10 years ago
| Attachment: | wrong_class_2a.png added |
|---|
by , 10 years ago
| Attachment: | right_class_2.png added |
|---|
by , 10 years ago
| Attachment: | right_class_2a.png added |
|---|
comment:10 by , 9 years ago
| Milestone: | 7.0.4 → 7.0.5 |
|---|
comment:11 by , 8 years ago
| Milestone: | 7.0.5 → 7.0.6 |
|---|
comment:12 by , 7 years ago
| Milestone: | 7.0.6 → 7.0.7 |
|---|
comment:13 by , 6 years ago
| Milestone: | 7.0.7 → 7.6.2 |
|---|
by , 6 years ago
| Attachment: | alternative_line.grass added |
|---|
drain on cost surface to build mask of ideal path
by , 6 years ago
| Attachment: | line_stats.grass added |
|---|
mask and r.to.vect to make kml shapefile and csv by segment
comment:14 by , 6 years ago
The algorithm builds lines grid cell by grid cell, scanning over the entire raster row by row. The resulting line features have a cell value and a line segment, one or more grid cells long. Without my patch, the routine builds the vertex lists, lengthening the diagonal and horizontal or vertical. This is incorrect when the grid cell value changes-- the result will have a long line with the value of the last cell in the diagonal chain, instead of shorter lines with consistent value. The code is already doing runs in horizontal and vertical correctly.
Since the grid cell centers are the vertices of the result line, the value is associated with the segment from grid center to grid center neighboring, instead of the usual value change at the grid cell edges. However, for miles of line in each category, this is correct.
You may argue that the start_line should specify node=1 but since node is unused anyway, I used 0.
I suspect that it is also not correct with other value types, but I only tested categorical data. The bug would show in a line feature with the entire line given the value (elevation) of the last point in long runs diagonally.
raster/r.to.vect/lines.c patch