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

EPSG/ESRI 37203 corrections (missing towgs84!) #49

Open
klokan opened this issue Jun 10, 2014 · 0 comments
Open

EPSG/ESRI 37203 corrections (missing towgs84!) #49

klokan opened this issue Jun 10, 2014 · 0 comments

Comments

@klokan
Copy link
Member

klokan commented Jun 10, 2014

This may be a problem of other from Proj4 ESRI derived systems in the EPSG.io database. May be solved properly by #24

Reported by:
[Dr.Sharad Lele, Senior Fellow, ATREE www.atree.org]
[email protected]

EPSG 37203 (or ESRI 37203) corresponds to GCS Everest India Nepal, which refers to Everest 1956 spheroid and India_nepal datum. This spheroid-datum combination is used in Survey of India toposheets of the 1960-2000 period.

The problem is that the proj.4 specification of 37203 is incomplete. It only specifies:

+proj=longlat +a=6377301.243 +b=6356100.230165384 +no_defs ...........................[1]

This implies there is no displacement of the datum with respect to the WGS84 centre of earth. But in fact, the India-Nepal datum is displaced significantly w.r.t WGS84. The displacement values are given in various documents (one such document is attached--search for Nepal). Accordingly, the correct proj.4 specification of this spheroid-datum combination would be:

+proj=longlat +a=6377301.243 +b=6356100.2284 +towgs84=295.00,736.00,257.00,0,0,0,0 +no_defs ...................... [2]

[PERHAPS a more accurate representation would be

+proj=longlat +a=6377301.243 +b=6356100.2284 +towgs84=295.00,736.00,257.00,12.00,10.00,15.00,7.00 +no_defs ............. .[3]

I am not sure about this].

As you know, QGIS software uses the proj.4 definitions directly. I have experimented in QGIS with using just 37203 as it is to geo-rectify scanned toposheets. But this results in the geo-rectified toposheet being displaced from its correct position by about 200meters. When i use my 'corrected proj.4 specification' [2], the geo-rectified toposheet sits perfectly in position. I have tested this with several toposheets and the same thing happens.

I hope I am making my point clear. I am not an expert on projections or GIS software as such, but I have over many years figured out how to correctly geo-rectify Indian toposheets. When I was using ERDAS Imagine to do this, I was explicitly defining the 'reference projection system' as "Geographic lat-long with Everest 1956 spheroid and India-Nepal datum", and things worked just fine. When I shifted to QGIS, I noticed this problem (because QGIS uses the proj.4 definitions), and so I thought of bringing it to your notice.

I would be happy to correspond further if any clarifications are required.

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

No branches or pull requests

1 participant