[GRASS-user] working with vectors

[Markus GRASS]

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
>