Incompatible API Changes in INTViewer 5.2

A/ The com.interactive.intviewerapi.IObjectAction interface uses Java generics

The signature of this interface has changed from:

public interface IObjectAction {
public Action toAction(Object object, int x, int y);

to:

public interface IObjectAction<T extends Object> {
public Action toAction(T object, int x, int y);

This change makes contextual actions easier to write (and more robust) by reducing arbitrary casts.

It affects sub-classes of IObjectAction such as AbstractObjectAction, AbstractLayerAction and AbstractObject3DAction.

As a result, contextual actions written prior to INTViewer 5.2 need to be slightly refactored. Here is an example of class extending AbstractLayerAction in INTViewer 5.1.1

public class ShowTrendStatisticsAction extends AbstractLayerAction {
    public ShowTrendStatisticsAction() {
        super("Show Trend Statistics");
    }
    @Override
    public Action toAction(Object object, int x, int y) {
        ILayer2D layer = (ILayer2D) object;
        NamedProps properties = layer.getProperties();
        Boolean property = properties.getProperty(IXpLayer.SHOW_TREND_STATISTICS);
        Action action = super.toAction(object, x, y);
        if (property) {
            action.putValue(Action.NAME, "Hide Trend Statistics");
        }
        return action;
    }
    @Override
    protected void performAction(ILayer2D layer, int x, int y) {
        NamedProps properties = layer.getProperties();
        Boolean property = properties.getProperty(IXpLayer.SHOW_TREND_STATISTICS);
        NamedProps props = new NamedProps();
        props.putProperty(IXpLayer.SHOW_TREND_STATISTICS, !property);
        layer.setProperties(props);
    }
}

This class should be written this way in INTViewer 5.2:

public class ShowTrendStatisticsAction extends AbstractLayerAction<IXpLayer> {
    public ShowTrendStatisticsAction() {
        super("Show Trend Statistics");
    }
    @Override
    public Action toAction(IXpLayer layer, int x, int y) {
        NamedProps properties = layer.getProperties();
        Boolean property = properties.getProperty(IXpLayer.SHOW_TREND_STATISTICS);
        Action action = super.toAction(layer, x, y);
        if (property) {
            action.putValue(Action.NAME, "Hide Trend Statistics");
        }
        return action;
    }
    @Override
    protected void performAction(IXpLayer layer, int x, int y) {
        NamedProps properties = layer.getProperties();
        Boolean property = properties.getProperty(IXpLayer.SHOW_TREND_STATISTICS);
        NamedProps props = new NamedProps();
        props.putProperty(IXpLayer.SHOW_TREND_STATISTICS, !property);
        layer.setProperties(props);
    }
}

B/ The ISeismicReader.findFirstTrace method has been replaced by ISeismicReader.findTracesWithin

This change was made to allow more flexibility in searching through trace selections. It is used to generate multiple ticks when gathers are displayed.

The signature of "findFirstTrace" was:

int findFirstTrace(SeismicRangeQuery query);

The signature of "findTracesWithin" is:

public enum Scope {
    SKIP_MISSING_TRACES,
    KEEP_MISSING_TRACES
};
public enum SearchOrder {
    ASCENDING_SEARCH_ORDER,
    DESCENDING_SEARCH_ORDER
}

public List<Integer> findTracesWithin(SeismicRangeQuery query, int maxMatchingTraces,
            Scope scope, SearchOrder searchOrder, ILongTaskProgressMonitor monitor);


This change affects all classes calling ISeismicReader.findFirstTrace or implementing ISeismicReader.

Code calling findFirstTrace this way:

ISeismicReader reader ...
SeismicRangeQuery query = ...
int traceId = reader.findFirstTrace(query)

should be rewritten:

ISeismicReader reader ...
SeismicRangeQuery query = ...
List<Integer> traceIds = reader.findTracesWithin(query, 1, Scope.SKIP_MISSING_TRACES, SearchOrder.ASCENDING);
int traceId = traceIds.get(0);

The now-removed findFirstTrace method was always skipping missing traces. This Scope.SKIP_MISSING_TRACES option is present for backward compatibility purposes.

We found that Scope.KEEP_MISSING_TRACES was a better option for all calls to findTracesWithin: SKIP_MISSING_TRACES is actually not used in INTViewer's code in INTViewer 5.2. If you implement your own ISeismicData/ISeismicReader, you do not need to implement the Scope.SKIP_MISSING_TRACES option unless you explicitly use it.

Code implementing findFirstTrace this way:

        @Override
        public int findFirstTrace(SeismicRangeQuery query) {
            for (int i = 0; i < traceList.size(); i++) {
                ITrace t = traceList.get(i);
                if (match(t, query)) {
                    return i;
                }
            }
            return -1;
        }

should be rewritten:

@Override

        public List<Integer> findTracesWithin(SeismicRangeQuery query, int maxNumber, Scope scope, SearchOrder so, ILongTaskProgressMonitor iltpm) {
            List<Integer> results = new ArrayList<>();
            if (so == SearchOrder.ASCENDING_SEARCH_ORDER) {
                for (int i = 0; i < traceList.size(); i++) {
                    ITrace t = traceList.get(i);
                    if (match(t, query)) {
                        results.add(i);
                        if (results.size() >= maxNumber) {
                            break;
                        }
                    }
                }
            } else if (so == SearchOrder.DESCENDING_SEARCH_ORDER) {
                for (int i = 0; i < traceList.size(); i++) {
                    int index  = traceList.size() - i - 1;
                    ITrace t = traceList.get(index);
                    if (match(t, query)) {
                        results.add(index);
                        if (results.size() >= maxNumber) {
                            break;
                        }
                    }
                }
            }
            return results;
        }

C/ Traces are aligned by default in XSection windows

Because of the feature described in http://intviewer.int.com/intviewer/docs/userguide/latest/file/align_trace_positions.html, the visualization of seismic layers in XSection windows will differ when these layers are stacked in the same window.

You can disable this feature entirely through the Tools->Options->Gui dialog

You can also programmatically set the IXSection.ALIGN_TRACE_POSITIONS property for each XSection window you create.

D/ The com.interactive.intviewerapi.plugins.traceprocessor.ISeismicProcessor interface has changed

The preProcess(ISeismicData, IVisual) method has been deprecated and made final: it cannot be overridden anymore.

If you implement ISeismicProcessor by extending com.interactive.intviewerapi.plugins.traceprocessor.AbstractSeismicProcessor directly, override both preProcess(IVisual) and preProcess(ISeismicData) instead. When you override preProcess(IVisual), make sure to call super.preprocess(IVisual) so that preProcess(ISeismicData) gets called.

If you extend com.interactive.intviewerapi.plugins.traceprocessor.AbstractStandaloneSeismicProcessor, no change should be required.

E/ The com.interactive.intviewerapi.objects3d.IObject3DFactory interface has changed

The following method has been added:

    public T createObject3D(V window, U data, IMemento m, boolean runEditor) throws Exception;

This method replaces the following deprecated method:

    public T createObject3D(V window, IMemento m) throws Exception;

The new method allows the passing of "data" as a parameter. Passing this parameter is required when copying 3D objects as the dataset identified by the "data" instance might not be stored on disk. Depending on the implementation of "restoreState", using the "memento" parameter alone might create a data duplicate instead of reusing the same data instance.

The new method is used as part of the "copy layer" feature for 3D objects. No change was required for 2D layers since 2D layer factories already had this method.

F/ The com.interactive.intviewerapi.editors.IObjectEditorNodeProvider interface has been modified

The method

public void setObjectEditorNodeVisible(boolean visible, Class selectedObjectEditorNodeClass)

has been changed to

public void setObjectEditorNodeVisible(boolean visible, Class<? extends IObjectEditorNode> selectedObjectEditorNodeClass)

This affects any class extending AbstractLayer2D and AbstractObject3D.

G/ The default path of file choosers has been modified

In 5.1.1, most file choosers were using the same DATA_PATH_PROPERTY environment variable as a default

In 5.2, each chooser has its own environment variable. Seismic has SEISMIC_DATA_PATH_PROPERTY, horizons have HORIZON_DATA_PATH_PROPERTY, etc. The DATA_PATH_PROPERTY environment variable is a default if SEISMIC_DATA_PATH_PROPERTY is not known. If DATA_PATH_PROPERTY is not set, the home directory of the current user is used (instead of the INTViewer installation directory in previous versions)

These environment variables are listed here:

http://intviewer.int.com/intviewer/docs/userguide/latest/tools/environment.html

H/ Deprecated methods and classes have been removed

Methods of com.interactive.intviewerapi.data.DataUtil have been removed

DataUtil.getExtensions(java.lang.String mime)

use MimeRepository.getDefault().getExtensions(mime) instead

DataUtil.getMimeDescription(java.lang.String mime)

use MimeRepository.getDefault().getName(mime) instead

DataUtil.getMimeTypes(java.lang.String dataType)

use MimeRepository.getDefault().getMimeTypes(dataType) instead

DataUtil.setExtensions(java.lang.String mime, java.lang.String[] exts)

use MimeRepository.getDefault().setExtensions(mime, exts) instead

DataUtil.writeData(IData data, FileObject fo, java.lang.String mime)

use writeData(data, null, fo, mime, new ILongTaskProgressMonitor.NullProgressMonitor()) instead

DataUtil.writeData(IData data, FileObject fo, java.lang.String mime, ILongTaskProgressMonitor m)

use writeData(data, null, fo, mime, m) instead

DataUtil.writeData(IData data, IDataQuery query, FileObject fo, java.lang.String mime)

use writeData(data, query, fo, mime, new ILongTaskProgressMonitor.NullProgressMonitor()) instead

The com.interactive.intviewerapi.crs.CoordinateSystemUtil class has been removed

CoordinateSystemUtil.lookupCoordinateSystemChooserService()

use ICoordinateSystemChooserService.Factory.getInstance()

CoordinateSystemUtil.lookupCoordinateSystemTransformationService()

use ICoordinateSystemTransformationService.Factory.getInstance()

The com.interactive.intviewerapi.util.ExtensionPoints class has been removed

Use the NetBeans "<this layer in context>" node in your project to explore graphically all extension points.