[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