Comments (6)
I'm impressed that it is that close. This comes down to the definition of the UTM projection has changed in PROJ.4.
So PROJ.4 (which pyproj is built atop) takes this line of code:
prj_obj_26916_from_epsg = pyproj.Proj("+init=EPSG:26916")
It has a lookup in epsg and creates finds this proj4 string:
# NAD83 / UTM zone 16N
<26916> +proj=utm +zone=16 +datum=NAD83 +units=m +no_defs <>
The proj4_str
that you show above from pycrs results in the proj4_string:
+proj=tmerc +datum=NAD83 +ellps=GRS80 +a=6378137.0 +f=298.257222101 +pm=0.0 +lat_0=0.0 +lon_0=-87.0 +x_0=500000.0 +y_0=0.0 +units=m +axis=enu +no_defs
I replaced +proj=tmerc
with etmerc, I get the first result that show. This is because PROJ.4 version 4.9.3 changed UTM projection algorithms from tmerc to etmerc (OSGeo/PROJ#316). At some point, PROJ.4 may change the definition of tmerc
to be the same as etmerc
, but I wouldn't hold my breath.
from pycrs.
Glad to hear you find it useful @zhiyuli. I'm just going to have to concur with @micahcochran, and props for keeping up with the latest on proj4.
So if I understand correctly, PyCRS uses the old way of referring to utm (tmerc)? How recent was this change and do you recommend that we change to the newer etmerc or stick with the old?
from pycrs.
@karimbahgat I found out about this when I was creating the GIGS testing framework for Proj4.
That is correct. etmerc
and tmerc
are algorithms for Transverse Mercator projections.
Proj4 version 4.9.3 was released 2016-08-22, which made UTM use the etmerc
version. The issue was raised in 2015-10-06. Their change was based on a report by the US National Geospatial Inteligence Agency on 2014-03-25. etmerc
algorithm was added to Proj4 release 4.8.0 (source), which was released 2012-03-07.
The WKT itself doesn't not specify the method/algorithm used to reproject data. The WKT only specifies that the coordinates stored in Transverse Mercator projection. tmerc
and etmerc
both give valid results.
I don't know if there is enough information in the WKT to say that this is a +proj=utm
. Another problem is that other spatial reference systems use the tmerc
algorithm. I'm not sure if it is fair to those countries geospatial authorities to do an algorithm shift. Even the utm
algorithm switch has already changed that algorithm around the world.
I haven't really thought through the right coarse of action.
from pycrs.
@micahcochran, thanks for the details. So since this is essentially a very recent legacy/incompatability issue, there is no clear solution of switching to the new etmerc method or sticking with the old tmerc, as this might lead to unexpected changes for projection definitions written before or not agreeing with the recent USGS recommendation.
Perhaps the best solution in this scenario is to let the user set a function arg or library constant deciding whether to use the old or new algo, defaulting to the old..
To be clear though, algorithms aside, setting the proj4 +init=utm is simply a shorthand to allow you to specify more easily w the +zone arg, but is functionally equivalent to using +etmerc with all the additional args (as was produced by pyproj)? Is this all that differentiates the utm projection from ordinary trans merc? This makes me wonder too, i cant remember taking into account utm zones when i wrote pycrs...
from pycrs.
@karimbahgat Everything you have stated is correct.
What you propose seems like a good solution.
from pycrs.
Assigning this to myself to add the extra arg to choose between old or new.
from pycrs.
Related Issues (20)
- Exception: The specified projection name 'Mercator_Auxiliary_Sphere' could not be found HOT 7
- Exception: The specified projection name 'Meter' could not be found HOT 3
- Exception: 'Unknown' object has no attribute 'metermultiplier' HOT 1
- Support 'Lambert_Conformal_Conic_2SP' HOT 2
- Support loading from prj2epsg.org HOT 4
- Why can't parse 3857? HOT 4
- Why can't parse 3857? HOT 2
- How to parse '{"proj": "aea", "lat_1": 25, "lat_2": 47, "lat_0": 0, "lon_0": 105, "x_0": 0, "y_0": 0, "datum": "WGS84", "units": "m", "no_defs": true}' HOT 9
- Point transform issue HOT 12
- Update to epsg.io as the source for crs codes HOT 2
- BUG: proj4 parser is case sensitive HOT 1
- CRS equality operator HOT 1
- How to get EPSG code from Shapefile? HOT 11
- Error in proj4 format in conversion from WKT to Proj4
- Parser issue
- Unable to get projection from EPSG HOT 1
- prj2epsg.org seems out of service HOT 2
- the specified projection name 'Gauss_Kruger' could not be found in the list of supported projections HOT 3
- Add CF projection conversion
- Release as Python 3 source wheel on PyPI? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pycrs.