Lambert_Conformal_Conic: falla la conversión de shapefile a geojson

Question

Tengo un shapefile que también contiene un proyecto archivo que se ve así:

PROJCS
[
    "MGI_Austria_Lambert",
    GEOGCS
    [
        "GCS_MGI",
        DATUM
        [
            "D_MGI",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]
        ],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]
    ],
    PROJECTION["Lambert_Conformal_Conic"],
    PARAMETER["False_Easting",400000.0],
    PARAMETER["False_Northing",400000.0],
    PARAMETER["Central_Meridian",13.33333333333333],
    PARAMETER["Standard_Parallel_1",46.0],
    PARAMETER["Standard_Parallel_2",49.0],
    PARAMETER["Latitude_Of_Origin",47.5],
    UNIT["Meter",1.0]
]

Quiero convertir este shapefile en un geojson así:

ogr2ogr -f GeoJSON \
    -s_srs STATISTIK_AUSTRIA_STADTREGIONEN_3MIO.prj \
    -t_srs EPSG:4326 \
     STATISTIK_AUSTRIA_STADTREGIONEN_3MIO.geojson \
     STATISTIK_AUSTRIA_STADTREGIONEN_3MIO.shp

Esto falla con el siguiente mensaje de error:

ERROR 6: No translation for Lambert_Conformal_Conic to PROJ.4 format is known.

Cambiar la proyecto para que contenga PROJECTION["Lambert_Conformal_Conic_2SP"] o PROJECTION["Lambert_Conformal_Conic_1SP"] en lugar de Lambert_Conformal_Conic resulta en archivos geojson válidos que parecen tener las coordenadas correctas PERO las coordenadas resultantes difieren en su segundo o tercer decimal, por ejemplo

LON               , LAT
16.526053978650904, 48.32876392574797

contra.

16.527168091786308, 48.32902755664574 

Mis preguntas son:

1. ¿Cuál de los dos (si es que hay alguno) es el resultado correcto?
2. ¿Existe una explicación intuitiva para la diferencia entre Lambert_Conformal_Conic, ~_1SP y ~_2SP que también un no cartógrafo sea capaz de entender?
3. Hay una inexactitud en el valor del GEOGCS UNIT valor en el proyecto mostrado arriba comparado con el valor dado para el proyección respectiva en spatialreference.org . ¿Es esta la razón de las diferencias?
4. El editor del conjunto de datos afirma que existe una versión más precisa (pero no gratuita) ( 1:500000 contra. 1:3000000 ) de los datos. ¿Es posible que las inexactitudes debidas a la fuente de datos sean mayores que las debidas a la reproyección inexacta?

Answer 1

La definición de MGI_Austria_Lambert procede directamente del software de Esri. Tiene varias diferencias en las convenciones de nomenclatura, además de peculiaridades en los nombres de las proyecciones/parámetros. Algunos de ellos se remontan a versiones anteriores del Registro de parámetros geodésicos de la EPSG donde Esri no ha actualizado para que coincida con EPSG.

Esri tiene una palabra clave para la cónica conforme de Lambert y es posible definir tanto los casos de 1 paralelo estándar + factor de escala como los de 2 paralelos estándar . EPSG y Proj4 dividen los dos casos en implementaciones de cónicas conformes de Lambert "diferentes". Si se establecen paralelas estándar y/o un factor de escala, la proyección cónica conforme de Lambert se convierte en un caso secante. Es decir, el "cono" corta la superficie del elipsoide, reduciendo así la distorsión causada por la proyección.

La diferencia de unidades de CRS geográficas en los valores de conversión de grados/radianes es irrelevante. Esri solía utilizar la versión más larga, pero cambió a la más corta para ajustarse mejor a los límites de la doble precisión. Las diferencias de coordenadas debidas a los distintos valores son menores que la precisión habitual de los datos.

Creo que la diferencia en las coordenadas de salida se debe a que no se produce ninguna transformación geográfica/de fecha entre MGI y WGS 1984. Si ogr2ogr es early-binding (es decir, tiene una transformación por defecto configurada para MGI-WGS84), puede que no se llame porque los nombres de Esri para el geoCRS y el datum de MGI no coinciden con los de ogr2ogr. O tal vez la transformación debería incluirse en la definición de WKT. No lo sé.

Divulgación: Trabajo para Esri y estoy en el subcomité que mantiene el Registro de Parámetros Geodésicos de la EPSG.