Fundamentals of Data Management in Landmark applications environment.
Naila Huseyn-zada
Managing Consultant Data Management
Landmark Software & Services (Halliburton)
Fundamentals of Data Management in Landmark applications environment
Have you ever faced the situation when data seemed to exist, but they were unstructured and isolated from
each other? Have your ideas gotten broken into a mass of heaped information? Have you been frustrated by various data
being chaotically placed in different databases from previous researches? Many of you will answer - yes, alas! Such things
happen in our wealth of information technologies, and the larger a company is, the more these occurrences may happen.
The search for a new way to handle these situations has led to the development of a data management program,
which has already made considerable contributions to the success of some leading companies. It is known that the
effectiveness of decision making directly depends on the quality and timeliness of the given information. The data quality
means the reliability of each data unit, and the speed of data gathering depends on the speed of access to it, which is only
possible with effective data structuring within the company and the use of high-speed applications and techniques. Thus,
if the responsibility for data quality lies on the shoulders of a workgroup, department, or company data managers, then
the decision for a data management concept and the type of technical base depends on a company itself.
As a data manager within the Landmark applications environment, I have gained extensive experience working
on various projects for different companies, which are outlined in this article. First, I would like to highlight the data
management concept offered by Landmark as well as to define what qualitative data are and how to structure them in
the framework of Landmark applications. Secondly, I would like to help Landmark users to get as much use from the
functionality of the classical package applications as is already available for them for efficient data management. Thirdly, I
would like to acquaint users with applications from the modern data manager, including WOW™, CDA, and
PowerExplorer® programs. Finally, I would like to draw attention to the modern problems in data management as a
means to educate and train data managers in the oilfield industry.
What is the “Classical package” of Landmark applications and the OpenWorks® project database?
The current “Classical package” for Landmark applications is a family of integrated OpenWorks® applications
based on the platforms, UNIX and Linux. The underlying system of the OpenWorks family represents a base structure for
geological and geophysical applications designed to
perform the following:
 seismic interpretation in 3-D and 2-D
Geological
Well Log
Seismic
 log-curve analysis
Interpretation
Analysis
Interpretation
 geological interpretation
 velocity modeling
 mapping
 data management
Data collection for sharing and collaboration is called
Processing
Mapping
the OpenWorks project. The OpenWorks application
History
includes two types of projects—project databases and
interpretation projects. The OpenWorks project database is
Prestack
Velocity
Data
organized in the Oracle relational database and represents
Seismic
Modelling
Management
Interpretation
a set of more than 1,000 tables capable of storing more
than 10,000 data elements, including various geological,
geophysical, and petrophysical data, such as well
information, log curves, faults, seismic navigation,
production data, interpretation, etc.
The number of interpretation projects that
Fig. 1—OpenWorks database is a basis for various geological and
represent a subset of the data or a certain area of interest
geophysical interpretation. All data in the OpenWorks project database
can be unlimited within a project database. Physical data
and its environment are inter-connected, which allows users to work
are located in a database for interpretation projects to
with high-productive applications for teamwork.
refer to. Such a model enables the avoidance of data
duplication, provides an economy for disk space, and strengthens data protection while preserving data integrity.
Some types of data, particularly seismic files and horizon 3-D, are within the directories of the OpenWorks
system hierarchy rather than in the database tables. The OpenWorks system also stores a large amount of other files and
data, including culture data, color maps, format files, etc. As a whole, the dataset of a project database is only limited by
the available disk space.
The OpenWorks application represents a structured database, providing reliable storage and quick access to data.
Because of its extensive capabilities, the OpenWorks project database R5000 has earned the Word Oil journal award for
“Best Data Management Solution” in 2008. Our task is to use the full capabilities of the OpenWorks software for the
creation of an efficient system for data management within the oil industry.
Naila Huseyn-zada
3/6/2016
Page 1 of 14
Fundamentals of Data Management in Landmark applications environment.
What is OpenWorks data management, and what should the
expert in this area know?
The OpenWorks database contains a wide range of
operations for managing its data, including:
 the gathering, analysis, processing, and placing of the
data in a project database
 data quality check
 associating data with each other
 data administrating, both in a project and in a system
 data transferring from a project to a project and from
a project to an application
Fig. 2—World Oil Award to OpenWorks database for “Best Data
 workflow and standard development
Management Solution” 2008. Over the last 10 years, Landmark
applications received 4 additional awards by the World Oil journal:
 data archiving
GeoProbe® software in 2001 for the “Best Development,
 documenting
Production, and Reservoir Data Solution”; AssetView™ software in
These operations assume a degree of knowledge in
2003 for “Best Visualization Solution”; GeoProbe software again in
various areas. Depending on the volume of data and a suite of
2004 for “Best Data Visualization Solution”, and DecisionSpace®
Desktop application in 2010 for “Best Visualization and
applications, data management can involve a single universal
Collaboration Solution”.
expert or a team with a variety of duties and activities.
However, experience shows that for either case, those involved
in data management within the Landmark applications should possess a certain level of knowledge, which includes the
understanding of geology and geophysics as well as knowledge in the following areas:
 UNIX/Linux operating system and commands
 OpenWorks project database
 Conception of the Oracle® relational database
 Geodata loading and management
 Seismic data loading and management
 StratWorks®, SeisWorks®, and Z-MAP Plus™ applications
 WOW, CDA, and PowerExplorer applications
 SQL (structured query language)
 Shell, AWK, and/or Perl scripting languages
 Data medium
 Basic foundation of documenting and reporting
This amount of knowledge is not gained in one day or by one training. Anyone interested in this knowledge should
possess goal-seeking behavior, inquisitiveness, and an eagerness for self-development. Unlike other specialties in which a
considerable quantity of books and manuals are available, the data management program, particularly in the area of georesearch, will not provide an abundance of literature in this field. Mastery, rather, comes with practice.
Data management begins with a name.
That statement should not surprise anybody. Standard practice for data management begins with naming individual
source files, wells, maps, projects, and directories and deciding where the data should be stored. The list of all possible
data is long, but the task of naming these data exists at each stage of the data management program.
We are free to choose names according to our practices, but each expert, workgroup, and company should have a
standardized naming scheme. Data analysis is highly effective if a workgroup has a system in place for naming and
allocating data. For example:
 Data could be grouped in directories according to maps, graphic files, source data files of a certain project, etc.;
 File names are informative, and, therefore, there is no need to look through the contents of each file in search of
necessary information;
 Names of key parameters are integrated in the framework for both a single project as well as a whole database.
For example, if the same parameter in different wells of a project has a different name, it can complicate the analysis
of a group of wells. Implementing a standardized naming scheme enhances many data management operations, such as
the transfer of data between different projects and data archiving.
When reading through these recommendations for a successful data management system, you may wonder why
these guidelines are so unique. While these recommendations may seem obvious and simplistic, the fact is that they are
often overlooked and rarely implemented because too much time is spent on the analysis of the available data.
Naila Huseyn-zada
3/6/2016
Page 2 of 14
Fundamentals of Data Management in Landmark applications environment.
Moreover, it is often easier to start from scratch
than to find the available data. A naming scheme in a
workgroup is especially useful during data transmission
from the client to the customer. Historically, it has been
common for data files to be named after employee family
members, pets, etc.; however, it would be more beneficial
to use names in conjunction with the content of the data.
Therefore, the first principle of effective data
management is to create a standardized naming scheme
and to effectively apply it to the company data
management program.
What are the key objectives required of a corporate
naming scheme?
Experience shows that any naming scheme is better
than no system at all. As a basis for developing a
standardized naming scheme, I suggest adhering to a
specific concept of listing the company’s key objectives and
incorporating data management fundamentals and criteria
of data quality control. This experience can be adopted,
developed, and adapted to a company’s specific needs.
The following is a basic list of key items that would require
the use of a standardized naming scheme:
 files, directories, file system
 database and interpretation projects of
OpenWorks applications
 well headers, statuses, symbols, lists
 log curves, aliases
 stratigraphic columns, surfaces, formations,
attributes
 lithological columns, classes, symbols
 seismic surveys, 2-D lines and 3-D volumes,
horizons, faults
 velocity models
 maps, grids, point sets, polygons
 sessions, color maps, graphic files, culture data
 format files for data import/export
 archival catalogs
Data
gathering
Data
processing
Fit
standard?
No
Naming
Convention
development
Yes
QC data
Apply
standards
Initialize
a pre-load
job
Relevant
workflow?
No Data Loading
workflow
development
Yes
QC job
Load data
to
OpenWorks
Run test
loading
Relevant
workflow?
No
QC data
workflow
development
Yes
QC data
Fig. 3—Typical flowchart of data loading to the OpenWorks project
database. The process of data loading, irrespective of their types,
includes stages of data gathering, preliminary processing, and actually
loading with QC on each stage. QC checks the uniformity of names, as
outlined by a company’s naming system. Adhering to company
procedures and standards is also an important part of data control.
Let’s begin with basics of file naming and the convenience
of using prefixes.
A file name should be informative, reflecting the
actual content of data, and should be an appropriate
length and be as unique as possible. It is best to avoid
using names with 1–2 characters; while they can be convenient in the short term, using these names permanently is
unacceptable. Extremely long file names, as a rule, are unreadable at first sight, and in some cases, can exceed the
admissible file name length. For different variations of the same data, it is desirable to use an original file name with the
addition a version number or edition date. Because the Landmark classical package works in UNIX/Linux systems, it is
important to use their wide range of capabilities and to understand the specifics of these systems so that file names are
assigned using the appropriate characters and symbols allowed by the operating system.
When using the OpenWorks software and its applications, each user should be assigned an interpreter ID, which
should not exceed 5 characters. StratWorks, PetroWorks®, and Z-MAP Plus interpretation data, including grids, contours,
well correlation, startigraphic columns and surfaces, well lists, well templates, etc., are assigned to the interpreter ID. The
interpreter ID is a convenient key-in data search, and it is recommended to create a clue for using it.
Many modules of applications in browser windows are capable of sorting data by various fields, and
consequently, if the capital letter in the interpreter ID is used as a prefix at the beginning of a name, then when sorting
the data alphabetically, your data will be grouped together. This simple reception allows for the facilitating of a particular
data search. The use of a prefix is not only convenient when naming the data that will be assigned to a database, but also
any other data that may be stored in common directories of a project (session files, format files, etc).
A little bit about the file extensions
Naila Huseyn-zada
3/6/2016
Page 3 of 14
Fundamentals of Data Management in Landmark applications environment.
File extensions should be used for describing data types. Unlike Windows, where a type of file is defined solely by
its extension, in UNIX/Linux systems, the extension has no significant importance. A file can have one, two, three, or more
extensions, or no extension at all because the system recognizes it as only a file name and nothing more. For example,
you can easily create a simple text file and type the extension gif or sh. The system will not try to open the file as a picture
or a shell script based on the extension provided because for OS, it is not the file name that is important, but its index
description. For the convenience of UNIX/Linux experts, it is acceptable to adhere to standard extensions.
The guidelines for file extensions mentioned above apply exclusively to UNIX/Linux systems. In Landmark
applications, the rules for extensions are completely different; applications actively use and distinguish between many
extensions, which are specific for each application. Documenting within the Landmark application is supplemented by
appropriate catalogs for data types and their extensions.
As you can see, extensions are convenient and important in the definition of the data types; it is necessary to be
instructed in their use and to put them into practice.
All about well headers
The OpenWorks database offers about 200 tables as well as all data forms in the Well Data Manager module for
all possible well information, but the main data forms that categorize a well according to its type and locations include
Well Header, Elevation, TD, Directional Survey, and Positional Log. OpenWorks Well headers are developed to provide as
much information as possible, and we should use this capability to the maximum. Well Header offers many fields. We will
first consider the fields that identify the well name, namely UWI, Common Well Name, Well name, and Well Number.
In an ideal situation, each well would possess a certain unique identification number within a company,
corporation, or country. If such information is not present, then we should devise a rule for creating UWIs. The Common
Well Name field, as indicated by its name, should contain the full name of a well; the Well Name field can be filled by a
shorter name of a well, and the number of a well can be entered into the corresponding field. Such well naming allows
using the option of Landmark applications to display a name of any header fields and/or well number listed above
according to a task or the desire of expert, which is highly useful in the case of regional analysis and mapping.
The following Well Header fields are especially important and demand attention:
 XY surface, XY borehole
 Elevation and Elevation type
 Total Depth
 Current Well Status
 CRS
 Data Source
 Remark
Position Log Data of a well are calculated based on the coordinates of well head and the directional survey data
adjusted for elevation and the Cartographic Reference System. Calculated by the table of the positioned log data, the
coordinates of well buttonhole are automatically written to the Well Header. The elevation and total depth values
inserted into Well Header are replicated in the corresponding data forms.
It is highly important that the key fields contain accurate information, otherwise all subsequent well
interpretations may be erroneous. Besides, the absence of parameters can lead to incorrect visualization of a well in
applications. For example, the absence of a Total Depth value does not allow for the visualization of a well in the
StratWorks Correlation panel.
It is necessary to pay special attention to the Current Well Status field of a Well Header. By default, the absence
of this information is identified by status UNKNOWN, but if there is correct information in the field, it is possible to build
maps in StratWorks and Z-MAP Plus applications with drawing symbols of well statuses, and also to visualize wells in
AssetView™ software with defined colors matching a particular well’s status. OpenWorks database offers a set of
standard well statuses in corresponding control tables and assigned symbols to these statuses. These data can be
extended and corrected through the Well Symbol Editor and Data Domain Dictionary. The history of well statuses, aside
from the Well Header, can be fixed in the special OpenWorks table—Well Status History. This information is useful in
studying the history of a field.
The Field Data Source of Well Header is also highly informative in the analysis and search of data sources.
Because data management also includes the knowledge of data sources, it is necessary to pay attention to records of
similar information as well. In the absence of corresponding fields, any other information pertinent to the Well Header
can be entered into the field, Remark.
It is necessary to remember that there are no trivial fields in Well Headers. There are a few more fields, which, in
the presence of the unified data, can be used as keywords in sorting, including Basin, Country, Field, Operator, and
Platform ID. The data in these fields are not essential, and, as a result, data are not entered into these fields or entered
without paying attention to spelling. While manually creating or editing Well Headers, OpenWorks database verifies the
entered data in these fields with special validation tables. If nothing was entered into these fields, the system assigns the
default value—UNKNOWN.
Naila Huseyn-zada
3/6/2016
Page 4 of 14
Fundamentals of Data Management in Landmark applications environment.
Fig. 4—The basic module for well data management. The Well Data Manager is the utility that allows users to view, edit, and delete well
information from a database. A user displays information by using data forms. Each data form contains data from one database table, such
as pick data, fault data, or log curve data, enabling a user to be focused only on necessary information.
In cases of batch data loading and loading data by the ASCII Loader, the data validation is not often activated,
and if in headings of the loaded data there are records of these fields (it is often observed in the headers of log curves in
LAS format), then all possible samples of a country or field writings are loaded to the OpenWorks project tables. It is,
therefore, difficult to be consistent if the OpenWorks project offers a wide variety of data (for example, AZERBAIJAN,
Azerbaijan, AZE). Such a discrepancy is immediately discovered in applications, including Well Data Manager, WOW, and
AssetView programs, in which a search by keys is offered and, thereby, renders the search inefficient.
Regardless of how large or small an OpenWorks project is based on the numbers of wells, it is necessary to fill in
all the above-listed fields correctly according to the generally-accepted naming scheme, thereby creating the basis for
merging data into large regional projects. The utility Data Dictionary allows the correcting of validation tables of
OpenWorks projects and adapting them to the naming scheme designed by a workgroup or company.
The primary goals of well headers data management are:
 Naming scheme development for well names, statuses, and their symbols;
 Correct entering of the information into header fields;
 Periodic audit of well headers.
Stratigraphic data
OpenWorks database offers the capability for each interpreter to create his own stratigraphic column for well
analysis. Experience shows that this possibility generates a mass of well picks and stratigraphic formations. A detailed
study of this mass found that several of the picks, in fact, have the same names, but different registers, syntax, and
abbreviations were used in the naming, and, as a result, these picks do not match each other (e.g., Pick A, PickA, pick A,
pick a, etc.). Variations are endless.
The occurrence of such a name variety in identical picks is based on the fear of interpreters “losing” and “not
recognizing” their own interpretation, which indicates insufficient understanding of the OpenWorks and StratWorks
application capabilities.
For OpenWorks database creation and storage, identical picks with the same names is not complex, as the Pick
Observation Number (the arbitrary number designating a particular pick) and Data Source (the interpreter ID) parameters
are being assigned to each pick. Therefore, the interpretation is assigned to the concrete interpreter ID that the security
system of OpenWorks data is based on; the applications do not allow the pick assigned to interpreters by another
interpreter to be changed without special permission. Permission might be granted in the case of carrying out a group
interpretation when several users are associated with one interpreter ID.
Naila Huseyn-zada
3/6/2016
Page 5 of 14
Fundamentals of Data Management in Landmark applications environment.
This feature prevents data duplication and the
complicated procedure of comparing and merging results of
interpretation under one interpreter ID, or the necessity to
assign the data to public ownership. OpenWorks database
also allows for decisions of specific tasks by a single user to
use several interpreter IDs and to have various versions of
interpretation assigned to these interpreter IDs.
The unification of stratigraphic names is just as
necessary for a single project as it is for the whole database.
There are quite a lot of advantages for it, for example, pick
data transferring together with other well data from project
to project, which enables regional analysis without
adaptation of the data and additional association of the
stratigraphic column. Moreover, the unification of pick
names and stratigraphic formations enables the use of
production data in StratWorks database (this topic is
covered widely in the “Production Data” section).
Stratigraphic formation attributes (Zone Strat Attribute),
including formation pressure, permeability, porosity, water
saturation, etc., also demand an effective naming scheme,
otherwise the difficulties appear in mapping in StratWorks
database.
The primary goals of stratigraphic data
management are:
 Naming scheme development for formations,
surfaces, picks, and formation attributes;
 Creating the standard stratigraphic column;
 Correctly entering data into a database;
 Periodic auditing of pick data.
Fig. 5—The basic stratigraphic frame of an OpenWorks project.
Stratigraphic column defined by the Strat Column Editor utility
establishes interrelation between surfaces and stratigraphic units.
Log curve data
Fig. 6—Log-curve interpretation in PetroWorks® Asset software. The log-curve data
processing in the classical package is carried out by applications of the PetroWorks
family. This package of petrophysical applications is directed on the decision of a
wide range of tasks, the analysis of log curve data, and petrophysical interpretation.
For the unification of log-curve names,
Landmark offers a list of more than 500 curve
names by default, based on the Schlumberger
curve names list. Upon loading the log curve into
an OpenWorks project, a curve, whose name is
not described in the above-mentioned list, the
Curve Loader utility offers two options—to pick a
log curve name from the list of available names or
to add a new name to this list.
Whether or not the log-curve name
unification assumes that within a project or a
database as a whole, that the log curve of one
type will be named identically, for instance, in the
presence of set of variants of names, it is
reasonable to use a minimum of variants of
gamma logs: GR = {gamma, GR, GR_v1}.
The unification of log-curve names, aside
from data ordering, offers the following
advantages in applications:
 creating the unified well templates that
simplifies well data analysis in
StratWorks and PetroWorks;
 selecting a long list of wells that instantly
accelerates the log-curve display in
SeisWorks and AssetView application;
 shortening a list of log-curve names that simplifies the data selection for manipulation;
OpenWorks database enables the joining of log curves into groups corresponding to certain acquisition data
denoting the Logging Service Name (e.g., a set of log curves “MUD_GAS”). It provides usability in the management,
processing, and edition of the data, both for PetroWorks software and for data transferring to third-party applications, for
which the OpenWorks application is a database. If log curve data are processed, interpreted, or cannot be associated with
Naila Huseyn-zada
3/6/2016
Page 6 of 14
Fundamentals of Data Management in Landmark applications environment.
some specific set, then such log curve data are loaded as composite/processed data. The specific service name can be
added to the database via the Data Domain Manager. The primary goals of log curve data management are:
 Naming scheme development for log curves and logging service names;
 Correct entering of the data into a database;
 Edition of the log curve parameters in Curve Dictionary—log curve types, amplitudes, color;
 Periodic audit of log curve data.
Production data
The OpenWorks database enables the storing of oil, gas, condensate, water production, and injection data daily,
monthly, and cumulatively, as well as perforation, completion, and treatment data. These data can be identified by wells,
an oilfield facility, leases, or by fields. In my practice, production and injection data were assigned to wells, and
OpenWorks database served as a database for DTVIP, GeoGraphix®, and DSS applications. The usability of such storage is
obvious—the database reliably protects against losses; the data are periodically updated, and named applications easily
import the necessary data to particular working projects. In classical applications, it is possible to build bubble maps in
StratWorks on the basis of production and injection data and to visualize these diagrams in AssetView software. One of
the basic elements for the storage of production, injection, and perforation data is the producing zone identified by
Zone_Name parameter, which should be correctly associated with the corresponding stratigraphic formation. In case an
association is made, the production and injection data become accessible in StratWorks database.
The second important point in data loading of production and injection is the unit of measure of their volumes. If
the production or injection is measured in units that are not supported by OpenWorks database, e.g., in tons, the unit
(“TON”) is indicated in the special field VO_USER_DEF, or production data can be converted into acceptable units by
OpenWorks, particularly barrels. For such conversion, a value for a substance’s specific weight is also required. After the
recalculation, the edited data can be loaded to the database. I believe that the first method is more rational, as there is
no recalculation or possible mistakes and errors.
OpenWorks offers a set of tables for storing all possible production and injection data. In addition, the
mentioned data in these tables can store information about the analysis of a produced substance (oil, gas, and/or water),
production zone properties (reservoir thickness, pressure, permeability, water saturation, reservoir temperature, etc.),
annotation information for production and injection entities, etc. The primary goals of production data management are:
 Naming scheme development for production zone;
 Correct entering of data in to a database;
 Periodic audit of data for regular updating.
In addition to well data
We have already discussed the data that are actively used by our customers, but the full list of data, which
Landmark applications work with and which can be stored in OpenWorks, is great enough. Covering all the data is
obviously not possible for this article. I will present only a short addition to well data. The StratWorks application works
with the following data:
 Well Core (Shift Values, Core, Core Description, Sample Description, Sample Analysis, Sample Property);
 DST & RFT (DST Job Header, DST/RFT Cushion, DST/RFT Fluid, DST/RFT Materials to Surface, DST/RFT
Summary, DST/RFT Pressure);
 Well Test (Well Test, Well Pressure, Well Pressure AOF, Well Pressure AOF 4 Pt, Well Pressure Bottomhole);
 Well Planning (Well Plan, Plan Parameters, Targets, Optimization Parameters);
 Well Drilling (Rigs, Platforms, Slots, Drilling Objectives, Drilling Summary, Mud Reports);
 Well Equipment (Casing, Completion, Liner, Packer, Perforation, Plugging, Tubing).
The primary goals of well data management are:
 Initial data QC and validity check;
 Correct entering of data into a database;
 Periodic audit and QC of data.
Seismic data
The allocation of seismic and seismic interpretation data in OpenWorks database differs from other types of data
allocations; for example, not all data relating to seismic are stored in an OpenWorks project database. OpenWorks tables
store 2-D lines navigation data, 3-D survey data, 2-D horizons, faults, horizon and seismic data catalogs, seismic, and
horizon data-processing history, as well as information about the physical allocations of data, which are stored out of the
Oracle database as flat files. The data stored in Oracle database include seismic data, 2-D and 3-D, and 3-D horizons.
As mentioned earlier, all these data can be associated with the so-called interpretation projects (IP), which
represent the logical data collection. Any number of interpretation projects can be created in one OpenWorks project
database. As a result, data are being associated with IP virtually, but not physically, in which the IP enables the sharing of
data dynamically, thereby eliminating the necessity for copying and subsequently duplicating the data. User access to the
Naila Huseyn-zada
3/6/2016
Page 7 of 14
Fundamentals of Data Management in Landmark applications environment.
IP is controlled at the level of each project. Such decision of access improves data security by means of restricting the
visibility of data to foreign users.
Each IP contains its own data, including color maps, format and sessions files, etc. IP files, which are not stored
within OpenWorks projects database, are located in the hierarchy of the file system according to the special allocation
schema, as described in the $OWHOME/conf/dir.dat file. The structure of such a file, for example, may look as follows:
/pa OTHER_FILES
/pb 3d_horizons
/pc 3d_seismic
District
OWSYSSID
owdir.dat
dir.dat
OW_PROJ_DATA
OWSYSSID
OW_SYS_DATA
Directories for
external project
data
Well symbols
Litho symbols
Data-load formats
OpenWorks Projects DB
Interpretation Projects






Project CRS
List of Lines/Surveys
Well list
Constraint Views
Unconstraint Views
Local Views






Original CRS
Wells
Logs
Seismic Data
Horizon Catalog
2D Horizons






Picks
Faults
Pointsets
Grids
Contours
Lists
OpenWorks
Projects Database
in an Oracle server
«Classical»
Applications
SeisWorks
StratWorks
PetroWorks
PostStack/PAL
TDQ
WellBorePlanner
ZMAP Plus
OpenWorks Project Data Files







Seismic Volumes
3D Horizons
Session files
Color files
CGM
ZGF
Mapping Contour files
Fig. 7—Data structure in OpenWorks environment. OpenWorks database stores project data in the Oracle
database and in a file system; the last one also contains applications files. This diagram represents all basic
components of OpenWorks database, which implement data storage and allocations.
According to the given allocations schema, the file system, /pb contents 3D horizon files, /pc – seismic data, and
/pa, and all other files imply certain extensions (color maps, sessions files, etc). Such a schema for file allocation is not
mandatory and can be changed for each specific case.
For the usability of seismic data allocation and management and especially for the usability of carrying out
backups, it is recommended to store the files of infrequently-updated data (seismic files) separately from files that are
updated often. Such allocation allows for the development of a back-up schedule so that file systems with dynamic data
can be backed up regularly.
Interpretation projects are based on the following primary data:
 seismic data 2-D and 3-D
 navigation data
 horizons
 faults
For work usability, the names of all above-mentioned data should be unified, not contain metasymbols, and be
informative and readable. Using prefixes helps to conduct a fast search and selection.
Fault interpretation in SeisWorks, PowerView, and DecisionSpace Desktop applications is based on so-called
segments, the smallest part of a fault. For usability during the interpretation, fault segments are assigned to a fault just
after the final decision of an interpreter to keep the concrete version of interpretation. If such an operation is not
performed on time, a mass of unassigned segments appears in the database, which complicates data ordering, data
Naila Huseyn-zada
3/6/2016
Page 8 of 14
Fundamentals of Data Management in Landmark applications environment.
manipulation, and most importantly, decelerates the speed of selecting a fault from a database. The primary goals of
seismic data management are:
 Considered data allocation in file system hierarchy;
 Name scheme development for horizons, faults, and seismic volumes;
 Name scheme development for maps and grids;
 Periodic audit of horizon and fault data;
 Removal test and mistaken interpretation; timely assignment of fault segments.
Lists and lists managers
OpenWorks database enables the restriction of the data selection for a working session of any applications by
various lists, from which the most actively used are well lists, lists of horizons lists, and faults. The lists enable the joining
of data of interest and are especially useful in large projects, as they significantly reduce the time for searching and
loading data into applications. Lists of horizons and faults can be created in SeisWorks software directly at the data
selection from a project. For wells, a
separate utility, the Well List Manager,
possesses a wide range of capabilities in
which a search can be conducted by well
details (log curves, picks, fault picks, and
zone strat attributes), comparisons of
among already available lists, and
broadcasting a selection to applications
without creating a list. Lists can also be used
for data transferring, both between
interpretation projects (SeisWorks Data
Transfer) and between OpenWorks projects
(Project Data Transfer).
Using lists, it is possible to create
and modify interpretation projects. In
addition to the above-named utilities, there
are other utilities that can be used for
creating and working with lists. Field List
Manager uses the data from fields and wells
assigned to them. This utility is useful for
large projects that cover various oil fields. As
previously mentioned, inserting information
into the Well Headers field creates the
usability for appropriate well selection and
its associated list. The Lease List Manager
enables the uniting of wells by leases, and
Seismic List Manager manages by lists of the
seismic 2-D lines. The grid lists unit grids,
which are useful for grid visualization in
Fig. 8—Lists managers. Lease, Field, Seismic and Well List Manager. Each of these managers
AssetView, thereby enhancing the search for
enables the creation of lists through a simple selection of the required data or by way of
required data.
certain criteria. The Pointed Dispatcher allows users to send the selected data to other
Through the use of OpenWorks
applications.
projects over the years, much of the
information accumulated has served to be useful, while some has not. There is certainly a risk of wasting time searching
through these multiple lists, which naturally reduces efficiency, which is why well lists, other lists, and all data in general,
should be periodically audited and the outdated information removed.
The primary goals of list management are:
 Name scheme development for lists;
 Creating general-purpose lists;
 Periodic audit of lists and the removal of outdated lists.
Data import and export. Data manipulations
After this short discussion on the types of data that can be managed in the OpenWorks database, we will talk
about the utilities for loading and unloading these data. In OpenWorks database, there are various utilities, each of which
is compatible with certain types of data. ASCII Loader imports well data to the OpenWorks database in text format, ASCII,
while Well Data Export is used to export well data in ASCII format. The Curve Loader imports log curve data, directional
survey and position log data, synthetic seismograms, and time-depth tables.
Naila Huseyn-zada
3/6/2016
Page 9 of 14
Fundamentals of Data Management in Landmark applications environment.
The Data Import/Data Export Wizard allows you to load and unload mapping data. The Seismic Data
Loader/Seismic Data Export is used to import and export navigation data of 2-D seismic lines. All these utilities are
provided by a sample of format files by default and are highly useful for creating your own format files.
The export option is available in many of these utilities. In the Well Data Manager, the data can be exported in
PDF, XLS, HTML, and text formats. The Pack & Go function in the Seismic Data Manager allows for the exporting and
importing of horizon and seismic data files. The Data Domain Manager, Map Data Manager, Curve Dictionary, as well all
list managers have the capability to export into text format.
Besides the ability to load in a graphical interface, OpenWorks database offers special programs for batch loading
well and log-curve data. These programs are run from a command line and used for single or multiple loading. In the case
of multiple loading, it is necessary to create a script with the series of loading, which can then be carried out consistently
and without additional intervention. This capability is highly useful when loading a large amount of data. With regular
loading of data to OpenWorks database, the script execution can be automated by setting start-up via the job-scheduler
UNIX utility - cron.
The
Project
Data
Transfer (PDT) feature is used for
the transferring of data between
OpenWorks
projects
and
interpretation projects. This
utility works with several data
types stored in OpenWorks
database. Moreover, PDT is
capable of transferring data
between projects that are located
in various Oracle databases. As
you can see, once loaded to
OpenWorks,
data
and
interpretation data can be easily
transferred from project to
project, bypassing the necessity
for unloading and subsequent
loading.
For the loading of
seismic data in SEG-Y format,
users are able to take advantage
of the PostStack Data Loader
feature (incomplete version of
Fig. 9—The basic data flows of input and output from OpenWorks database projects. Landmark offers
PostStack/PAL), intended for
the series of utilities for data import and export, which help a user to transfer between applications
seismic data loading to Landmark
working in the OpenWorks environment and other third-party applications and databases.
formats—bricked
file
(.bri),
compressed file (.cmp), 3-D
vertical section file (.3dv), and time-slice file (.3dh), as well as for seismic data exporting from Landmark formats to SEG-Y.
Full package PostStack/PAL contains a set of 45 possible seismic data processing operations. However, for interpretation
project (IP) management and seismic data loading, the applications of PostStack Data Loader are quite sufficient. The
primary goals of data manipulation management are:
 Name scheme development for source data and format files;
 Creating general-purpose format files;
 Source data storage and archiving system development;
 Documentation on source data storage;
 Periodic audit and removal of outdated format files.
Data management applications
So far, we have covered OpenWorks database, the primary database of the Landmark classical package, and all of
the possible data that can be stored in it and actively used by applications, the necessity of a naming scheme for each
data type, the capabilities for data manipulation in the OpenWorks environment, and the tasks facing data managers. It is
important to remember that while OpenWorks database is the main database for applications, it also allows for some
applications to have their own database. For example, Z-MAP Plus software creates files with metadata MFD, with
graphical data ZGF, and many other files. These files can be included or not included in the OpenWorks hierarchy, but
either way, the application creates its own database. GeoProbe software actively works with OpenWorks and SeisWorks
data, but at the same time, creates its own hierarchy of directories, both with its own data and data converted from other
applications. In this same way, ProMAX® software creates libraries of seismic data and so forth.
Naila Huseyn-zada
3/6/2016
Page 10 of 14
Fundamentals of Data Management in Landmark applications environment.
The main principles stated for an OpenWorks database are applicable to all possible geo-data and to each of the
databases as well as the tasks of data management for a whole set of various geo-data, data storages, databases, project
data, etc., as follows:
 Development of a name scheme for each type of data
 Development of a data allocation system in a file system hierarchy
 Development of a storage system of source data
 Development of an archiving system of completed projects
 Documentation conducted about the data availability, receipt, and transmission
 Data quality control on each stage of working with them
 Periodic data audit and the removal of mistaken, temporary, and outdated data
 Creation standard templates, lists, columns, colour maps, format files, etc.
Irrespective of their size, the presence of various databases and data storages are observed by today’s oilfield
companies. Below are two primary goals:
 Creation of verified and reliable data that can be used as a basis for project creation;
 Integration of databases into one general interface for facilitated access to each element of data and for
effective data quality control.
I have shown that for the first task solution, OpenWorks database, as a base, is the most appropriate option. For the
second task solution, as an aid for data managers, Landmark offers a whole list of applications for solving problems both
within a working group and a corporation. The following sections discuss four applications, which are effective for
reaching the primary goals of data management and meeting the general requirements of a medium-sized company.
Web OpenWorks (WOW)
As previously mentioned in the beginning of this article, the primary goals of efficient data management include
the reduction of time spent on data retrieval required for making a business decision, the simplification of the search for
previous interpretation data, and the completion of quality checks on the available data. These and many other tasks are
solved by the WOW application. The WOW application allows access to data through the company intranet. The easy-touse interface allows for the viewing and analyzing of data from all databases of such Landmark applications, including
OpenWorks, SeisWorks, GeoProbe, Z-MAP Plus, ProMAX, CDA, VIP®, Asset Journal™, as well as the third-party application,
Geolog.
It is remarkable that
when viewing the application
data, the applications that
created these data are not
being used. WOW program
also has the capability of
providing QC data and
comparison analysis across
multiple projects, which is
especially useful for data
managers. For OpenWorks
data QC, queries and scripts
are written on SQL, the set of
which can be extended by
existing script files. With the
results of any query, the socalled reports, can be saved in
Excel format. For graphic data,
there is a converter ZGF to
shapefiles (data format for
ArcGIS) in the WOW program
and a converter OpenWorks
basemaps to KML (format for
Google Earth).
WOW has many other
valuable features. However,
Fig. 10—Access to Z-MAP Plus data through the WOW interface. WOW interface easily solves many data
the most important feature is
management tasks and, among them, such tasks as joining data into one interface and even e-mailing to
the efficient accessibility it
users the notifications about data updates.
provides to all geo-data
available in a company network. This application is a valuable tool, not only for a data manager, but also for any expert,
especially for upper-level management for whom it is important to view all of the geo-data of a company.
Corporate Data Archiver™
Naila Huseyn-zada
3/6/2016
Page 11 of 14
Fundamentals of Data Management in Landmark applications environment.
The importance of backing up this information is clear as soon as the first digital document appears. It cannot be
otherwise, as the data loss and inability to restore it quickly leads to severe losses. There have been cases in which
commercial organizations that have experienced a loss of data have gone out of business. Many companies today make
the decision to archive their data; however, archiving presents yet another problem: how, once archived, can the data
then be found and restored? A highly-detailed description of the data can be found in the archival documentation, but
this is not always the case, especially for the geo-data.
Landmаrk offers users the Corporate Data Archiver™ (CDA) application, which only makes copies of the data on
media for archiving. The CDA application creates an organized archive of the data as well as information and data from a
particular activity, such as a field study or prospect evaluation.
CDA application organizes data into logical archives. For example, the archive can contain multiple geological and
geophysical projects, Linux directories containing varied applications data, and documents from Microsoft Office from
different shared folders. Thus,
detailed “snapshots” of projects
are produced, which are always
accessible online, even after the
archive is transferred to
external media, such as tapes or
disks, and removed from the
system. Snapshots contain such
extensive data in the archive
that there is no need for
restoration just to see the data.
In addition to the CDA
program, with this application,
OpenWorks, SeisWorks, Z-MAP
Plus, GeoProbe, ProMAX, and
VIP projects are archived, and
snapshots of projects in a set of
files in HTML format are
accessible in WOW. CDA at the
objective level creates the
metadata in the Oracle
database, but it is possible to
work with application itself in
Linux, like with the WOW
application.
Asset Journal™
Fig. 11—Snapshots of seismic horizons in the Corporate Data Archiver application. The possibility of
Sooner or later, any
creating tiny images of seismic horizons, cubes, and lines renders CDA irreplaceable both for archiving and
group, department, or company
for an estimation of the data in the cleaning process.
as a whole will realize the need
for the creation of an electronic
library of the documentation on geo-researches. As a result, Landmark recommends the Asset Journal easy-to-use
application for creating documents in HTML format. Asset Journal application edits and operates all types of information,
including common files, screen captures, tables, audio files, and images. Thus, Asset Journal application enables the
creation of all possible documents and organizing them into libraries, including reports, procedures, atlases,
presentations, notes, and notices. In addition, the ability to access Asset Journal projects through WOW software enables
continuous access to company documents. Moreover, using this application while working on a project allows experts to
prepare a report directly in an operating time.
PowerExplorer™
If you work for a globally-dispersed corporation, as most modern oil companies are, or different databases for
geo-data are available, it is often difficult to centralize and identify dispersed information resources and knowledge,
including the spatial data in files and databases, ESRI, or Landmark ZGF. In large companies, data managers need the
capability to view data from different sources, saving information for the creation of basemaps and efficient transferring
of information in a timely and cost-effective manner.
Let’s say, for example, that management needs to make an important decision regarding a particular lease and
there is a deadline to find all information on this lease as well as its limits, say, a radius of 2–3 km. The problem becomes
complicated when this information is contained in different company databases. PowerExplorer database is ideal for
these types of situations. This package allows you to carry out this type of search quickly and qualitatively. The selected
information arrives in the project, bypassing the tiresome and dangerous stage of exporting data to external files. Thus,
Naila Huseyn-zada
3/6/2016
Page 12 of 14
Fundamentals of Data Management in Landmark applications environment.
the dilemma of centralizing the different databases and granting a common interface for search and transfer of this data
for future research is resolved by the PowerExplorer application.
The PowerExplorer application is based on web technologies and contains the broadest capabilities for viewing
and managing spatial and tabular geo-data. The application is capable of integrating every possible geo-data store,
including OpenWorks, SeisWorks, Z-MAP Plus, CDS, MDS, ArcGIS, GeoFrame projects, etc. A user has direct access to the
data from the database without the risk of duplication.
Because the PowerExplorer application is capable of performing quick and effective searches of different geodata, it provides unobstructed data exchange between various applications and, most importantly, gives data managers
the opportunity to have complete knowledge about the available data for easy estimate and quality control.
Fig. 12—Window PowerExplorer application with data sample of the AOI. The Area of Interest Wizard allows users to easily create a
geographical area with which they want to work and to operate them to add other sources of the data for display.
Afterword
It is important to remember that only with a proper attitude towards information, no matter how small or large,
in combination with the use of these technologies, is it possible to be successful in data management. The success in data
management, cost-based at first glance, will pay for itself in repeated profit through the reduction of errors in decisionmaking owing to incomplete or unreliable information. Experts can now spend their time working with the data rather
than searching for them and trying to understand the degree of their reliability.
As a whole, the scale of a data management is huge. Challenges associated with data management are extensive
and require efficient application toolkits for the most difficult customer needs. Using WOW, CDA, and PowerExplorer
applications, Landmark offers users a whole spectrum of applications for data management that are interesting, multipurpose, and effective in solving problems for large corporations; these applications include TeamWorkspace®, Reference
Data Manager, Advance Data Transfer, Corporate Data Store, and PetroBank® Master Data Store™. These applications
solve problems specific to that particular application and should not be used interchangeably. Altogether, they will allow
for the creation of not only an effective data management system, but a degree of company satisfaction. The description
of all Landmark applications for a data management is not included in this article, but detailed information about these
applications can be found at www.lgc.com.
It is necessary to note that in addition to using these technologies and the availability of proper instructions for
data management, through daily work, a keen interest in data management and in the capabilities of available
applications, constant search for new decisions, innovation and enthusiasm in the business will lead to positive results.
Naila Huseyn-zada
3/6/2016
Page 13 of 14
Fundamentals of Data Management in Landmark applications environment.
If this article has proven useful to you, then it has succeeded in reaching its goal. Please send your responses on
my corporate email nguseinzade@lgc.com, and I will be glad to continue the discussion on the topic of data management
using the Landmark classical applications with you.
Reference







OpenWorks® Software Data Management. OpenBook June 2009, Release 5000.0.1.0
OpenWorks® Software Data Import/Export. OpenBook June 2009, Release 5000.0.1.0
OpenWorks® Release 5000.0.2.0 Data Model. OpenBook June 2009
“Corporate Data Archiver™ Software” data sheet, H05675-A4 03/10
“PetroWorks® Asset Software” data sheet, H04854-A4 03/08
“PowerExplorer® Software” data sheet, H04857-A4 01/08
“WOW™ Software” data sheet, H05653-A4 03/10
All trademarks and copyrights referenced in this article are property of their respective owners. All rights reserved.
Naila Huseyn-zada
3/6/2016
Page 14 of 14