CS-MAP, a leading open source coordinate reprojection library, is becoming more standards compliant. In its upcoming v13 release (and current development branch), CS-MAP’s approach to datum transformation and axis ordering more closely matches EPSG’s. I think this is a good thing for interoperability and wanted to take a moment to reflect on the changes.

Why Does Coordinate Reprojection Matter?
The most fundamental problem in computer mapping is associating real world locations with coordinates, a prerequisite for everything from map display to complex analysis. In general, every map has a coordinate system which captures how this was done. There are a huge number of coordinate systems in use, and there is a need to convert between them e.g. to combine data or present it appropriately. FME uses CS-MAP for this purpose by default, and also works with a number of alternatives including ArcGIS, some national software packages, and includes an extension framework to plug in others.

Datum Shifts: More Choice, No More WGS84 Pivot
A coordinate system is typically comprised of a projection (how to flatten the map) and a datum (how to model the earth and map real locations to e.g. latitude/longitude), and it’s this second part that is most challenging to account for when converting between coordinate systems. As previously discussed, there are a number of different approaches, and traditionally CS-MAP has used the concept of a pivot datum: Each datum defines a single conversion to/from WGS84 (the GPS datum) and every datum transformation goes via WGS84. While simple and great for usability, this breaks down when (a) it isn’t appropriate to use WGS84 as an intermediate datum, or (b) when there are multiple ways to transform to between two datums that are valid in different situations. CS-MAP is changing to use a model closer to EPSG and ArcGIS, and will no longer depend on the WGS84 pivot nor force the selection of a single transformation for each pair of datums.

Axis Order: Juggling De Facto and De Jure
There is an interesting tension in the GIS industry around axis order. Most GIS software and formats assume geographic coordinates will be recorded exclusively as longitude/latitude, while the relevant standards implicitly (and increasingly explicitly) require conformance with latitude/longitude definitions. A common example: GIS software might refer to a coordinate system as EPSG:4326 (lat/long WGS84) but store coordinates as (long/lat).

CS-MAP continues to follow the long/lat convention — essential to maintain interoperability — but will now include information about the standards-compliant axis orders. This will make it easier to work with CS-MAP in conjunction with those formats that have made the switch, e.g. WMS, WFS, and GML.

Reflection
While CS-MAP is only one of a number of options, these updates highlight an ongoing, slow trend towards standardization. More interestingly, the datum shift changes suggest the industry may be moving from “just do the right thing” (choose the datum shift for me) to “the details matter” (force me to pick the right datum shift) experiences for coordinate reprojection.

What do you think? If you work with data in different coordinate systems, are you using user interfaces that try to “do the right thing” and stay out of your way? Or, are you using interfaces that force (allow) you to consider the details? (Hybrids, where an expert configures software once and then others users see limited options, also exist.) I can imagine success or disaster stories resulting from either approach; why don’t you share yours?

About Data Coordinate Systems Interoperability Open Source Transformation

Paul Nalos

Comments

6 Responses to “Moving to Standardization in Coordinate Reprojection: CS-MAP, Datum Shifts, and Axis Order”

  1. Martin Desruisseaux says:

    Those changes in CS-Map are very welcome! But just to let know what were done in alternative software, I would like to mention that datum shift without WGS84 pivot and authority-compliant axis order are implemented in Geotoolkit.org/GeoTools (admittedly less known libraries) for approximately 10 years. At that time, they were debate about the value of supporting arbitrary axis order and not many libraries followed that path. The situation evolved since then.

    About datum shifts, the EPSG database seems to care a lot about details. In addition to specifying the Bursa-Wolf parameters used for datum shift, it also specifies the method to use: Molodensky, Abridged Molodensky or Geocentric translation (all those methods could be interchanged – using the same parameters – and produce somewhat close numbers). However I have not yet meet any user outside mapping agencies concerned about the exact method used. Maybe the situation will evolve – like the axis order situation evolved – when requirements for centimetric precision will be more common…

  2. Paul Nalos says:

    Hi Martin,

    Thank you for the Geotools and Geotk references; I’m less familiar with the Java side of the open-source reprojection space. A little bit of digging reveals flexible axis-order handling in both libraries. I had a harder time finding examples where the datum shift transformation is explicitly specified, but don’t doubt it’s possible. I’m most interested in GIS applications built on these libraries that explicitly expose the datum shift choice; are you aware of any? For example, I installed uDig (based on Geotools) for the first time and couldn’t find that functionality.

    With regard to choosing between near-synonyms for datum shift algorithms (e.g. Bursa-Wolf vs. Helmert, Molodensky vs. Geocentric), I think the main (significant!) benefit is ensuring repeated transformations don’t needlessly distort data. EPSG is a fantastic resource for absolutely unambiguous coordinate system and transformation metadata, and I refer to their “Coordinate Conversions and Transformation including Formulas” guide often.

  3. Uta Griwodz says:

    In Europe the INSPIRE guidelines require the delivery of data based on the datum ETRS89. Most of the existing spatial datasets refer to different local datums e.g ED50, DHDN, NTF,…
    So datum conversion in Europe is very important the moment and in the near future.

    If you have a look at the transformation approaches and parameters of all different European countries on http://www.crs-geo.eu, you see, that several of the countries have several transformations between their local datum and ETRS89. So there is a need to choose between several datum conversions. In many cases it’s not possible that FME can do the “right” conversion automatically based just on the information about the coordinate system of the source and target data.

    In Germany we have the situation that all the existing datasets need to be converted from DHDN to ETRS89.
    Dependent on the quality and the scale the spatial data refer to, different datum conversion approaches have to be used.
    For topographical data (scale 1:5000 and smaller) a ntv2-method (grid-file BeTA2007) has to be used which is implemented in FME.

    For less accuracy exist several 7-parameter-conversions based on the parameters from the official state department (BKG, Bundesamt für Kartographie und Geodäsie). The most inaccurate and oldest 7-parameter-version of the BKG is implemented in FME. The accuracy is only about 5m.
    It’s even more complex with large scale data (e.g. 1:1000 and greater). There are different approaches used in the different federal states in Germany. Some are working with special grid-files for NTv2 and some have implemented their own transformation programs. Some of these special transformation programs are integrated in FME as custom transformers. The special grid files for NTv2 can be used in FME instead of BeTA2007, the official grid for whole Germany.
    But in all cases it is necessary that the user knows about the details. It’s not possible to “do the right thing” just based on the source and target coordinate system, the user has to think about the appropriate conversion method and conversion parameters for his particular data.

    To answer your question about other programs. As far as I know:
    Smallworld does the same as CS_Map did before: they define WGS84 as “root-system”.
    In MapInfo it’s done in a comparable way as now in FME.
    ArcGIS, as you know, chose the other way: there you have to choose the appropriate datum conversion from a list.

    I agree with you, that success or disaster stories result from either approach.
    The problem is, that the reason for the datum conversion and the different approaches for the conversion are really difficult to understand.

    My favorite is the ArcGIS approach, where you have to choose between the different datum conversions connected to one source and one target datum. My opinion is that this is the best model for the situation and it forces the user to think about the conversion method he uses.

  4. Paul Nalos says:

    Uta – Thank you for this wonderfully detailed summary of the situation in Germany. The DHDN to ETRS89 datum shift is a good example of a common, high value transformation that requires users to really know what they are doing.

  5. Roel Nicolai says:

    I discovered this discussion a bit late, but would still like to repsond. I am a member of the Geodesy Subcomittee of IOGP, which publishes and maintains the EPSG dataset and was closely involved with the development of its data model, ISO 19111.
    It is good news that there appears to be a move to standardisation, part of which concerns the axes order. Axes order is included for good reasons in the ISO model: in a large number of countries grid coordinates are provided in the order Northing, Easting. Quite important to know that for interoperability reasons. ISO 6709 specifies the order latitude, longitude for geographic coordinates, which is why the EPSG dataset specifies that order. After the long debate on this issue in OGC it was agreed that OGC would set up its own namespace with its own codes, one them describing WGS 84 with axies order longitude, latitude. They have done that; I couldn’t connect to their website to provide you the URL, but it’s there.

    Regarding coordinate transformations – if you care about standardisation you shouldn’t call them datum conversions or datum shifts! – it is good that CS-MAP has abandoned the ‘hub’ concept with WGS 84 being the hub or root. A more important concept is acknowledging that there may be multiple coordinate transformations between any pair of of coordinate reference systems. Uta describes that very well in her response.

    The “Reflection” section of the blog states that:
    …”More interestingly, the datum shift changes suggest the industry may be moving from “just do the right thing” (choose the datum shift for me) to “the details matter” (force me to pick the right datum shift) experiences for coordinate reprojection.”
    That is good news as well, but I really disagree with the way it is described. To describe something as going from “doing the right thing” toward “details” will put off most users. I for one wouldn’t like to be associated with losing myself in details when the right thing is already done! (that’s not what is actually written, but it risks being interpreted that way). The key thing is that the “old” way of modelling coordinate transformation, viz as part of, or at least joined at the hip with, the coordinate refrence system does not describe geodetic reality well (as Uta describes for Germany). Sticking to one predefined coordinate transformation does not mean the right thing is done; it may simply be the wrong transformation for the circumstances.
    ArcGIS is doing the right thing in part: it offers the user the option to choose the transformation, but unfortunately does not provide help to that user in picking the right one. Blue Marble Geographic Calculator (not a GIS, I know) preselects a subset of transformations based on the area of validity, also stored in the EPSG dataset.
    Despite my critical comments: good news!!

  6. Paul Nalos says:

    @Roel – Thanks very much for your detailed response.

    I agree that getting axis order right is critical for interoperability, and efforts like OGC’s “urn:ogc:def:crs:OGC:1.3:CRS84” are a step in the right direction. I also like GeoJSON’s approach, where they allow references to coordinate systems but explicitly override the coordinate order (http://geojson.org/geojson-spec.html#coordinate-reference-system-objects). From my perspective we’re on a journey from standards that underspecified axis order (or whose implementations ignored those aspects), to updated standards that are more explicit and are being increasingly adopted.

    Since this post, there has been growing awareness of the need to carefully consider coordinate transformation(s) when working with coordinate systems based on different datums. I agree that tools that make it easier to choose correctly provide great value. Our product, FME, has made some advancements in this area, and those that wish to use Blue Marble’s library within FME have that option as well (https://www.safe.com/solutions/specialty/bluemarblereprojector/).

Leave a Reply

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

Related Posts