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
log-curve analysis
geological interpretation
velocity modeling
mapping
data management
Data
collection
for
sharing
and
collaboration is called the OpenWorks project.
The OpenWorks application includes two types
of
projectsproject
databases
and
interpretation projects. The OpenWorks project
database is organized in the Oracle relational
database and represents 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, Fig. 1OpenWorks database is a basis for various
faults, seismic navigation, production data, geological and geophysical interpretation. All data in the
OpenWorks project database and its environment are interinterpretation, etc.
The number of interpretation projects connected, which allows users to work with highproductive applications for teamwork.
that represent a subset of the data or a certain
area of interest can be unlimited within a project database. Physical data are located in a
database for interpretation projects to 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.

Naila Huseyn-zada

1/6/2016

Page 1 of 15

Fundamentals of Data Management in Landmark applications environment.

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.
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
Fig. 2World Oil Award to OpenWorks database for
data transferring from a project to a Best Data Management Solution 2008. Over the last
project and from a project to an application 10 years, Landmark applications received 4 additional
awards by the World Oil journal: GeoProbe software
workflow and standard development
in 2001 for the Best Development, Production, and
data archiving
Reservoir Data Solution; AssetView software in 2003
for Best Visualization Solution; GeoProbe software
documenting
again in 2004 for Best Data Visualization Solution,
These operations assume a degree of and DecisionSpace Desktop application in 2010 for
knowledge in various areas. Depending on the Best Visualization and Collaboration Solution.
volume of data and a suite of applications, data
management can involve a single universal 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 selfdevelopment. Unlike other specialties in which a considerable quantity of books and manuals are
available, the data management program, particularly in the area of geo-research, 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;
Naila Huseyn-zada

1/6/2016

Page 2 of 15

Fundamentals of Data Management in Landmark applications environment.

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.
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 companys key
objectives
and
incorporating
data
management fundamentals and criteria of
data quality control. This experience can be
adopted, developed, and adapted to a
companys 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

Fig. 3Typical 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 companys naming system. Adhering to company
procedures and standards is also an important part of data
control.

Lets 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 12
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
Naila Huseyn-zada

1/6/2016

Page 3 of 15

Fundamentals of Data Management in Landmark applications environment.

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
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.

Naila Huseyn-zada

1/6/2016

Page 4 of 15

Fundamentals of Data Management in Landmark applications environment.

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 wells 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 valueUNKNOWN.
In

Fig. 4The 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.

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
Naila Huseyn-zada

1/6/2016

Page 5 of 15

Fundamentals of Data Management in Landmark applications environment.

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 Fig. 5The basic stratigraphic frame of an OpenWorks
insufficient understanding of the OpenWorks project. Stratigraphic column defined by the Strat Column
and StratWorks application capabilities.
Editor utility establishes interrelation between surfaces
For OpenWorks database creation and and stratigraphic units.
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.
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.

Naila Huseyn-zada

1/6/2016

Page 6 of 15

Fundamentals of Data Management in Landmark applications environment.

Log curve data

Fig. 6Log-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 abovementioned list, the Curve Loader utility
offers two optionsto 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 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 Dictionarylog 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
obviousthe 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 substances specific weight is also required.

Naila Huseyn-zada

1/6/2016

Page 7 of 15

Fundamentals of Data Management in Landmark applications environment.

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 3D, 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 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

Naila Huseyn-zada

1/6/2016

Page 8 of 15

Fundamentals of Data Management in Landmark applications environment.

/pc 3d_seismic
to

According
given

the

Fig. 7Data 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.

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
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;
Naila Huseyn-zada

1/6/2016

Page 9 of 15

Fundamentals of Data Management in Landmark applications environment.

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 abovenamed 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
Fig. 8Lists managers. Lease, Field, Seismic and Well List Manager. Each
appropriate well selection and its
of these managers enables the creation of lists through a simple selection
associated list. The Lease List
of the required data or by way of certain criteria. The Pointed Dispatcher
Manager enables the uniting of
allows users to send the selected data to other applications.
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 AssetView, thereby enhancing the search for required data.
Through the use of OpenWorks 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.
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

Naila Huseyn-zada

1/6/2016

Page 10 of 15

Fundamentals of Data Management in Landmark applications environment.

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 jobscheduler 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, Fig. 9The basic data flows of input and output from OpenWorks database projects.
bypassing the necessity Landmark offers the series of utilities for data import and export, which help a user
for
unloading
and to transfer between applications working in the OpenWorks environment and other
subsequent loading.
third-party applications and databases.
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 PostStack/PAL), intended for seismic data loading to Landmark
formatsbricked 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
Naila Huseyn-zada

1/6/2016

Page 11 of 15

Fundamentals of Data Management in Landmark applications environment.

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.
The main principles stated for an OpenWorks database are applicable to all possible geodata 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 todays 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 easyto-use 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 so-called reports,
can be saved in Excel
format.
For
graphic
data,
there
is
a
converter
ZGF
to
shapefiles (data format Fig. 10Access to Z-MAP Plus data through the WOW interface. WOW interface easily
solves many data management tasks and, among them, such tasks as joining data into
one interface and even e-mailing to users the notifications about data updates.
Naila Huseyn-zada

1/6/2016

Page 12 of 15

Fundamentals of Data Management in Landmark applications environment.

for ArcGIS) in the WOW program and a converter OpenWorks basemaps to KML (format for Google
Earth).
WOW has many other valuable features. However, the most important feature is the
efficient accessibility it 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
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.
Landmrk 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 Fig. 11Snapshots of seismic horizons in the Corporate Data Archiver application. The
the Oracle database, but possibility of creating tiny images of seismic horizons, cubes, and lines renders CDA
it is possible to work irreplaceable both for archiving and for an estimation of the data in the cleaning
with application itself in process.
Linux, like with the WOW application.
Asset Journal
Sooner or later, any group, department, or company 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.
Naila Huseyn-zada

1/6/2016

Page 13 of 15

Fundamentals of Data Management in Landmark applications environment.

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.
Lets 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 23 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, 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 geo-data, 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. 12Window 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
Naila Huseyn-zada

1/6/2016

Page 14 of 15

Fundamentals of Data Management in Landmark applications environment.

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 decision-making 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, multi-purpose, 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.
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

1/6/2016

Page 15 of 15