[GRASS-user] working with vectors

[achim]

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 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>   
> 
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : screenshot.png
Dateityp    : image/png
Dateigr??e  : 16949 bytes
Beschreibung: nicht verf?gbar
URL         : http://lists.osgeo.org/pipermail/grass-user/attachments/20090519/a9191482/screenshot-0001.png