Which coordinate system should a survey in India use?

UTM cuts the world into 6 degree strips, and the zone number is floor((longitude + 180) / 6) + 1. India's mainland runs from about 68 degrees 7 minutes east in Kutch to about 97 degrees 25 minutes east in Arunachal Pradesh, so the formula gives zone 42 at the western end and zone 47 at the eastern one. Six zones, north of the equator, which makes the EPSG codes 32642 through 32647.

The bands follow directly from the rule rather than from a list anyone has to maintain. Zone 42 is 66 to 72 degrees east and holds little more than western Kutch; zone 43 is 72 to 78 and carries most of the populated west; zone 44 is 78 to 84 and takes the eastern Deccan and the Gangetic plain; zone 45 is 84 to 90; zone 46 is 90 to 96, covering the north-east and the Andaman and Nicobar Islands; and zone 47 catches only the far tip of Arunachal. Which side of a six-degree line your site falls on is the whole question, and the UTM zone by city guide carries the zone, the code and the distance to the boundary for the places people actually ask about.

Each zone has a central meridian three degrees in from its western edge - 69, 75, 81, 87, 93 and 99 degrees east - where the scale factor is 0.9996. That deliberate under-scaling costs one part in 2500, or 40 cm per kilometre, on the central meridian itself; the scale climbs back through unity toward the zone edge, where at Indian latitudes it reaches roughly one part in 1500. For a drone site a few kilometres across, a single zone is right and nothing else needs discussing.

Where one zone is not enough - a pipeline, a transmission corridor, a state-wide or national dataset - EPSG:7755, WGS 84 / India NSF LCC, is the one modern grid that covers the whole country. It is a Lambert Conic Conformal with two standard parallels at 12.472955 and 35.1728044444444 degrees north, a false origin at 24 north and 80 east, and 4000000 m added on both axes. The EPSG entry names the conversion 'Survey of India Lambert' and sources it to ISRO's NNRMS Technical Report TR 122:2005.

George Everest defined his ellipsoid in Indian feet, not metres: a semi-major axis of 20922931.8 Indian feet and a semi-minor axis of 20853374.58, the figures that Bomford's Survey of India Professional Paper 28 of 1939 records. An ellipsoid defined in feet only becomes a number a modern library can use once somebody picks a foot-to-metre ratio, and India picked more than one.

The 1937 readjustment of the Indian triangulation adopted 0.30479841 metres per Indian foot, which turns Everest's axis into 6377276.345 m with an inverse flattening of 300.8017. That is the ellipsoid EPSG calls Everest 1830 (1937 Adjustment). After metrication the conversion moved to roughly 0.3047995 m - the EPSG unit record defines the Indian foot as 0.99999566 British feet against a British yard of 0.9144025 m - and the same 20922931.8 feet became 6377299.151 m, inverse flattening 300.8017255. That is Everest 1830 (1975 Definition).

The two differ by 22.806 m in the semi-major axis. Pakistan's 1962 definition lands at 6377301.243 m, and there are further variants for Malaysia and Brunei. None of this is a registry curiosity: software that silently picks the wrong Everest for your data produces coordinates that are plausibly wrong rather than obviously wrong, and nothing in the file says which one was meant.

For scale, WGS 84's semi-major axis of 6378137 m sits 837.849 m above the 1975 Everest figure. The Everest ellipsoid was fitted to the subcontinent and not to the planet, which is exactly why it fits India well and why it cannot be reconciled with a geocentric system by adjusting a number or two.

An ellipsoid is not a datum. The datum is where that ellipsoid is pinned to the ground, and in India it is pinned at Kalianpur, a station in Madhya Pradesh, in three successive versions: Kalianpur 1880, Kalianpur 1937 (EPSG:4144) and Kalianpur 1975 (EPSG:4146). Each uses a different Everest definition, and coordinates from one are not coordinates from another.

On top of those sit the India zones, a Lambert Conic Conformal with one standard parallel, divided by latitude. Zone I is north of 28 degrees north, with its origin at 32.5 north and a central meridian of 68 east. Zone IIa covers 21 to 28 north west of 82 east, origin 26 north, central meridian 74 east; IIb takes the same latitude band east of 82. Zone IIIa runs 15 to 21 north west of 82 east, IIIb takes the same band to the east, and zone IVa lies south of 15. On Kalianpur 1975 these six are EPSG:24378 through EPSG:24383.

Two details on those zones are worth knowing before you open a file. The scale factor is 0.99878641, which is a reduction of about one part in 824, or 1.21 m per kilometre - three times UTM's, because the zones are latitude bands rather than narrow longitude strips. And the false origin is imperial in disguise: the metric false easting of 2743195.5 m is exactly 3000000 Indian yards and the false northing of 914398.5 m is exactly 1000000 of them. The Kalianpur 1880 versions of the same zones are still published in Indian yards.

Older Survey of India topographic sheets are a third thing again. The department's own account is that before the National Map Policy of 2005 the topo sheets were on a polyconic projection and the Everest datum. That policy created two series: Defence Series Maps, classified, and Open Series Maps, which the Survey of India states are on UTM projection and WGS 84 datum. So a sheet's vintage, not its scale, tells you which world it belongs to.

This is the crux, and it is not a gap in your software. The Survey of India observed GPS at hundreds of old Great Trigonometrical Survey stations specifically to determine Everest-to-WGS 84 transformation parameters for the country, and uses them internally to convert old topo sheets into Open Series Maps. An ISPRS paper from IIT Roorkee states plainly that those values are not available to the user community, and that several conflicting sets circulate from other sources instead.

What the EPSG registry carries in their place is a military set. Kalianpur 1975 to WGS 84 (1), EPSG:1156, is three geocentric translations - 295, 736 and 257 metres - derived at 7 stations, sourced to the US Defense Mapping Agency's TR8350.2 of August 1993, scoped 'military survey', with a stated operation accuracy of 22 m and per-axis accuracies of 12, 10 and 15 m. The entry carries an explicit warning in the registry itself: care, the DMA ellipsoid is inconsistent with the EPSG ellipsoid, and the transformation parameter values may not be appropriate.

For Kalianpur 1937 the position is worse. EPSG:4144's area of use spans Bangladesh, India, Myanmar and Pakistan, but the transformations attached to it are for Bangladesh onshore and for Myanmar's Moattama area. There is no published EPSG path from Kalianpur 1937 to WGS 84 for mainland India at all. If a tool offers you one, it has borrowed a neighbour's parameters.

The size of the problem is easy to state. Those three translations have a length of about 834 m, which is how far the Kalianpur 1975 origin sits from the earth's centre of mass under that model. The ground displacement between Everest coordinates and WGS 84 coordinates is of that order - hundreds of metres. Treat one as the other and your survey does not look slightly off; it sits in the wrong village. The failure that is harder to catch is the quiet one: applying the DMA set anyway, on a job specified to 5 cm, and shipping a 22 m uncertainty under a centimetre label.

The coordinate converter here runs proj4 in your browser and carries EPSG:7755 and all 120 UTM zones in its local registry, so WGS 84 to zone 43N or to India NSF LCC is a pure in-page calculation with no network call and nothing uploaded. That covers the recommendation above end to end.

It does not carry the Kalianpur systems locally. Typing EPSG:4146 or EPSG:24378 into the picker offers to look the code up on epsg.io, which is a network request to a third party - the only one the tool makes, and it fetches a definition rather than sending your coordinates. Say plainly that you are comfortable with that before you use it on client work.

Even when the definition arrives, it brings the DMA translations with it, warning and all. proj4 can apply three-parameter shifts and nothing better: grid-based datum shifts need a binary grid file too large to load client-side, which is the same limit that stops this site doing NTv2 anywhere else. If your contract needs Everest coordinates to survey tolerance, that work belongs with a licensed surveyor holding Survey of India control, not in a browser tab.

Everything above is horizontal. The vertical datum is an independent choice and the more expensive one to get wrong, because a horizontal error is visible the moment someone drops the data on a basemap and a vertical one is not.

A GNSS receiver, and therefore an RTK drone, gives you height above the WGS 84 ellipsoid. India's levelling network and every contour, drainage design and flood study reference mean sea level instead, and the two differ by the geoid undulation, which is negative across the whole subcontinent. A global model such as EGM96 or EGM2008 will get you close enough for navigation and not close enough for a deliverable.

The practical route in India is to tie the survey to a published Survey of India benchmark rather than trusting a global geoid, and to write both datums into the handover. The detail - what the geoid is, which of your drone's three altitude fields is which, and why this error survives review - is covered in full on the ellipsoidal height versus mean sea level guide on this site.

Capture in WGS 84. It is what the aircraft and the base station produce, it is unambiguous, and it does not bake a projection or an unpublished datum shift into the archive. Keep the raw positions.

Deliver in the UTM zone that covers the site, or in EPSG:7755 if the extent crosses zones. Name the code, not the family: 'EPSG:32644' says something, 'WGS 84' does not say whether you mean degrees, UTM or a Lambert grid.

Tie heights to a Survey of India benchmark and state the vertical datum next to the horizontal one. Two lines in a readme prevent the most common reprocessing bill in drone survey.

If the client insists on an Everest or Kalianpur deliverable, make the transformation their input rather than your assumption. Ask which Everest definition, which Kalianpur realisation, which zone, which units, and which parameters - and ask them to supply the parameters in writing. If they cannot, the honest answer is that no public set exists with the accuracy their drawing implies, and the deliverable should be agreed in WGS 84 with control points listed in both systems.

Before any of that, check your own flight. The metadata viewer on this site reads EXIF and XMP from your images in the browser, including GPS position, RTK or PPK status and the altitude fields, and exports the photo positions as CSV, KML or GeoJSON so you can see where the aircraft thought it was. Nothing is uploaded. Then put a coordinate from it through the zone finder to confirm the zone before anyone starts processing.