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

Comments

Projects
None yet
4 participants
@proj4-bot
Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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.4 that referenced this issue Dec 27, 2018

rouault added a commit to rouault/proj.4 that referenced this issue Dec 27, 2018

@kbevers kbevers closed this in a4d389c Dec 27, 2018

kbevers added a commit that referenced this issue Dec 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.