[GRASS-user] working with vectors

[Markus GRASS]

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
>>>   
>>>       
>>
>> ------------------------------------------------------------------------
>>