For example, zone UTM zone 12S in Google Earth Pro contains southern UT and AZ…
while in QGIS, zone 12S appears to be in the southern hemisphere. Probably a ridiculous question, but not quite sure what am I missing.
[GIS] Why do zones differ for WGS84 UTM in Google Earth Pro vs. in QGIS 3.4
coordinate systemgoogle earthqgis
Related Solutions
There are two things happening during this coordinate transformation: reverse projection (from x,y in meters to latlong) and datum transformation (from latlong in one datum to latlong in another datum). Now when the datum transformation properties are not fully known this whole datum transformation is skipped. This happens when no datum or to_wgs84 parameter is present.
When no transformation is selected in ArcGIS it skips the datum transformation, and interprets the latlong coordinates as being WGS84. The same happens in Google Earth, since the datum in the .prj file of a shapefile is usually not fully defined (not in the ESRI version at least, QGIS stores an additional fully defined .qpj file, according to OGC specifications).
The reason that in the end these untransformed coordinates are still different from interpreting them as WGS84 UTM 37N is that also the projection is dependent on the used ellipsoid. When the size of the ellipsoid is slightly different the conversion factor from degree to meter is also slightly different, giving a slightly scaled result.
Now to get the Google Earth/ArcGIS <None> behaviour in QGIS the proj4 string to be used should have an incomplete datum definition. By default all projections in QGIS are from EPSG and are fully defined, so a custom CRS should be added with incomplete parameters, like "+proj=utm +zone=37 +ellps=clrk80 +units=m +no_defs". Note that this always skips the datum tranformation, so it depends on the project CRS if it is displayed as wanted, in this case the display CRS should use the WGS84 datum.
To transform the shapefile to correct Adindan coordinates first convert it to WGS84 using an incomplete datum, and then back to Adindan using a fully defined datum. For example with ogr2ogr:
ogr2ogr -s_srs "+proj=utm +zone=37 +ellps=clrk80 +units=m +no_defs" -t_srs EPSG:32637 test_wgs84.shp test_adindan.shp
ogr2ogr -s_srs EPSG:32637 -t_srs EPSG:20137 test_adindan_correct.shp test_wgs84.shp
(Google Earth can also do the correct tranformation if the datum transformation parameters are fully known. If "TOWGS84[-166,-15,204,0,0,0,0]" is added to the datum definition in the .prj file it will do the datum transformation.)
UTM zone is one of sixty 6 degree wide bands numbered from west to east (1-60). It requires only a longitude value. Either of these Python expressions will work (the second slightly faster, but more obscure):
zone = int(longitude + 180.0) / 6 + 1
zone = int(longitude + 186.0) / 6
UTM Zone can also refer to one of 120 band segments (north and south), which would then require a longitude value and be represented as a string:
zone = str(int(longitude + 186.0) / 6) + ('S' if (latitude < 0) else 'N')
Even though it is not strictly part of a UTM zone designations, many also use the military grid reference system (MGRS) band designators to slice the 164 degrees of UTM-addressed meridians (from 80S to 84N) into mostly 8 degree tall bands, lettered 'C' through 'X' (skipping 'I' and 'O') -- the 'X' band is 12 degrees tall. MGRS uses 'A' and 'B' for south of 80S (west and east of the Prime Meridian, respectively) and 'Y' and 'Z' for north of 84N (similarly).
The following Python function takes a geometry parameter and generates a three character formatted string suitable as a rough spatial index hash based on MGRS (fixed-width, so 1X would be rendered 01X, and lexographic sorting is possible):
def calcMGRS(geom):
bandVals = "CDEFGHJKLMNPQRSTUVWXX"
if (not geom):
return '61B'
ddLon = geom.extent.XMin
ddLat = geom.extent.YMax
zone = int(ddLon + 186.0) / 6
if (ddLat >= 84.0):
band = 'Y' if (ddLon < 0.0) else 'Z'
elif (ddLat <= -80.0):
band = 'A' if (ddLon < 0.0) else 'B'
else:
band = bandVals[int(ddLat + 80.0) / 8]
return '{:02d}{:s}'.format(zone,band)
Note that this is different from the Esri utility, since it uses the upper-left corner of the geometry, not the centroid to identify the zone and band.
Generating a UTM spatial reference string would be simple enough, given the second code block (with direction). The trickiest part would be to extract GeogCS from the current map canvas.
Best Answer
There are 60 UTM Zones, each 6 degrees wide (about 700km at the equator), and stretching from 84 degrees North to 80 degrees South (the poles are reference with the Universal Polar Stereographic grid system). So the "UTM Zone" is technically just the number part (eg: 12), a long strip effectively from pole to pole, within which Eastings and Northings are defined in meters. The Northings are specified as either north or south of the Equator... in the north, the equator is zero meters. In the south, the equator is 10,000,000m.
Each zone is divided into "Latitude Bands", denoted by the letters shown in Google Earth. These are technically not part of UTM, but part of the closely related Military Grid Reference System (MGRS).
It looks like QGIS is showing you the N (north) and S (south) parts of Zone 12, while Google Earth is showing the "Band S" in Zone 12.
You can find a lot more information about the UTM grid system at these links:
https://www.maptools.com/tutorials/grid_zone_details
https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system