Remove support for proj_def.dat

[proj4-bot]

Reported by ysid on 10 Dec 2012 17:26 UTC
This is a suggestion for PROJ4. Please refer to OSGeo ticket 320 for background:

http://trac.osgeo.org/osgeo4w/ticket/320

Essentially, the issue is that the default parameters in proj_def.dat can cause problems for folks who use PROJ4, OSGeo, GDAL, etc. When defaults are used in software, they should be used judiciously. In this case, it is not judicious to default to a conterminous US projection, when that is only one of hundreds of in-use Lambert conformal projections out there. On the other hand, the WGS84 ellipsoid default makes sense, because that is the most common ellipsoid used, and it's likely that someone using the PROJ4 library may forget to specify the ellipsoid.

It is also arbitrary to just specify defaults for two projections, and not for others.

The defaults can throw off users who do not know about the "+no_defs" parameter. Although it's wise to use "+no_defs" when unsure, it should not be a requirement to get a projection to work properly.

My suggestion is to remove the defaults for both the Lambert conformal conic and Albers equal area projections from the proj_def.dat file. A few users who rely on the defaults for the conterminous US projections may have a problem with this, but if this change is noted prominently, this would be ample warning.

Migrated-From: https://trac.osgeo.org/proj/ticket/201

[busstoptaktik]

This probably should have a go on the mailing list. I fully agree that it is a problem having to add +no_defs everywhere to get expected behaviour.

[kbevers]

I am in favour of getting rid of the defaults. To get an idea of the impact that would cause you can make a PR with the projection parameters removed from proj_def.dat and see if anything in the test suite fails.

[busstoptaktik]

Once upon a time, while this thread lived on trac.osgeo.org, ysid said:

On the other hand, the WGS84 ellipsoid default makes sense, because that is the most common ellipsoid used, and it's likely that someone using the PROJ4 library may forget to specify the ellipsoid.

No - not even this choice makes sense. GRS80 would make sense, since that is what is adopted by the IAG and IAU as the best fitting ellipsoid for the Earth. Unfortunately, the WGS84 ellipsoid differs by a minuscule amount.

Hence, there appears to be no arguments left for keeping proj_defs.dat. For backwards compatibility at the millimetre level, however, one could argue for having GRS80 (or perhaps the most recently agreed upon "best fitting") as default ellipsoid.

Pro forma PR #619 checks out a subset of the consequences by, as @kbevers suggests above, eliminating all actual info from proj_def.dat.

Let's get rid of proj_def.dat and hence, get rid of the necessity of numerous cases of +no_defs

[rouault]

I've just realized that proj_defs.dat is a terrible evil ! I have removed it in a branch, and I discovered it completely messed up LCC 1SP cases of EPSG and IGNF registries. Those use the "+proj=lcc +lat_0=X +lat_1=X" syntax, hoping that the code in lcc.cpp will consider lat_2 to be lat_1, but due to the lat_2=45 default in proj_def.dat, it turns out that the projection definition is completely messed up. I don't understand how it wasn't raised before !

[rouault]

I retract my previous comment. The EPSG and IGNF registries had the no_defs flag. The confusion came from projinfo generating pipelines without no_defs, and so this affected cs2cs that is now using it underneath (and I apparently modified the expected results of proj_outIGNF.dist thinking this was due to grid shift files not being used previously). But this is a good proof that this is a super dangerous feature. Working on a PR to remove it

[kbevers]

I don't understand how it wasn't raised before !

@busstoptaktik and I have been aware of that for quite a while but maybe our discussions of the matter has mostly been face to face. But as you can see in the history of this issue it has been a concern for a while. proj_defs.dat comes with a lot of surprises as you have just discovered.

Working on a PR to remove it

Awesome!