processing map and well log data for geological and soil surveys

Mathematical Geology, Vol. 18, No. I, 1986

Processing Map and Well Log Data for Geological and Soil Surveys 1

J, van Kuilenburg z

Design of a system which accepts" geological maps or soil maps, together with corresponding well logs and produces interpretation maps, is described. The major aim was to get a processing program that would be useful at an operational scale that avoids the use of special purpose graphics hardware. This was achieved by using segment encoding of lines and by treatment of mapped units as basic graphical units ("atoms"). The system operation was split into an input phase and a processed phase. Input- and file-building require some technical experience, but are a one-time affair, whereas subsequent processing requires less (graphical) resources and experience, but is of a repetitive nature. When writing processing programs, emphasis was placed on ease of adding options. Clever improvements o f efficiency (e.g., disk traffic) were not deemed worthwhile or even wise. Two driving forces behind the project required the programs reported here. First was the observation that digital data can be used only i f appropriate programs are readily available to produce required results without need for large investments in hardware. Second was the idea that digital tools could be most effective i f they allow the end-user (' 'customer' ') to interact directly with the full base of data without recourse to technical experts. The resulting system is operational and running on a VAX 11/750, coded in FORTRAN.

KEY WORDS: mapping, geology, soils.

INTRODUCTION

Demands for maps and related well logs in digital form are steadily increasing in the Netherlands. Users of these maps cannot afford the use of expensive CAD systems of the type operated by full-time mapping agencies. This restricts the potential application of digital material to a considerable extent. In order to improve this situation it was decided to provide suitable computer processing programs together with digital map data. This approach is comparable to that of the ordnance survey in the United Kingdom (Gardiner-Hill, 1974). Programs could be kept simple and still provide facilities needed by use of a suitable data structure.

~Manuscript received 14 June 1984; accepted 26 February 1985. 2Geological Survey of the Netherlands, Haarlem, The Netherlands.

75 0882-8121/86/0100-0075505.00/0 © 1986 Plenum Publishing Corporation

76 van Kuilenburg

A thorough understanding of the use of the maps first had to be gained to make sure that all required processing capabilities could be provided. After generalizing the requirements of output products, about a dozen options ap- peared to be sufficient. These related to: selection of a subarea; selection of profile data; recoding and manipulation of map units using Boolean operators; some map "cosmetics"; and computation of tables showing total area of resulting map units.

Several processing steps which can make computer-aided cartography expensive were circumvented by proper manual preparation of data. For example, when extracting sub areas, the necessity of cutting boundary lines was sup- pressed by adding every potential map boundary beforehand that might be required (e.g., of an administrative nature) when digitizing the original map. From a technical point of view this type of preparation can be considered impractical at first glance. These boundaries are, however, added without any problems by the.end user, who knows what kind of map is wanted and recognizes that in this way the result needed can be obtained on his or her graphical terminal or microcomputer. In this way, accessability of the digital map and its related well logs is optimized.

Speed and accuracy of operation now allow one to get output that would not be considered feasable without computer support.

INPUT DATA AND OUTPUT REQUIREMENTS

In a technical sense, maps and well log information required for soil and geological surveys have the same structure. In this paper only geological data is used for illustrative purposes. A more elaborate analysis of specific applications and extensions required for soil mapping will be published elsewhere. A fragment of a typical printed geological map is shown (Fig. 1). Lines bordering map units have to be digitized in order to enter them into a computer in vector format. Each map unit is numbered and tied to its corresponding legend unit (Hageman, 1963) by an arbitrary point within its interior. Location of this point should be such that adjacent codes do not overlap when plotted on the map; it also should be placed at a location suitable to be a representative for the map unit (e.g., near the center of gravity for a regular area). The last requirement is not only for aesthetic reasons but also because this point will be used to rep- resent the map unit when extracting data of a subarea. The second basic input is a topographic map (Fig. 2) showing well locations. Well logs (Table 1) can be extracted from the computerized archive of the Netherlands Geological Sur- vey. Input of well log information is by data entry on intelligent terminals. All data is stored subsequently in the computer in a compact form, using a header record followed by data for each depth interval. Input has to be standardized and complete to allow machine processing. This well log system has elaborate facilities to verify data but a description falls outside the scope of this paper.

Map and Well Log Data for Surveys

532

77

531

530

52 ° 45'

529 6 ° 10'

206 207 208 209 210 Fig. 1. Fragment of geological map sheet 16E (ter Wee, 1978) as published by the Netherlands Geological Survey (original scale 1 : 50,000; in color). TW 4: peat on fluvio- periglacial deposits; TW 4 +: Coversand (< 2 m) on fluvio-periglacial deposits; TW 5: slope deposits; TW 5 + : Coversand ( < 2 m) on slope deposits; DR 6: Drente Formation; DR 6+: Coversand (<2 m) on Drente Formation; EH 4: Eindhoven Formation; and EH 4 +: Coversand (< 2 m) on Eindhoven Formation.

Basic data available for processing thus consists of areal data (maps) which contain a considerable amount of geological interpretation, and point data (well logs) which contain mainly raw data (layer descriptions) with the addition of some interpretation (stratigraphy).

Output to be derived are interpreted maps which can be produced at four levels of sophistication:

1. Only map data are processed using Boolean selection of map unit codes; e.g., to show the distribution of a certain stratigraphic unit.

2. The map units codes are compared to some interpretation table before a selection is made; e.g. , to show the distribution of a particular lithologic property extracted from all the map areas.

3. Well log descriptions are scanned to obtain the distribution of a certain property within the map units; e.g. , to obtain an isopach map.

The fourth level, which is not implemented yet, should use profile descriptions together with a user-supplied physical model; e.g. , to compute a hydrological permeability map.

78 van Kuilenburg

E

¢-

.,..~

0

r ~

0

"-d

e~

m

[...

~ . +

d

< L)

[--

L~

>

©

0

~D

Z 0

Z

. 2

0

Map and Well Log Data for Surveys 79

k

Fig. 2. Topographic map of well locations for map in Fig. I. at the same scale. A well is uniquely identified by its truncated kilometer coordinate and sequence number.

Whichever map output type is required, a need will generally exist to re- strict processing to a subarea of the data base. The first step in any processing run therefore will be the selection of a target area. Moreover, a need will often arise to have a tabular summary of results (e.g., map code by area) as part of the output, and this facility must therefore be available as a standard option. The most demanding technical requirement, however, is the need to implement the system at an operational scale on low-cost hardware, using either a stand- alone unit or a graphics terminal linked to a central computer.

S Y S T E M D E S I G N

The technical solution chosen was to split tasks into the initial once-only requirement for data input and structuring and the repeating one of generating interpreted maps. The input phase would generally be carried out by persons trained for this job and is computer intensive. In contrast, in the second phase computer experience is considered as overhead, and turn-around times should fit into the schedule determined by their related manual work. When analyzing workflow in practice, this latter decision leads to an important technical con- sequence. Namely, whereas the first phase requires extensive facilities to update and correct data, the second phase does not necessarily do so, since it is related entirely to extraction of data. I f data are guaranteed to be consistent and error-

80 van Kuilenburg

free in the second phase, the end user may require little interactive graphic capability and should not need to update databases.

This conforms to a natural situation where a mapping agency invests in reliable databases and may require powerful interactive graphics for editing, etc., whereas a receiving agency carries out straight-forward processing tasks without adding geological information. The only complicated operation required in the second phase of data interpretation is selection of subareas. In its full implementation this may require splitting geological boundaries and reorganiza- tion areal information. To cope with this problem, a compromise was made by allowing only complete map areas to be extracted from the database. Cutting and joining in that case reduces to the simple operation of deleting line segments and appending complete line files. In order to avoid obvious problems, this approach requires that large map areas are split first when digitizing into subre- gions using artificial boundaries. Potential administrative boundaries are also added, whenever appropriate, at the same time, again using artificial boundaries. These artificial boundaries are suppresed easily on output, as they are bordering areas with the same legend unit and are thus uniquely recognizable.

Introduction of the concept of an "a tomic" map area was a major choice for system implementation. Another was to use a variant of the DIME format (Weber, 1978) for line-segment storage. In this method, each boundary, lying between two nodes (a meeting point of more than two lines) is stored only once, as a table of coordinates preceded by identification of map areas to the left and to the right. This choice is attractive because the graphics display can be produced by scanning sequentially through the file and only showing a line ("drop- ping the pen") if adjacent map areas have different (re)coded values. These advantages have been recognized and exploited by several authors (e.g., Lou- don et al., 1980).

TECHNICAL REALIZATION

The tasks involving data input and file generation, which form the first of the two processing phases, are summarized (Table 2). A modest computer with a digitizer and a plotter is sufficient to carry out these tasks. Some tasks could use more computer support but in practice ~ppeared to be done as effectively by hand. For instance, step 2.2 (Table 2) can be carried out by point-in-polygon operations on the well log location file and map file. This step does not involve much manual work and provides a useful visual check which has to be done at some stage anyway.

In step 1.2, on the other hand, the choice often will be for an automatic procedure, since it appears that the center of gravity is a good choice in most cases, and the program is cheap in terms of computer resources. A reorgani-


Table 2. Processing Steps for Building Map and Well Log Files

Activity Remarks

1. Geological maps

1.0. Finalize manuscript map. Add artificial boundaries to break up large map areas and include all other boundaries of (potential) interest. Number polygons with increasing, generally consecutive, numbers. Mark a few control points for geometrical restitution.

1.1, Digitize individual polygon outlines on geological map.

1.2. Include polygon number, or, digitize polygon centers; include polygon number.

1.3. Convert digitized to absolute coordinates.

1.4. Plot, check, and correct data.

1.5. Convert polygon file to a line segment file.

1.6. Input alphanumeric list of legend unit and relate with corresponding polygon numbers.

1.7. For final checking, plot data, compute individual polygon areas and their sum. Correct errors.

2. Well location maps and well logs.

2.1. Digitize well log location and transform to absolute coordinates.

2.2. Add area numbers (and height) to each well log.

2.3. Input well logs.

2.4. Merge well log and location files. m

Mark nodes for automatic recognition. Choose two arbitrary nodes on closed boundaries. Digitize an " is land" after its surrounding polygon.

Alternatively use computed center of gravity (which can be shifted if considered not appropriate in step 1.4).

Use absolute coordinates of known control points selected in 1.0.

All lines (except the map boundary) appear twice, keep only first appearance.

Incomplete polygons will give large errors in almost all cases, and so area check is a sensitive one.

Transformation on basis of control point in 1.0.

Use manual overlaying. Calibrate height to height above sealeveI.

Computer controlled data entry.

82 van Kuilenburg

zation of data is carried out as a result of this entire procedure. In the beginning, a polygon boundary file, a polygon center file, a well location file, and a well log file exist. At the end, we have obtained a line segment file, a polygon center point file, and a well log file, all linked by polygon number. This number plays a crucial role as a result of choice of map area as the basic spatial unit, although it is only an internal pointer (invisible to the user). The resulting data structure is schematically shown (Table 3) with an example of actual data file contents (Table 4).

Although some information in the files could be omitted, as it can be computed from data (e.g., extreme coordinates in the last columns of polygon center point file) these values have been retained to speed often used operations. For example, on data extraction extreme coordinates are used for a first check, whether a candidate point could be inside the corresponding map polygon.

Table 3. Basic File Layout

Polygon Point Center File: one entry for each map area:

max and min center point, coordinates

area number legend unit X, Y X, Y X, Y

etc.

Line Segment File: one variable length entry for each line segment

area number area number number of left right points coordinate list

X, YX, Y ' ' '

Well Log File: one header entry for each well log followed by one entry for each layer

well log point coordinate polygon area number of number X, Y, Z number layers

depth litholology layer information

depth litholology next layer information

next well log

etc.


When considering tasks to be performed, only the polygon center point file need be held in memory, whereas others can be (binary) sequential files on disk. This choice follows from an estimate of the size of files and their required access mode. A typical map contains, say, 5000 well logs with up to 10 layers and 1000 polygons, with each polygon described by 10 line segments of 5 points each.

The first file (Table 3) then will need typically about 9000 words of in- core storage, which is quite manageable. The second (disk) file will contain about 90,000 words and the third one could be something like 1,000,000 words.

In practice, these last two files are not big enough to warrant use of direct or index-sequential access. For larger data sets, this sophistication would improve speed but the resulting overhead is counterproductive for smaller areas since most processing requires an exhaustive (mainly sequential) search anyway.

For simple map interpretation, only a look-up table which returns a coded value for each legend unit is needed. This table is not large, because the number of legend units in a typical map will usually not exceed 100 entries and will generally be much smaller than the number of map areas (polygons).

After the input phase has been completed, resulting files can be used for further processing on the same or another computer system. The only requirement for the second computer system is the presence of a plotter; a digitizer is not needed. When working at a remote location, a simple graphical screen for previewing plots and a printer are of great value. For instance, when working with DEC equipment, a VT240 terminal (with graphics capability) and an LA50 of LA 100 printer will function well on a central computer equiped with a regular penplotter. All major processing tasks are simple to program and run. Basic tasks and corresponding operations needed are summarized (Table 5).

Plotting can be done with a single program for each basic map form: to- cation, contour, or isopach and area. The contour map program will normally be a simple module for a plotter (Watson, 1982), lineprinter (SYMAP, anonymous 1982; Davis, 1973), or an extensive package (SURFACE II, Sampson, 1975). For other maps, the program is so simple that a homemade product suffices. Because the line segment file already looks much like a plot file, application of "cosmetics" is straightforward. Acceptable line smoothing is ac- complished using algorithms such as that of Butland (1980), removal of super- fluous digitized points also is done easily (e.g., Dettori and Falcidienno, 1984) and line fonts can be applied (e.g., Yoeli, 1982). Other general basic algorithms, which are needed, are well-kilown. For instance, in our case table look- up is carried out using a binary search; sorting by shell-sort, area calculation by trapezoid rule for numerical integration, geometric transformation by least- squares adjustment, and point-in-polygon operations using Salomon's (1978) algorithm.

p~

z z

I I I I I ~ I I

I I I I I ~ I I

I I

I I

<

N

Z

~Q

©

o ~

<~

86 van Kuilenburg

Table 5. Processing Tasks

Utility functions Operations

Map subarea extraction

Merge different subareas

Compute and display area of map units

Display maps

Plot location map

Print well logs

Interpretation function

Select and display map codes

Select and display map subcodes

Rename and display map codes

Display depth of selected layers

Display thickness of selected maps

Extract polygon centers within a given boundary; subsequently retain only line segments and well logs which contain accepted polygon numbers

Paste corresponding files together (e.g., by appending); sort center point file if necessary

Scan line segment file sequentially and accumulate map unit areas

Scan line segment file sequentially and plot lines with unequal neighboring area values c.q. codes

Scan well log file sequentially and plot points, superimpose map lines if requested by former step

Scan well log file sequentially and print logs

Operation

Enter codes requested, plot map, and print areas

Perform Boolean selection of codes and print areas

Enter look-up table for map codes and print areas

Enter lithology, scan well log file, and plot posted value or contour map

Enter lithology, scan well log file, and plot posted value or isopach map

A B

d) ×

i i

C

× ×

[3

i t

E

× X

Fig. 3. Computation of polygon areas: (A) original polygon; 1; (B) area to " lef t" gives negative contribution to area of 1 ; (C) area to " lef t" gives positive contribution to area of 1; (D) resultant are for 1 positive; (E) net contribution of an island (2) within 1 would be negative.


Only the computation of areas need be discussed in more detail because treatment of line segment storage may not be readily apparent. The principle of method is illustrated (Fig. 3). The algorithm for calculation of areas proceeds as follows: keep a table with one entry for each polygon, initialize this table to zero, and compute the area between each line segment and an arbitrary fixed line (e.g., the x axis). Each area computed must be added to the entry in the table for the polygon to the left of the line segment and must be subtracted from that of the polygon to the right. If this procedure is systematically carried out, while scanning through the line segment file, then at the end of the process the table will contain the total area of each polygon. Because the quickest way of storing values in the table is by addressing array elements, it should be held as an array in which the index is the polygon number. (This is another reason why the list of polygon numbers should preferably be sorted and show no big "gaps" ) . Thus by "b l indy" applying the area-accumulating rule for all segments, correct polygon areas are obtained without the need of assembling polygons. Segments need not be sorted and direction of digitizing is free, as long as left and fight polygons are properly indicated with respect to digitizing direction. In computer memory, only an area accumulation table with one entry for each polygon is needed while no more then one linesegment has to be available at a time.

Direction of digitizing is not important as long as relative " le f t " and "r ight" are correct. Islands, to any number and depth, are handled by this approach and the full polygon never has to be assembled explicitly. Area calculation can, in many cases, be shortcut by including the polygon area as aux- iliary data in the polygon center point file (Table 3). This value is computed once (when setting up the center point file) and can be used subsequently whenever the polygon area is needed. Examples of maps showing extraction of all geological units and a major stratigraphic unit are shown (Figs. 4 and 5). Avail- ability of well log data and map units allows further useful processing.

One facility is the possibility of characterizing quantitative properties of map units by computing actual well log values in the unit concerned. For instance, in this way a check can be made on how many well logs actually contain a stratigraphic unit depicted on the map (Fig. 6), or average shale content of a unit can be computed, et cetera.

Another example is the restriction of posted value and contour maps in space to areas occupied by certain legend units. This is useful when, for instance, an isopach map (Fig. 7) has to be made for a certain stratigraphic unit. This isopach is controlled by a number of wells (Fig. 6) and cut off at the boundary of Peat overlying fluvio glacial deposit unit Tw 4 (Fig. 1).

An exiting extension could be computation of hydrogeological properties from well logs; this is, however, beyond our reach at this moment. We would also like to be able to couple layer description (lithology, texture, etc.) data to more sophisticated laboratory analyses, such as penetrometer values, geophys-

88 van Kuilenburg

C)

I ~o

~D

E ~

4~

÷

eq ~ 0 o~

0

~q

..=

E o

0

0 eq

90 van Kuilenburg

o i ~0

°~

°F

o

°~

o • • °

N

o~

.m

°I

°~

° °

m D

oQ

~N

~m

B

e ~

a ~

°~

Q~

0

~ N

m

°'4"

e •

o;¢1

I g

a ~

°m

o~

o~

E

6

o~

r ' , - ~ c-

o '~ "~ 6 ~

¢,4

t O


ro u% uo

~°

N a + ~ m

.~=~

• - - m

N ~

© 0

~ 8 / 9 0 / 6 8 31V0 L "ON l O q d X . J / /

O - £ L V3~V 1 S 3 1 3HDVdOSI

92 van Kuilenburg

ical logs, and the like. If the need arises, mapping programs that provide greater quality graphical output (e.g., crosshatching with CALFORM, Anonymous, 1982) could be interfaced.

These extensions would to be difficult to incorporate in an effective operations system on the medium term without the use of greater cost database and display systems such as those in use in the petroleum industry.

IMPLEMENTATION

A pilot system has been tested on a DEC-10 system as a part of a coop- erative program between the Netherland Soil and Geological Surveys. The Netherland Soil Surveys Institute has a full implementation of the design pre- sented in this paper. It runs on a VAX 11-750 which is in operational use for soil survey of reallotment projects. Geological application had lesser priority and was restricted to the pilot system, and so it will be implemented using the final version on an in-house VAX 11-785. As the system is supposed to be por- table, no use is made of the standard software normally applied (ORACLE at the Soil Survey, Rdb/Datatrieve, and UNIRAS at the Geological Survey).

REFERENCES

Anonymous, 1982, Lablog: Harvard Laboratory for computer graphics and spatial analysis, Cam- bridge, Mass.

Butland J., 1980, A method of interpolating reasonable-shaped curves through any data. Proceed- ings of Online Conference: Comput. Graph., v. 80, p. 409.

Davis J. C., 1973, Statistics and data analysis in geology: John Wiley & Sons, New York, 310 p. Dettori G., Falcidienno B., 1984, An algorithm for selecting main points on a line; Comput.

Geogri., v. 10, no. 2-3, with erratum, p. 351-353. Gardiner-Hill R. C., 1972, The development of digital maps: Ordnance survey, professional paper,

new series, no. 23. Hageman B. P., 1963, De profieltype-legenda van de nieuwe geologische kaart: Tijdschrift KNAG,

v. 80, p. 217-229. Loudon T. V., Wheeler J. F. and Andrew K. P., 1980, A computer system for handling digitized

line data for geological maps: Comput. Geosci., v. 6, p. 29%308. Salomon K. B., 1978, An efficient point-in-polygon algorithm: Comp. Geosci., v. 4, no. 2, p.

173. Sampsom R. J., 1975, Surface II graphics system: Series on spatial analysis, no. 1, Kansas Geo-

logical Survey, 240 p. ter Wee, M. W., 1978, Blad steenwijk oost (160): Netherlands Geological Survey, Haarlem.

Watson D. F., 1982, ACCORD: automatic contouring of raw data: Comp. Geosci., v. 8, no. 1, p. 67-101.

Weber W., 1978, Three types of map data structures, their ands and nots, and a possible or, Proceedings of the First International Advanced Study Symposium on Topological Data Struc- tures for Geographic Systems, Harvard, v. 1.

Yoeli P., 1982, Cartographic drawing with computers, M. J. McCullagh and P. M. Mather (Eds.), Computer applications, v. 8; University of Nottingham, England.

processing map and well log data for geological and soil surveys

Documents