v.edit tool=break: breaking more then 6 coords and producing of an unexpected line

[achim]

1/2

using v.edit tool=break results for more than 6 coordinates in an error: "Attempt to delete dead feature".

after error message the topology of vector-file is destroyed: WARNING: Size of 'coor' file differs from value saved in topology file WARNING: Please rebuild topology for vector map

two equal coordinates result in an error, too

---

2/2

breaking a line returns three(!) lines: the two desired and one straight connecting the breaking point and the end or start point of the input-line

[achim]

picture of produced unexpected line

[achim]

2/2

has to do with direction of line. If line direction is flipped, everything is done alright.

Guess, it has to do with " Vect_append_point" in lines 94, 106, which add a line to the last! one.?

[martinl]

Replying to achim:

1/2

using v.edit tool=break results for more than 6 coordinates in an error: "Attempt to delete dead feature".

after error message the topology of vector-file is destroyed: WARNING: Size of 'coor' file differs from value saved in topology file WARNING: Please rebuild topology for vector map

two equal coordinates result in an error, too

---

2/2

breaking a line returns three(!) lines: the two desired and one straight connecting the breaking point and the end or start point of the input-line

Can you attach testing data to the ticket (e.g. in GRASS ASCII format - v.out.ascii format=standard) and exact commands to reproduce buggy behaviour of v.edit? Thanks. Martin

[achim]

example-lines in ASCII standart format

[achim]

how to reproduce bugs (make a copy named "network" between commands)

[achim]

Hi, I added a code example. Hope it helps... Achim

[achim]

Forgot: its EPSG 4326 at

g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 31:27:30N south: 4:01:30S west: 23:27E east: 39:48E nsres: 0:00:30 ewres: 0:00:30 rows: 4258 cols: 1962 cells: 8354196

[GG1234]

Hello all,

I am having the same unexpected additional lines when I brake lines of my map. Is there any hope for this ticket to be resolved in a near future or should I find a workaround ? Has anybody ideas of workarounds ? I tried on PostGis with the ST_Split function but wasn't lucky at using it, and I would rather stay in GRASS if possible.

Regards,

Cev.

[martinl]

Replying to GG1234:

I am having the same unexpected additional lines when I brake lines of my map. Is there any hope for this ticket to be resolved in a near future or should I find a workaround ? Has anybody ideas of workarounds ? I tried on PostGis with the ST_Split function but wasn't lucky at using it, and I would rather stay in GRASS if possible.

I will take a look at this issue during Christmas. No promises that it will help of course:-) Happy Xmas, Martin

[martinl]

Replying to achim:

2/2

has to do with direction of line. If line direction is flipped, everything is done alright.

Guess, it has to do with " Vect_append_point" in lines 94, 106, which add a line to the last! one.?

hopefully fixed in r58512 (devbr6).

The command breaks both lines (1 and 2)

v.edit map=network tool=break coords=33.6708333333333,16.9041666666667

You want probably break only line with id 1

v.edit map=network tool=break coords=33.6708333333333,16.9041666666667 id=1

Another option would be to break lines on intersections

v.clean in=network out=network_break tool=break

or

v.edit map=network tool=break id=1-9999

assuming that the map has less them 10e3 lines.

[martinl]

Breaking lines with multiple coordinate pairs hopefully fixed in r58516 (GRASS 6.5 only). Note that command

v.edit map=network tool=break coords=33.6708333333333,16.9041666666667,32.5041666666667,15.6458333333333,33.0208333333333,15.2708333333333

breaks all lines in given bounding boxes. You probably want to break lines only on intersections (v.clean tool=break)

[GG1234]

Hello Martin,

I am afraid I still have artifacts, see attached picture. For further debugging, I attach my layer and a txt files with the points on which I break.

I didn't try the first described bug yet, but will do so ASAP.

Thanks for the help and Merry Christmas to all,

Cev

[GG1234]

Artifacts still visible

[GG1234]

Used layers and breaking points

[martinl]

Replying to GG1234:

I am afraid I still have artifacts, see attached picture. For further debugging, I attach my layer and a txt files with the points on which I break.

please could you attach also commands to reproduce this bug. I have imported two shapefiles and created a point map.

[GG1234]

I extracted the commands from the python script I use. Here it is :

def montest():
	print g.run_command('v.patch', quiet=True, overwrite=True, input = ("Support_2","Raccos"), output="network")
	file = open('Conn_Pt2.txt', 'r')
	resultatParse = file.read()
	file.close()
	resultat = resultatParse.split("\n")
	for macoord in resultat[1:]:
		print "braking at point "+macoord
		print g.run_command('v.edit', map = "network", layer=1, tool = 'break', coords = macoord, thresh=1 ,overwrite=True)

[GG1234]

Thanks to Martin's Christmas present the bugs have vanished. My previous tests were wrong, I guess my Grass build wasn't recent enough. With a new setup it works like a charm !

Many thanks to Martin for this bug resolution, I will close the ticket. Any ideas if the fix is also in Grass 7 or will be in near futur ?

Cev.

[neteler]

Replying to GG1234:

Many thanks to Martin for this bug resolution, I will close the ticket. Any ideas if the fix is also in Grass 7 or will be in near futur ?

Reopening since lacking from G6.4 (two differences) and potentially 7.

[martinl]

Replying to neteler:

Reopening since lacking from G6.4 (two differences) and potentially 7.

right, backported to relbr64 as r58933 and r58934. Could anyone test it (probably GG1234?)? Thanks.

[martinl]

Replying to GG12345:

it means that it doesn't work for you? What exactly?

[GG12345]

Hello and Happy Christmas to all ! Sorry for the delay, was doing additional testing.

This bug seems to like Xmas time... I reopened the ticket because I still have the same artifacts on 7.0.2.

Below is a simple way to reproduce the bug :

In a location based on EPSG:27572

v.in.ogr --overwrite -o input=/.../test_break_lines2.shp output=ptnet
v.edit --verbose --overwrite map=ptnet layer=1 type=line tool=break coords=531934.28,1851818.17,531949.15,1851831.79 threshold=0.01
v.out.ogr --overwrite -cs input=ptnet olayer=ptnet format=ESRI_Shapefile type=line output=/.../test dsco="SHPT=ARC"

Data is attached.

v.edit behaves differently depending on the precision of breaking coordinates. For the following examples I used only one point to break the lines.

• With 8 decimals (531934.283798572,1851818.16932773) it selects the features but does not brake them. Debug=3 shows that spdist value of Vect_line_distance is 0 which is wrong. I wasn't able to track the bug further.
• With 2 decimals (531934.28,1851818.17) it selects 2 features but breaks 2 which is wrong
• With 3 decimals (531934.283,1851818.169) it selects 3 features and breaks 2 which are both wrong

Other thing to notice : I tried it on a windows OSGeo4W version of GRASS 7.0.2 and it works (only tested with 8 decimals). It seems to bug only on unix (Debian).

Is it the same bug as for 6.5 ? Any solution ?

Thanks for the help ! Cev.

g.version shows :

GRASS 7.0.2 (2015)
PROJ.4: 4.8.0
GDAL/OGR: 1.10.1
GEOS: 3.4.2
SQLite: 3.8.7.1

g.proj shows :

-PROJ_INFO-------------------------------------------------
name       : Lambert Conformal Conic
proj       : lcc
ellps      : clark80IGN
lat_1      : 46.8
lat_0      : 46.8
lon_0      : 0
k_0        : 0.99987742
x_0        : 600000
y_0        : 2200000
towgs84    : -168,-60,320,0,0,0,0
pm         : paris
no_defs    : defined
-PROJ_EPSG-------------------------------------------------
epsg       : 27572
-PROJ_UNITS------------------------------------------------
unit       : meter
units      : meters
meters     : 1

g.region shows :

projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      towgs84=-168,-60,320,0,0,0,0
ellipsoid:  clark80IGN
north:      1
south:      0
west:       0
east:       1
nsres:      1
ewres:      1
rows:       1
cols:       1
cells:      1

[GG12345]

test_break_lines2 shapefile

[GG12345]

Picture of artifacts with breaking coordinates in red circles and artifacts pointed by arrows

[GG12345]

Hello all and best wishes for 2016 !

Any time for this bug ? Are there some tests I could do ?

I was wondering if the region precision could be of any help for this, but if I read correctly in g.region manual, "Typically all raster and display modules are affected by the current region settings, but not vector modules. Some special modules diverge from this rule, for example raster import modules and v.in.region." Any clues ?

Thanks,

Cev.

[mlennert]

Looking at this briefly, wouldn't it be enough to port r58512 and r5851 to the grass7 branches ? The original fix was only applied to grass6.

[neteler]

Replying to mlennert:

Looking at this briefly, wouldn't it be enough to port r58512 and r5851 to the grass7 branches ? The original fix was only applied to grass6.

Sure about r5851? One digit lost?

[mlennert]

Replying to neteler:

Replying to mlennert:

Looking at this briefly, wouldn't it be enough to port r58512 and r5851 to the grass7 branches ? The original fix was only applied to grass6.

Sure about r5851? One digit lost?

Yes, sorry, this should have been r58512 and r58516 (as mentioned in earlier comments by Martin).

[mlennert]

Replying to mlennert:

Replying to neteler:

Replying to mlennert:

Looking at this briefly, wouldn't it be enough to port r58512 and r5851 to the grass7 branches ? The original fix was only applied to grass6.

Sure about r5851? One digit lost?

Yes, sorry, this should have been r58512 and r58516 (as mentioned in earlier comments by Martin).

I just tested trunk without and with the above fixes applied. Without I can reproduce the issue reported by the OP, with the issue seems to be solved. So I took the liberty to forward port both fixes to trunk.

Please test. I don't know the code well enough to judge the invasiveness of this fix and am not sure if this should still go into 7.0.3. Maybe we should wait a bit and backport it for 7.0.4 ?

[mlennert]

Replying to mlennert:

Replying to mlennert:

Replying to neteler:

Replying to mlennert:

Looking at this briefly, wouldn't it be enough to port r58512 and r5851 to the grass7 branches ? The original fix was only applied to grass6.

Sure about r5851? One digit lost?

Yes, sorry, this should have been r58512 and r58516 (as mentioned in earlier comments by Martin).

I just tested trunk without and with the above fixes applied. Without I can reproduce the issue reported by the OP, with the issue seems to be solved. So I took the liberty to forward port both fixes to trunk.

For the reference: r67577.

[martinl]

Replying to mlennert:

For the reference: r67577.

the modified function is used only in v.edit. I took liberty to backport patch also to relbr70 (r67579). Closing ticket, feel free to reopen if needed.

[GG12345]

Great !! Many thanks Moritz ! I will be testing it in a few days time and will come back with output. Cev.

[martinl]

Replying to GG12345:

I will be testing it in a few days time and will come back with output.

you can test 7.0.3RC2 (this version contains the patch too).

[GG12345]

Hello all, I have tested trunk & 7.0.3RC2 : both work as expected ! Many thanks to Moritz & Martin ! Cev.