field scale map accesses
eight pages, created at the township scale to show the detailed
well spots (Figure 9). Discussion
of the ImageMap command of HTML is provided under a later section
(Linking maps with HTML).A goal of the Digital Petroleum Atlas (DPA) was to provide users flexible access to the original data and intermediate steps of the study. Results of field studies are fed immediately into the databases. The flexibility of the Web provides access to the data that went into the study at the same time as the results.
To support these technical goals, a design was created for the web site. Several models were drawn up, but the goals were very simple:
As the DPA was constructed, there were two obvious "paths" through the digital data. The user could move geographically through several scales of data:
At each geographic scale, the user would be presented with choices and answers.
As an alternative the DPA could be structured around topical areas. For the DPA the topical areas were broken into following categories:
|
Regional Geophysics |
General Reservoir |
Geology Wells |
For each field, basin and county, information was structured in terms of both geographic scale and topical area. These two general structural styles of information (pages based on geographical scale and pages based on topical area) result in a grid system. However, in practice this structure becomes rapidly unmanageable. While it would be nice to simultaneously compare the geologic maps of three or four fields (isopach or structure), it is not possible and not desirable to have links from each geology page to every other geology page. As a result, for the DPA we emphasized movement among geographic scales, and worked to maximize the visitor’s ability to move from County to Field to Well. Movement between topical areas is limited to within the selected geographic scale (e.g., figures 1, 2).
At the present time, the Digital Petroleum Atlas currently contains over 6,000 static web pages covering 8 counties, 7 fields and two regions of Kansas. "Static" pages are actual HTML text files on the DPA web server showing information to visitors. Most of DPA pages are very similar--that is, a template can be made and multiple pages extracted from that template. For example, for a set of county geology pages (Figure 2), the only differences are the names of the files, the window titles, and the two figures (i.e., map and stratigraphic chart). The navigation is adjusted for each page (assigning a "Previous" page and assigning a "Next" page). As a result, a new set of geologic maps, core photos, etc., for a new play or field can be integrated into the DPA efficiently as a new set of static web pages.
However, the method of creating static web pages has two problems. The first problem is maintenance of pages containing variable data. Data such as oil and gas production changes monthly, and the pages must be updated periodically. With more and more fields added, the work of creating all the new pages and updating all the previously created pages can take up all available time. The second problem is one of scale. For any small field (25-100 wells), it is easy to create pages for each well and attach scanned well completion forms, digital well logs, and other information. But with larger fields, such as the Chase-Silica field with 10,378 wells, assembling the data is in itself a major task and pages can not be created by hand. By creating pages with a relational data base management system (e.g., Oracle), whatever data is available can be displayed to the visitor. New production data is available immediately. Plus, the database can create lists of wells for the user based on location information, and pages for the wells can be created only if the user wants to see detailed information.
The first field added to the DPA was Arroyo, a field with 36 wells needing web pages. These pages were created by hand and links were made from the field map and the web pages (Figure 6). After the well pages were created, pages for completion forms, production, petrophysical analysis, etc. were created as needed and attached by hand to the well pages. Updating the production pages would take only a few hours of student time.
Big Bow was handled the same way, but Gentzler and Schaben fields added a new challenge. While the number of wells in Gentzler and Schaben fields was reasonable, the geographic scale of these new fields meant that the visitor could not select an individual well of interest because the well spots were too small to resolve on the user's screen. For fields with a larger geographic area, clicking on the main map brings up a map with more detail on the particular quarter of interest (Figure 7).
For Chase-Silica Field (Rice County), simple zooming does not
allow a clear picture of all wells without creating several levels
of zoom. In addition, the resulting maps and individual well pages
would require the creation and maintenance of 10,378 additional
web pages. The map of Chase-Silica Field covers eight townships
(288 square miles). At this scale it is impossible to resolve
and select all wells, and only currently producing well are shown.
Clicking on selected parts of the field scale map accesses
eight pages, created at the township scale to show the detailed
well spots (Figure 9). Discussion
of the ImageMap command of HTML is provided under a later section
(Linking maps with HTML).
The township scale maps of Chase-Silica Field are also active maps that use the ImageMap command of HTML (Figure 9). However, clicking on an individual section does not access a web page, but generates a query to several relational database tables. The result returned to the user is a web page that contains an annotated list of all wells for which production and geologic data is available (Figure 10). Clicking on the "Well_ID", normally the API number, generates additional queries for detailed well, wireline log and production data and returns a web page to the user (Figure 11).
The web pages at Chase-Silica Field are not static. They are generated as requested by the user and contain the latest geologic, production and other data loaded into the various relational databases. Using relational databases significantly improves the efficiency of undertaking and maintaining large-scale field studies. The thousands of potential web pages are reduced to small number of programs operating on a manageable number of relational data tables. Updates to the various data tables are immediately accessible to the user. Procedures for constructing and providing web access to relational database tables are discussed in a later section.
Navigation by clicking on areas of map images to access web pages is provided by the "Imagemap" command of HTML. The creator of the web page can assign web Uniform Resource Locators (URLs) to geometric shapes (rectangles, polygons, and circles). The figure below shows a part of a larger map and the shapes defined for the map. Finney County is defined by a polygon of 7 points. If the user clicks in the polygon, the page at "/DPA/County/def/finney.html" is displayed.
|
<area shape="poly" coords="105,259, 105,203, 178,205, 177,233, 141,232, 141,260, 105,259" href="/DPA/County/def/finney.html"> <area shape="rect" coords="141,231, 177,287" href="/PRS/County/ghj/gray.html"> <area shape="rect" coords="104,258, 142,294" href="/PRS/County/ghj/haskell.html"> |
Haskell and Gray counties use rectangles for ease of creation, even though technically they would be better modeled by polygons. The coordinates of the user’s browser determine access to one of several static web pages (Figure 12).
The ImageMap command of HTML can also be used to ask a question of a database. Here is an ImageMap syntax fragment for the map of a portion of Chase-Silica Field (Figure 9):
<area shape=rect coords="408,54,478,124" href="http://magellan.kgs.ku.edu/abyss/public/dpa.chase.mainTRS?twn=18&rge=10&sct=36">
The link shows that the computer called " magellan.kgs.ku.edu" is asked for a web page. On that computer, the words " abyss/public/" mean that the Oracle database called "abyss" will be called with a publicly available question. The program that will run the database query is "dpa.chase.mainTRS." Finally, the program needs township, range, and section values ("twn=18&rge=10&sct=36"). Even though 36 sections are "imagemapped" for each township scale map, the process uses search and replace functions that are very efficient.
Software provided with relational database management systems,
such as Oracle,
is used to connect the web pages to the database.
This "middleware" receives the parameters from the web
browser, formats them, and sends them to the programs stored in
the relational database (Figure 13).
After each query is executed, the database sends the data back
through the middleware. The results appear to the user with a
web browser just like any static web page (Figure
13).
A number of separate tables in the relational database are used to support the DPA web pages. The main table is a list of wells located in the Chase-Silica field. Technically, this table is not needed, since a table containing all wells in Kansas could be used as the source with Chase-Silica wells extracted as needed. However, pre-creating a smaller file of wells improves performance. The relational database uses the main table of 10,378 records in the well list and additional subsidiary tables (e.g., lease production) to create well pages as needed for any well in the field. To the user the pages generated from the query to the database appears and acts exactly as the static, hand-created pages.
The
subsidiary data files accessed by the DPA are often not maintained
by project personnel. Kansas Geological Survey personnel, and
even other state agencies, provide update the information in the
tables as part of other projects (Figure
14). An example would be monthly oil and gas production data
obtained from the Kansas Department of Revenue. The DPA structure
is used to extract up-to-date data from those external tables
and present to the user web pages that look and act just like
normal DPA pages. The result is that parts of the DPA are automatically
maintained and updated and will continue to be maintained after
the project has ended ("a living publication").
While the static pages already built for Arroyo, Big Bow, and the other small fields in the DPA will not be completely replaced by pages from relational databases, links to selected data are being changed from static pages to database-created pages (e.g., production).
| Next Page | Previous Page | Top of Report |