ArcGIS-ESRIMapsCadastre

Geobide, ED50 and ETRS89 Coordinate System Transformation

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.

ED50 and ETRS89 geobide

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:

  1. Generic Transformation:ED50 and ETRS89 geobide

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.  

  1. 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.

ED50 and ETRS89 geobide

Many grids can be found on the Internet, even worldwide, but by size they are not automatically available in the Geobide application downloads.

  1. 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.

ED50 and ETRS89 geobide


  1. 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.

ED50 and ETRS89 geobide

Result

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.

ED50 and ETRS89 geobide

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.

ED50 and ETRS89 geobide


PRJ File Nomenclatures

ED50 and ETRS89 geobideAnd 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.

 

http://www.geobide.es/

Golgi Alvarez

Writer, researcher, specialist in Land Management Models. He has participated in the conceptualization and implementation of models such as: National Property Administration System SINAP in Honduras, Management Model of Joint Municipalities in Honduras, Integrated Cadastre-Registry Management Model in Nicaragua, Territory Administration System SAT in Colombia . Editor of the Geofumadas knowledge blog since 2007 and creator of the AulaGEO Academy that includes more than 100 courses on GIS - CAD - BIM - Digital Twins topics.

Related Articles

Leave a comment

Your email address will not be published. Required fields are marked with *

Back to top button