I just read the following in a QGis blog post.
+datum=nad27 will look up all north American datum shift values from conus and other grid shift files. This overrides any
+towgs84 parameter set, as long as you are inside the area of grid file definition."
And, if I drop the +datum=NAD27 and leave the ellipse, the +towgs84 values start making an impact using the mygeodata website you provided.
So, that explains why the results are always the same, but not why the answers are different. I am curious about the grid shift files. As far as I know, the proj4 distribution in Mapsuite doesn’t have any conus shift files packaged… Maybe that’s the issue is it reverts to some other method when it can’t find what it wants.
As far as my test point, that’s another mystery. I loaded a shape in WGS84 and then changed the project projection to NAD27 15N at which point it asked me for the transform (as above). The value I sent you was the value of the point of interest from the shape on the screen after the conversion completed. I get the same result as you using the python editor, so let’s assume that is correct and just focus on why Mapsuite gives different result.
One other observation - If I drop the +datum=NAD27 in the python editor and run it again, I get the same result as Mapsuite along with an error as follows. I have no idea why QGis is asking for grid files when we say we want to use a 3 parameter shift.
The preferred transform between EPSG:32615 - WGS 84 / UTM zone 15N and EPSG:2027 - NAD27(76) / UTM zone 15N is not available for use on the system.
- This transformation requires the grid file “May76v20.gsb”, which is not available for use on the system.
Current transform “Inverse of UTM zone 15N + Ballpark geographic offset from WGS 84 to NAD27(76) + UTM zone 15N” has an unknown accuracy, while the preferred transformation “Inverse of UTM zone 15N + Inverse of NAD27(76) to WGS 84 (1) + UTM zone 15N” has accuracy 1 meters.