[GRASS-dev] [GRASS GIS] #3356: v.to.db: incorrect area calculations in lat-long location

GRASS GIS trac at osgeo.org
Mon Jun 5 04:20:41 PDT 2017


#3356: v.to.db: incorrect area calculations in lat-long location
--------------------------+-----------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.4.0
 Component:  Vector       |    Version:  svn-trunk
Resolution:               |   Keywords:  v.to.db area lat-long
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-----------------------------------

Comment (by mlennert):

 Replying to [comment:5 annakrat]:
 > I fixed the rendering issue in r71163 and r71164.

 Yes, works great now, thanks !

 > But the area computation problem must be somewhere in
 [https://grass.osgeo.org/programming7
 >/area__poly1_8c.html#af6f1f53bacc34249be98006c95369695
 G_ellipsoid_polygon_area], probably related
 > to very small numbers, but I couldn't pinpoint the problem. There is
 something specific about this
 > polygon, when I draw a similar one, it gives more reasonable results.

 Yes:


 {{{
 v.in.ogr training_single.shp out=poly
 v.to.db -p poly op=area
 Reading areas...
  100%
 cat|area
 1|38.2256243922775
 g.region vect=poly
 v.in.region out=test
 v.to.db -p test op=area
 Reading areas...
  100%
 cat|area
 1|0.155378405506674
 }}}

 Another interesting test:


 {{{
 v.generalize poly method=douglas out=poly_gen thresh=0.000000001 --o
 v.to.db -p poly_gen op=area --q
 1|38.2255972503724
 v.generalize poly method=douglas out=poly_gen thresh=0.00000001 --o
 v.to.db -p poly_gen op=area --q
 1|2.27719829466825
 v.generalize poly method=douglas out=poly_gen thresh=0.00000002
 v.to.db -p poly_gen op=area --q
 1|0.0634717598906464
 v.generalize poly method=douglas out=poly_gen thresh=0.00000003 --o
 v.to.db -p poly_gen op=area --q
 1|0.134256325986436
 v.generalize poly method=douglas out=poly_gen thresh=0.0000001 --o
 v.to.db -p poly_gen op=area --q
 1|0.000968180796418213
 }}}

 IOW: just very slight generalization gives much better area calculations,
 but very small differences in generalization can lead to quite erratic
 area calculation results.

 So, yes, this definitely seems to be a precision issue, but at this stage
 I can't really see where in the source code, and don't have much time to
 delve into it in greater detail. Maybe MarkusM has an idea ?

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



More information about the grass-dev mailing list