Geophysical Insights at SEG 2017 in Houston, Booth #301
Using Attributes to Interpret the Environment of Deposition - A 1 day course. Taught by Kurt Marfurt, Rocky Roden, and ChingWen Chen
Dr. Kurt Marfurt and Dr. Tom Smith featured in the July edition of AOGR on Machine Learning and Multi-Attribute Analysis
Rocky Roden and Ching Wen Chen in May edition of First Break - Interpretation of DHI Characteristics using Machine Learning
Seismic interpretation and machine learning by Rocky Roden and Deborah Sacrey, GeoExPro, December 2016

Storing Post Stack Seismic Meta Data in PPDM

By Ken Cooley

March 2011

Click here to download the PDF

Full Article Text...

We propose a Method of populating seismic survey meta data that resolves some confusion about which PPDM tables to use for which pieces of Seismic data related to documenting meta data about 2D and 3D post stack seismic trace data files.

We selected specific PPDM Seismic, Reference, and Records Management tables that were suitable for the requirements. The selected tables fit together well given the relationships between them, resulting in accurate storage and retrieval of the needed data.

This pattern of populating seismic survey meta data allows us to unambiguously store and access the data in a PPDM database in a standard way. Other companies could use this pattern to enable sharing of seismic survey meta data among different software applications. Clearly, this would support better integration with fewer data exchange obstacles.

Introduction

Geophysical Insights was facing the following challenge:

  • We needed an industry standard data model for storing information about seismic post stack trace data (meta data).
  • PPDM was chosen because it is comprehensive, open, and supported.  

It supports any kind of data in one database. Other applications can access the data, and there is ongoing work to refine and further develop it. The PPDM organization has been very responsive to our questions.

Initially, the complexity of the Seismic data model was a concern. There are many ways of representing the same information. This discrepancy can result in disconnects between different implementations of the same PPDM module.

However, we have been able to choose a way of representing Survey, Geometry, Trace, and storage information for Post Stack trace data (3D Seismic Attribute volumes and 2D data types) in PPDM that satisfies our needs.

The goal was to be able to collect Seismic Attribute volumes (3D) and data types (2D) from Seismic Surveys from several different Oil & Gas Seismic projects via OpenSpirit.

For each 3D Seismic Attribute Volume, for example, we needed to store the bulk data (traces) in large binary files, but for selection, graphical display, and processing, we needed to represent the meta data in the PPDM data model.

A method was chosen of representing the following information for Post Stack trace data (3D Seismic Attribute volumes and 2D data types) in PPDM:

  • Seismic Survey
  • Geometry
  • Trace Info
  • File Storage

This is the Meta data about the trace data. Seismic Post Stack Data comes from processing raw Seismic data. (Figure 1)

Many different seismic attributes can be calculated from a single set of post stack amplitudes. There can easily be as many as 50 different kinds attributes calculated for a single survey. For each 3D Seismic Attribute Volume, for example, we needed to store the bulk data (traces) in large binary files. For survey selection, graphical display, and processing, we needed to represent the survey and post stack trace meta data in the PPDM data model.

Typically, we would need to access meta data for many surveys at once, for mapping logic, for example. But for bulk trace data, we would only need to access one volume at a time.

As a result, specific PPDM Seismic, Reference, Records Management tables were selected that were suitable for the above requirements. The selected tables fit together well given the relationships between them.

3D Seismic Survey

These tables can “share” the same key value. The common key ties them to a 3D survey. (Figure 2)

All these tables have “SS_1001” as their ID primary key value. It ties them together associating the rows with a single 3D Survey. The “SS_” is mainly for clarity in the presentation. The key is a text field, but can be just numbers. This represents a 3D survey, named “GOLDEN” with an attribute volume for the “Coherence” attribute.  

Additional volumes would get incremented COMPONENT_ID’s.

Records Management Information Item (Figure 3)

These tables share the “II_2001” Information Item key value, and represent the records management record for the Coherence attribute volume for a specific Survey.

Records Management Data Store (Figure 4)

These tables share the “IIS_3003” Data Store key value, and represent the actual disk location and file name for the bulk data associated with the attribute volume.

Are more PPDM tables required in order to correctly persist the data?

Here are additional tables which link position information to spatial databases:

SEIS_SET_GEOMETRY?

SP_LINE, SP_POINT, SP_LINE_POINT?

In order to group a 2D Line as part of a 2D survey we would use SEIS_GROUP_COMP to tie the SEIS_LINE to a SEIS_ACQTN_SURVEY.

Post stack trace data (attributes) are inputs into our business solution. Classification volumes (3D) and lines (2D) are outputs. Their meta data is also stored in PPDM as attributes. (Figure 9)

A Possible PPDM Extension could include, Self Organizing Map (SOM) analysis results, which are another output of our business solution. Currently, there is no place in the PPDM for them. We may propose some PPDM data model extensions to cover these.

This paper represents a top level view. There are many additional details. Some are self-explanatory. The column names describe the usage of the columns. There are, of course commonly used PPDM tables which also describe many other parts of the PPDM model, like:

  • Coordinate systems
  • Units of measure
  • Etc.

Conclusion

In summary, this approach results in an accurate and straightforward storage and retrieval mechanism for the required data. Other companies could use this method to enable sharing of seismic survey meta data among different software applications. This sharing would support better integration, with fewer data exchange obstacles.

We were motivated to publish this method because PPDM exists to enable standardization, but PPDM is flexible. It allows mismatches between different implementations.

There has been very little published PPDM Seismic Survey usage info available. For example, there are no 3D Surveys in the Teapot Dome data set.

The sooner a convention for using Post Stack Seismic data is adopted, the fewer incompatibilities between different Implementations may result. Our hope is to provide a good start on “best practices” for seismic meta data storage.

We would like to express thanks to Steve Cooper, President of EnergyIQ and Trudy Curtis, CEO of PPDM. We received a great deal of instruction and assistance from them.

 

© 2011 Geophysical Insights. All rights reserved. No part of the material protected by this copyright may be re­produced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, broadcasting or by any information storage and retrieval system, without permission in writing from Geophysi­cal Insights.


Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out