specifications of standards for digital geophysical …geomind.elgi.hu/doc/d6_2.pdfspecifications of...

Specifications of standards for digital geophysical content

1/64

Grant Agreement Number: ECP-2005-GEO-038150

GEOMIND


Deliverable number D6.2

Dissemination level Public (PU)

Delivery date 31 July 2007

Status Draft, Version 1.2.1

Author(s) László Sőrés (ELGI)

Contributor(s) Mikael Pedersen, Valdas Rapsevicius, Klaus Kühne, Jörg Kuder

eContentplus This project is funded under the eContentplus programme1,

a multiannual Community programme to make digital content in Europe more accessible, usable and exploitable.

1 OJ L 79, 24.3.2005, p. 1.

PDF created with pdfFactory Pro trial version www.pdffactory.com

http://www.pdffactory.com


2/64

TABLE OF CONTENTS

1 OVERVIEW OF THE GEOMIND METADATA PROFILE ............................................................. 4 1.1 INTRODUCTION ............................................................................................................................... 4

1.1.1 Terms and abbreviations............................................................................................................ 4 1.1.2 Packages ................................................................................................................................... 5 1.1.3 Prefixes used in this document................................................................................................... 5

1.2 GEOMIND EXTENSION PROFILE TO THE ISO 19115 METADATA STANDARD ....................................... 6 1.2.1 Metadata entity set information ................................................................................................. 7

1.2.1.1 GE_GeophObjectSet....................................................................................................................... 8 1.2.1.2 GE_GeophObject............................................................................................................................ 9 1.2.1.3 GE_Report ....................................................................................................................................10

1.2.2 GE_GeophysicalInfo ............................................................................................................... 10 1.2.3 identificationInfo ..................................................................................................................... 12

1.2.3.1 MD_GeographicExtent ..................................................................................................................12 1.2.4 distributionInfo (ISO 19115 modified) ..................................................................................... 13 1.2.5 dataQualityInfo (ISO 19115 modified) ..................................................................................... 13

2 OVERVIEW OF THE GENERAL GEOPHYSICAL DATA MODEL ............................................ 15 2.1 HIERARCHY OF GEOPHYSICAL DATASETS (HGDS).......................................................................... 15 2.2 GENERAL GEOPHYSICAL DATA MODEL .......................................................................................... 16

2.2.1 ME_Measurement.................................................................................................................... 16 2.2.1.1 Layout ...........................................................................................................................................18 2.2.1.2 LayoutComponent..........................................................................................................................18

2.2.2 MO_Model .............................................................................................................................. 20 2.2.2.1 MO_LayerModel ...........................................................................................................................21 2.2.2.2 MO_GridModel.............................................................................................................................21 2.2.2.3 MO_GeneralModel........................................................................................................................22

GENERIC GGDM CLASSES........................................................................................................................... 23 2.2.3 GG_ParameterCatalogue ........................................................................................................ 23

2.2.3.1 GG_ParameterType .......................................................................................................................24 2.2.3.2 GG_ParameterSet..........................................................................................................................24 2.2.3.3 GG_Parameter...............................................................................................................................24

2.2.4 GG_LocalCRS......................................................................................................................... 24 2.2.5 GG_DomainSet ....................................................................................................................... 25 2.2.6 GG_Recording ........................................................................................................................ 26

2.2.6.1 GG_MeasDataArray......................................................................................................................27 2.2.6.2 GG_MeasDataElement ..................................................................................................................27

2.2.7 GG_Archive ............................................................................................................................ 28 3 ANALYSIS OF INTERNATIONAL GEOPHYSICAL DATA STANDARDS................................. 28

3.1 SIEMICS ........................................................................................................................................ 28 3.1.1 Present state of the GEOMIND concept................................................................................... 32

3.2 WELL LOGGING ............................................................................................................................ 32 3.2.1 DLIS........................................................................................................................................ 33 3.2.2 LIS........................................................................................................................................... 35 3.2.3 WellLogML.............................................................................................................................. 37 3.2.4 WITSML .................................................................................................................................. 39 3.2.5 LAS 3.0.................................................................................................................................... 41 3.2.6 Present state of the GEOMIND concept................................................................................... 45

3.3 SEISMOLOGICAL DATA ................................................................................................................... 45 3.3.1 SEED ...................................................................................................................................... 46 3.3.2 PASSCAL SEG-Y..................................................................................................................... 48

3.4 MAGNETOTELLURICS..................................................................................................................... 50 3.4.1 Present state of the GEOMIND concept................................................................................... 53

3.5 TDEM.......................................................................................................................................... 53 3.5.1 PCGerda ................................................................................................................................. 54 3.5.2 GAIA-TDEM ........................................................................................................................... 56 3.5.3 Amira ...................................................................................................................................... 58




3/64

3.5.4 WingLink ................................................................................................................................. 58 3.5.5 Present state of the GEOMIND concept................................................................................... 59

4 ANALYSIS OF EXISTING DATA STRUCTURES AT THE GEOMIND DATA PROVIDERS.... 60 4.1 ANALYSIS OF GRAVITY STANDARDS AND DATABASES..................................................................... 60

4.1.1 Present state of the GEOMIND concept................................................................................... 62 4.1.2 References............................................................................................................................... 63

4.2 ANALYSIS OF VERTICAL ELECTRIC SOUNDING DATABASES ............................................................. 63 4.2.1 Present state of the GEOMIND concept................................................................................... 64

LIST OF FIGURES 1. figure, Overview of theGEOMIND object class packages ............................................................................. 5 2. figure: UML diagram of the MD_Metadata element. Standard elements within MD_Metadata are not shown

............................................................................................................................................................... 8 3. figure GEOMIND Extention classes GG_Instrumentation and MeasuringConditions ................................. 11 4. figure, UML diagram of the MD_Distributionand GE_DistributionOption classes. .................................... 13 5. figure UML diagram of the dataQualityInfo class....................................................................................... 14 6. figure UML diagram of the HGDS classes and their relations .................................................................... 15 7. figure UML diagram of the ME_Measurement class. .................................................................................. 17 8. figure UML diagram of the MO_Model class.............................................................................................. 20 9. figure UML diagram of GG_ParameterCatalogue and the related classes.................................................. 23 10. figure UML diagram of the GG_LocalRCS class ...................................................................................... 25 11. figure UML diagram of the GG_DomainSet class ..................................................................................... 26 12. figure UML diagram of GG_Recording and the related classes ................................................................ 27




4/64

1 Overview of the GEOMIND Metadata Profile

1.1 Introduction

To support the international exchange of geophysical information the GEOMIND consortium is going to set up a general standard that will be a base for data transfer through the GEOMIND portal. The core of it is an extension profile to the ISO 19115 standard for geographic metadata. Because of the diversity of geophysical information it is necessary to build a general data model for geophysical datasets (collections of geophysical objects) and a general geophysical data model for detailed geophysical information. To help the community to understand and use the profile best practice examples and basic validation tools will be provided.

The aim of this document is to give an overview of the specified GEOMIND metadata profile and the General Geophysical Data Model. The logical structure of the newly defined classes are presented as UML diagrams. Explanations on the classes and attributes help the reader in understanding the model. For a more technical presentation class definitions are listed as data dictionaries in annex A. This is the base for the schema definitions of the GEOMIND markup language.

1.1.1 Terms and abbreviations Metadata Data about data. It is used to find geophysical information and inform the user about the data source. Header data List of technical parameters related to geophysical measurements. It is part of the GEOMIND metadata extension profile Detailed data Measurement data. It includes layout geometry, measured, processed and interpreted data. HGDS Hierarchy of Geophysical Datasets. Data model to describe complex geophysical datasets and dataset aggregates. GGDM General Geophysical Data Model. A complex hierarchy of entities to describe geophysical measurements (detailed data). GO - Geophysical Object Geophysical object is a generalization of geophysical measurement and geophysical model. GOS - Geophysical Object Set Collection of geophysical objects, Projects, campaigns, or other groups of geophysical objects.




5/64

CRS Coordinate Reference System

1.1.2 Packages Classes that are defined in this document are organized into packages. The hierarchy of packages is shown on figure 1.

1. figure, Overview of theGEOMIND object class packages

1.1.3 Prefixes used in this document Object class names are prefixed by two letter abbreviations. These abbreviations are related to packages that are the following: CI Citation (ISO 19115) DQ Data quality (ISO 19115) EX Extent (ISO 19115) GE GEOMIND object package GG General Geophysical Data Model (GGDM) HG Hierarchy of Geophysical Data Dets (HGDS) LI Lineage (ISO 19115) MD Metadata (ISO 19115) ME Measurement (GGDM) MO Model (GGDM)




6/64

1.2 GEOMIND extension profile to the ISO 19115 metadata standard

The GEOMIND metadata profile is based on the ISO 19115 metadata standard for geographyc datasets that was defined in 2003. The technical implementation of this standard is based on xsd schema language definitions that has been defined in ISO 19139. ISO19115 is a very broad and complicated standard, designed to cover many areas of geographic meta-information. To maintain usefulness and not to discourage potential users it was necessary to reduce the number of supported elements and optimize the metadata content for geophysics. Core metadata components represent the minimum set that must be provided. Community profiles are based on the core component set, a restricted set of non core elements, and may also support metadata extension classes.

ISO19115 metadata community profile The root of the ISO 19115 metadata tree is the MD_Metadata element that is fully defined in the standard. Annex A of this report contains the data dictionary of the GEOMIND data model, and describes the architecture in full details. All standard metadata elements that are not changed by this profile are only referenced. For complete description of standard metadata elements the reader is kindly requested to study the original ISO 19115 documentation, and the ISO 19139 schema definition package. The GEOMIND metadata profile is intended to strongly support the following categories:

• Spatial search by bounding box (or polygon) • Textual search by keywords from controlled dictionaries and header attributes • Temporal search by temporal extent metadata • Data distribution • Quality control

The ISO19115 metadata standard contains classes to store data to help search engines, and provide information on the above categories. There are four areas where the standard doesn’t provide enough facilities for geophysicists, and seems to be inevitable to introduce a few extension classes. These areas are:




7/64

• Description of instrumentation • Description of measuring conditions • Description of geophysical parameters used in a dataset • Brief technical summary about a geophysical object (Header information)

The proposed structure supports these areas and keep the possible minimum to provide a useful metadata profile for the community.

1.2.1 Metadata entity set information MD_Metadata entity set information elements of the GEOMIND profile are based on the ISO 19115 core, with only a few extensions, shortly explained in the following list: dataProvider (GEOMIND) Data providers are identified by a URL. In the GEOMIND portal metadata objects are globally identified. Global identifiers are concatenated by the dataProvider URI and the local identifier. To be able to create global identifiers dataProvider must be defined. fileIdentifier (ISO 19115) The ISO fileIdentifier element is used in geomind to store the local identifier string for the metadata record. language (ISO 19115) In GEOMIND it is always English. characterSet (ISO 19115) In GEOMIND it is always utf8. parentIdentifier (ISO 19115) It is the local identifier of the parent object. ParentIdentifer of geophysical objects are equal to the primary geophysical object set (project, campaign) fileIdentifer. With parentIdentifier it is possible to aggregate geophysical object sets and reports. hierarchyLevel (ISO 19115) Hierarchy level defines the type of the metadata object. The extended MD_ScopeCode codelist contains added elements for geophysical objects, geophysical object sets and reports. contact (ISO 19115) Contact person or organization responsible for maintaining metadata. dateStamp (ISO 19115) Time of metadata creation or update. metadataStandardName (ISO 19115) In GEOMIND it is always “geomind” metadataStandardVersion (ISO 19115) Version number of the GEOMIND extension profile.




8/64

referenceSystemInfo (ISO 19115) Data sources use different spatial reference systems. The GEOMIND portal will convert all geographyc information to WGS84 coordinates. To be able to carry out the conversion properly the local system must be defined. It is done by storing the appropriate EPSG code of the spatial reference system in the referencInfo section. identificationInfo (ISO 19115) Basic information about the data resources. distributionInfo (ISO 19115) Information about the distributor of the data source and the distribution options. dataQualityInfo (ISO 19115) Information about the data quality of the data source and the processing steps carried out. In the GEOMIND profile MD_Metadata element has three subtypes: GE_GeophObjectSet, GE_GeophObject and GE_Report. (see figure 1.) These types are sufficient to describe complicated hierarchies of geophysical information on the metadata level.

2. figure: UML diagram of the MD_Metadata element. Standard elements within MD_Metadata are not shown

1.2.1.1 GE_GeophObjectSet Geophysical object set is a collection of geophysical objects, grouped by some common properties, or constraints. A measurement or a model may be a member of more than one geophysical object sets depending on the rules and conditions by which the objects are grouped. Geophysical object sets can be primary, or secondary. Each geophysical object must be a member of a primary geophysical object set. This provides the primary way to find a geophysical object. Geophysical objects that were created together belong to the same primary object set. Metadata attributes are inherited in the hierarchy through the primary object set relations. Secondary object sets are overlapping collections of objects that are used together for any reason. In UML terminology primary object sets are compositions, secondary object sets are aggregations. GE_GeophObjectSet has all MD_Metadata elements and the followings:




9/64

objectSetType The type of a geophysical object set. It can be project, campaign, objectGroup, geophCoverage or repository.

campaign Campaign is a series of actions to produce geophysical data or documentation. It is usually limited in time and space and related to one specific type of activity or geophysical method. There can be measurement, interpretation, archiving, documentation and other campaigns. project Project is an administrative term that refers to a series of geophysical objects or object sets, related to some common task. Projects may be aggragations of campains, and projects themselves may also be aggregated to superprojects. Projects may extend over a longer time period and larger area. objectGroup Object groups are secondary object sets. More geophysical objects may belong to the same group, and the same object may belong to many objectGroups. Typical examples of objectGroups are sounding profiles that are arbitrary collections of selected geophObjects. geophCoverage Geophysical coverages (parameter maps) are handled as secondary geophysical object sets in the GEOMIND metadata hierarchy. (Special types of objectGroups.) They are composed by using many geophysical objects. In principle, there exist a list of geophObjects that are used to create the coverage. Although, it is possible that those objects are lost or do not exist in a digital database for some other reason. repository Repositories are aggregates of geophysical object sets, equivalent to data stores. The GAIA storage system of ELGI, or the GERDA system of GEUS is a repository.

objectType The types of a geophysical objects that are members of this set. (e.g: A project may contain VES and TDEM type geophysical objects) geophysicalInfo Geophysics related information about the data source. (instruments, measuring conditions, parameters …)

1.2.1.2 GE_GeophObject Geophysical object is a generalized class. Measurements and Models are special types of geophysical objects (connected by inversions). GE_GeophObject has all MD_Metadata elements and the followings: groupIdentifier Local identifier of an objectGroup this object is member of. (e.g: a profile) objectType The type of the geophysical object. Object type are methods, or measurement type in the traditional meaning. (VES, TDEM, MT, gravity …)




10/64

geophysicalInfo Geophysics related information about the data source. (instruments, measuring conditions, parameters …)

1.2.1.3 GE_Report Report can be any document related to a spatially identifiable geophysical (or non geophysical) data source. GE_Report has all MD_Metadata elements and the followings: reportType Report type can be map, profile, sounding, text. Report components may be aggregated to complex reports. geophData Local identifier of the geophysical data source related to the report.

1.2.2 GE_GeophysicalInfo The geophysicalInfo section is the main source of geophysics related metadata. It has the following elements: measuringConditions Information about relevant measuring conditions. Sometimes measuring conditions have important impact on geophysical data, and must be taken into consideration. It is useful to provide a simple structure that stores free text descriptions for different kinds of conditions. Measuring conditions contain information on the platform, noise, weather, topographic, borehole and other conditions.




11/64

3. figure GEOMIND Extention classes GG_Instrumentation and MeasuringConditions

instrumentation Information about measuring equipments. The description of instrumentation is based on the Device and Instrumentation classes of GGDM. Instrumentation is an aggregation of different devices that were used to complete the geophysical measurements. The Device class contains relevant information on instruments, measuring equipments. Attributes of Device are product number, device name, manufacturer, description, software, etc. Calibration data and other parameters may also be connected to device data records. header GeophObject level technical information. A collection of header attributes is set up for each kind of geophysical data types (methods). It is supposed to contain the most important technical parameters that help the users to decide, if he/she wants to download, or order the dataset. Header data is stored in GGDM parameter sets. All header attributes will be defined in parameter catalogues. Header attributes should be searchable and fit into a simple table with no underlying structure. This would allow data providers to organize location maps and header tables into simple shape files. parameterSet Any geophObjectSet or geophObject level technical information expressed in key-value pairs. Geophysical object sets are often influenced by technical parameters that should appear in metadata. (e.g: density for Bouguer anomaly maps, or frequency for airborne EM resistivity maps) Those parameters are listed in the parameterSet element. Parameter sets are lists of key-value pairs. It is a flexible way to store parameters that are defined by the user. Parameter codes refer to parameter catalogue records with parameter type definitions. In GEOMIND all parameters must have a corresponding parameter catalogue definition. parameterCatalogueCitation




12/64

reference to the parameter catalogue used with the data source. ParemeterCatalogueCitation contains citation information on the referenced parameter catalogues. (see GG_ParameterCatalogue for more details)

1.2.3 identificationInfo The identificationInfo section contains basic information about the data resources. It has the following elements: citation (ISO 19115) Citation data about the data resources. Citation title is used as a human readable text identifier of the data set. Alternate identification is possible by using the citation alternate title element. abstract (ISO 19115) Abstract is a brief narrative about the data resource. status (ISO 19115) Codelist definition for the status of the data source, to inform the user about the readiness of the data set. pointOfContact (ISO 19115) Responsible organizations, persons. Detailed address, contact info and roles can be defined. The ISO 19115 CI_RoleCode list has been extended to include roles often used in geophysical metadata (client, contractor, operator, interpreter …) graphycOverview (ISO 19115) This element can be used to add any kind of graphical illustration to the metadata. It can be a file reference to an image, or an inline GML sequence. descriptiveKeywords (ISO 19115) List of descriptive keyword, to help the user in thematic and keyword search. Keywords are selected from controlled dictionaries (thesauri). resourceConstraints (ISO 19115) It describes use and security constraints regarding the resources. topicCategory (ISO 19115) In GEOMIND it is always “geoscientificInformation” extent (ISO 19115 modified) Horizontal, vertical and temporal extent of the data resource.

1.2.3.1 MD_GeographicExtent ISO standard requires only geographic names or outlines of the data source. The GIS functionality of the GEOMIND portal requires exact definition of objects with arbitrary geometry. For this reason MD_GeograpicExtent element was modified, and the geometry element is added. Geometry can be defined by inline GML sequences. It is only mandatory at geophObject level.




13/64

1.2.4 distributionInfo (ISO 19115 modified) The distributionInfo section contains basic information about the distribution of the data resources. It is used to inform the user about contact information, download options, file formats, fees etc.

4. figure, UML diagram of the MD_Distributionand GE_DistributionOption classes.

The MD_Distributor class is simplified in the GEOMIND profile. Source data is distributed by any number, but at least one distributor. Each distributor may provide source data in any number of ways. Each way of distribution is defined by the GE_DistributionOption class. It has the following elements: distributionOrderProcess (ISO 19115) Price, ordering instructions, turnaround time, etc. distributionFormat (ISO 19115) Name, version of the source data format, decompression info, etc. distributionTransferOptions (ISO 19115) It defines the data source availabitily. If data available online, access is defined by a CI_OnlineResource element (URL, protocol, description, etc). If data available offline (CD, or printed material), data source is defined by MD_Medium (media name, density, number of volumes, medium format, etc.) distributionUnit (GEOMIND) Distribution unit defines the base for the price. It can be geophObject, or geophObjectSet.

1.2.5 dataQualityInfo (ISO 19115 modified)




14/64

DataQualityInfo sections is simplified in the GEOMIND profile. Only lineage information is used to describe data processing step sequences.

5. figure UML diagram of the dataQualityInfo class

Metadata records may contain any number of dataQualityInfo elements. Each of them may be associated to different scope (sub area or subset of data), and different quality aspects. Quality is described by LI_Lineage structures, that include a general statement on quality, and any number of processing steps. LI_ProcessingStep contains the following elements: description Description of the processing step rational What was the aim of the processing step? dateTime When was the processing step carried out? processor Person, organization responsible for the processing step




15/64

2 Overview of the General Geophysical Data Model

2.1 Hierarchy of Geophysical Datasets (HGDS)

In the previous chapter the hierarchy of geophysical datasets was discussed is relation with the GEOMIND metadata extension profile. The portal applications and the underlying metadata storage system is closely connected to this topic. In the following pages more or less the same structure is examined, but in relation with the local data stores.

6. figure UML diagram of the HGDS classes and their relations

Local data stores are heterogeneous. The structure of geophysical data resources at national data providers are extremely diverse, and no general rules can be applied. The architecture of HGDS provides a general frame that can be used to integrate the existing data resources with the least difficulties and the possibility to keep the original structure. The architecture was designed to minimize the need of reorganizing existing data structures on national level. Figure 6. shows the basic relations between the top level classes of the HGDS model. HG_GeophObject, HG_GeophObjectSet and HG_Report are mirroring the GE_ GeophObject, GE_GeophObjectSet and GE_Report metadata classes. They provide alternatives on local data provider level for storing geophysical data sets and data set aggregations. On the other hand, it is also possible, that HG classes are completely replaced by the corresponding GE metadata records and portal applications are used also on the local data provider side.




16/64

GeophObjectSets and reports may be infinitely aggregated and organized into tree architectures. Some object sets are compositions of geophysical objects (primary object sets) others are aggregations (object groups). Reports can be related either to single objects or object sets. To demonstrate the usage of the HGDS model for different data structures two simple examples are shown below. Example 1: Radioactive waste disposal site assessment project GOS project-001 (radioactive waste disposal site assessment super project) GOS project-002 (measurements in 2003) GOS campaign-001 (VES measurements in 2003) GO VES-001 GO VES-002 … RP report-001 (Technical report on campaign-001) GOS campaign-002 (TDEM measurements in 2003) GO TDEM-001 GO TDEM-002 … RP report-002 (Technical report on campaign-002) RP report-003 (report on project-002) GOS project-003 (measurements in 2005) GOS campaign-003 (VES measurements in 2005) GO VES-101 GO VES-102 .. RP report-004(Technical report on campaign-003) GOS campaign-004 (TDEM measurements in 2005) GO TDEM-101 GO TDEM-102 … RP report-005(Technical report on campaign-004) RP report-006 (report on project-003) RP report-007 (final report on the radioactive waste disposal site assessment activity ) Example 2: Mineral exploration in Albania, 2005 GOS project-004 (Mineral exploration in Albania, 2005) GO TDEM-1001 GO TDEM-1002 GO TDEM-1003 … RP report-008 (technical report on project-004) RP report-009 (final report on project-004)

2.2 General Geophysical Data Model

GGDM is a data model for storing, and exchanging geophysical detailed data. It is the base for the GEOMIND XSD schema definitions. Measurements and models distributed in GEOMIND format follow the concept of GGDM, and must be valid against the future GEOMIND XSD schemas.

2.2.1 ME_Measurement In the GGDM data model measurement is defined as a series of layouts (instrument device arrays) with any number of layout components. By defining layout components and storing all relevant information about each measurement component, it is possible to fully describe very complex measurement setups and forget about the concept of “geophysical method”. Measurement in GEOMIND sence is a series of closely related layouts that are usually handled as one unit.




17/64

Examples of measurements are EM or DC soundings, borehole logs, gravity stations, or seismic profiles. ME_Measurement contains the following elements: identifierName Name, that identifies the measurement in the local namespace. comment Any notes or descriptions related to the measurement localCRS Local metric coordinate reference system. It is defined by an origin (center point) and a rotation angle, relative to the absolute CRS (defined in the metadata record). Measurement geometry is usually defined in the local CRS. If necessary, localCRS data can be used to calculate real world coordinates to each components. parameterSet Parameter set is used to store a list of measurement level parameters. In the case of location based measurements (gravity, magnetic stations), where no layout definition is required, parameter set is used to store measured (and calculated) data. Parameter codes must be defined in the referenced parameter catalogues.

7. figure UML diagram of the ME_Measurement class.




18/64

2.2.1.1 Layout Layout is a spatially fixed array of layout components. A layout includes all data collected by the sensors within the same time range, using the same set of sources, driven by the same signal. Elements: i Serial number of the layout comment Any notes or descriptions related to the layout parameterSet Layouts may also have an associated parameter set. It contains information that is specific for the layout (like run specific parameters in the LAS 3.0 borehole logging standard).

2.2.1.2 LayoutComponent LayoutComponent is a generalization. Sources and sensors that are used to carry out geophysical measurements are subtypes of layout components. This is the lowest level of the GEOMIND data hierarchy. It contains structures that makes it possible to store any kind of data related to the component. Layout components have device type (electric dipole, induction coil, geophone etc) and geometry (size, position, orientation). They are related to physical devices that may be described by the GG_Device class. Measurement data is stored in domain sets and range sets, similarly to GML coverages. Layout components have dimensionality. It means that devices may collect data in 0, 1, 2, 3 or more dimensions. For example, a device that collects data about the time variations of the magnetic field is a 1D sensor. A borehole camera is a 3D sensor with 2 spatial dimensions plus time. A gravimeter is a 0D sensor with no dimensions. Layout component data is stored in domain set and range set structures, like coverage data in GML, but GEOMIND domain sets and range sets are different. They are not limited to spatial dimensions. Layout components may be real, or virtual. Real components are equivalent to physical devices that collect data, while virtual components are often used to store processed data. A special type of virtual layout component is the cluster. Layout components may be aggregated to create complex systems. The adventage of using clusters is to store common data, that are shared by more sensors or sources, only once. Elements: i Serial number of the layout component. Sensors and sources are counted separately, meaning, that there may be 2 components with i=1: sensor-1 and source-1. comment Any notes or descriptions related to the layout component deviceType




19/64

Device type of the layout component. It is a theoretical name of an ideal elementary device, that is usually related to the measurement of some physical parameter, e.g: electricDipole, currentLoop, inductionCoil etc. Complex and intelligent measuring devices, like borehole sensors, or magnetometers (that are made of many elementary devices) have logical deviceType names, e.g: resistivityProbe, neutronPorosityProbe, magnetometer etc. The codelist of device types is extendable. device The real world device, that was used as a layout component. It is a reference to a piece of equipment that may be catalogued in a local instrumentation database. layoutComponentType It is a switch. It can be sensor, source, sensorCluster or sourceCluster. box Box defines a 3D bounding box for the layout component. Relevant geometry data can be stored here, as size, position and orientation. Default value for a geometry elements is always 0. parameterSet Layout components may have associated parameter set. It contains any information that is specific for the layout component or characterize the device (like pull direction for a borehole tool, or weight of a probe). dimensions Number of dimensions used by the layoutcomponent. (examples: 0 – gravimeter, 1 – geophone, 2 – image recorder, 3 – video camera) domainSet Domain sets define the positions of the measured data values (range data) in the parametric space, e.g: sampling time instances of a seismological recording. recording Measurement data is stored in recordings. Recordings are one or more range data array blocks, separated by recording time. Time separation may be as small as few seconds for repeated measurements, or months, even years for monitoring data. sequence It is used to further specify domain set data. E.g: for a time series data record domain set is used to store sampling time values (gate center times). A sequence can be used to store gate widths for the same domain set. The GG_Sequence class contains the parameter code, and the corresponding parameter catalogue record must explain what it is used for. cluster Reference to the cluster to which the layout component belongs. layoutComponent Reference to the component which belongs to the cluster.




20/64

2.2.2 MO_Model In GGDM the geophysical model is a type of geophysical object. It is the result of inversion or modelling. MO_Model provides a general structure to store and exchange modeling data. MO_Model has 3 subtypes: one for traditional layered model data, one for 2D gridded model data, and one for general 2D or 3D models with arbitrary geometry. To define complex model geometry GML sequences are used in compliance with the ISO 19107 spatial schema.

8. figure UML diagram of the MO_Model class

MO_Model has the following elements: identifierName Name, that identifies the model in the local namespace. comment Any notes or descriptions related to the model tag A human readable label to identifiy the model between many of which were created using the same data set. localCRS Local metric coordinate reference system. It is defined by an origin (center point) and a rotation angle, relative to the absolute CRS (defined in the metadata record). Model geometry




21/64

is usually defined in the local CRS. If necessary, localCRS data can be used to calculate real world coordinates to each components. parameterSet List of model level parameters

2.2.2.1 MO_LayerModel It is the traditional 1D layered model. It may include any number of layers, that have the following parameters: i Serial number of the layer. label Human readable label to identifiy a layer by a (geological) keyword. top, thck Depth and thickness of the top of the layer. topFixed, thckFixed Flag to indicate whether top or thck is fixed. property Physical property that is defined for the layer by inversion, or modeling. MO_Property is a structure with a GG_prameter and a flag indicating property fixation.

2.2.2.2 MO_GridModel Grid models are often used in geophysics. The result of 2D or 3D inversions are generally a mesh of rectangular cells with variable size. It can easily be modelled by multidimentsional domain sets and range sets. Domain sets define mesh geometry, range data sets (here called property sets) are used to store the inverted physical parameters. Elements: domainSet Domain sets to define mesh geometry. (cell center locations.) dimensions Number of spatial dimensions propertySet Array of inverted model parameters. Fixation data may also be stored as integer or boolean type measDataElements. Sequence Domain modifier sequences (to store cell size data).




22/64

2.2.2.3 MO_GeneralModel A general model consists of unlimited model components. Model components are 2D or 3D geometry primitives that are associated with physical parameter values. There are two subtypes of GG_ModelComponents, one for 2D and one for 3D. Elements of GG_ModelComponent : geometry Geometry primitive defined in compliance with the ISO 19107 spatial schema. (GML) property Physical property that is defined for the model component by inversion, or modeling. MO_Property is a structure with a GG_prameter and a flag indicating property fixation. strike only for GG_ModelComponent2D: strike direction of the cross section




23/64

Generic GGDM classes

2.2.3 GG_ParameterCatalogue The General Geophysical Data Model (GGDM) provides a very flexible way to handle all kinds of domain data, range data and parameter types. This is done by using the GG_Parameter and GG_ParameterType classes that provide a key–value pair approach. To avoid uncontrolled diversity in parameter usage standard parameter catalogs are going to be developed and provided by the GEOMIND system. Parameter catalogues are extensible standardized lists of type definitions for parameters that may appear in a GEOMIND digital document. Parameter definition includes parameter code, human readable name, units of measure, data type, description, default value and optional values for enumerations. Associations to controlled dictionary terms (categories) are also allowed. For calculated parameters recursive dependencies on other parameters can also be defined by using parameter sets.

9. figure UML diagram of GG_ParameterCatalogue and the related classes

Elements of GG_ParameterCatalogue: catalogueName Citation name of the catalogue, uniq in the local namespace. catalogueScope Scope of the catalogue content




24/64

fieldOfApplication Fields where the catalogue content is used versionNumber versionDate Publication date of the catalogue producer Creator of the catalogue e.g: Geomind Consortium

2.2.3.1 GG_ParameterType parameterCode Identifier code for the parameter. GG_Parameter.parameterCode refers to GG_ParameterType.parameterCode. parameterName Human readable name for the parameter unitOfMeasure Unit of measure of the defined parameter. Everywere in the data source the same unit is supposed to be applied. dataType Data type of the defined parameter. It can be double, integer, string, boolean, or URI. Type definition must harmonize with the parameter usage. Validation is a typical schematron task. description brief summary about the defined parameter.

2.2.3.2 GG_ParameterSet Parameter aggregate, used in many cases, where unforeseeable or user defined parameters may appear.

2.2.3.3 GG_Parameter Parameters are key – value pairs. Parameter code is used as key to search for the parameter or identify it’s type. Value may be numeric, string, Boolean and even URI. Numeric parameters may also have error.

2.2.4 GG_LocalCRS The local metric coordinate reference system is defined by the origin (center point) and a rotation angle, relative to the absolute CRS (defined in the metadata record). Elevation must




25/64

also be included. If it is required, local CRS may be defined in more than one spatial reference system. Elements: azimuth Clockwise rotation angle, between the local x axis and North. srsName EPSG code of the global spatial reference system in which origin is defined verticalDatum (EPSG ?) code for the vertical dataum in wich elevation is defined

10. figure UML diagram of the GG_LocalRCS class

elevation Height measured above the vertical datum x, y Center point coordinates of the local CRS expressed in cartesian global CRS. latitude. longitude Center point coordinates of the local CRS expressed in spheric global CRS.

2.2.5 GG_DomainSet Domain sets are dimensional sequences, time offset, frequency offset, spatial offset etc. They are used as positions of measured data values in the parametric space. e.g: sampling time instances of a seismological recording. Sequences may be regular (equally spaced sampling) or irregular (defined by a sequence of numbers). Irregular sequences are often reusable components in the system.




26/64

11. figure UML diagram of the GG_DomainSet class

elements: i serial number of the domain set. sequenceName Identifier name for a reusable sequence, uniq in the local namespace. Elements Number of elements within the sequence. If dimensionality is higher than 1, it is important to know the serial number and the number of elements in the sequence, to be able to calculate range data indices. parameterCode Identifier code of the parameter that is used as domain for the measured data.

2.2.6 GG_Recording Measurement data is stored in recordings. Recordings are one or more range data array blocks, separated by recording time. Time separation may be as small as few seconds for repeated measurements, or months, even years for monitoring data. Elements: startTime, endTime




27/64

Each recording contains two time stamps to define time range. If time search is relevant, these values may be copied into temporal extent metadata elements.

12. figure UML diagram of GG_Recording and the related classes

rangeSet Range sets are bunch of data arrays that store measured data together with indices in GG_MeasDataArray structures. Each range set can be considered as a channel of a layout component. The number of such channels is not limited.

2.2.6.1 GG_MeasDataArray Each data array belongs to one parameter, that is measured by, or calculated for the layout component. Range data type can be double, integer and string. Domain sets and range data together defines the geophysical data. (pe: time sequence data and measured magnetic field values in MT). Elements: parameterCode identifier code to which the data array belongs. dataElements Number of elements in the array. The number of range data elements, the number of layout component dimensions and the number of domain set elements must be harmonized. Validation for this should be done by schematron.

2.2.6.2 GG_MeasDataElement Array data is stored in GG_MeasDataElement structures. i




28/64

Serial number (index) of the element. In multidimensional arrays (>1) correspondence between domain set and range set elements is not trivial, but it can easily be calculated from the number of layout component dimensions and the number of domain set elements. mask Boolean flag to hide bad data. If mask is true data is used, if false, it is not used.

2.2.7 GG_Archive

3 Analysis of international geophysical data standards

As the variety of geophysical methods is very large, the same is true for the standards, and formats that are used to store and exchange geophysical information. Those methods, that are often used in hydrocarbon exploration (like seismics and well logging) has a long history of international and industry standards. Though, within international organizations, or specialized communities certain recommendations exist, there is no such thing as ISO data standard in the world of geophysics. The most frequently used formats are spreading as it is required by the market, or the practice, based on the data processing and interpretation softwares.. To be able to analyse the present situation a questionnairy action was carried out. The aim was to answer simple questions regarding the nature, acceptance, depth, advantages, disadvantages of using the existing standards. In the following sections the results of the questionnairy action is reported. Each form contains questions and answers about one specific method in 3 categories. 1. General questions about the existence of international standards 2. Short description of the listed standard types 3. Conclusions about the usefulness of the standards from the GEOMIND point of view At the end of the forms the present state of the GEOMIND concept is attached.

3.1 Siemics

Analysis by GEUS Part 1. General questions 1. Do international, national, or industrial standards exist for the specific method?

yes

Note: International standards are issued by international organizations, like ISO, EPSG or SEG. National standards are typically accepted and used by a user community of a country. Industrial standards are used by user groups of specific data acquisition, processing or interpretation tools that may be widespread internationally. 2. List of standards:




29/64

name of standard scope of standard ( Industrial/National/International)

SEG-2 International

SEG-A International

SEG-B International

SEG-C International

SEG-D International

SEG-Y International

SEG-P1 International



SEG-SPS International

UKOOA P1/84 International




ESSO V2 Industrial

EUROSEISMICS International (not exactly a standard, but should be mentioned)

Part 2. Questions about standard types Standards from SEG – Society of Exploration Geophysicists Name of the standard

Date of Publication

General purpose of the standard

SEG-2

1990 A data file format for raw or processed data shallow seismic data in a small computer environment.

SEG-A 1967 Field tape format

SEG-B 1967 Field tape format

SEG-C 1972 Field tape format

SEG-D 2006 (rev. 2.1) Commonly used binary format for raw field data

SEG-Y 2002 (rev. 1) Commonly used for processed data (can also be used for raw data). The format uses a combination of textual records (ASCII or EBCDIC encoded) and binary data traces.

SEG-P1 1983 Textual format for postplot location data

SEG-P2 1983 Textual format for marine positioning field data.




30/64

SEG-P3 1983 Textual format for land survey field data.

SEG SPS 2006 (rev. 2.1) Textural formats for 3D survey positioning information. The format describes 3 different file types which in combination gives the position of source, receiver and their cross-reference. Furthermore, a fourth comment file is included in the format. The format can besides 3D survey be used for land seismics, where the configuration may vary from shot to shot.

Standards from UKOOA – UK Offshore Operators Association Name of the standard

Date of Publication


UKOOA P1/84 1984 Old textural format for postplot location data

UKOOA P1/90 1990 Commonly used textural format for postplot location data

UKOOA P2/91 1991 Old textural format for raw marine positioning data

UKOOA P2/94 1994 Commonly used textural format for raw marine positioning data

Other standards Name of the standard

Date of Publication


ESSO V2 ? Textual format for stacking velocities

Euroseismics 2002 XML-based format for seismic survey and line metadata. The standard is described in the attached files (Euroseismic_Metadata_Handbook.doc and Procedure for supplying data to Maris.doc) and an example is given in seismic_example.xml. No DTD or XSD exist as far as we know.

Part 3. Conclusions of Analysis by GEUS SEG-D and SEG-Y seems to be the most commonly used formats for raw and processed seismic data. Both are more or less binary of nature and can not be used directly for the purpose of GEOMIND. SEG-Y can have coordinates of source, receiver or CDP’s in the trace headers, but it is our experience, that many files will contain no such information and hence can not be used for GIS presentations. A lot of useful information about the processing sequence could furthermore be included in the textual header of a SEG-Y file, but no rules apply to this header, and it can therefore be used for many different things making it of no use to GEOMIND. The UKOOA formats contain navigation information, which can be used in GIS presentations. The P2 series contain the raw navigation data, which is of no directly use to the GEOMIND




31/64

portal, whereas the P1 series contain processed shot point information, which is very useful for presentation of seismic lines on a map. The P1/84 is very limited, so it is the recommendation that further analyses is done on P1/90, which also can contain important header information in terms of acquisition parameters. For more complex navigation data (3D seismic and land seismic), the SEG SPS format(s) seems to be very useful – not directly for GIS presentation but for navigation data of non-linear seismic setups. At last, the XML exchange format developed during the Euroseismic project should be mentioned. The format should be studied to get an idea of commonly used survey and line metadata information and is in that context very useful for the GEOMIND project, but unfortunately no DTD or XSD has been published. 1. Geophysical terms to be adopted by GEOMIND data model and thesaurus term Description

Navigation data Data about the positioning of measurement points

2. Data model elements, or ideas to be adopted by GEOMIND In terms of data model, seismic data can be divided into the following categories:

• Survey metadata (header data in the GEOMIND meaning I think??) • Navigation data • Raw data • Processed (and reprocessed) data (including processing header information) • Velocity data (stacking velocities as well as other types) • Interpreted data

We can adopt some data structure for survey header data and navigation from the Euroseismic project, but it may be possible to make a survey and navigation header data core, that fits most data types. Processed data should not be supported by the GEOMIND data model. Processing header data could be, but the actual data should stay in SEG-Y files. Velocity data could also be supported by the GEOMIND data model, but some types (e.g. velocity models) should probably stay in binary form as images. Stacking velocities could easily be modeled. No standards exist for interpreted data, but the data are very simple. If we want to support interpreted seismic data, we should analyze how various seismic programs are able to export such data. The description above mainly applies to reflection seismic data. Differences may exist for refraction seismic data. We should discuss if we are going to support both and if so, how deeply we want to develop the data model. 3. Recommendation




32/64

Keep the existing standard as it is, no GEOMIND equivalent is required

no

Keep the existing standard, because it is very common, and develop a GEOMIND equivalent

yes

Existing standards are partial, develop a new GEOMIND standard

no

3.1.1 Present state of the GEOMIND concept

• Seismic field data and processed seismic profiles will be handled as separate geophysical objects.

• Navigation data will be extracted from the original data records and included in the metadata extent information, called geometry.

• Header information (seismic line level technical information) will be extracted from the original data records, and included in the metadata geophysicalInfo section, called header.

• Seismic data will be distributed as it is, but GEOMIND recommendation is SEG-Y. • Each seismic line must be distributed with attached metadata record (generated on

geophysical object level) and with reference to the primary geophysical object set metadata.

3.2 Well Logging

Analysis by GGA Part 1. General questions 1. Do international, national, or industrial standards exist for the specific method?

yes

Note: International standards are issued by international organizations, like ISO, EPSG or SEG. National standards are typically accepted and used by a user community of a country. Industrial standards are used by user groups of specific data acquisition, processing or interpretation tools that may be widespread internationally. 2. List of standards: name of standard scope of standard ( Industrial/National/International)

LAS 3.0 International

LIS Industrial

DLIS Industrial

WITSML International




33/64

WellLogML International, in development.

Antares Industrial, the geological services of the German states use it.

Note: Please, list the name and scope of standards that exist for the geophysical method.

Part 2. Questions about standard types

3.2.1 DLIS 1. Name of the standard:

DLIS

2. Authority:

Schlumberger now Petrotechnical Open Standards Consortium (POSC rebrands as Energistics see http://www.energistics.org/posc/Default.asp)

Note: Authority is the organization responsible for the specification and publication of the standard 3. Date of publication

4. Publication reference http://www.posc.org/technical/data_exchange/RP66/V2/rp66v2.html

5. General purpose of the standard

Schlumberger geophysical logging format. A more sophisticated file format for log data than e.g. LIS, allowing for multi-sample curves and log image data

Note: Please describe the general purpose of the standard 6. Acceptance by GGA Obligatory

recommended

frequently used

occasionally used

not used yes

Note: Please, qualify the standard’s acceptance by one of the above categories. 7. Application support strongly supported Many standard program supports DLIS.

supported

weakly supported


http://www.energistics.org/posc/Default.asp)

http://www.posc.org/technical/data_exchange/RP66/V2/rp66v2.html



34/64

not supported

Note: Please, qualify the standard’s application support, by considering the number of different applications that understand the standard, or provide export/ import functionality to it. 8. Depth of standard data acquisition Yes

processed data Yes

interpreted data Yes

header data Yes

Metadata Yes

general yes

Note: Please, sign the data type categories that are covered by the standard. (Metadata is general information on the geophysical data, typically describing responsible parties, data quality, general location etc. Header data is additional technical information about the data, or instrumentation.) 9. Standard definition XML schema

DTD

textual description yes

other

Note: The structure of objects, conforming the standard is described somehow. Please, refer to the description method. 10. Format of standard files binary yes

ASCII

relational database

11. Advantages of using the standard

Storage and management of digital log data such as tools, equipment, process and data. Includes comprehensive data regarding the data acquisition environment and calibration. Can record data with complex structure such as waveforms and images. DLIS can be extended with new object types. DLIS give much more information about acquisition environment, calibrations and data processing. The so called API-SI unit model




35/64

based upon SI. DLIS can record data frames with different sampling rates in one file. Used as archive file format for industrial data.

12. Disadvantages of using the standard

The data is binary stored. Use of any DLIS attribute is considered optional unless otherwise stated in the POSC RP66V2. But more stringent requirements on presence of attributes is delegated to content standards, which are not part of this document.

3.2.2 LIS 1. Name of the standard:

LIS

2. Authority:

Petrotechnical Open Standards Consortium (POSC rebrands as Energistics see http://www.energistics.org/posc/Default.asp)

Note: Authority is the organization responsible for the specification and publication of the standard 3. Date of publication 1979

4. Publication reference http://www.posc.org/technical/data_exchange/lis-79.pdf


Standard file format for transfer of depth and time based log data defined by Schlumberger. Revised in 1990 with expanded capabilities. Well supported by well log processing software. Now superseded by DLIS, but still in use.


recommended

frequently used

occasionally used

not used yes

Note: Please, qualify the standard’s acceptance by one of the above categories. 7. Application support strongly supported Many standard program supports LIS



http://www.posc.org/technical/data_exchange/lis-79.pdf



36/64

supported

weakly supported

not supported


processed data

interpreted data

header data Yes

Metadata Yes

general yes


DTD


other


ASCII

relational database


Storage and management of digital log data. International still widely used standard. Used as archive file format for industrial data.




37/64


The data is binary stored. Not up to date, supersede by DLIS. Can not record data with complex structure such as waveforms and images. LIS can not extend with new object types. LIS can only record data frame rates that are multiples of the base frame rate. LIS give not much information about acquisition environment, calibrations and data processing.

3.2.3 WellLogML 1. Name of the standard:

WellLogML

2. Authority:



4. Publication reference http://www.posc.org/ebiz/WellLogML/ and http://www.witsml.org/


An XML based log data storage system proposed and maintained by POSC (aspires to supercede LAS). Version 1.0, the initial release of WellLogML, is a general-purpose format, based on Canadian Well Log Society (CWLS) Log ASCII Standard (LAS) Version 2.0. Not currently implemented by data providers

The current active WITSML Version 1.3.1 includes now the wellLog object that supports all forms of well log data (including wireline) and an enhanced mud logging object..


recommended

frequently used

occasionally used

not used yes

Note: Please, qualify the standard’s acceptance by one of the above categories.



http://www.posc.org/ebiz/WellLogML/

http://www.witsml.org/



38/64

7. Application support WellLogML, WITSML supersede WellLogML strongly supported

supported

weakly supported yes

not supported

Note: Please, qualify the standard’s application support, by considering the number of different applications that understand the standard, or provide export/ import functionality to it. 8. Depth of standard data acquisition No

processed data Yes


header data Yes

Metadata yes

general yes

Note: Please, sign the data type categories that are covered by the standard. (Metadata is general information on the geophysical data, typically describing responsible parties, data quality, general location etc. Header data is additional technical information about the data, or instrumentation.) 9. Standard definition XML schema yes

DTD

textual description

other

Note: The structure of objects, conforming the standard is described somehow. Please, refer to the description method. 10. Format of standard files binary

ASCII yes

relational database

11. Advantages of using WellLogML Version 1 based on LAS 2.0, see LAS. Easy to read,




39/64

the standard open International Standard used by major oil companies. WellLogML data objects can be added to the system without affecting existing data definitions. It is also possible to extend existing data objects. Extensions may be added to the schema to enable sharing of the data object extensions. Since Sender and receiver must use the same schema it is ensured that all items can be identified and decoded.


Not up to date, superseded by WITSML. See LAS.

3.2.4 WITSML 1. Name of the standard:

WITSML

2. Authority:



4. Publication reference http://www.witsml.org/


The Wellsite Information Transfer Standard Markup Language (WITSML) is a standard for sending well site information in an XML document format between business partners. XML schemas are used to define the content of an XML document.


recommended

frequently used

occasionally used

not used Yes




http://www.witsml.org/



40/64

7. Application support strongly supported Yes, but only within the oil and gas companies, see below.

supported

weakly supported

not supported

Named supporters on WITSML website: POSC WITSML SIG, Active Members: BP, ChevronTexaco, Datalog, ExxonMobil, Norsk Hydro, Shell, Statoil, Baker Hughes, CTES, Geolog, Geologix, Halliburton, Landmark, HRH, IFP, INT, Key Energy Services, Knowledge Systems, Merrick Systems, M/D Totco, National Oilwell Varco, Open Spirit Corporation, Paradigm Geotechnologies, Peloton, Petrolink, IRIS Research, Roxar, Schlumberger, Seismic Micro-Technology, Sense Intellifield, Smith Technologies, TietoEnkator, TOTAL, UK DTI, US Synthetic, Visean, Well Data Technologies, Wellstorm, POSC Note: Please, qualify the standard’s application support, by considering the number of different applications that understand the standard, or provide export/ import functionality to it. 8. Depth of standard data acquisition Yes

processed data Yes


header data Yes

Metadata Yes

general yes

Note: Please, sign the data type categories that are covered by the standard. (Metadata is general information on the geophysical data, typically describing responsible parties, data quality, general location etc. Header data is additional technical information about the data, or instrumentation.) 9. Standard definition XML schema yes

DTD

textual description

other

Note: The structure of objects, conforming the standard is described somehow. Please, refer to the description method. 10. Format of standard files binary




41/64

ASCII yes

relational database


Easy to read, open International Standard used by major oil companies. Wide range definition set, easy to fit to own needs. Existing LAS in WITSML converter (*). WITSML data objects can be added to the system without affecting existing data definitions. It is also possible to extend existing data objects. Extensions may be added to the schema to enable sharing of the data object extensions. Since Sender and receiver must use the same schema it is ensured that all items can be identified and decoded.

(*) Well Log Data Conversion Utility “LAS to WITSML” http://www.energistics.org/posc/Well_Log_Data_Conversion_Utility.asp?SnID=1648576293 12. Disadvantages of using the standard

Made for the needs of oil companies, further development take care of the companies’ interests. Didn’t support all LAS possibilities directly, e.g. parameter zoning, column data and column definition section associations. Form of matrix definition depends on realization by the user.

3.2.5 LAS 3.0 1. Name of the standard:

LAS 3.0

2. Authority: Canadian Well Logging Society


4. Publication reference http://cwls.org/las_info.php


Log ASCII Standard, defined by the Canadian Well Logging Society. Widely supported by processing and interpretation software.



http://www.energistics.org/posc/Well_Log_Data_Conversion_Utility.asp?SnID=1648576293

http://cwls.org/las_info.php



42/64

recommended

frequently used

occasionally used yes

not used

Note: Please, qualify the standard’s acceptance by one of the above categories. 7. Application support strongly supported Many standard programs working with well logs supports

LAS, even GOCAD display the Well Log data.

supported

weakly supported

not supported


processed data Yes


header data Yes

Metadata Yes

general Yes


DTD


other

Note: The structure of objects, conforming the standard is described somehow. Please, refer to the description method.




43/64

10. Format of standard files binary

ASCII yes

relational database


Flexible, you can add your own attributes. Globally distribution of the format. Inconstant step increment is allowed.

Supports Multiple Runs. Handles 1D, 2D, 3D arrays. Parameter Zoning. Can be read by humans. Online data acquisition is possible. Programming of own application interface is easy, because of open standard and ASCII Format. The format contains about 100 defined attributes for different data objects, called sections (Version, Well, Core, Inclinometry, Drilling, Tops, Test and Ascii or Log).


No defined units. No definitions and description rules for logging tools. Needs more space than DLIS.

Part 3. Conclusions of Analysis by GGA LIS, DLIS and LAS are international used and accepted logging standards with a wide application support. WellLogML is a XML format for exchanging well log data, it ought to supercede LAS. WITSML could, and for the oil companies should be the new standard for data interchange in “near real time” or “static”. There exists a lot of logging tool producers with own standards. Antares is an example for a German producer. Antares is a local standard which is often used by the geological services of the German states. Antares, LIS and DLIS do not satisfy the purpose of GEOMIND and should be ignored. Antares it is not globally used and known. The version WellLogML 1.0 based on LAS 2.0, the further development of the standard is stopped because WellLogML was integrated in WITSML. LIS and DLIS have their advantages, but both store the data binary, so that the format does not satisfy the purpose of GEOMIND directly. Even Schlumberger convert incoming data from DLIS into LAS format, in a typical TransACT order, to deliver Data. LAS is a proven open standard format for log data exchange. Most standard applications, which using well log data, have in-/export interfaces for LAS. Even GOCAD display the Well Log data. It is easier to build an LAS interface for one’s own purpose than a DLIS/LIS Interface. LIS and DLIS users can transform their data to LAS 2.0 with the free Schlumberger Log Data Toolbox, and a Toolbox program can be used to check self-produced LAS files for compliance to the published LAS standard [8].




44/64

LAS files contain Meta and Header data which could easily be expanded with a lot of useful information about everything. LAS 3.0 defined 6 thematic sections and only 108 mnemonics. In use are about 13 000 mnemonics [9]. It is easy to create own sections but the LAS manual recommended the use of the defined sections. “If they [the data] fit in within a preexisting data type, they must be placed in that section type. Add addition sections to existing section using the [1] [2] index extensions rather than creating your own.” [3] WITSML is an open International Standard in XML used by major oil companies with a wide range definition set. The Format provides 25 different data objects, e. g. rig information, risk information and so on. The defined objects covers the information needs to run an oil producing rig, more than necessary for GEOMIND. In addition to that WITSML provide a widespread unit and conversion dictionary in contrast to LAS. New WITSML data objects can be added to the system without affecting existing data definitions. It is also possible to extend existing data objects. Extensions may be added to the schema to enable sharing of the data object extensions. The great improvements of WITSML in comparison with LAS 3.0 are the benefits of XML. The full controlled data access and the input control can go through XSD if so desired. But we have the same problem in WITSML with mnemonics as in LAS, because the WITSML standard only contains specifications about the data transport media, format, protocol, data objects and their elements. The standard does not define how the mapping and names on curves etc should be done. A free converter transforms LAS 2.0 files to WITSML. This converter only supports LAS 2.0 [7]. The new functions in LAS 3.0 are not supported. WITSML has no similar functions as parameter zoning and data associations, but WITSML can construct the functions with its own utilities. According to the information at the 3rd technical meeting in Prague about the GEOMIND portal, we have no require for the full control of the measurement data. Only Meta and Header data are presented on the portal. For this purpose LAS is superior to the younger standard WITSML. LAS is well known internationally and supported by more standard applications than WITSML. DLIS/LIS user can transform their files to LAS 2.0, because it is a part of the LAS 3.0 format with a few exceptions. We save work because there is no need to integrate LAS 3.0 constructions into WITSML. Maybe WITSML is the coming standard for exchange logging data for the oil companies, but today it looks like that the GEOMIND participants do not use WITSML at all. And I’m sure that new applications for WITSML will provide a support for LAS 3.0 too. If we use LAS for GEOMIND, we have to expand the description rules and to reduce the amount of allowed mnemonics. 108 are to few and 13 000 are too many for an exchange format. It would also be necessary to define the required units and to implement a catalogue of logging tools.

Properties of Well Log Standards

Property LAS LIS (*) DLIS (*) WITSML Antares WellLogML

Data storage format ASCII Binary Binary XML ASCII XML

Handling ++ -- -- + + +




45/64

Distribution ++ ++ ++ O - -

Depth of definition + O ++ ++ - +

Number of Data Types, e.g. Core, Drilling + - ++ ++ - +

Application support ++ ++ ++ - -- -

Acceptance ++ ++ ++ O - -

Portability ++ - - ++ O +

Flexibility ++ - - ++ ++ +

(*) The problem of LIS and DLIS is their format, if you are able to write an interface to handle LIS and DLIS files they could be portable and flexible, but to do this you need a lot of known how.


• Well logging data may be distributed in two ways. The GEOMIND recommendation for external data format is LAS (LAS2 and LAS3), but a GEOMIND well logging data format will be developed, based on the General Geophysical Data Model (GGDM).

• Each well logging data set must be distributed with attached metadata record (generated on geophysical object level) and with reference to the primary geophysical object set metadata.

• LAS mnemonics will be extensively used by GEOMIND, and published in the standard GEOMIND parameter Catalogues. Definition of Units is part of the parameter catalogue structure.

• Implementation of logging tool catalogues is also possible by using the GGDM.

3.3 Seismological data

Analysis by ELGI Part 1. General questions 1. Do international, national, or industrial standards exist for the specific method?

yes

Note: International standards are issued by international organizations, like ISO, EPSG or SEG. National standards are typically accepted and used by a user community of a country. Industrial standards are used by user groups of specific data acquisition, processing or interpretation tools that may be widespread internationally. 2. List of standards:

Notation

++ Very good

+ Good

O Satisfying

- Bad

-- Very bad




46/64


SEED International

PASSCAL SEG-Y International

Note: Please, list the name and scope of standards that exist for the geophysical method. Part 2. Questions about standard types

3.3.1 SEED 1. Name of the standard:

SEED

2. Authority:

International Federation of Digital Seismograph Networks

Incorporated Research Institutions for Seismology

United States Geological Survey

Note: Authority is the organization responsible for the specification and publication of the standard 3. Date of publication SEED Format Version 2.4

March, 2006

4. Publication reference http://www.iris.edu/manuals/SEEDManual_V2.4.pdf


The Standard for the Exchange of Earthquake Data (SEED) is an international standard format for the exchange of digital seismological data. SEED was designed for use by the earthquake research community, primarily for the exchange between institutions of unprocessed earth motion data. It is a format for digital data measured at one point in space and at equal intervals of time.

Note: Please describe the general purpose of the standard 6. Acceptance Obligatory no

recommended no

frequently used yes

occasionally used no


http://www.iris.edu/manuals/SEEDManual_V2.4.pdf



47/64

not used no

Note: Please, qualify the standard’s acceptance by one of the above categories. 7. Application support strongly supported no

supported yes

weakly supported no

not supported no

Note: Please, qualify the standard’s application support, by considering the number of different applications that understand the standard, or provide export/ import functionality to it. 8. Depth of standard data acquisition yes

processed data yes

interpreted data no

header data yes

metadata yes

general no

Note: Please, sign the data type categories that are covered by the standard. (Metadata is general information on the geophysical data, typically describing responsible parties, data quality, general location etc. Header data is additional technical information about the data, or instrumentation.) 9. Standard definition XML schema no

DTD no


other


ASCII no




48/64

3.3.2 PASSCAL SEG-Y 1. Name of the standard:

PASSCAL SEG-Y

2. Authority:

Incorporated Research Institutions for Seismology

Note: Authority is the organization responsible for the specification and publication of the standard 3. Date of publication PASSCAL SEG-Y

4. Publication reference http://www.passcal.nmt.edu/software/segy.html


PASSCAL SEG Y

The PASSCAL SEG Y trace format is a modified form of the standard SEG Y traceformat. Each PASSCAL SEG Y file contains one trace (data block).


recommended no

frequently used yes


not used no

Note: Please, qualify the standard’s acceptance by one of the above categories. 7. Application support strongly supported no

supported yes

weakly supported no

not supported no

Note: Please, qualify the standard’s application support, by considering the number of different applications that understand the standard, or provide export/ import functionality to it.


http://www.passcal.nmt.edu/software/segy.html



49/64

8. Depth of standard data acquisition yes

processed data yes

interpreted data no

header data yes

metadata no

general no


DTD no


other


ASCII no



Part 3. Conclusions of Analysis 1. Geophysical terms to be adopted by GEOMIND data model and thesaurus term description

3. Recommendation




50/64

Keep the existing standard as it is, no GEOMIND equivalent is required

no


yes


no

Present state of the GEOMIND concept

• Seismological data may be distributed in two ways. The GEOMIND recommendation for external trace data format is SEG-Y, but other internationally accepted formats may also be used. The General Geophysical Data Model makes it possible to easily create a special format for seismological data. Though, it is not included in the present project as part of the GEOMIND system, it may be implemented later, if resources will be available.

• Each seismological data set must be distributed with attached metadata record (generated on geophysical object level) and with reference to the primary geophysical object set metadata.

• LAS mnemonics will be extensively used by GEOMIND, and published in the standard GEOMIND parameter Catalogues. Definition of Units is part of the parameter catalogue structure.

• Implementation of logging tool catalogues is also possible by using the GGDM.

3.4 Magnetotellurics

Analysis by ELGI Part 1. General questions 1. Do international, national, or industrial standards exist for the specific method?

yes

Note: International standards are issued by international organizations, like ISO, EPSG or SEG. National standards are typically accepted and used by a user community of a country. Industrial standards are used by user groups of specific data acquisition, processing or interpretation tools that may be widespread internationally. 2. List of standards: name of standard scope of standard ( Industrial/National/International)

SEG-EDI International

Part 2. Questions about standard types 1. Name of the standard: SEG-EDI




51/64

2. Authority:

SEG, Society of Exploration Geophysicists


4. Publication reference


SEG-EDI standard files are structured ASCII text files. They are used to exchange processed MT sounding data. The files contain some metadata, header information, layout geometry and a series of calculated frequency-dependent impedance tensor components


recommended yes

frequently used yes


not used no

Note: Please, qualify the standard’s acceptance by one of the above categories. 7. Application support strongly supported yes

supported no

weakly supported no

not supported no

Note: Please, qualify the standard’s application support, by considering the number of different applications that understand the standard, or provide export/ import functionality to it. 8. Depth of standard data acquisition no

processed data yes

interpreted data no




52/64

header data yes

metadata yes

general no


DTD no


other

Note: The structure of objects, conforming the standard is described somehow. Please, refer to the description method. 10. Format of standard files binary no

ASCII yes


The standard is well known and accepted by most MT data provider. Software support is strong. The ASCII text is easy to read and interpret


Only processed data is reported. Metadata section is relatively poor.




53/64

Part 3. Conclusions of Analysis 1. Geophysical terms to be adopted by GEOMIND data model and thesaurus term description

2. Data model elements, or ideas to be adopted by GEOMIND Storing frequency sequences and frequency dependent range data arrays separately reduces storage space. The concept of frequency dependent matrices should be adopted by GEOMIND. 3. Recommendation Keep the existing standard as it is, no GEOMIND equivalent is required

no


yes


no


• Magnetotelluric sounding data may be distributed in two ways. The GEOMIND recommendation for external data format is SEG-EDI. The General Geophysical Data Model makes it possible to create a special format for MT data. Though, it is not included in the present project as part of the GEOMIND system, it may be implemented later, if resources will be available.

• Each MT data set must be distributed with attached metadata record (generated on geophysical object level) and with reference to the primary geophysical object set metadata.

• Metadata and header data elements (geophysical object level technical parameters) will be extracted from the SEG-EDI files and included in the accompaning metadata record.

3.5 TDEM

Analysis by GEUS and ELGI

Part 1. General questions 1. Do international, national, or industrial standards exist for the specific method?

yes

2. List of standards:




54/64


PCGerda Danish national

GAIA-TDEM ELGI

Amira Australian exchange format

WingLink Geosystem exchange format

Part 2. Questions about standard types

3.5.1 PCGerda 1. Name of the standard:

PCGerda

2. Authority:

GEUS


4. Publication reference http://gerda.geus.dk


The PCGerda standard is structured in a relational database structure. It is used to import and export electrical and electromagnetic data types (Wenner, Schlumberger, PACES, MEP and TDEM) from GEUS geophysical database GERDA. PCGerda contain metadata, header information, layout geometry, measured and inverted data.

Note: Please describe the general purpose of the standard 6. Acceptance Obligatory Yes in

Denmark

recommended Yes

frequently used Yes

occasionally used No

not used No



http://gerda.geus.dk



55/64

7. Application support strongly supported Yes

supported No

weakly supported No

not supported No


processed data Yes


header data Yes

Metadata Yes

general ?


DTD no


other Yes, ER-diagram

Note: The structure of objects, conforming the standard is described somehow. Please, refer to the description method. 10. Format of standard files binary No

ASCII No

relational database

Yes, Access, Interbase, SQL Server and ORACLE




56/64


It is a very detailed standard that gives the opportunity to exchange almost all information of a TDEM sounding.

It is easy to make an application that works directly on a PCGerda database.


In relation to GEOMIND a disadvantage is that the standard is not in XML.

3.5.2 GAIA-TDEM 1. Name of the standard:

GAIA-TDEM

2. Authority:

ELGI

Note: Authority is the organization responsible for the specification and publication of the standard 3. Date of publication 2000.12.31

4. Publication reference ELGI annual report, 2000: Az Országos Geoelektromos és Elektromos Adatbázis című projekt eredményei.


It is used to import and export TDEM sounding data to the GAIA system of ELGI. Internal data transfer between system modules is also done with GAIA-TDEM DIF (Data Interchange) files.

Note: Please describe the general purpose of the standard 6. Acceptance Obligatory No

recommended Yes

frequently used Yes

occasionally used No

not used No

Note: Please, qualify the standard’s acceptance by one of the above categories. 7. Application support strongly supported Yes in ELGI




57/64

supported No

weakly supported No

not supported No

Note: Please, qualify the standard’s application support, by considering the number of different applications that understand the standard, or provide export/ import functionality to it. 8. Depth of standard data acquisition No

processed data Yes


header data Yes

Metadata Yes

general No


DTD no


other Yes, ER-diagram

Note: The structure of objects, conforming the standard is described somehow. Please, refer to the description method. 10. Format of standard files binary No

ASCII Yes

relational database

Yes


It is a flexible structured language to upload and download TDEM data within ELGI. It is easy to convert to XML.




58/64


In relation to GEOMIND a disadvantage is that the standard is not in XML. Used only in ELGI.

3.5.3 Amira Amira is a text based tabular format to exchange TDEM measurement data. It is often used in relation with special software tools that require Amira format.

3.5.4 WingLink The WingLink TDEM format is a text based structured format to exchange TDEM measurement and processed data. It is usd for data import and export by the WingLink software of Geosystem Srl. Part 3. Conclusions of Analysis In the GEOMIND project it has been decided to use XML as exchange format. PCGerda is in a relational database structure witch means that it can not be used in GEOMIND as it is. PCGerda is however a very detailed format and it would be possible to use a lot of the content in a new XLM exchange format. GAIA-TDEM is also detailed and flexible, but used only in ELGI. Other data exchange formats, like Amira, WingLink-TEM are also partially used in relation with special software tools. 1. Geophysical terms to be adopted by GEOMIND data model and thesaurus Term Description

2. Data model elements, or ideas to be adopted by GEOMIND 3. Recommendation Keep the existing standard as it is, no GEOMIND equivalent is required

No


No


Yes




59/64


• TDEM data will be distributed in GEOMIND format, as a special application of the GGDM data model.

• Each TDEM data set must be distributed with attached metadata record (generated on geophysical object level) and with reference to the primary geophysical object set metadata.

• Metadata and header data elements (geophysical object level technical parameters) will be extracted from the existing local data sources and included in the accompaning metadata record.




60/64

4 Analysis of existing data structures at the GEOMIND data providers

4.1 Analysis of Gravity Standards and Databases

To establish the concept of a general data model a detailed analysis of existing gravity database structures and international gravity standards were carried out. There seems to be no internationally accepted standards for storing gravity data. Gravity standards are more related to datums, and procedures of gravity data corrections. There are standards for exchange of location based data, but those are specific formatting instructions for tabular text files, rather than data models. ( ASEG-GDF2, 2003) Altogether five national data providers reported detailed information of their gravity database structure: CGS, ELGI, GSSR, GEUS and PGI. The structure of gravity databases are in most cases quite simple, restricted to one single table. Data storage systems are different, most often used solutions are MS Excel, MS Access and field separated ASCII files. Exceptions are GGA and GEUS. At GGA gravity data is structured into several tables forming a subsystem of FIS-GP. Gravity data of Denmark is originally managed by the national space center (DNSC) and stored in ASCII files. GEUS is recently developing a database to incorporate gravity data into GERDA. The structure under development was reported to GEOMIND. Based on the data content type of the gravity databases, fields can be divided into 3 main groups:

1. Coordinate system information 2. Gravity data and corrections 3. Supplemental information (metadata)

Coordinate system information Spatial coordinates have special role in gravity. Apart from localization, coordinates are also used for different kinds of corrections. In terms of coordinate systems, datums, and corrections national systems significantly differ from each other. GEOMIND have to support a common standard based on international recommendations and the consent of data providers. As GEOMIND is not intended to harmonize detailed data on international level, or rebuild databases, the differences between national systems must be precisely reflected and handled in a general database model. To follow the international recommendations and to keep traditions national gravity databases typically store coordinates in more then one coordinate reference systems. National and international planar coordinates with different ellipsoid coordinates are often stored together for the same stations. Vertical datum may also be different. The most often used system is the Baltic Sea System. Sometimes elevations interpolated from digital terrain models can also be found. (quality control for topographic corrections) International standards recommend the usage of the WGS84/GSR80 ellipsoids as horizontal and vertical datum for gravity measurements. (Hinze et al. 2005) (Featherstone W. E. and Dentith M.C. 1997)




61/64

Conclusions:

• The General Geophysical Data Model should support the option of storing more than one spatial reference systems for each station. At least one of the CRS-s must be WGS84/GRS80 ellipsoidal system with latitude, longitude and elevation.

Gravity data and corrections Different types of gravity data are stored by national data providers. Most often used data types are absolute gravity, Bouguer anomaly and topographic correction values. Absolute gravity values are stored everywhere, but the gravity datum may be different from country to country. (Internationally recommended gravity datum is the worldwide IGSN71 and the European UEGN gravity network). Some data providers do not store Bouguer anomaly values, as those are easy to calculate. Others do store them for different densities. There are many different ways to calculate gravity corrections (Normal correction, Free-air correction, Bouguer correction). The traditionally used approximating formulas are not recommended any more, instead simple closed form equations for the WGS84/GSR80 ellipsoids can be used. Topographic corrections may also have multiple values depending on the zonation parameters, or techniques used (manual processing or digital TC based on digital terrain models).

horizontal

datum vertical datum

gravity datum

normal correction

height correction

Bouguer correction

curvature correction

DTM_H DTM_V DTM_GR CORR_NRM CORR_HGT CORR_BG CORR_CRV

CGS WGS84

S-42

JTSK

BalticSea ??? Somigliani SecondOrderForm BouguerPlate BullardTerm

ELGI HD72/EOV

Krassovskij

AdriaticSea MGH-50 Cassinis FirstOrderForm BouguerPlate none

GEUS ??? ??? ??? ??? ??? ??? ???

GGA ??? ??? ??? ??? ??? ??? ???

GSSR WGS84

S-42

JTSK

BalticSea ISGN71 ??? ??? ??? ???

PGI S-42

92 ?

??? ??? Somigliani

Helmert

GRS80 form ??? ???

Hinze et al.

WGS84 GRS80 ISGN71 Somigliani SecondOrderForm SphericalCap NotNeeded

Table 1. Datums and corrections used by GEOMIND participants

Conclusions:

• The data structure of gravity measurements is simple, and the general data model (GGDM) can easily be applied in all cases.




62/64

• The variety of gravity parameters can be handled by the key–value approach of the general data model (ParameterSet), but it is necessary to implement a standardized gravity parameter catalog to control the usage of parameters.

Supplemental information (metadata) Supplemental information in gravity databases are very spars and no common practice exist. The following list is the union of all metadata elements used by the data providers:

Year of measurement Cartographic Map reference Scale of survey Instrument reference (Closing) Error Owner of data Control point reference Report reference

Most of these metadata elements are typically campaign/project level information. Presently they are stored on measurement level, as - in most countries – gravity data is explicitly not organized to a higher level dataset hierarchy. In most countries some additional metadata information exists about reports, campaigns, projects, so this hierarchy – in principle – can be built. Conclusion: The GEOMIND Dataset Hierarchy Model (HGDS) together with the ISO19115 metadata can be used to structure national gravity datasets. Data providers should do this by identifying either campaigns/projects or reports, and create metadata records for them. Potential problems: It is a question, whether data providers will have enough resources and time to reorganize their data.


• As no generic international standard exists, gravity station data will be distributed in GEOMIND format.

• The GGDM is used to create the common model to describe gravity station location and measurement data. The location based measurement model will be defined by measurement level parameter sets.

• Metadata elements will be included in object level metadata records, and references to primary object sets also have to be used.

• Definition of secondary object sets (profiles, collections for maps) is optional.




63/64

4.1.2 References ASEG-GDF2, 2003. The ASEG-GDF2 standard for point located data Hinze W. J. et al. 2005. New standards for reducing gravity data: The North American gravity database. Geophysics, vol 70. no 4.

Featherstone W. E. and Dentith M.C. 1997. A Geodetic approach to gravity data reduction for geophysics. Computers and Geosciences Vol 23, No 10.

4.2 Analysis of Vertical Electric Sounding Databases

The simplicity of the VES methode is one of the reasons why there is still no standards for storing and distributing DC sounding data. GEOMIND VES data providers all have their own company or national standards. Partly the analysis of their reported data structures were used to establish the GEOMIND concept of a VES data model. Five data providers reported their VES data structures. GEUS, GGA and ELGI has relational database for VES soundings, CGS and Geocomplex use excel tables and human readable ASCII files to store DC sounding data. VES data commonly consist of 3 types of information:

1. geographic location, and local CRS 2. layout data 3. measured data 4. supplemental information (metadata) 5. object set information (project, profile)

Geographic location and local CRS The layout geometry of DC soundings are defined by a center point, and a direction. Center point defines the reference point for the measurements, and it is used to measure electrode distances. (MN potential electrodes, AB current electrodes) The direction defines the azimuth of the layout, that is always a straight line. Layout data Layout data is one or more sequence of AB distances. Sometimes AB/2 is stored. To each series of AB one MN distance is also stored. These electrode combinations are used to measure the sounding data. The maximum and minimum distance of the AB electrodes is also often stored. Measured data To each AB-MN combination one or more measured (or calculated) data is stored. The series of electrode distances together with the corresponding measured values are called the sounding curve. Measured values can be source current, measured voltage, calculated apparent resistivity, geometry coefficient, etc.




64/64

Supplemental information (metadata) Supplemental information in VES databases are usually spars and no common practice exist. The following list shows typical metadata elements used by the data providers:

Date of measurement Instrument reference Operator Contractor organization Geographic description Data quality codes interpreter

Object set information The following list shows metadata elements that are shared by more than one geophysical objects.

Project reference Report reference Author(s) of report


• As no internationally accepted standard exists, VES sounding data will be distributed in GEOMIND format.

• The GGDM is used to create the common model to describe VES sounding location, layout and measured data.

• Metadata elements will be included in object level metadata records, and references to primary object sets also have to be used.

• Definition of secondary object sets (profiles, collections for maps) is optional. • 1D Interpretation results of VES data will be handled as layered models.



specifications of standards for digital geophysical …geomind.elgi.hu/doc/d6_2.pdfspecifications of...

Documents