Diferentes resultados para la misma transformación en diferentes instalaciones de PostgreSQL / Postgis

Pregunta:

Al migrar servicios web de un servidor a otro, notamos diferentes resultados de transformación para la misma consulta. En nuestro caso, se suministra un Polígono en WKT con SRID = 4326 y se envía una consulta a PostgresSQL para transformarlo a 31467. Se sospechaba que los diferentes servidores tienen diferentes definiciones de proj4, pero la información espacial_ref_sys para srid 31467 es idéntica.

Ejemplo de polígono en WKT, SRID = 4326:

POLYGON((6.765692822761539 51.00597872375141,6.767598964757953 51.00509342952401,6.771910476416512 51.006635544034566,6.7707304837520645 51.00806338213016,6.765692822761539 51.00597872375141))

Servidor A

SELECT ST_AsText(ST_Transform(ST_GeomFromText('POLYGON((6.765692822761539 51.00597872375141,6.767598964757953 51.00509342952401,6.771910476416512 51.006635544034566,6.7707304837520645 51.00806338213016,6.765692822761539 51.00597872375141))',4326),31467))

rinde:

POLYGON((3343258.68567984 5654686.62282287,3343389.47157136 5654584.09718158,3343697.23474346 5654746.47217529,3343619.23068104 5654907.79612667,3343258.68567984 5654686.62282287))

Información adicional de la versión:

SELECT PostGIS_Full_Version();  
SELECT version();

rendimientos

POSTGIS="2.2.5 r15298" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6" LIBJSON="0.11" RASTER
PostgreSQL 9.4.13 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit

y

SELECT proj4text FROM spatial_ref_sys WHERE srid=31467;

rendimientos

+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +datum=potsdam +units=m +no_defs

Cuando ejecutamos la transformación en el servidor B,

SELECT ST_AsText(ST_Transform(ST_GeomFromText('POLYGON((6.765692822761539 51.00597872375141,6.767598964757953 51.00509342952401,6.771910476416512 51.006635544034566,6.7707304837520645 51.00806338213016,6.765692822761539 51.00597872375141))',4326),31467))

Nosotros recibimos

POLYGON((3343204.36380305 5654547.24689407,3343335.13281662 5654444.73197122,3343642.85963301 5654607.08595063,3343564.86647133 5654768.39203429,3343204.36380305 5654547.24689407))

Un resultado notablemente diferente en comparación con el polígono devuelto por el servidor A.

Información adicional de la versión:

SELECT PostGIS_Full_Version();
SELECT version();

rendimientos

POSTGIS="2.5.3 r17699" [EXTENSION] PGSQL="100" GEOS="3.7.2-CAPI-1.11.2 b55d2125" PROJ="Rel. 6.2.0, September 1st, 2019" GDAL="GDAL 3.0.1, released 2019/06/28 GDAL_DATA not found" LIBXML="2.9.1" LIBJSON="0.11" LIBPROTOBUF="1.0.2" RASTER
PostgreSQL 10.10 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit

y

SELECT proj4text FROM spatial_ref_sys WHERE srid=31467;

rendimientos

+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +datum=potsdam +units=m +no_defs

Cuando ambos polígonos se exportan a geojson y se renderizan en QGis, la diferencia se vuelve obvia: Diferencia entre geojson del servidor A y B

No hubiéramos esperado que una versión más reciente de PostGIS y las bibliotecas asociadas tuvieran tal efecto en los resultados, especialmente porque la definición de proj4 para 31467 en ambas instalaciones es idéntica. ¿Hay algo que extrañamos aquí?

Respuesta:

La biblioteca PROJ ha tenido tres definiciones diferentes para el datum de potsdam .

En la versión 4.8.0, se cambió de una forma de tres parámetros a una forma más precisa de siete parámetros. Esta forma de siete parámetros es lo que está usando el servidor A y lo que se muestra en epsg.io.

En la versión 5.0.1, se cambió para usar la cuadrícula BeTA2007 . Esto es lo que está usando el servidor B.

Leave a Comment

Your email address will not be published. Required fields are marked *

web tasarım