[GRASS-user] working with vectors

[achim]

Thanks,

I just found out. It wasnt the rmdangles-command, which was wrong.
Sorry, I mixed some outputs and thus something was wrong. Anyway, I dont
really understand the threshold-option with v.rmdangles! It does not
make any sense to me.

I solved the problem exactly by doing:
v.clean --overwrite input=grid_af_lines_plus_accu400_areas at achim
output=grid_af_lines_plus_accu400_areas_clean at achim type=boundary
tool=rmdangle,rmbridge,rmsa thresh=100000.0.000001

and then again just with tool=rmdangle thresh=100000

achim

Markus GRASS schrieb:
> achim wrote:
>> 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. 
> Not sure if I understand right. Cutting a line by another one is done by
> v.clean tool=break. After that you can remove dangles. That should take
> care of the blue crosses in the screenshot. Maybe you get rid of all
> dangles if you set the threshold to something < 0? Have you selected the
> appropriate type for cleaning? The bit that's labelled as missing should
> not be deleted when removing dangles if lines/boundaries were broken first.
> 
> It's easier to figure out the problem if you could post the commands you
> used, for all steps.
> 
> Markus M
> 
>> 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 at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>>   
>>>>       
>>> ------------------------------------------------------------------------
>>>
>