Thanks Markus! There is still remaining a problem:
by removing dangles I do not delete 'open ends' until the line is cut by another one. But that what I need. Otherwise I will lose the character of geometrically closed areas... to illustrate I attached a sceenshot.., achim Markus GRASS schrieb: > achim wrote: >> Hi, >> >> its not as easy as it should be... >> >> 1) Having two sets of lines (one from a set of polygons) >> > Just to be on the safe side, make sure the one set of lines from a set > of polygons is of type lines not boundaries. >> 2) Patch them >> > 3) Lines to boundaries > 4) Clean them with these tools in this order: > 1. break polygons: v.clean tool=bpol type=boundary > 2. remove duplicates: v.clean tool=rmdupl type=boundary > Steps 1 and 2 can be combined with v.clean tool=bpol,rmdupl > type=boundary > > 3. break lines at intersections: v.clean tool=break type=boundary > 4. remove duplicates: v.clean tool=rmdupl type=boundary > 5. remove small angles: v.clean tool=rmsa type=boundary > Steps 3 to 5 can be combined with v.clean tool=break,rmdupl,rmsa > type=boundary > > 6. if the vector was modified in step 5, repeat steps 3 - 5 until > v.clean tool=rmsa no longer modifies the vector >> 3) Clean them (break, ..) >> 4) Lines to boundaries >> 5) add centroids >> ... >> 6) ..do not get the areas that should be areas >> > Any errors in output of v.build, e.g. incorrect boundaries or duplicate > centroids? >> Even if they are geometrically closed. >> I think its a problem of topology, in particular line directions eg. ? >> > Line directions don't matter for correct topology. Most likely the > vector is still not clean. >> I spend a lot of time with these things (including connecting db's, ex- >> and importing shapes trying alternatives). Wouldnt it be cheaper to try >> with arc gis? ;-) There I do know to run zonal statistics > v.rast.stats or r.univar.zonal from grass-addons ;-) >> and to connect >> tables from vector data. Well.. I like grass, ...I spend a lot of >> time... Maybe there should be some things easier, more intuitive and >> better connected that one is led better thought all these all days >> procedures. >> >> Thanks a lot, >> achim >> >> >> Hamish schrieb: >> >>> Achim: >>> >>>>> , measure length of lines even in an latlong projection... >>>>> >>> Moritz: >>> >>>> v.to.db, although I'm not 100% sure how that deals with >>>> lat-long. Only comment in the man page: >>>> >>>> "When calculating perimeters in Latitude-Longitude >>>> locations, the geodesic distance between the vertices is >>>> used." >>>> >>>> I would suppose that this is the same for line length... >>>> >>> actually ??, although I do get correct looking results in meters >>> from v.to.db option=length, it looks like v.to.db/lines.c needs >>> to have in a few other places: >>> >>> - len = Vect_line_length(Points); >>> + if (G_projection() == PROJECTION_LL) >>> + len = Vect_line_geodesic_length(Points); >>> + else >>> + len = Vect_line_length(Points); >>> >>> ??? not sure when that code is used though -- >>> it also uses length() instead (from v.to.db/calc.c) which uses >>> G_distance() (LatLon-aware), which is probably where the >>> reasonable output comes from. >>> >>> >>> perhaps we need to make a new V_distance(Points) lib fn that, >>> like G_distance(), automatically switches to geodesic mode when >>> the location is lat/lon? >>> >>> test: >>> >>> test_lines.vasc >>> L 2 1 >>> 166 -45 >>> 167 -45 >>> 1 1 >>> L 2 1 >>> 166 -46 >>> 166 -47 >>> 1 2 >>> L 2 1 >>> 167 -44 >>> 168 -45 >>> 1 3 >>> >>> v.in.ascii in=test_lines.vasc out=test_lines format=standard -n >>> v.db.addtable test_lines col='length_m double' >>> v.to.db test_lines opt=length colum=length_m >>> v.db.select test_lines >>> >>> vertical line should be 1 deg lat dist (~ 1852m * 60) >>> horiz line should be 1 deg lon dist (~ 1852 * 60 * 0.707 here) >>> >>> >>> ?, >>> Hamish >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >
<<inline: screenshot.png>>
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user