[GRASS-user] working with vectors

[achim]

> 1) Having two sets of lines (one from a set of polygons)
> 2) Patch them
> 3) Clean them (break, ..)
> 4) Lines to boundaries
> 5) add centroids
> ...
> 6) ..do not get the areas that should be areas
>
> Even if they are geometrically closed.
> I think its a problem of topology, in particular line directions eg. ?

6) clean tool=rmdangle
7) add centroides
8) done

PS: 7.1) clean tool=rmbridge
7.2) add centroides

well..finally done..

"v.centroids will not put centroids in closed areas if there are
'dangles' inside the 'area'. Use v.clean (..) tool=rmdangle after adding
centroids and then repeat command v.centroides"
is missing
(shouldnt things like that not be scripted and easily usable ..by
clicking and typing?)

Besides I miss some self explaining pictures in the documentation...

wish you all the best,
achim


achim schrieb:
> Hi,
> 
> its not as easy as it should be...
> 
> 1) Having two sets of lines (one from a set of polygons)
> 2) Patch them
> 3) Clean them (break, ..)
> 4) Lines to boundaries
> 5) add centroids
> ...
> 6) ..do not get the areas that should be areas
> 
> Even if they are geometrically closed.
> I think its a problem of topology, in particular line directions eg. ?
> 
> 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 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