[GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length

GRASS GIS GRASS GIS developer
1

Hi,

should be fixed in CVS.

Martin

2007/10/12, grass-dev@grass.itc.it <grass-dev@grass.itc.it>:

code R item #510, was opened at 2007-10-12 15:40
Status: Open
Priority: 3
Submitted By: Maciej Sieczka (msieczka)
Assigned to: Nobody (None)
Summary: v.to.db option=length: please report line's 3d length
Issue status: None
GRASS component: vector
Operating system: all
Operating system version:

Initial Comment:
Currently v.to.db always assumes input vector is flat. Condider two vector lines:

$ v.out.ascii line_3d form=standard
L 2
571600 5722275.5 1
571610 5722275.5 4

$ v.out.ascii line_flat form=standard
L 2
571600 5722275.5
571610 5722275.5

Although line_3d's length is 10.440307 and line_flat's is 10, v.to.db will report 10 for both:

$ v.to.db -p opt=length map=line_3d col=dummy
cat|length
-1|10

v.to.db's options coor, start, end already support Z attribute. Please implement it for length too.

----------------------------------------------------------------------

You can respond by visiting:
http://wald.intevation.org/tracker/?func=detail&atid=188&aid=510&group_id=21

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

2

Martin Landa wrote:

should be fixed in CVS.

After brief testing looks OK. Thanks much Martin!

Soon after I noticed v.to.db didn't report 3d length, I had
the same problem with v.distance (looking for a workaround),
which I noted down in the same ticket. Copying the note below:

Same request applies to v.distance. It apparently assumes
input points are flat too. Consider 2 3d points:

$ v.out.ascii start_3d
571600|5722275.5|1|1

$ v.out.ascii end_3d
571610|5722275.5|4|1

The distance between them is about 10.440307. Yet,
v.distance claims it's round 10:

$ v.distance -p from=start_3d to=end_3d upload=cat,dist
col=to_cat,dist
from_cat|to_cat|dist
1|1|10.000000

Maciek

3

Ahoj Maciek,

v.distance should be fixed in CVS (not tested with 3d lines...)

Martin

2007/10/13, Maciej Sieczka <tutey@o2.pl>:

Martin Landa wrote:

> should be fixed in CVS.

After brief testing looks OK. Thanks much Martin!

Soon after I noticed v.to.db didn't report 3d length, I had
the same problem with v.distance (looking for a workaround),
which I noted down in the same ticket. Copying the note below:

Same request applies to v.distance. It apparently assumes
input points are flat too. Consider 2 3d points:

$ v.out.ascii start_3d
571600|5722275.5|1|1

$ v.out.ascii end_3d
571610|5722275.5|4|1

The distance between them is about 10.440307. Yet,
v.distance claims it's round 10:

$ v.distance -p from=start_3d to=end_3d upload=cat,dist
col=to_cat,dist
from_cat|to_cat|dist
1|1|10.000000

Maciek

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

4

Maciej:
> Same request applies to v.distance. It apparently assumes
> input points are flat too. Consider 2 3d points:

Martin wrote:

v.distance should be fixed in CVS (not tested with 3d lines...)

d.what.vect will give you a 3D distance to compare against for an easy test.

Hamish

____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/

5

Hamish wrote:

Maciej:

Same request applies to v.distance. It apparently
assumes input points are flat too. Consider 2 3d
points:

Martin wrote:

v.distance should be fixed in CVS

Martin

You are too quick for me to catch on with testing :). I
confim now v.distance calculates the distance between 3D
points OK. BTW - v.distance suffers the same issue you have
just fixed in v.to.db, among the others, that a dummy column
is required in -p(rint) mode.

(not tested with 3d lines...)

Works if both input point and line are 3d:

$echo "571710|5722300|4|1" | v.in.ascii -zt z=3 out=pt3d --o

$ echo "L 2
571600 5722275.5 0
571610 5722275.5 0" | v.in.ascii -zn form=standard out=l3d

$ v.distance -pa from=pt3d to=l3d upload=cat,dist col=cat,dist
from_cat|cat|dist
1|null|103.035188

$ echo "L 2
571600 5722275.5 1000
571610 5722275.5 1000" | v.in.ascii -zn form=standard
out=l3d --o

$ v.distance -pa from=pt3d to=l3d upload=cat,dist col=cat,dist
from_cat|cat|dist
1|null|1001.307271

As can be seen the reported distances change as the input 3d
line moves in Z. Same happens if the 3d point changes elevation.

If *either* or both input is flat, the distance is
calculated in 2d space.

d.what.vect will give you a 3D distance to compare
against for an easy test.

Sorry I'm dense, but I don't get it how d.what.vect can
measure 3D distance. Can you explain?

Maciek

6

Hamish:

> d.what.vect will give you a 3D distance to compare
> against for an easy test.

Maciek:

Sorry I'm dense, but I don't get it how d.what.vect can
measure 3D distance. Can you explain?

Length is one it the outputs... just this:

echo "L 2
571600 5722275.5 0
571610 5722275.5 20" | v.in.ascii -zn form=standard out=l3d

echo "L 2
571600 5722276.5
571610 5722276.5" | v.in.ascii -n form=standard out=l2d

g.region v=l3d
d.vect l3d
d.vect l2d color=blue

d.what.vect -x --q

571604.16666667(E) 5722276.5(N)
l3d in user1 Nothing Found.
l2d in user1 Line
length 10.000000

571603.95833333(E) 5722275.45833333(N)
l3d in user1 Line
length 22.360680
Line height min: 0.000000 max: 20.000000
l2d in user1 Nothing Found.

Hamish

      ____________________________________________________________________________________
Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more!
http://tv.yahoo.com/collections/3658