3

I`m using Qgis 2.2 and 2.4 and loaded a wms-map using the coordinate system ERTS89 UTM 32N. I set 8 points (all in on shp-fileand in UTM 32N) on various locations on the map. After that i created a buffer for each of the points with 72 and later 99 cricle-segments, because i thought this is more accurate according to a real circle. Each buffer has a radius of 50m.Then i calculated the area of this buffer-polygons using the fieldcalculator.

Now the problem.

Not only that the calculated areas differ from a mathematic calculated circle (with a radius of 50m, the area should be around 7853m² --> fieldcalc gives areas around 7830m²). The areas of each of 8 polygons differ between each other. And the more circle-segments i use, the more deviation between the results, alldough the difference between calculated area and mathematical area gets smaller. WHY does that deviation exist, alldough each polygon should have the same radius and therefore the same area.

I understand the difference between qgis-calculated area and mathematic area, but not the difference between the calculated ones. I tried to use different coordinate-systems like WGS84, Nad83 (NSRS2007), Lambert, DHDN GK4,...... All with the same problem.

Is it a qgis-discrepancy i have simply to deal with or did i something wrong?

julien
  • 10,186
  • 6
  • 55
  • 93
Chris
  • 31
  • 1
  • I suspect this is linked to the use of map datums and projections. http://gis.stackexchange.com/questions/664/whats-the-difference-between-a-projection-and-a-datum Depending on where your features are they could end up with different areas. This game highlights the difficulties in projecting a sphere onto a flat surface: http://flowingdata.com/2013/01/31/mercator-map-puzzle/ – MAJ742 Nov 25 '14 at 12:49
  • 1
    Yes, you are right with that point. But this difference according to the projection-typ shouldn`t produce area-differences of 20m² in rather small scale. If you look over a large area (lets say germany) then a difference between mapped polygon-areas seem logical to me, but not in the scale of 50kmx50km. Overall, i tried verious proj.-types. What else can i do? – Chris Nov 25 '14 at 13:08
  • It might be a rounding error on the calculations. What field type are you using to do the calculations? - For example a short integer could lead to rounding errors as it only stores whole numbers whereas a Double would be better as it allows for decimal places. http://resources.arcgis.com/en/help/main/10.1/index.html#//003n0000001m000000 – MAJ742 Nov 25 '14 at 13:11
  • I use real/double with 9 fields and 3 decimal places. But a rounding error of 20m²? Isn`t it a little much? When i use 72 circle-segments the variance is 4-5m². Using 99 (max.) the variance is 15-20m², but closer to the mathematical result. – Chris Nov 25 '14 at 13:20
  • Yeah if you're using a double field then it's probably not that - but may be worth changing to the max decimal places allowed just to confirm. I'm running out of ideas but just to clarify are you adding together multiple rings of buffering or a single 50m buffer for each point? http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00080000001p000000 – MAJ742 Nov 25 '14 at 13:29
  • Using one 50m-buffer for each point, but with one command. Buffer point.shp x (containing 8 points) with a radius of 50m and 72/99 segments. Thats it. Pain simple and it doesnt give me a single result but 8 different results. Perhaps i should switch to AutoCad. – Chris Nov 25 '14 at 13:37
  • More disturbing. I`m the only one in my company having this problem. – Chris Nov 25 '14 at 13:43
  • 1
    I feel your pain. GIS can be super frustrating at times. My final suggestion is to use the Grass command of v.buffer.distance and see what happens. Also try the calculations without a basemap to doubly ensure that isn't affecting the projections. (and compare the steps to what your colleagues are doing) http://grass.osgeo.org/grass65/manuals/v.buffer.html – MAJ742 Nov 25 '14 at 13:45
  • Ok. Never been using Grass. But ill try. The last suggestions you mentioned are already done. Without a psoitiv outcome for me. Usualy a wouldnt mind such a small difference between numbers. Failure is about 0,069-0,1%. But if its money behind this number i cant tell if our customers are that generous. :) – Chris Nov 25 '14 at 13:54
  • Grass v.buffer.distance is available from the QGIS Processing Toolkit, you won't need to go into GRASS to use it. – nhopton Nov 25 '14 at 16:26
  • @Chris, could you share a table showing: X/Y coords of the points being buffered, the # segments, and the area of each buffer? Also, you mention you're the only one having the issue in your company - confirm you're all using the same tools and projections, but you're the only one getting variant results? – Simbamangu Nov 26 '14 at 13:22

0 Answers0