Taking advantage to follow the Capabilities of the Geobide Suite, We will see the options to transform Reference Systems. Interesting for those who need to transform between different Datum, in this case we will see how to do it with the systems ED50 and ETRS89 which is almost the same case in Latin America between NAD27 and WGS84.
Are the data moved?
This is not the case of Google Earth, where more transformations are made, the many images are displaced, something that can be checked in overlaps between different shots; however in many countries, states or autonomous communities public institutions have provided GoogleEarth with accurate georeference images, with the disadvantage that GoogleEarth uses WGS84 as a generic Datum, so using data in another system requires a transformation. The transformation depends first of its own definition but also of the zone in which we are. That is why generic systems do not provide the special parameters of each zone.
Let's take the ED50-30N (EPSG: 23030) transformation to ETRS89-30N (EPSG: 25830) for Navarre as well as Spain for example. The generic definition of the transformation has a different degree of precision depending on the area in which it is applied. Therefore there are some extra parameters, which do not go in the generic definition and that in Navarra for example are some but in Asturias can have other values.
If we look at the captured image above of Geomap, we see a map with two layers (orthophoto and plot) moved between them. It is the result of projecting the Cadaster of Navarre on the flight in ED-50N about a layer of GoogleMaps in WGS84 and the resulting offset is related to the problem described in the previous paragraph.
A recent tutorial from Geobide, from which we are doing this article now publishes at least 4 methods to solve it,. With Geobide, it is now possible to indicate the datum conversion for a transformation between Coordinate Systems in four different ways:
This option uses generic transformation without spatial parameters, and is the least precise. For Navarra for example moving from ED50 to ETRS89 has an error of ~ 100-200m in x and y. (Remembering that this does NOT affect coordinate systems with equal datum).
Very similar is the case of NAD27 with WGS84 that walks as in 202 meters to the North and 6 meters to the east in the Central American zone, it changes as it changes the latitude, although it is only significant in the latitude as it comes from the equator while in the length just comes from the false east.
Transformation Using a Grid NTv2:
This option uses a grid with values to correct the conversion by linear interpolation. This option is more precise than the first method and has been adopted by the IGN. Precise, of course, if we have a grid for our work area.
The applications of Geobide now offer the two grids provided by the IGN for Spain, covering the Peninsula and Balearic Islands, and published in 2003 and 2009. The user can easily choose the grid to use.
On the Internet you can find many grids, even world-wide, but by size are not automatically available in the downloads of Geobide applications.
Molodensky transformation (method of 3-parameters):
3 uses offset values at the origin between ellipsoids. A pre-configured wizard recommended by the IGN exclusive dealer for Spain.
Bursa-Wolf transformation (method of 7-parameters)
This transformation uses 7 values to transform between ellipsoids. The parameters to be entered are: Offset (Dx, Dy, Dz), Rotation (Rx, Ry, Rz) and Scaling Factor (μ)
In the applications Geobide 3 wizards are pre-configured recommended by the IGN for the Northwest, Central Zone and East of the Peninsula, respectively.
As you can see the results do not vary much between the 3 latest methods, but yes with the first. That is why you must know if the transformation needs any of these advanced options.
Between the ED50-xxN (EPSG: 230xx) and ETRS89-xxN (EPSG: 258xx) systems of the Spanish zone should be used since the Datums / Elipsoides ED50 and the ETRS89 / WGS84 are not equivalent.
For example, if this advanced data is not configured in Geomap, the Navarra data in ED50-30N (EPSG: 23030) reprojected on the fly on the data provided by Google Maps (Elipsoide WGS84) will be moved. For them to look good, it is necessary to use the most precise transformations that have already been explained.
It seems to me very well that Geobide makes a significant effort not only to leave the capacities to his system, but also to document in a little more detail this question since it can affect a lot the quality and precision of the work, other than just to understand it too is another effort.
So far, all this was automatically integrated into the engine, but as Geobide's friends told us, the demands of users have led them to make it visible in the applications so that the user himself is aware of it and even changes the setting, or put another one for your own work zone.
Transformation of ellipsoidal / geoidal heights
In the new version, the ellipsoidal / geoid height difference calculation box has also been changed so that the user can now select the geoid model to be used.
PRJ File Nomenclatures
And finally, another change that seems right in your effort for interoperability with OGC standards or practices of popularized programs. The PRJ files that Geobide generates are in the OGC WKT nomenclature, which is a standard recognized by many CAD / GIS tools. Not so for ESRI applications, whose PRJ, although they contain the same mathematical definition as the standard ones, denominate the Coordinate Systems differently.
In the content of a PRJ file of the OGC, the ETRS89-30N system (EPSG: 25830) is defined with the code name "ETRS89 / UTM zone 30N"; the applications ESRI, instead, they call it "ETRS_1989_UTM_Zone_30N". If in ArcGis we mix layers with PRJs in the two nomenclatures this software will perform the spatial transformation even when the mathematical definition of the Coordinate Systems is identical.
Paying attention to this
stubbornness, Geobide has enabled a new option in the reference system selector so that the user can indicate if he wants a Coordinate System with a PRJ in EPSG style or style ESRI.