I have a shapefile that also contains a proj file that looks like so:


I want to convert this shapefile into a geojson like so:

ogr2ogr -f GeoJSON \
    -t_srs EPSG:4326 \

This fails with the following error message:

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

Changing the proj file to contain either PROJECTION["Lambert_Conformal_Conic_2SP"] or PROJECTION["Lambert_Conformal_Conic_1SP"] instead of Lambert_Conformal_Conic results in valid geojson files that seem to have the correct coordinates BUT the resulting coordinates differ in their 2nd or 3rd decimal places, e.g.,

LON               , LAT
16.526053978650904, 48.32876392574797


16.527168091786308, 48.32902755664574 

My questions are:

  1. Which one of the two (if any) is the correct result?
  2. Is there a intuitive explanation for the difference between Lambert_Conformal_Conic, ~_1SP, and ~_2SP that also a non-cartographer is able to understand.
  3. There is an inaccuracy in the value of the GEOGCS UNIT value in the proj displayed above compared to the value given for the respective projection at spatialreference.org. Is this the reason for the differences?
  4. The publisher of the dataset states that there is a more accurate (but non-free) version (1:500000 vs. 1:3000000) of the data. May it be that the inaccuracies due to the data source is bigger than the inaccuracies due to inaccurate re-projection?
  • 2
    Re 3: You're talking about differences in the seventeenth significant figure! That is of no consequence at all. (To get some intuition for how significant figures relate to precision, please see gis.stackexchange.com/questions/8650 .)
    – whuber
    Aug 20, 2014 at 22:44
  • Thanks for the reply. I could have guessed that this is of no consequence. See also mkennedy's answer. The link you provided is dead.
    – georg
    Aug 21, 2014 at 6:00
  • Thank you for pointing out the link problem. The address that you read there was correct all along, but the site took you to a 404. I fixed the problem by inserting a space after the URL.
    – whuber
    Aug 21, 2014 at 13:34

1 Answer 1


The definition for MGI_Austria_Lambert is straight from Esri software. It has several differences in naming conventions plus quirks in the projection/parameter names. Some of these date to older versions of the EPSG Geodetic Parameter Registry where Esri has not updated to match EPSG.

Esri has one keyword for Lambert conformal conic and it's possible to define both 1 standard parallel + scale factor and 2 standard parallel cases. EPSG and Proj4 split the two cases into 'different' Lambert conformal conic implementations. Setting standard parallels and/or scale factor turns the Lambert conformal conic projection into a secant case. That is, the 'cone' cuts through the ellipsoid's surface, thus reducing distortion caused by the projection.

The geographic CRS unit difference in the degree/radian conversion values is irrelevant. Esri used to use the longer version, but switched to the shorter one to better match double precision limits. Coordinate differences due to the different values are less than the usual data accuracy.

I think the difference in the output coordinates are due to no geographic/datum transformation occurring between MGI and WGS 1984. If ogr2ogr is early-binding (aka has a default transformation set up for MGI-WGS84), it might not be called because Esri's names for the MGI geoCRS and datum don't match ogr2ogr's. Or perhaps the transformation should be included in the WKT definition. I don't know.

Disclosure: I work for Esri and I'm on the subcommittee that maintains the EPSG Geodetic Parameter Registry.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.