search

OSGeo / grass

GRASS GIS - free and open-source geospatial processing engine
https://grass.osgeo.org
Other
823 stars 302 forks source link

[Feat] Use GeographicLib for computing ellipsoidal areas #1235

Open jratike80 opened 3 years ago

jratike80 commented 3 years ago

The algorithm that GRASS uses for computing areas on ellipsoids gives different results than GeographicLib that is used by Proj and PostGIS. QGIS is also using the GRASS algorithm. It seems that GRASS developers have already considered in 2018 that it would not be a huge deal to start using GeographicLib and that the library delivers accurate results but the idea apparently was left drifting.

The switch into GeographicLib would mean that totally four OSGeo projects (GRASS, Proj, PostGIS, QGIS) would compute areas in the same way - I would call it interoperability.

http://osgeo-org.1560.x6.nabble.com/area-calculations-in-several-GIS-td5379541.html https://github.com/qgis/QGIS/issues/40888

mlennert commented 3 years ago

@metzm what do you think about this ?

metzm commented 3 years ago

The GeographicLib is included as geodesic.[c|h] in PROJ. We could include a simple interface to GeographicLib in lib/proj to calculate geodesic distances and areas. We probably need only three functions: geod_init(), geod_inverse(), and geod_polygonarea(), should not be too difficult. Then all affected modules need to be updated.

I will try to get some time to implement the interface to GeographicLib.

metzm commented 3 years ago

We could also modify the existing fns in lib/gis: G_begin_distance_calculations(), G_distance(), G_begin_cell_area_calculations(), G_area_of_polygon(). Less changes, and modules need not be touched. But this would require to add PROJ lib as a new dependency to lib/gis. I am not sure if this is a good idea or potentially dangerous.

neteler commented 3 years ago

We could also modify the existing fns in lib/gis: G_begin_distance_calculations(), G_distance(), G_begin_cell_area_calculations(), G_area_of_polygon(). Less changes, and modules need not be touched. But this would require to add PROJ lib as a new dependency to lib/gis. I am not sure if this is a good idea or potentially dangerous.

An option is to add this in a branch to master and see about its currently unknown impact.

metzm commented 3 years ago

An option is to add this in a branch to master and see about its currently unknown impact.

The GeographicLib is already included in PROJ 4.9.x, thus problems could only arise if master is compiled against some ancient GDAL / PROJ versions which is very unlikely. I would prefer to put #1283 directly into master and, if problems arise, introduce a minimum requirement of PROJ >= 4.9.1 (from 2015).

metzm commented 3 years ago

@jratike80 somehow I am not able to add you as reviewer to #1283, could you anyway review this PR? Thanks!

nyalldawson commented 3 years ago

https://github.com/qgis/QGIS/pull/41726