With the LEA Data Cataloguing software, you can
Back to:
Database systems based on tables are widely used in the exploration industry to organise and archive exploration data. At the same time, legacy data exist in a variety of proprietary formats, requiring data to be verified and re-formatted before use.
Exploration Archivist converts collections of exploration data files in a variety of formats into an organised archve using the concept of an "exploration data object". For each type of data (report, seismic, well etc) a corresponding LEA Object is defined. This has a set of properties which describe the object's common attributes, but which are independent of the actual file format used to store the data. For a given type of Object, each property corresponds to a field in a database table.
To populate the tables, Catalogue Builder searches a chosen directory structure for files, of the chosen LEA Object type and copies their properties to a the database table fields. The files remain in their original formats. The tables for the various object types are then linked to a reconciliation catalogue, a master database table which links objects with their location information, which can be queried in the usual way for extraction of individual objects or groups.
The geographical locations of objects are derived from location maps, which are themselves objects in the catalogue. This enables data easily to be exported to a GIS, for display as a map, or manipulation on a geographical basis. The contents of individual files can be displayed by specialised viewers, cutomised to individual file types and formats.
Lynx Exploration Archivist can be used either as a stand-alone system or as a general tool for populating existing databases and building GIS projects in ESRI Arcview or other GIS systems.
For each category of file, there are several basic steps:-
The applications in the Lynx Exploration Archivist cataloguing suite comprise:
"Exploration Data" are files, maps, reports, bits of paper, photographs, notebooks, scouting information, books, reports, correspondance, even "real" material like rock and core samples, stream sediment samples, reservoir fluids, thin sections etc. Anything, in fact.
To surmount the problems caused by different and incompatible file formats, LEA uses the concept of an "exploration object", which represents a class of files, all containing a particular type of exploration data. For example, seismic data can be in any one of a number of formats such as SEG-Y, Lynx Trace file, Western Code 4 etc. These formats all belong to the "seismic" exploration object.
Examples of other Objects:
This concept enables all file formats belonging to the same object to be handled in the same way. Each object has a set of attributes, corresponding to a superset of all the properties defined in individual file formats and belonging to the corresponding object. For example, some seismic trace file formats have the property “first shotpoint” – this therefore becomes an attribute of the Seismic object, even though in some seismic file formats (e.g. SEG-Y) this property may not be defined.
LEA standard Object types are
The User object enables new file categories to be created. For example, scanned images of well logs appear to belong either to the category "Raster file", or to "Wireline". You could either create a new category "Wireline Scans", combining the properties of both, or add the Raster File format capability capability to the "Wireline" category .
For details of how LEA Objects are defined, and how to extend an object by adding new properties, or create new objects specific to your data types and formats, see The Lynx Exploration Archivist Object.
For most types of real data, files usually exist in several different physical formats. LEA provides built in drivers for the most common file types. New file types or format definitions can be added by the user using the Object Wizard. In the real world, format definitions are rarely adhered to religiously and data may be missing, incorrect or otherwise corrupted. LEA enables new format variations to be added as they are encountered.
Almost all archiving systems use database tables. Various systems are available, some proprietary, some de facto “industry standard”, some designed by committee. Fields and table structure vary widely for any given data type and field names in different systems are not standardized. There is rarely any proper provision for changing field names or handling foreign language issues.
for details of the database formats supported by Lynx Exploration Archivist see Using Databases in LEA Applications. A recommended set of field names and descriptions is provided by LEA for a simple archiving schema, but these can be adapted by the user to suit local requirements - even the language can be changed, both for the field descriptions and for the data themselves.
To display the archived objects on a map, the Reconciler will build the necessary relationships between exploration objects and location data in the form of location files. These can be converted into shape files for use with ESRI Arcview, or loaded into a spatial database (Oracle Spatial) for use with ESRI ArcSDE, and can be imported into other GIS systems.
A well established principle in windowed operating systems is that clicking on a file’s icon will display the contents of the chosen file type, or launch an application. Exploration Archivist contains effective viewers for seismic, well log, raster files and other specialised exploration data, for use at any point in the archiving process.
An archive is a collection of items with an index to enable search and retrieval. The "secondary" database tables built by LEA for each individual Object type are combined by the Archive Manager into a "primary" or master table. This is a database table containing a description and physical location of all the items, of all types, in the archive. This can be searched using database queries in the usual way, or the Catalog Manager module can be used to select items geographically. More detailed information on any given item is obtained from the secondary table in which it resides, or ultimately from the file itself. A viewer can be used to display the actual contents of the file which is pointed to by the secondary table.
If not already available online, files to be archived are moved to their final locations. The storage medium can be virtually any online, nearline or offline storage device capable of storing files, on tape or disk, with the proviso that the volume labels of the physical storage media should be unique. This enables networked disks, CD-ROM juke boxes and robotic tape stackers to co-exist within the same archive.
For each type of exploration object, a "secondary" database table design
is created in Catalogue Designer (Dougal), tailored to
the attributes which are of interest. (e.g. for Seismic objects – Line
name, first and last shotpoint etc.). The "primary" catalogue is a master table
which contains a reference to every object in all of the secondary tables, for
all object types.
Back to