CRS

Jul 17 2024

Mastering Advanced CRS Conversions with Apache SIS

In the world of geospatial data, precise coordinate transformations are essential. Apache SIS is a powerful open-source library that can be used to perform a wide variety of coordinate operations. As described in our previous blog, How Apache SIS Simplifies the Hidden Complexity of Coordinate Systems in IVAAP, Apache SIS can pick the best conversion steps to use when converting points from one Coordinate Reference System (CRS) to another Coordinate Reference System, which can be useful in several different scenarios where a user does not know which conversion steps they want to use when converting from one CRS to another.

In this technical guide, we’ll dive into how to leverage Apache SIS to perform advanced CRS conversion with explicit control over each step. We’ll cover the four primary conversion steps, explore when to use each, and provide code samples to walk you through the process. Whether you’re dealing with projected or geographic coordinate systems, complex transformations, or the need for intermediate CRS like WGS 84, this guide will help you master these CRS conversions with Apache SIS.

We will be referencing the CRS we are converting from as the From CRS and the CRS we are converting to as the To CRS.

Conversion Step 1: From CRS Projection
Conversion Step 2: From CRS Transformation to WGS 84
Conversion Step 3: Transformation from WGS 84
Conversion Step 4: To CRS Projection

We will assume that the transformations defined are To WGS 84 Transformations. These steps will be using the WGS 84 CRS as an intermediate CRS for the transformation operations.

Each of the four conversion steps is optional. In most scenarios, most steps will not be used.

To showcase how Apache SIS can be used to specify each of these steps, we will be picking a scenario where all four conversion steps are required. We will be converting from CRS AGD66 / AMG zone 56 to CRS AGD84 / AMG zone 56 using From CRS Transformation AGD66 to WGS 84 (17) and To CRS Transformation AGD84 to WGS 84 (1) (https://epsg.io/1109).

To start, we establish the CRSs and transformations required for our conversion. We use the CRSAuthorityFactory class to create the CRSs and the CoordinateOperationAuthorityFactory class for transformations and other related operations. In this example, we’ll use EPSG codes to define our CRSs and transformations, although Well-Known Text (WKT) representations can also be used if needed.

CRSAuthorityFactory authorityFactory = CRS.getAuthorityFactory("EPSG");
CoordinateOperationAuthorityFactory opFactory = (CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG");

ProjectedCRS fromCRS = authorityFactory.createProjectedCRS("EPSG:20256");
fromCRS = (ProjectedCRS) AbstractCRS.castOrCopy(fromCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
CoordinateOperation fromTr = opFactory.createCoordinateOperation("EPSG:15786");

ProjectedCRS toCRS = authorityFactory.createProjectedCRS("EPSG:20356");
toCRS = (ProjectedCRS) AbstractCRS.castOrCopy(toCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
CoordinateOperation toTr = opFactory.createCoordinateOperation("EPSG:1109");

In this example, we know that the CRSs are projections so we can use the CoordinateOperationAuthorityFactory.createProjectedCRS method to create a ProjectedCRS object. If the specific type of CRS is unknown, you can use the CoordinateOperationAuthorityFactory.createCoordinateReferenceSystem method to create a generic CRS object.

After the ProjectedCRS objects have been created, we will need to get the base CRS associated with the ProjectedCRS. This can be done using the ProjectedCRS.getBaseCRS.

GeographicCRS toBaseCRS = toCRS.getBaseCRS();
toBaseCRS = (GeographicCRS) AbstractCRS.castOrCopy(toBaseCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
GeographicCRS fromBaseCRS = fromCRS.getBaseCRS();
fromBaseCRS = (GeographicCRS) AbstractCRS.castOrCopy(fromBaseCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);

From CRS Projection

The first conversion step that may be needed is a CRS projection. This is needed for the use case where the From CRS is a projected CRS.

CoordinateOperation fromProj = CRS.findOperation(fromCRS, fromBaseCRS, null);
MathTransform fromProjTransform = fromProj.getMathTransform();
CoordinateSystemAxis fromProjFirstAxis = fromProj.getSourceCRS().getCoordinateSystem().getAxis(0);
if (fromProjFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    fromProjTransform = MathTransforms.concatenate(MathTransforms.linear(swapMatrix), fromProjTransform);
}
fromProjTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

The above code section will perform the conversion step needed to convert points from the From CRS to its base CRS. This code includes a check on the order of the axis for the projection. This is needed because some CRS projections or transformations will flip the order of points from x, y to y, x. We want to ensure that the output of this conversion will be in the format of x, y or longitude, latitude.

From CRS Transformation to WGS 84

The second conversion step that may be needed is to perform a transformation to WSG 84.

CoordinateOperation xyToDatumOperation = CRS.findOperation(fromBaseCRS, fromTr.getSourceCRS(), null);
MathTransform fromTrStep1 = xyToDatumOperation.getMathTransform();
MathTransform fromTrStep2 = fromTr.getMathTransform();
MathTransform fromTrTransform = MathTransforms.concatenate(fromTrStep1, fromTrStep2);
CoordinateSystemAxis fromTrFirstAxis = fromTr.getSourceCRS().getCoordinateSystem().getAxis(0);
if (fromTrFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    fromTrTransform = MathTransforms.concatenate(fromTrTransform, MathTransforms.linear(swapMatrix));
}
fromTrTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

The above code will perform the conversion step needed to convert points from the base CRS of the From CRS to WGS 84 using the From CRS Transformation. Similar to the Projection Step mentioned earlier, we may need to flip the axis. An additional conversion is needed to convert from the base CRS to the source CRS of the From CRS Transformation.

To CRS Transformation to WGS 84

The third conversion step that may be needed is to perform a transformation from WSG 84 to the base CRS of the To CRS.

CoordinateOperation datumToXYOperation = CRS.findOperation(toTr.getSourceCRS(), toBaseCRS, null);
MathTransform toTrStep1 = toTr.getMathTransform().inverse();
MathTransform toTrStep2 = datumToXYOperation.getMathTransform();
MathTransform toTrTransform = MathTransforms.concatenate(toTrStep1, toTrStep2);
CoordinateSystemAxis toTrFirstAxis = toTr.getSourceCRS().getCoordinateSystem().getAxis(0);
if (toTrFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    toTrTransform = MathTransforms.concatenate(MathTransforms.linear(swapMatrix), toTrTransform);
}
toTrTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

The above code will perform the conversion step needed to convert points from the WGS 84 to the base CRS of the To CRS to WGS 84 using the To CRS Transformation. This is similar to the Transformation to WGS 84 except we have to reverse the order of conversions and invert the transformation.

To CRS Projection

The fourth and last conversion step that may be needed is a CRS projection. This is needed for the use case where the To CRS is a projected CRS.

CoordinateOperation toProj = CRS.findOperation(toBaseCRS, toCRS, null);
MathTransform toProjTransform = toProj.getMathTransform();
CoordinateSystemAxis toProjFirstAxis = toProj.getSourceCRS().getCoordinateSystem().getAxis(0);
if (toProjFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    toProjTransform = MathTransforms.concatenate(MathTransforms.linear(swapMatrix), toProjTransform);
}
toProjTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

The above code section will perform the conversion step needed to convert points from the To CRS base CRS to the To CRS. This code will be similar to the code section for From CRS Projection.

The full code section that contains all the conversion steps listed above is shown below

CRSAuthorityFactory authorityFactory = CRS.getAuthorityFactory("EPSG");
CoordinateOperationAuthorityFactory opFactory = (CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG");

ProjectedCRS fromCRS = authorityFactory.createProjectedCRS("EPSG:20256");
fromCRS = (ProjectedCRS) AbstractCRS.castOrCopy(fromCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
CoordinateOperation fromTr = opFactory.createCoordinateOperation("EPSG:15786");

ProjectedCRS toCRS = authorityFactory.createProjectedCRS("EPSG:20356");
toCRS = (ProjectedCRS) AbstractCRS.castOrCopy(toCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
CoordinateOperation toTr = opFactory.createCoordinateOperation("EPSG:1109");

GeographicCRS fromBaseCRS = fromCRS.getBaseCRS();
fromBaseCRS = (GeographicCRS) AbstractCRS.castOrCopy(fromBaseCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
GeographicCRS toBaseCRS = toCRS.getBaseCRS();
toBaseCRS = (GeographicCRS) AbstractCRS.castOrCopy(toBaseCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);

CoordinateOperation fromProj = CRS.findOperation(fromCRS, fromBaseCRS, null);
MathTransform fromProjTransform = fromProj.getMathTransform();
CoordinateSystemAxis fromProjFirstAxis = fromProj.getSourceCRS().getCoordinateSystem().getAxis(0);
if (fromProjFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    fromProjTransform = MathTransforms.concatenate(MathTransforms.linear(swapMatrix), fromProjTransform);
}
fromProjTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

System.arraycopy(xyOutputCoordinates, 0, xyInputCoordinates,0,  xyOutputCoordinates.length);

CoordinateOperation xyToDatumOperation = CRS.findOperation(fromBaseCRS, fromTr.getSourceCRS(), null);
MathTransform fromTrStep1 = xyToDatumOperation.getMathTransform();
MathTransform fromTrStep2 = fromTr.getMathTransform();
MathTransform fromTrTransform = MathTransforms.concatenate(fromTrStep1, fromTrStep2);
CoordinateSystemAxis fromTrFirstAxis = fromTr.getSourceCRS().getCoordinateSystem().getAxis(0);
if (fromTrFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    fromTrTransform = MathTransforms.concatenate(fromTrTransform, MathTransforms.linear(swapMatrix));
}
fromTrTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

System.arraycopy(xyOutputCoordinates, 0, xyInputCoordinates,0,  xyOutputCoordinates.length);

CoordinateOperation datumToXYOperation = CRS.findOperation(toTr.getSourceCRS(), toBaseCRS, null);
MathTransform toTrStep1 = toTr.getMathTransform().inverse();
MathTransform toTrStep2 = datumToXYOperation.getMathTransform();
MathTransform toTrTransform = MathTransforms.concatenate(toTrStep1, toTrStep2);
CoordinateSystemAxis toTrFirstAxis = toTr.getSourceCRS().getCoordinateSystem().getAxis(0);
if (toTrFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    toTrTransform = MathTransforms.concatenate(MathTransforms.linear(swapMatrix), toTrTransform);
}
toTrTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

System.arraycopy(xyOutputCoordinates, 0, xyInputCoordinates,0,  xyOutputCoordinates.length);

CoordinateOperation toProj = CRS.findOperation(toBaseCRS, toCRS, null);
MathTransform toProjTransform = toProj.getMathTransform();
CoordinateSystemAxis toProjFirstAxis = toProj.getSourceCRS().getCoordinateSystem().getAxis(0);
if (toProjFirstAxis.getDirection() == AxisDirection.NORTH) {
    Matrix swapMatrix = Matrices.createTransform(
            new AxisDirection[]{AxisDirection.NORTH, AxisDirection.EAST},
            new AxisDirection[]{AxisDirection.EAST, AxisDirection.NORTH});
    toProjTransform = MathTransforms.concatenate(MathTransforms.linear(swapMatrix), toProjTransform);
}
toProjTransform.transform(xyInputCoordinates, 0, xyOutputCoordinates, 0, 1);

Using all of these steps will allow users to perform most CRS conversions. This example also allows the user to know what the coordinate points values are after each conversion step. Most CRS conversions will not require all four conversion steps.

Visit us online at int.com/ivaap for a preview of IVAAP or for a demo of INT’s other data visualization products.

For more information, please visit www.int.com or contact us at intinfo@int.com.

Dec 02 2020

IVAAP Release 2.7: More Map Search and ArcGIS Features

IVAAP™ is a subsurface data visualization platform that provides developers and product owners powerful subsurface visualization features for their digital solutions in the cloud. IVAAP enables users to search, access, display, and analyze 2D/3D G&G and petrophysical data in a single user-friendly dashboard on the web. The latest release of IVAAP 2.7 comes with various new features and significant improvements.

Highlights from this release include many advanced search and map capabilities, improved 3D widget filter dialog, new interval curves support, new date/time picker for Cross-Plot widget axis settings, and more!

Advanced Mapping Capabilities

IVAAP features support for visual-based data discovery using map-based search, and is fully integrated with ArcGIS (ESRI), allowing for the search of structured and unstructured data in a data lake or any other file repository. IVAAP supports a wide range of map formats and services like ArcGIS, GeoJSON, KML, Mapbox, Bing, WMS, and more.

With the ArcGIS integration, you can easily access all layers and details from your ArcGIS server and display them within IVAAP to enrich map-based search of well, seismic, and other subsurface data.

New features include the ability to display a dynamic metadata table for a selected object in the map (Well, Seismic, etc.).

Most layers are supported. Image services (ArcGIS Image Service Layer, Image Services Vector Layers, and WMS) and Tile services (Image Service, ArcGIS Tiled Map Service Layer, Web Tiled Layer, OpenStreetMap) are supported. Feature Services include map service (ArcGIS Feature Layer), KML, WFS, and CSV. We also provide some real-time services support like stream services (ArcGIS Stream Layer), GeoRSS, Vector Tiles (VectorTileLayer), and Bing Maps services. Two extra formats that are supported are GeoJSON and GPX.

This release includes improved search capabilities allowing search across any metadata for any user. Access to data can be restricted to read-only mode. We also made improvements to fence highlighting and access to well lists, and labels can now be saved with the dashboard.

More Themes Control

Previously, theme control within IVAAP was a bit limited. We’ve expanded the theme mechanism to all widgets so that users can customize themes with more control and options and access new updated themes.

New Image Widget

IVAAP can now display simple image files such as jpeg or png files in the image widget, align, and zoom in to show detail. This feature allows users to customize dashboards with logos or other image files needed to display.

Improvements in 3D

IVAAP’s 3D widget now supports tagging and aliases when displaying well data. We added reservoir data that can be serialized in the dashboard template. Users now have the ability to mix data with CRS and data without CRS. Another new feature is that users can apply properties to multiple or individual objects. And we’ve improved the dashboard restoration of multiple inlines, crossbones, and time slices. Finally, the 3D widget filter dialog has been redesigned.

New Features in WellLog

For WellLog, we improved the set main index support for templates, dashboards, and well switching. With this improvement, a secondary index can be used to display data into a different index and secondary indexes can be restored when opening an existing dashboard or template. An improved automatic logarithmic mode gives users the ability to add a curve to a logarithmic track. New features added to WellLog include: the ability to automatically rotate labels for lithology and a reset action where users can right-click with the option to clear their display.

New in Schematics

For the Schematics package, new features include: perforation with state definition support, the ability to customize by using a filter dialog, and the ability to use cursor tracking between Schematics and WellLog. We also improved the component selection support in the Schematics widget.

Time Series: Annotations and Perforations

We improved the ability to select a data series from the legend. The Time Series widget now features support for annotations and perforations. The tooltip now shows the index data and time.

New and Improved Line Chart

The IVAAP line chart now supports templates and data series dialog. We improved the ability to edit existing data series. Users can now flip the axis for date and time data, and the legend has been improved to show or hide the data series parent. There is also an improvement for single data sets, multi-data sets, and multi parent projects.

This release includes many more improvements to features and to the UI. For more information, check out the full release here.

Or check out int.com/ivaap for a preview of IVAAP or for more information about INT’s other data visualization products, please visit www.int.com or contact us at intinfo@int.com.

Sep 15 2020

Integrating Powerful Map Capabilities into Your Subsurface Web Applications

Map-based search is an integral part of subsurface data visualization. In order to meet usability expectations, developers of subsurface applications in the cloud must add powerful map and map-based search functionalities.

The GeoToolkit map widget simplifies the process, allowing users to get quick and clear insights using common web mapping services. In this blog post, we will cover how to access the map widget in GeoToolkit, how to integrate other Web Services, including ArcGIS, ESRI REST, OpenStreetMap, Google, Microsoft, etc., and more about GeoToolkit’s features, including layering, labeling, symbols, annotations, and more.

Features

With GeoToolkit.JS, there are many general functionalities that you can use in your web application. The map, which is based on the Core toolkit, provides two different versions of libraries: it has ECMAScript 6 or if you’re going for a more classical approach, ECMAScript 5. It can be used in part with different UI frameworks like React, Angular, or VUE. Moreover, it has user-friendly functionalities like symbol aggregation, label collision, export to PDF, and imaging formats.

There are also different functionalities that can be available such as axes, titles, and scrollbars. The predefined interaction tools allow you to display crosshair, panning tools, zoom to measure distance, tooltip, rubberband, and more. GeoToolkit.JS map supports a wide range of map formats and services like ArcGIS, GeoJSON, KML, Mapbox, Bing, and so on. It is also compatible with other GeoToolkitJS elements like charts, shapes, and widgets.

Getting Started

import {Map} from '@int/geotoolkit/map/Map';
import {Plot} from '@int/geotoolkit/plot/Plot';
import {Tile} from '@int/geotoolkit/map/layers/Tile';
const map = new Map();
map.addLayer(new Tile({
 'name': 'OpenStreetMap',
 'url': https://demo.int.com/osm_tiles/{z}/{x}/{y}.png
}))
const plot = new Plot({
  'canvaselement': canvas,
  'root': map
});

Create a map widget.
Connect DOM canvas with the widget by creating a Plot done like other widgets.
Add a layer (or layers) of interest to the widget.

Web Services: ESRI REST, OpenStreetMap, Google, Microsoft

It is important to consider which types of services can be supported since all of your data is received from different types of servers. Some services hosted include: ESRI Rest, ArcGIS, OpenStreetMap, Google Map, Microsoft, etc.

The ArcGIS Web Map protocol which is used by ArcGIS online is an easy and convenient way to build your map application. You can go to ArcGIS online, create your content, put necessary layers, combine them together, provide the link to our map widget and it will automatically be recognized. Most layers are supported. Image services (ArcGIS Image Service Layer, Image Services Vector Layers, and WMS) and Tile services (Image Service, ArcGIS Tiled Map Service Layer, Web Tiled Layer, OpenStreetMap) are supported. Feature Services include map service (ArcGIS Feature Layer), KML, WFS, and CSV. We also provide some real-time services support like stream services (ArcGIS Stream Layer), GeoRSS, Vector Tiles (VectorTileLayer), and Bing Maps services. Two extra formats that are supported are GeoJSON and GPX.

Map Services

Services cannot be used without visualization. Our part in maps products is to provide visualization for these services. To start visualization, you need to create your map widget and specify different properties. One example of a system is CRS, which is a common coordinate system of displayed data. You can specify map limits if you want to limit the visualization area of interest. You can also set different adornments to your maps like map scale. Zoom settings include min/max with a range of scales available and time/speed to customize the map management to your convenience.

Map Layers

There are four main types of layers supported:

Image type that displays a single image received from a server. For example, WMS for Web Maps Services and ArcGISImage supports ArcGIS MapServer and ImageServer services.
With Tile layers, the data consists of several images (tiles) painted next to each other and thus forming a complete picture. Tile can be used as a universal layer for any tile service. Bing can be used for all Microsoft Bing Services.
Vector layers draw not pictures but vector data (called “features”): points, polygons, and polylines, which depict cities, rivers, islands, and more. Support of different formats includes: GeoJSON, KML, CSV, GeoRSS, Lerc translate their format into the map objects, the ArcGISFeature supports ARCGIS FeatureServer services., WFS for Web Feature Services, and VectorTile.
Shape layer is used for compatibility with other GeoToolkitJS elements to display on the map charts, contours, and other complex shapes (or just trivial ones).

Layer Settings

General setting for layers include url to the server or file, data coordinate system (epsg codes are supported), alpha as the value of the layer transparency, layerfilter for setting visibility conditions, tooltip.visible to enable tooltip support by the layer, and tooltip.formatter to generate information (in HTML format) of the tooltip content (can be used in both the basic GeoToolkitJS formatters or a custom one).

Examples of different layers:

Geo-Reference Images

Geotoolkit provides powerful options like fast WebGL implementation and ImageTransform to help speed up the process to transform any image in your application.

Feature Annotations

In map displays, you can have a lot of different annotations and some of them can potentially overlap. To help filter out the overlapped annotations, you want to use some collision detection to remove unnecessary labels. We provide all of these functionalities which can be configured. The steps to display labels are:

Use annotations.visible layer property to include annotations (hidden by default)
To select annotation info, change the annotation.strategy parameter to the AnnotationByAttribute or AnnotationByRule instance with the attribute name or \expression to display.
Set the text shape for the template to customize annotations drawing styles and textSizeInfo option to dynamically resize annotations.
Annotation filters prevent some information from being written in order to save space, time, etc.

Robust Map Features for Your Subsurface Application

Overall, GeoToolkit’s map widget allows you to integrate many robust map features into your subsurface or exploration applications. We hope this helps you simplify the process, meet usability expectations, and get the insights you need.

For more information on GeoToolkit’s maps widget and its features, please visit our GeoToolkit page.

Want to know more? Check out our webinar: Integrating Powerful Map Capabilities into Your Subsurface Web Applications.

Jul 21 2017

A Closer Look at Coordinate Conversions

The CRS chooser when you type “World Mercator” in the search box

INTViewer makes coordinate conversions virtually transparent to users. Users pick two Coordinate Reference Systems (CRS), one for their data and one for the visualization map, and the visualization updates automatically.

How does INTViewer do it? The short answer is “it depends”. The long answer is that the strategy used varies based upon the CRSs selected, and the points to convert. To explain this, a better understanding of CRSs is needed: Coordinate Reference Systems are essentially defined as an origin, a bounding box, and a mathematical formula to convert each point to LAT-LONG coordinates.

A well-known CRS is the Mercator projection spanning the entire globe (except the poles) and using LAT-LONG coordinates with Greenwich, UK as its origin. This CRS is known in INTViewer as “WGS 84 / World Mercator”.

There are thousands of well-known CRSs used all over the world; this is only one of them. The European Petroleum Survey Group (EPSG) was formed in 1986, and maintains the list of these CRSs. This group provides a database of CRSs to all subscribers and this database is exported in the form of XML files to INTViewer. When you pick a CRS, you are essentially going through that exported list of CRSs.

When INTViewer converts coordinates between two CRSs, one strategy is to use WGS 84 as a hub. This means that we first convert coordinates from the first coordinate system to the WGS 84 coordinate system, then we convert the resulting coordinates to the second coordinate system. Unfortunately, this cannot be done with the CRS definitions alone; a “transform to WGS 84” needs to be specified for the conversion to WGS 84.

By default, INTViewer doesn’t prompt for that transform even where there are several possible options. INTViewer picks the transform to WGS 84 automatically based upon the bounding box of the points to convert. Each transform has its own “area of use” and INTViewer tries to pick the transform that has the smallest area of use but still contains all points to convert.

Users can elect to pick transforms manually by checking the highlighted option in the CRS options panel.

The “WGS 84 hub” technique is an easy way to convert coordinates between any two CRSs, but this is not the most accurate method, as it can introduce errors of more than 10 meters. For really accurate conversions, NADCON (North American Datum CONversion) and NTV2 (National Transformation Version 2) grids are a better option.

In a few words, NADCON and NTV2 grids allow much more precise conversions between two CRSs that have overlapping bounding boxes. NADCON and NTV2 grids are not defined for the entire planet, only specific areas of interest like North America, Europe, Australia, or the Middle East. As a result, INTViewer will use the WGS 84 technique as a fallback only if NADCON or NTV2 grids are not defined.

North America typically uses two different datums: NAD27 and NAD83. NAD27 and NAD83 are two geodetic reference systems, one created in 1927, the other in 1983. In 1989, U.S. states started defining High Accuracy Reference Networks (HARN) using GPS technology, making it possible to convert coordinates to LAT-LONG without a loss of precision of more than one meter. To take advantage of this precision, INTViewer attempts to use HARN-based conversions when possible.

In conclusion, the strategy to convert coordinates is highly based on the area of use (the bounding box) of the points to convert. If these points are found to be outside of a NADCON or NTV2 area, WGS 84 will be used as a hub. HARN may be used within the NADCON areas.

INTViewer has been evaluated against the OGP Geospatial Integrity of Geoscience Applications (GIGS) compliance guidelines and found to be compliant in 2013. The International Association of Oil&Gas Producers (OGP) created these guidelines to eliminate common failures of geospatial integrity in geoscience software applications.

While not a pure mapping software, INTViewer tries to find the right mix between ease of use and accuracy. The accuracy is good enough that it can be used to manage exclusion zones in seismic data, as demonstrated by the Mineral Rights plugin. As a developer, you can leverage this conversion mechanism in your own plugin without worrying about the implementation details.

Check back soon for more new features and tips on how to use INTViewer or contact us for a demo.

Apr 18 2017

Choosing the Right Coordinate Reference System

INTViewer has been around for quite a while now. And over the last 8 years that I have worked on it, it has evolved a lot. As more and more users used the application, we were able to solicit and integrate their feedback, further maturing the application.

Sometimes, however, you don’t need to add new features to make a software great — just revisiting a design can sometimes add value. For INTViewer, the Coordinate Reference System (CRS) selection dialog is one of the areas we improved just by tweaking the design.

The most often used window of INTViewer is the XSection. When we surveyed our customers, we found that many didn’t know about the mapping capabilities of INTViewer. This is a shame since INTViewer makes it very easy to visualize your survey from a bird’s eye view in the map window.

To integrate satellite imagery and view your survey in context, you need strong coordinate reprojection capabilities. Five years ago, we worked to make INTViewer GIGS (Geospatial Integrity of Geoscience Applications) compliant. Actually, most of the work was done in J/CarnacGIS, a Java library designed for the visualization of Geographic Information System (GIS) data. INT developed this product separately, but it is included in INTViewer. I leverage its API often when I develop plugins, and customers do, too. CRS conversions done with INTViewer are very accurate — they use NADCON (North American Datum Conversion) and NTV2 (National Transformation version 2) grids when available. But a key to a valid conversion from one CRS to another is to pick the right CRSs in the first place!

Up until INTViewer 5.1.1, the CRS selection dialog looked like this:

This dialog essentially listed all CRS in the European Petroleum Survey Group (EPSG) database, prompting the user to choose the right code … among approximately 2,000 codes.

In INTViewer 5.2, the user interface has been enhanced to show a map that highlights the area of use of the CRS you are selecting:

When you perform quality analysis of your data before sending it for interpretation, you want to make sure that it is properly geolocated. This dialog allows you to check that the CRS you are picking is in the right region, and it highlights its area of use. If your data falls outside of this area of use, the validity of CRS conversions is compromised, leading to invalid visualizations.

INTViewer compares the bounding box of your data with the bounding box of the area of use. If the area of use fully contains your data, a green badge will be shown next to the CRS and in the map.

If there is only a partial match, a yellow badge will be shown.

This is a simple way to validate your selection. The CRS selection feature itself hasn’t changed, but the user experience has improved.

Users who work primarily on one survey won’t be affected by this change: they know by heart which CRS their survey uses. For me, as I often switch from one survey to another when I perform demos, this makes my task much simpler as I don’t always remember the EPSG code I need to enter. Customers who use INTViewer as a presentation tool (for example to showcase acquisition surveys) should also benefit.