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

Support numerical factors only #664

Merged
merged 6 commits into from Nov 15, 2017

Conversation

Projects
None yet
2 participants
@busstoptaktik
Member

busstoptaktik commented Nov 13, 2017

Support for the "special" entry of PJ, which enabled PROJ.4 to compute analytically derived, rather than numerically approximated, values for a. o. scale factors and convergence, was limited to the PJ_lcc.c and PJ_eqdc.c projection implementations.

And for the past 20 years, the need for that functionality has not been so huge as to animate anyone to implement it for more than those two projections - so the need is apparently limited.

It could even be argued that it is more relevant to get the numerical approximation for the actually implemented algorithm, than the analytically derived values for the mathematical abstract version.

Removing the feature simplifies the code a bit, and also reduces the documentation needed to be written a comparative bit.

Note: This PR does not touch the availability of the convergence, etc. computations - it just results in treating all projections equal, by using numerical approximation even in those two cases that formerly provided analytical versions.

@busstoptaktik busstoptaktik self-assigned this Nov 13, 2017

@kbevers

This comment has been minimized.

Show comment
Hide comment
@kbevers

kbevers Nov 14, 2017

Member

Have you tested how the analytical and numerical calculations compare?

Member

kbevers commented Nov 14, 2017

Have you tested how the analytical and numerical calculations compare?

@busstoptaktik

This comment has been minimized.

Show comment
Hide comment
@busstoptaktik

busstoptaktik Nov 14, 2017

Member

@kbevers : they are indiscernible to within the number of decimals provided by proj.exe:

$ echo 12 55 | bin\proj -S  +proj=lcc +ellps=GRS80
794682.65       6469768.20      <1.03785 1.03785 1.07714 0.000285335 1.03785 1.03785>   

$ echo 12 55 | proj -S  +proj=lcc +ellps=GRS80
794682.65       6469768.20      <1.03785 1.03785 1.07714 0.000285335 1.03785 1.03785>   

$ echo 12 55 | proj -S  +proj=eqdc +lat_1=45 +ellps=GRS80                       
858340.13       6130795.52      <1 1.11887 1.11887 6.43214 1.11887 1>                   
                                                                                    
$ echo 12 55 | bin\proj -S  +proj=eqdc +lat_1=45 +ellps=GRS80                  
858340.13       6130795.52      <1 1.11887 1.11887 6.43214 1.11887 1>                   

(bin\proj is the numerical version, proj is the older supporting analytical)

Member

busstoptaktik commented Nov 14, 2017

@kbevers : they are indiscernible to within the number of decimals provided by proj.exe:

$ echo 12 55 | bin\proj -S  +proj=lcc +ellps=GRS80
794682.65       6469768.20      <1.03785 1.03785 1.07714 0.000285335 1.03785 1.03785>   

$ echo 12 55 | proj -S  +proj=lcc +ellps=GRS80
794682.65       6469768.20      <1.03785 1.03785 1.07714 0.000285335 1.03785 1.03785>   

$ echo 12 55 | proj -S  +proj=eqdc +lat_1=45 +ellps=GRS80                       
858340.13       6130795.52      <1 1.11887 1.11887 6.43214 1.11887 1>                   
                                                                                    
$ echo 12 55 | bin\proj -S  +proj=eqdc +lat_1=45 +ellps=GRS80                  
858340.13       6130795.52      <1 1.11887 1.11887 6.43214 1.11887 1>                   

(bin\proj is the numerical version, proj is the older supporting analytical)

@busstoptaktik busstoptaktik merged commit 7aeb1fb into OSGeo:master Nov 15, 2017

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.1%) to 73.051%
Details

@busstoptaktik busstoptaktik deleted the busstoptaktik:not-so-special branch Nov 15, 2017

int code; /* always 0 */
};
enum deprecated_constants_for_now_dropped_analytical_factors {

This comment has been minimized.

@kbevers

kbevers Nov 15, 2017

Member

I may have missed something, but why are these necesary still?

@kbevers

kbevers Nov 15, 2017

Member

I may have missed something, but why are these necesary still?

@busstoptaktik

This comment has been minimized.

Show comment
Hide comment
@busstoptaktik

busstoptaktik Nov 15, 2017

Member

@kbevers, they are necessary still because user programs may be checking them. By ensuring that fac->code==0, these programs will still get the right answer, that "these factors were computed numerically"

Member

busstoptaktik commented Nov 15, 2017

@kbevers, they are necessary still because user programs may be checking them. By ensuring that fac->code==0, these programs will still get the right answer, that "these factors were computed numerically"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment