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 takes; However, in many countries, states or autonomous communities, public institutions have provided GoogleEarth with their images with precise georeference, 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 all on its own definition but also on the area in which we find ourselves. That is why the generic systems do not provide the special parameters of each zone.
Let's take as an example the transformation ED50-30N (EPSG: 23030) to ETRS89-30N (EPSG: 25830) for Navarra, and for Spain. The generic definition of the transformation has a different degree of precision depending on the area in which it is applied. For this reason, there are some extra parameters, which do not go in the generic definition and which in Navarra for example are some but in Asturias they may have other different values.
If we look at the image above captured from Geomap, we see a map with two layers (orthophoto and parcel) moved relative to each other. It is the result of projecting on the fly the Cadastre of Navarra in ED-50N on a layer of GoogleMaps in WGS84 and the resulting offset is related to the problem described in the previous paragraph.
A recent Geobide tutorial, from which we are doing this article now publishes at least 4 methods to fix it,. With Geobide, it is now possible to indicate the datum conversion for a transformation between Coordinate Systems in four different ways:
-
Generic Transformation:
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 They now offer the two grids provided by the IGN for Spain, covering the Peninsula and the Balearic Islands, and which were published in 2003 and 2009. The user can easily choose the grid to use.
Many grids can be found on the Internet, even worldwide, but by size they are not automatically available in the Geobide application downloads.
-
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.
Results
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.
For example:
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.
