[GRASS-dev] Re: [GRASSLIST:962] Re: GRASS and vector lines: how can I change the direction of digitized lines?

Hamish hamish_nospam at yahoo.com
Mon May 15 19:55:07 EDT 2006


> >> 2. I use "v.clean tool=snap thresh=0.01" to re-connect the flipped
> >> and the remaining original lines. Is it 100% robust? No risk that
> >> some won't be connected?
> 
> >If anything I would make thresh much smaller so that no new lines are
> >snapped. The coordinates should not be changed unless you did printf
> >%f from awk (shortens decimal precision, use %s to output full input
> >string instead of proccessing as a number). So snapping should be
> >exact.
> 
> I see. I don't do any maths on coordinates, I only use awk to select
> particular lines from v.out.ascii output and pipe them into another
> file, in a given order, so I should be on the safe side here.
> 
> Is it possible to estimate what treshold should be enough? 0.0001,
> else???

So the coordinates haven't moved and should line up exactly. Thus
a tresh of 0.0 should catch them, but as a general rule floating point
numbers are of finite precision so it is usually better to test if
(a1-a2 < 1e-15) or so.

But this is mostly academic, anything smaller than a centimeter should
probably be snapped and your original value of 0.01 should be fine.
(unless this is a lat/lon location &/or your units are not meters!)
This means your module "touches the data" and isn't a fully reversable
proceedure, which may not be desired.

 

> >Call temporary maps like tmp_vflip_$$_toflip:
> >tmp_${PROG} makes it easy to spot orphans, $$ gives it a 1 in 32k
> >chance of being unique.
> 
> I'm already using $$, I think (TMP="`g.tempfile pid=$$`"). Is this
> what you mean? Added $PROG, thanks.

$$ gives current process id number. adding it to the map name means
multiple runs of v.flip won't collide if an earlier one broke.

$PROG is ok for tmp filenames but a bad idea for vector map names -- you
can't use "." in a vector map's name. Just helps you spot where strange
left over files came from in a week's time.

 
> >It is easier to read, if instead of
> >
> >output=$OUTPUT"_toflip"
> >  you do
> >output=${OUTPUT}_toflip
> >  or
> >output="${OUTPUT}_toflip"
> 
> Is the 1st one error prone or only "not nice"?
> 
> Is any of the 2 you recommend better? I'll correct my script
> accordingly.

all work, just cleaner to use. Quoting the whole thing only matters if
you have special characters in the map name, which are illegal anyway.
Hopefully then you get an informative GRASS error instead of a cryptic
bash error.


> >asis=`cat $TMP.cat_asis`
> >asis=`echo $asis | sed 's/ /,/g'`
> >probably hit the limitied size cap for a shell variable? (4096
> >chars?) Use a tmp file.
> 
> Hmm, $asis is an input in the line 129:
> 
> v.extract -t layer=$LAYER input=$INPUT list=$asis output=
> $OUTPUT"_leaveasis"
> 
> list= has to be a single, long string of numbers separated with ",".
> So even if I avoid hitting the 4096 chars limit of a bash variable by
> doing all in a TMP file, I will finally have to pass it to "v.extract
> list=" as a one string, which will make it fail if the string is
> longer than 4096 (is my thinking correct?).

ok. maybe better to use an SQL query then where= cat is not flip_list?
Don't know how to specify that. v.select doesn't have op=not, maybe need
v.overlay? If only flipping a few of several thousand lines you may have
trouble.

doesn't help here, but you can go back and forth from a list in a file
to csv with the "tr"ade unix command:

tr '\n' ','
 and
tr ',' '\n'

(same as  sed 's/\n/,/g' )



> A possible workaround would be to to convert long, continous sets
> like eg. 1,2,3,4,5,...,100 into 1-100 and so on to save space. Is
> there an easy way of doing it?

don't know.


> Thank you very much for all the hints.

You already had it working, which is the hard part. A lot of this is
just tricks to make the code simpler & easier to catch errors.


Hamish




More information about the grass-dev mailing list