[GRASS-dev] [GRASS GIS] #2669: v.net.iso: different results depending on direction

GRASS GIS trac at osgeo.org
Mon Feb 22 02:38:22 PST 2016


#2669: v.net.iso: different results depending on direction
--------------------------+----------------------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.0.4
 Component:  Vector       |    Version:  svn-trunk
Resolution:               |   Keywords:  network v.net.iso direction cost
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+----------------------------------------------

Comment (by mmetz):

 Replying to [comment:1 mlennert]:
 > Apparently the problem arises when lines are diagonal (in comparison to
 NS or EW direction). Here's a reproducible testcase:
 >
 > * horizontal
 >
 > {{{
 > v.in.lines in=- out=testline sep=, --o << EOF
 > 610000,225000
 > 680000,225000
 > EOF
 > echo "645000|225000" | v.in.ascii in=- out=testpoint --o
 > v.net testline point=testpoint op=connect thresh=500 out=testnet --o
 > v.db.addtable testnet col="length double precision, cost double
 precision"
 > v.to.db testnet op=length col=length
 > v.db.update testnet col=cost qcol="length/(100*1000/60)"
 > v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40
 arc_column=cost --o
 > }}}
 >
 > * diagonal
 >
 >
 > {{{
 > v.in.lines in=- out=testline sep=, --o << EOF
 > 610000,200000
 > 680000,300000
 > EOF
 > echo "645000|225000" | v.in.ascii in=- out=testpoint --o
 > v.net -s testline point=testpoint op=connect thresh=50000 out=testnet
 --o
 > v.db.addtable testnet col="length double precision, cost double
 precision"
 > v.to.db testnet op=length col=length
 > v.db.update testnet col=cost qcol="length/(100*1000/60)"
 > v.net.iso testnet out=testiso center_cats=1-999
 costs=10,20,30,40,50,60,70 arc_column=cost --o
 > }}}
 >
 > * vectical
 >
 >
 > {{{
 > v.in.lines in=- out=testline sep=, --o << EOF
 > 645000,200000
 > 645000,300000
 > EOF
 > echo "645000|250000" | v.in.ascii in=- out=testpoint --o
 > v.net -s testline point=testpoint op=connect thresh=50000 out=testnet
 --o
 > v.db.addtable testnet col="length double precision, cost double
 precision"
 > v.to.db testnet op=length col=length
 > v.db.update testnet col=cost qcol="length/(100*1000/60)"
 > v.net.iso testnet out=testiso center_cats=1-999
 costs=10,20,30,40,50,60,70 arc_column=cost --o
 > }}}
 >
 > I'll attach the respective images. In the diagonal case, the isochrones
 are much closer towards the South-West (~37km - using the wxgui measuring
 tool - to reach the beginning of cat=8) than towards the North-East (~78km
 to reach the beginning of cat=8). As cost is defined via only one column,
 it should be identical in both directions.

 The problem/reason is that the length values in the length column are not
 what you expect. v.net has broken the line where the point has been
 snapped to. The two new lines have the same category values like the old
 line, i.e. identical category values, thus one common entry in the
 attribute table. The length value in the attribute table is thus the sum
 of the lengths of the two lines. You get results as expected with e.g.

 {{{
 v.in.lines in=- out=testline sep=, --o << EOF
 610000,200000
 680000,300000
 EOF
 echo "645000|225000" | v.in.ascii in=- out=testpoint --o
 v.net -s testline point=testpoint op=connect thresh=50000 out=testnet_1
 --o
 v.category in=testnet_1 out=testnet type=line op=add layer=3
 v.db.addtable testnet col="length double precision, cost double precision"
 layer=3
 v.to.db testnet op=length col=length layer=3
 v.db.update testnet col=cost qcol="length/(100*1000/60)" layer=3
 v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40,50,60,70
 arc_column=cost arc_layer=3 --o
 }}}

 Here, unique categories are created with v.category in a new layer 3.

 v.net keeps the original categories when splitting up a line because these
 categories can encode important information such as type of the road or
 speed limit which in turn might be needed for cost calculation. An example
 is given in the manual for v.net.path.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2669#comment:6>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list