Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove support for proj_def.dat #201

Closed
proj4-bot opened this issue May 22, 2015 · 6 comments
Closed

Remove support for proj_def.dat #201

proj4-bot opened this issue May 22, 2015 · 6 comments
Assignees
Milestone

Comments

@proj4-bot
Copy link

@proj4-bot proj4-bot commented May 22, 2015

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
Copy link
Member

@busstoptaktik busstoptaktik commented Oct 18, 2017

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
Copy link
Member

@kbevers kbevers commented Oct 18, 2017

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
Copy link
Member

@busstoptaktik busstoptaktik commented Oct 20, 2017

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

@busstoptaktik busstoptaktik self-assigned this Oct 25, 2017
@kbevers kbevers added this to the 6.0.0 milestone Mar 5, 2018
@kbevers kbevers changed the title PROJ4 projection defaults cause more problems than they solve Remove support for proj_def.dat Mar 5, 2018
@rouault
Copy link
Member

@rouault rouault commented Dec 27, 2018

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
Copy link
Member

@rouault rouault commented Dec 27, 2018

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
Copy link
Member

@kbevers kbevers commented Dec 27, 2018

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!

rouault added a commit to rouault/PROJ that referenced this issue Dec 27, 2018
rouault added a commit to rouault/PROJ that referenced this issue Dec 27, 2018
…ication (refs OSGeo#201)
@kbevers kbevers closed this in a4d389c Dec 27, 2018
kbevers added a commit that referenced this issue Dec 27, 2018
Remove proj_def.dat (#201)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants