DINO  BRO Rico Tönis Account Manager DINO E&P Data 24-03-2011

1. DINO  BRO Rico Tönis Account Manager DINO E&P Data 24-03-2011

2. E&P data in DINO DINO is the Dutch National Data Repository (NDR) DINO also stores E&P data of The Netherlands The DINO department is part of The Geological Survey of the Netherlands The DINO department operates the DINO database DINO can be accessed by www.nlog.nl or www.dinoloket.nl

3. DINO E&P Data flow 2 10 januari 2011 www.DINOloket.nl Intranet TNO Filter E&P data from companies www.NLOG.nl Filter DINO Service desk Disc etc. DINO applications

4. Which E&P data is collected Well data (logs etc.) Seismic data Licence data Mining Act Well production data (oil, gas, rocksalt, and in near future also geothermal data) E&P Infrastucture Drilling reports Drill cores & drill cuttings 3 10 januari 2011

5. Why E&P data collection in DINO Because there exists a Dutch Mining Act (Petroleum Act) Why the need for BRO (allready have DINO & Mining Act)? Technology update (webservices, skills employees etc.) BRO will enhance data description and data will be stored at one place (production data, drilling reports). Improvement of data management Clustering of E&P data with shallow subsurface data gives better recipe for long term survival (America has no NDR…) BRO will be INSPIRE proof, DINO is not BRO realizes Dutch government program “Andere Overheid” BRO will be a new ICT infrastructure in The Netherlands, it will facilitate innovations 4 10 januari 2011

6. Transition DINO  BRO Basisregistratie Ondergrond (BRO) The BRO will be a Dutch Key Register (1 of 13) BRO = DINO 2.0 + BIS 2.0 BRO project has started BRO program leader is Ministry of Infrastructure and Environment DINO department plays important role in construction of BRO 5 10 januari 2011

7. BRO concept 6 10 januari 2011 BRO Key register Subsurface Mandatory Use Mandatory delivery Mandatory feedback

8. BRO concept systeem BRO register systeem webservices 7 10 januari 2011

9. Transition DINO  BRO Core business of BRO project is: Standardization of subsurface data Construction of BRO Data conversion DINO & BIS  BRO Dutch BRO legislation will follow (Q4 2011) BRO will be INSPIRE-certified (European Directive) Objective: BRO is live on 1-1-2014 TNO will be register administrator of BRO http://www.youtube.com/watch?v=lY0pQ5FZ6ls 8 10 januari 2011

10. E&P data in BRO BRO project will standardizes following E&P data types: Mining Act License Mining Act Borehole (logs etc.) Mining Act Well (produced oil, gas, salt, geothermal power, CO2 storage, gas storage etc.) Seismic Surveys Each standardization traject of a data type is a project For every data type a data catalogue will be defined 9 10 januari 2011

11. Data type Mining Act Well Phase 1: Exploration. In this phase TNO will make an initial proposal to standardize well production data. Phase 2: Expert group will be discussing the TNO proposal. Expert group will also contain people from industry. Phase 3: Governmental work group will appove the proposal from the expert group. Phase 4: Public consultation (www.dinoloket.nl) Phase 5: BRO steering group will approve (or not) proposed data catalogue from governmental work group 10 10 januari 2011

12. Data type Seismic Surveys Second BRO data type project will start Q3 2011 DINO-DO user meetings always have many seismic data questions integrate these questions into BRO project “Data type Seismic Surveys” 11 10 januari 2011

13. Data issues concerning Seismic Surveys 12 10 januari 2011 Seismic Issues BRO data type Seismic Surveys 1 2 What seismic data will be stored in the BRO Conversion 2D analogue data  digital data Data management Issues www.nlog.nl 3 4 BRO portal provides better publication of seismic data, more advanced search options 1. Bulk conversion possible? High costs NLOG issues: 208 210 240 Field data Pre-stack Post-stack Depth migrated etc. 2. TNO collects copies of converted 2D data present at companies, commitment companies DINO Data management is making a plan independent from BRO Data format 3. TNO-DINO will digitize complete surveys to TIFF’s when customer requests data. Costs paid by first customer

14. Questions Interest in paying money for bulk conversion of analogue 2D seismic data to SEG-Y? Any of you interested in attending BRO session, for example expert group “Seismic Surveys” or “Mining Act Well”? Or attending a workshop on drawing the BRO work processes? 13 10 januari 2011

15. Round table discussion“What do users & suppliers of mining act data expectof the introduction of the BRO”? 1. Will the deep geological model published in the BRO? 14 10 januari 2011

16. Round table discussion“What do users & suppliers of mining act data expectof the introduction of the BRO”? Only 2 data formatswillbesupported as input data for the BRO BRO input datatype and analternative datatype Will thisinfluenceyourworkproces? systeem register systeem webservices 15 10 januari 2011

17. Round table discussion“What do users & suppliers of mining act data expectof the introduction of the BRO”? 3. The communication with the BRO is through webservices, will this effect your work proces? systeem register systeem webservices 16 10 januari 2011

18. Round table discussion“What do users & suppliers of mining act data expectof the introduction of the BRO”? 4. Do you think the BRO will cost you money? 17 10 januari 2011

19. Round table discussion“What do users & suppliers of mining act data expectof the introduction of the BRO”? 5. When do you think you have to act? 18 10 januari 2011

20. Round table discussion“What do users & suppliers of mining act data expectof the introduction of the BRO”? 19 10 januari 2011

21. Is er informatie in DINO relevant voor SoDM? Standard for Exchange of Digital Seismic Data, Recommended by TNO Seismic datasets consist of navigation, velocity and signal (post-stack) data. In addition there is accompanying information about the data, which is e.g. stored in the headers of the files concerned or in separate acquisition and/or processing reports. 1. Accompanying Information General: All three datasets should contain in their headers: - name of the owner - name of the area (toponym) - 2D or 3D - period of acquisition (last day of acquisition: of day, month and year) - company code for the project (if applicable) It is strongly recommended that the line names used in the navigation, velocity and signal data sets match exactly. Line numbers and CDP-numbers for the navigation, velocity and signal data must correspond. The data should be accompanied by its outline for 3D, (on paper or as ASCII-file) or by a map indicating the location of each line. Reports that describe the acquisition and processing of the data can be sent as paper report, word, rtf or pdf-file. Navigation: The header should at least contain: - date and/or version number of the dataset - date of preparation of the file, tape or other medium - co-ordinate system, geodetic datum (e.g. ED50 or RD) and the specifications of the projection used - in the case of 2D lines : for each line or line-segment the relationship needs to be indicated between the SP-number in the data record and the CDP-number (as used in the SEGY dataset) of the trace which is located at that mentioned SP-number. Velocity: The header should contain: - type of velocity (e.g. stacking, DMO, migration) - date of the completion of the processing - indication to what kind of SP the velocity-time pairs are attached (e.g. CMP, shotpoint, geophone position). For 2D lines, see remark for navigation data. Signal (SEGY): - processing contractor - description of the processing sequence - date of the completion of the processing - grid inline and crossline interval for 3D and nominal CDP-interval for 2D 2. Data Formats Navigation: Preferably UKOOA P1/84 (see e.g. First Break 1985, vol. 3, No 10) or UKOOA P1/90 (see First Break 1991, vol. 9, No 4), or SEG (Shell SPS format) (see Geophysics 1995, vol. 60, No2). If the standard navigation file is not available, for 3D, also a definition of the bin-grid can be given. E.g. by supplying corner points coordinates and line/bin numbers. Velocity: The ‘Standard’ velocity format, with 6 velocity/time pairs per record of 80 characters (e.g. NAM, ShellV5) is preferred above e.g. EssoV2. Line ordering of velocity data must match that of the signal and navigation data. Note: with 3D surveys processed though PrSTM this may not be possible as the velocities are picked on the gathers from the original acquisition line orientation and the final migration may be on a different merged or rotated grid. In this instance x, y locations in the velocity are required. Signal: Standard SEG-Y format should be used. Preferably the data format used is 4 bytes floating point (data sample format code = 1). Data samples should be at least 16 significant bits. Concerning 3D surveys additional requirements are: - the traces have to be sorted according to inlines - each inline has to be followed with a "EOF" mark; so each inline starts with an EBCDIC and a binary header. - compound bin-numbers may be used, but then the inline and crossline numbers need to be indicated separately The following byte locations are mandatory: binary header * 3205 - 3208 = line number (numerical part of line name) * 3213 - 3214 = number of data traces per record * 3217 - 3218 = sample interval in s * 3221 - 3222 = number of samples per data trace * 3225 - 3226 = data sample format code * 3227 - 3228 = nominal CDP fold trace header * 001 - 004 = trace sequence number within line (first trace of each line is 1) * 021 - 024 = CDP ensemble number * 029 - 030 = trace identification code * 115 - 116 = number of samples in this trace * 117 - 118 = sample interval in s - line number - compound number in stead of line number and cdp-number - co-ordinates may also be given in the trace header; the co-ordinate system should be indicated in the accompanying information. Please Note: - the values of ‘number of samples’ and ‘sample interval’ in the binary header should be equal to those in the trace header, - the real number of samples in a trace should be equal to the value written in the binary and trace headers. Data can be either packed or one line per file. The latter is preferred. In case packed segy-files are supplied, each packed file must be smaller than 2 Gb. Whether the data are packed should be indicated on the tape or disk label. If data are packed, it must be done in such a way that no lines are split over two packed files. For packed data, the line number must be indicated in the trace header. 3. Media and Information - The signal, navigation- and velocity data are preferred on DVD, CD an USB hard-disk or (Exabyte) 8mm tape. Media should have labels with the above mentioned information. If an usb-disk is used, please provide a readme-file with the above mentioned information. On the tape or disk label the following items should be indicated: - operator - survey name and project number (if applicable) - year of acquisition (end of acquisition dd-mm-yyyy as precise as possible) - type of data (e.g. CDP position, DMO velocity, final filtered 3D migration) - format (e.g. P1/84, SEGY, packed or not, TAR if applicable) - range of inlines (and crosslines) When signal, navigation and velocity data are stored on tape with the UNIX ‘tar’ or ‘dd’ commands, the correct commands to retrieve the data have to be indicated. Information sheet Seismic surveys The digital data send to TNO concerns the following data. General: Name of the ownerName of the area (toponym)2D or 3DPeriod of acquisition or, at least,last day of acquisition (day, month and year)Period of processing or, at least, the last day of the processing (day, month, year)Company code for the project (if applicable) □ The location map on paper is annexed. □ Navigation data □ ukooa file □ included in trace header. □ Navigation data included in □ UTM31, □ TM5 or □ other, please specify: ………….. □ Signal data □ Velocity data included. Signal data is □ Stack. □ Post Stack Migration: □ Time □ Depth □ Pre Stack Migration: □Time □ Depth. Signal data is □ tarred □ packed □ one file per line. Trace header location of: - Line number: - CDP number: 20 10 januari 2011