ThinkGeo.com    |     Documentation    |     Premium Support

GetArea() does not calculate area correctly?

files.zip (86.4 KB)

Hello. I’ve attached a geojson file containing a FeatureCollection of 4 MultiPolygons in WGS84 lat/long (EPSG 4326). This geojson validates with geojsonlint. When I calculate the area of those geometries in square meters (unprojected, or projected to UTM zone 13 (EPSG 32613)) using any of three methods 1) QGIS Field Calculator; 2) ArcMap Calculate Geometry; 3) PostGIS ST_AREA() - I get consistent results at least to several decimal places. But when I use MultipolygonShape.GetArea(), some features calculate fairly closely, while others differ substantially.

I’ve included screenshots of a table showing the areas calculated by QGIS and ArcGIS, and a screenshot from the Visual Studio debugger showing the area calculated after projecting to UTM Zone 13 (EPSG 32613). The second and 3rd features are the worst offenders, with area off by 1-5 sq meters.

Here is the function I use to calculate area. I hope you can tell me that I am doing something wrong?

	public static double GetUtmAreaMeters(int sourceDataEPSGId, Feature sourceFeature)
	{
		BaseShape sourceShape = sourceFeature.GetShape();
		PointShape centerShape = sourceShape.GetCenterPoint();
		int utmzoneEpsg = Convert.ToInt32(32700.0 - Math.Round((45.0 + centerShape.Y) / 90.0) * 100.0 + Math.Round((183.0 + centerShape.X) / 6.0));
		Proj4Projection projection = new Proj4Projection();
		projection.InternalProjectionParametersString = Proj4Projection.GetEpsgParametersString(sourceDataEPSGId);
		projection.ExternalProjectionParametersString = Proj4Projection.GetEpsgParametersString(utmzoneEpsg);
		projection.Open();
		MultipolygonShape projectedShape = projection.ConvertToExternalProjection(sourceShape) as MultipolygonShape;
		double area = projectedShape.GetArea(GeographyUnit.Meter, AreaUnit.SquareMeters);
		return area;
	}

Hi Mark,

Thanks to let us know your question.

In fact I have a little confused about your images, so the table.png record the test result from QGIS and ArcGIS right? And all the other images from VS is the result of our map?

We want to reproduce that, so we want to know how your create the feature from geojson data, could you please paste the code how your render the data into feature so we can make sure we render the data follow the same way?

Regards,

Ethan

thanks very much for the reply, and your time. I’ve attached a VS2015 .NET 4.5.2 console app project that removes all but the essentials. GetAreaTest.zip (1.7 MB)

In Visual Studio, build, then run it with F5 and it will print out the area in UTM zone 13N sq meters of each of the 4 features in the feature collection in the file. Compare those results to my earlier screenshot of from ArcMap/QGIS and you will see that the area of feature ID 2 differs by a little over 1 sq-m, and feature ID 3 differs by ~5 sq-m, while features ID 1 and 4 agree within a few hundreths of a sq-m. Example output:

Feature 1 area: 173167.9921875 sq-m.
Feature 2 area: 233988.7578125 sq-m. (should be 233989.9936)
Feature 3 area: 322125.1875 sq-m. (should be 322121.6224)
Feature 4 area: 111790.375 sq-m.

The reading of each geojson feature from the featurecollection boils down to very simple: I use Newtonsoft.JSON to parse nodes in the file and loop over the contents of the “features” JArray, and use ThinkGeo.MapSuite.Core.Feature.CreateFeatureFromGeoJson() on each feature JToken.

I’ve validated that geometries in this geojson featurecollection are correctly wound (by geojson’s interpretation of the right-hand-rule), and anyway it isn’t like there is any hole in features 2 or 3 that are of a size to explain the difference I see.

Hi Mark,

It looks we need more time on research about this problem.

Any update I will let you know.

Regards,

Ethan

Hi Mark,

Our developer research this problem, here we a workaround, it can works for V9, and it only works when mapunit equal meter.

Please view attache sample for this workaround.
GetAreaTest_20180516.zip (1.8 MB)

Our developer will fix this problem in future, but because our V9 code is frozen now, so our fix will only be valid in V10.

Regards,

Ethan