 |
 |
A Web-based Data Format
and |
|
|
A Web-based Data Format
and |
Abstract
A language called GeotechML (Geotechnical Mark-up Language) has been developed for exchanging geotechnical data via the World Wide Web. GeotechML is a geotechnical version of XML (Extensible Mark-up Language). The file structure is outlined for GeotechML files containing ground investigation data. It is shown how style sheets can be used to produce different forms of display in a web browser. These have been used to show simple text-based borehole logs and tables of test data. A Java program is also described that can graphically display the contents of a GeotechML file to produce borehole logs, cross-sections and plots of test data. It is suggested that GeotechML is likely to become a standard exchange format for geotechnical data, not only for web-based applications but also for other software applications.
Introduction
GeotechML is a version of XML (Extensible Mark-up Language) specifically targeted at geotechnical engineering. The concept of creating a geotechnical version of XML was first proposed by W3G (The World Wide Web of Geotechnical Engineers) (http://www.ejge.com/GML/) in 1998 and the process of defining the language is underway (McPhail, 2001). Toll and Cubbitt (2001; 2003) have described how geotechnical entities (e.g. foundations, retaining walls and dams) can be represented in GeotechML. It is likely that the development of the language will continue for some time. The great power of XML is its built-in extensibility, which will allow the language to continue to evolve to meet the needs of geotechnical professionals.
XML allows simple text files to be 'marked up' by including 'tags' within the file. These tags can be recognised by an XML compliant web browser (e.g Microsoft Internet Explorer 5.0 and above). XML is being widely adopted by web developers for producing the next generation of web-based materials (http://www.w3.org/XML/). XML is a more generic form of mark-up language than HTML (Hyper-Text Mark-up Language), which, to date, has been the main language used on the World Wide Web. HTML was purely a display language that allowed tags to be introduced to define how the text would be formatted for display within a web browser. For instance, a piece of text enclosed within the following tags <b> … </b> would be displayed in a bold font. XML uses the same concept, but allows the tags to be user defined. This means that the tags can be used to give meaning to the contents of a file; for instance data can be marked up using <borehole> ... </borehole> tags to indicate that all data between these tags relates to borehole information. It will be possible to use XML tags in order to search for files on the World Wide Web. This will make web-based searching much more productive and focused, rather than the keyword searching options that are currently available.
This paper focuses on using GeotechML to represent ground investigation data i.e. data obtained from boreholes and trialpits. File structures have been developed for representing ground conditions, insitu test data, laboratory test data etc. An existing exchange format for such data was put forward by the Association of Geotechnical and Geoenvironmental Specialists (AGS) in 1992, which has been widely adopted in the UK. This data format is now in its third edition (AGS, 1999) and is available from the AGS web site at: http://www.ags.org.uk McPhail (2001) notes some limitations of the AGS format and argues that an XML format has great advantages. The GeotechML format proposed here is closely based on the AGS format, although some important changes have been introduced.
GeotechML itself is a file format. Although XML compliant browsers can display XML data directly, the browser produces only a simple text-based display with predefined formatting to indicate the information hierarchy. Therefore, in order for this format to be useful it is necessary to have the ability to transform the XML file into different display formats. Extensible Stylesheet Language (XSL) has been developed in parallel with XML to allow XML files to be transformed into HTML for display. The paper describes how style sheets can been written in XSL to produce simple text-based borehole logs and tables of test data.
However, ground investigation data is best presented graphically. Therefore, a program has been written in Java that can produce graphical representations from a GeotechML file. This program can produce cross-sections, graphical borehole logs and plots of test data.
Parts of the definition of GeotechML are outlined in this paper. However, complete definitions of GeotechML are available at the Durham University GeotechML website (http://www.dur.ac.uk/geo-engineering/geotechml/). The website also provides links to the style sheets and Java program described in the paper.
Some XML Concepts
The simplest construct in XML is called an element, for example:
<project>"Durham University Project"</project>
In this example, a project element is defined by enclosing data between a start tag <project> and an end tag </project> and thus identifies it as a project. However, we might want to store other information about the project (for example, the location and an identifier for the project) and this could be done in a number of ways. The first option is to assign attributes to the element, for example:
<project location="Durham" identifier="00001">"Durham University Project"</project>
The second option is to nest other elements within the project element, for example:
<project>
<name>"Durham University Project"</name>
<location>"Durham"</location>
<identifier>"00001"</identifier>
</project>
Although attributes might seem a more convenient way of representing the information, their use is more restricted than elements. If it is the intention that the piece of information should be available for general search purposes then it is better to represent the data as elements rather than attributes.
It is important that XML documents are well formed i.e. they conform to a predetermined format. This makes error checking possible and means that misspellings and incorrect definition of tags is avoided. An XML document can contain a Document Type Definition (DTD) that defines the elements that should be present within the XML file. The DTD is interpreted by a parser (a piece of software that reads the XML file and abstracts the relevant information between the tags).
An example of a DTD for the latter version of the project element described above would be as follows:
<!ELEMENT project (name?, location?, identifier?)>
<!ELEMENT name (#PCDATA?)>
<!ELEMENT location (#PCDATA?)>
<!ELEMENT identifier (#PCDATA?)>
This defines the project element as comprising the child elements: name, location, identifier. The question mark after the element names indicates that there should be zero or one entry for each of these element. Alternatives would be a plus sign '+' to indicate one or more elements or an asterisk '*' to indicate zero or more elements. The child elements are then defined themselves as comprising #PCDATA. This indicates parsed character data, meaning that the information is character data (i.e. a text string) and is to be processed by a parser.
Defining GeotechML
The overall structure of GeotechML suggested by Toll and Cubbitt (2001) is shown in Figure 1. The top level element Geotechnical Project is divided into the component parts of Site Investigation, Entities, Construction and Monitoring. Only the Site Investigation component will be addressed in this paper. Some work on the Entities component has been done by Toll and Cubbitt (2001) but will not be discussed here. The Site Investigation element is represented by: Desk Study, Site Reconnaissance, Ground Investigation and Field Monitoring. A Ground Investigation element can comprise a number of Borehole or Trialpit elements.
Figure 1. GeotechML structure for ground investigation data
Figure 2. shows a GeotechML file displayed in an XML compliant browser. The browser allows the tree structure of an XML file to be expanded and collapsed by clicking on the appropriate element. A minus sign '–' to the left of an element name in Figure 2 indicates that all information for that element is being displayed. A plus sign '+' indicates that there is more information that could be displayed. If neither a '-' nor '+' is shown that means that there are no child elements below that element.
Figure 2. A GeotechML file displayed in an XML compliant web browser
The hierarchy identified in Figure 1 can be seen in Figure 2, starting with GEOTECHNICAL_PROJECT which contains the elements: IDENTIFIER, NAME, DATE, GEOTECH_ML_VERSION, PROJECT_DETAILS (i.e. representing the properties of GEOTECHNICAL_PROJECT) and then the child element SITE_INVESTIGATION. The SITE_INVESTIGATION element again contains IDENTIFIER, NAME and DATE elements but can also be seen to contain two GROUND_INVESTIGATION elements (one for a preliminary ground investigation and a second main ground investigation). GROUND_INVESTIGATION contains a number of BOREHOLE elements.
The full definition of the Document Type Definition (DTD) for a GeotechML file is available at the Durham GeotechML website (http://www.dur.ac.uk/geo-engineering/geotechml/). However, selected parts of the DTD are listed in Figure 3 and these are discussed in the following.
|
<!ELEMENT BOREHOLE (IDENTIFIER?, HOLE_DETAILS?, GROUND_CONDITIONS?, INSITU_TESTS?, SAMPLES?, WATER_STRIKE*, PIEZOMETER*)> <!ELEMENT GROUND_CONDITIONS (LAYER+, GROUND_DETAIL*, CORE*, DISCONTINUITIES*, FRACTURES*, WEATHERING*)> <!ELEMENT LAYER (TOP?, BASE?, NAME?, DESCRIPTION?, GEOLOGICAL_ORIGIN?, MATERIAL*, LEGEND?)> <!ELEMENT GROUND_DETAIL (TOP?, BASE?, DESCRIPTION?)> <!ELEMENT MATERIAL (NAME?, TYPE?, MOISTURE_CONDITION?, CONSISTENCY?, PLASTICITY?, CONSTITUENT*, STRUCTURE*)> <!ELEMENT INSITU_TESTS (CONE_PENETRATION_TEST*, DYNAMIC_PROFILING_TEST*, HORIZONTAL_PROFILING_GAUGE*, INSITU_CBR*, INSITU_DENSITY*, SINGLE_POINT_INSTRUMENT*, INSITU_PERMEABILITY_TEST*, INSITU_REDOX_TEST*, INSITU_RESISTIVITY_TEST*, INSITU_VANE_TEST*, PROFILING_TEST*, PRESSUREMETER_TEST*, PUMPING_TEST*, STANDARD_PENETRATION_TEST* )> <!ELEMENT STANDARD_PENETRATION_TEST (TOP?, TYPE?, N_VALUE?, SEATING_BLOWS?, MAIN_TEST_BLOWS?, TOTAL_PENETRATION?, REPORTED_RESULT?, BLOWS_INCREMENT_1?, BLOWS_INCREMENT_2?, BLOWS_INCREMENT_3?, BLOWS_INCREMENT_4?, BLOWS_INCREMENT_5?, BLOWS_INCREMENT_6?, PENETRATION_INCREMENT_1?, PENETRATION_INCREMENT_2?, PENETRATION_INCREMENT_3?, PENETRATION_INCREMENT_4?, PENETRATION_INCREMENT_5?,PENETRATION_INCREMENT_6?, CASING_DEPTH?,WATER_DEPTH?, COMMENTS? )> <!ELEMENT SAMPLES (SAMPLE+)> <!ELEMENT SAMPLE (TOP?, IDENTIFIER?, TYPE?, SAMPLE_DETAILS?, LABORATORY_TESTS?)> <!ELEMENT LABORATORY_TESTS (CONSOLIDATION_TEST*, COMPACTION_TEST*, CBR_TEST*, CHALK_TEST*, CLASSIFICATION*, MOISTURE_CONDITION_VALUE_TEST*, PERMEABILITY_TEST*, RELATIVE_DENSITY_TEST*, ROCK_TESTS*, SHEAR_BOX_TEST*, SUCTION_TEST*, TEN_PERCENT_FINES_TEST*, TRIAXIAL_TEST*)> <!ELEMENT CLASSIFICATION (SAMPLE_IDENTIFIER?, DEPTH?, SPECIMEN?, PREPARATION_METHOD?, NATURAL_WATER_CONTENT?, LIQUID_LIMIT?, PLASTIC_LIMIT?, BULK_DENSITY?, DRY_DENSITY?, PARTICLE_DENSITY?, PERCENT_PASSING_425um?, SHRINKAGE_LIMIT?, LINEAR_SHRINKAGE?, HAND_VANE_PEAK_STRENGTH?, HAND_VANE_REMOULDED_STRENGTH?, PENETROMETER_STRENGTH?, LAB_VANE_PEAK_STRENGTH?, LAB_VANE_REMOULDED_STRENGTH?)> |
Boreholes
The DTD definition of a BOREHOLE element is shown in Figure 3. In this definition IDENTIFIER is a single element that uniquely identifies each borehole (e.g. BH1). All other details of the borehole itself are stored within a child element HOLE_DETAILS. Results from the boring and testing are stored within the elements GROUND_CONDITIONS, INSITU_TESTS, SAMPLES, WATER_STRIKE and PIEZOMETER.
The HOLE_DETAILS element is used by both BOREHOLE and TRIALPIT elements. Its definition within the DTD is also shown in Figure 3. The elements within it closely mirror the AGS definition for the HOLE data group (AGS, 1999). However, full names have been used in the GeotechML definitions rather than the 4 digit codes used within AGS (e.g. CASING_DIAMETER rather than the AGS code HOLE_CDIA). This gives much greater transparency to the file. It is felt that a GeotechML file could be understood by a geotechnical specialist without reference to any further documentation.
Since the HOLE_DETAILS element is used by both BOREHOLE and TRIALPIT elements it includes an either/or definition: ((DIAMETER … ) | (LENGTH …)) as shown in Figure 3. The first group of properties are those used for boreholes and the latter are appropriate for trialpits. Some of the items are followed by an '*' symbol to indicate there can be more than one of these element for each hole.
Ground Conditions
GROUND_CONDITIONS is a particularly important element of a BOREHOLE or TRIALPIT element. It contains LAYER and GROUND_DETAIL elements. These are the equivalent of the AGS groups, GEOL and DETL. The name Layer is thought to be clearer than Geology (the logical name if the AGS GEOL name were expanded) as Geology has much wider connotations.
The LAYER element represents the ground layers as revealed by boring, referenced by TOP and BASE (i.e depth to the top and base of the layer). GROUND_DETAIL elements can contain additional descriptive information (again referenced by TOP and BASE). These are used to note additional information about a small part of a layer (e.g. more clayey). Alternatively it can span across layer boundaries (e.g. cobble being pushed ahead). Therefore GROUND_DETAILS are defined at BOREHOLE level rather than being contained with a LAYER element.
Each layer can contain NAME, DESCRIPTION, GEOLOGICAL_ORIGIN, MATERIAL and LEGEND. The DESCRIPTION element within LAYER is the full engineering soil or rock description, as per British Standard 5930 (1981). GEOLOGICAL_ORIGIN is an interpretation of the origin of the layer (e.g. Alluvium, Fluvio-Glacial etc). LEGEND represents the graphical legend should be shown on the borehole log for the layer. These three elements coincide with the AGS codes GEOL_DESC, GEOL_GEOL and GEOL_LEG.
Thereafter, the layer definition departs from the AGS format and adopts a more complex representation based on work by Toll and Oliver (1995). An example is given in Figure 4. This representation allows soil and rock descriptions to be stored in a structured form, rather than as a single text string. If information needs to be abstracted from the description, say the consistency of the soil, the text description must be parsed. Rather than parse a description each time a piece of information is needed from it, a more efficient practice would be for the parsed information to be stored. The information contained in the description is then available as separate fields within the data structure, and is easily and efficiently accessible.
|
<GROUND_CONDITIONS> <LAYER> <MATERIAL> <CONSTITUENT> <CONSTITUENT> <CONSTITUENT> <GROUND_DETAIL> <GROUND_DETAIL> </GROUND_CONDITIONS> |
Toll and Oliver recognised that some descriptions of layers may contain more than one material (soil or rock). For example 'SANDSTONE interbedded with SILTSTONE' or 'CLAY with pockets of SAND'. In these examples two distinct materials are present within the layer, yet cannot be distinguished as separate layers (a layer being defined by depth limits). Therefore GeotechML allows for the possibility of multiple materials within a layer . The relationships between the materials are stored in a STRUCTURE element. In the first example given above, the term 'interbedded' would describe both the materials SANDSTONE and SILTSTONE. In the second example the term 'pockets' would describe the SAND while CLAY would be described as 'dominant'.
This format can also deal with the case where a soil or rock changes significantly from the top to the base of a layer e.g. Silty SAND becoming clayey SAND. The first material Silty Sand would be identified as 'Top' in the STRUCTURE element and Clayey SAND as a separate material identified as 'Base'. Other information on the structure can be recorded such as bedding dip, orientation and spacing, or spacing of inclusions.
A Material can be further broken down into Constituents. The CONSTITUENT element indicates which constituents eg silt, sand, clay etc make up the material. The amount of each constituent is identified. The convention adopted is that the amount is described as Main if the constituent is dominant (SILT etc), or as Major Very silty etc), Secondary Silty etc), or Minor (Slightly silty etc.) for the lesser constituents (Toll and Oliver, 1995). This scheme can also be used to represent descriptions which are not those recommended by British Standard 5930 (1981) (but which are still found in older borehole records) such as with some ..., with a little ... etc. An example is given in Figure 4.
Detailed information on Grading, Shape and Texture can relate to a particular constituent, rather than the stratum as a whole (e.g. CLAY with a little black subrounded coarse gravel - where subrounded and coarse refer to the lesser constituent, gravel). Therefore, this information is stored in the CONSTITUENT element, rather than at the MATERIAL level. Colour can also relate to the individual constituents, rather than to the stratum as a whole (e.g. when the lesser constituent gravel is described as black in the example above). Colour information is therefore included at CONSTITUENT level in GeotechML. Colour is represented by MAIN_COLOUR (e.g. red), SECONDARY_COLOUR (e.g reddish) and COLOUR_MODIFIER (light, dark etc).
Insitu Tests
The INSITU_TESTS element can contain multiple results from a range of test types. The tests currently incorporated into GeotechML are those recognised within AGS, 1999. The DTD definition in Figure 3 shows the list of test types.
|
<INSITU_TESTS> <SAMPLES> <LABORATORY_TESTS> |
Figure 5 shows a simple representation for Standard Penetration Test results. The only elements shown for each STANDARD_PENETRATION_TEST element are TOP, N_VALUE and TYPE. Many more elements are defined in the DTD for this test (Figure 3), but only the elements that are needed have to be defined. The example shows two STANDARD_PENETRATION_TEST elements, but as many as are required can be included within the INSITU_TESTS element.
Samples and Laboratory Tests
A collective element SAMPLES is attached at BOREHOLE level and this can contain multiple SAMPLE elements. The DTD definitions are given in Figure 3. Each SAMPLE element contains TOP, IDENTIFIER, TYPE elements, but further information about each sample can be stored in SAMPLE_DETAILS (Figure 5). A LABORATORY_TESTS element is included in each SAMPLE element. Initially, LABORATORY_TESTS was attached at BOREHOLE level, rather than at SAMPLE level. However, it was found that mistakes in data entry could easily lead to a mismatch between sample depths and identifiers. Including LABORATORY_TESTS within SAMPLE meant that the sample information was only entered once and avoided any ambiguity about sample information.
The DTD definition in Figure 3 show the range of laboratory tests currently recognised within GeotechML. These are based on those defined in AGS, 1999. The DTD definition for classification tests is also given in Figure 3. Examples of test results reported within the CLASSIFICATION and TRIAXIAL_TEST elements are shown in Figure 5. The result from a Triaxial test is given using the UNDRAINED_SHEAR_STRENGTH element. The alternative elements COHESION and FRICTION_ANGLE are left empty (<COHESION/> is a shorthand form for <COHESION></COHESION>). These elements did not need to be included, but leaving them 'Empty' has the same effect.
Style sheets for displaying GeotechML
Figures 6 and 7 show how GeotechML can be transformed using style sheets for display in a web browser. Figure 6 shows how a simple text-based borehole log can be generated. Figure 7 shows how test data can be displayed in tabular form. The style sheet, written in XSL, actually transforms the XML into HTML for the purposes of display. If a reference to the style sheet is included in the XML file then the browser will always transform the file. Viewers of the web page might be completely unaware that it was an XML file that was being viewed; they would just see the formatted version.
Figure 6. A borehole log created using a style sheet
Figure 7. A table of test data created using a style sheet
|
<xsl:for-each select="/GEOTECHNICAL_PROJECT/SITE_INVESTIGATION/GROUND_INVESTIGATION"> <td width="10%">Borehole</td> <xsl:for-each select="BOREHOLE/SAMPLES/SAMPLE/LABORATORY_TESTS/CLASSIFICATION"> |
A section of the XSL style sheet used to generate the display in Figure 7 is listed in Figure 8. The first line is an XSL 'for-each' command:
<xsl:for-each select="/GEOTECHNICAL_PROJECT/SITE_INVESTIGATION/GROUND_INVESTIGATION">
This instructs the style sheet to loop through all the occurrences of GROUND_INVESTIGATION elements found within the GeotechML file. It then checks for the occurrence of any classification data with the XSL 'if' command:
<xsl:if test="BOREHOLE/SAMPLES/SAMPLE/LABORATORY_TESTS/CLASSIFICATION">
If this is satisfied then a full width table is created using the HTML tag <table width="100%">. A table row is created using <tr> … </tr> which is filled with a heading that spans over ten columns <td colspan="10" ><b>Classification Tests</b></td>. In the next row ten columns are created, each filled with a column heading e.g. <td width="10%">Plastic Limit (%)</td>.
The style sheet then loops through all the CLASSIFICATION elements using the XLS 'for-each' command:
<xsl:for-each select="BOREHOLE/SAMPLES/SAMPLE/LABORATORY_TESTS/CLASSIFICATION">
For each element a new row is created and the values of the elements within the CLASSIFICATION elements are entered into the table cells using the XSL 'value-of' command. For example "PLASTIC_LIMIT"/> enters the value of PLASTIC_LIMIT, one of the elements containing data within the CLASSIFICATION element.
This is just one example of how XSL can be used to generate an HTML output. The great advantage is that a variety of style sheets can be produced that can reformat the XML file and display it differently, without having to alter the underlying XML data structure in any way. This means that each user can generate their own preferred display mode (using their own style sheet), but that a standard underlying data format can be maintained that is common to all users.
A Java program for producing graphical output from GeotechML files
It is normal practice for ground investigation data to be presented graphically in the form of borehole logs, cross-sections and plots of test data. Such a graphical presentation cannot be achieved using XSL style sheets. Therefore, a Java program has been written to demonstrate other possible ways in which a GeotechML file could be displayed.
Java is an object-orientated, programming language that was designed to be machine independent, meaning that it can be run on a variety of different computer systems. Java enables programmers to write small programs called applets, which can be embedded within web pages, but can also be used for writing larger scale application programs. Java provides the most robust set of tools for XML manipulation of any programming language and is ideally suited to developing applications that make use of XML. Graphical representations can also be generated using the Graphics 2D classes available in Java version 1.2.2.
The Java program has been written to be run from a web page and is available at the Durham GeotechML website (http://www.dur.ac.uk/geo-engineering/geotechml/). Figure 9 shows a screen display showing all boreholes contained in a GeotechML file. In this screen the layers are colour coded, rather than using the conventional graphical legends, since it is difficult to distinguish legends when many boreholes are being displayed. When the mouse pointer is moved over any borehole, the borehole identifier, location and ground level are displayed in the bottom right-hand area of the screen. The full layer description for each layer is also displayed at the bottom of the screen when the mouse pointer is moved over them.
Figure 9. A Java program to graphically present ground investigation data
Provision is also made to allow selected boreholes to be drawn along a defined section line. The 'Graphs' menu (available from the menu bar at the top of the screen) can be used to show a plan view of the site showing the borehole positions. A section line can be drawn on the plot so that projections of selected boreholes will be drawn along the chosen line.
A full graphical borehole log for each borehole can be displayed by double clicking with the mouse on any borehole displayed within a cross-section. An example is shown in Figure 10. This provides a conventional graphical log, drawn to scale, with graphical legends to indicate the soil and rock types within each layer. A depth and reduced level scale is provided. Information on samples and insitu tests are displayed, referenced to depth, in tables alongside the log. A small inset shows a site plan indicating the location of the selected borehole with a different colour. A full description of each layer can be obtained by moving the mouse pointer over each layer. The description is shown at the bottom of the window.
Figure 10. A borehole log created using the Java program
Plots of test data are also provided through the 'Graphs' menu. The program currently provides plots of standard penetration tests against depth (Figure 11); liquid limit, plastic limit and natural water content against depth; liquidity index against depth and a Plasticity Chart (Figure 12).
Figure 11. A plot of Standard Penetration Test N-Values against depth created using the Java program
Figure 12. A classification chart created using the Java program
A simple interpolation option is also provided. Linear connections are drawn between layers that have been given the same name. This makes use of the NAME element attached to each layer (Figure 4).
Discussion
GeotechML has been developed using the XML language which will become the main form of data representation used on the World Wide Web. It is an extension and a generalisation of the existing AGS format (AGS, 1999). GeotechML uses an object representation in which each data element is located within a hierarchy. In contrast, the AGS format is a tabular format that makes use of relational links to impart a data structure. This made the AGS ideally suited for transferring data between relational database systems, which use similar column/row formats. However, the AGS format could not be used as a way of representing data on the World Wide Web since the web relies on object linkages.
The AGS format has been highly successful as an exchange format between different spreadsheet and database packages. However, it has no use beyond that. GeotechML, however, provides all the possibilities that XML provides. Tools are available for XML that provide many ways of displaying the data (e.g. XSL and Java). However, perhaps the major advantage is that using an XML format will make it possible to search all geotechnical data available on the web. For instance, it would be possible to locate GeotechML files that contain projects within a particular geographical location. In this way the World Wide Web will become an international repository of geotechnical information, available to the whole community. This avoids the necessity to establish national or international geotechnical databases; each data owner can make their data directly available on their own web server.
Although GeotechML has been designed for use on the World Wide Web it will not be limited to that. It uses very simple text files that can be easily accessed and read. Its data structure and the fact that the tags have meaningful names make it intelligible to a geotechnical specialist, in most cases without the need for a data dictionary. Therefore, it could be used as an interchange format for any geotechnical software application (Toll, 2001).
Although this paper deals only with ground investigation data, GeotechML will become more extensive that this. It will have ways to represent geotechnical entities (Toll and Cubbitt, 2001), to name one aspect that has so far been addressed. In contrast, the AGS format, as it exists at present, can only be used for factual ground investigation data. GeotechML will be much more powerful in being able to link together many different aspects of a geotechnical project.
It could be argued that GeotechML will be less compact in terms of file size than the AGS format. GeotechML requires an opening and closing tag for each individual data element whereas the AGS tabular format requires the data names to be defined only once at the top of each data group. However, the constraints on file size (both in terms of disc storage or transfer via the internet) are not such a problem as when the AGS format was being developed. The GeotechML uses only about 10 kbytes per borehole for a typical set of information. The resulting file sizes are still very small compared to current file sizes on the web. (A typical photograph image displayed on the web in JPEG format image can be larger than 100 kbytes). The slight increase in file size compared to AGS is not a major disadvantage when weighed against the many advantages of GeotechML.
Conclusions
A mark-up language (GeotechML) has been developed that can be used to represent geotechnical information on the World Wide Web. The data structure for ground investigation data is presented here, although GeotechML can also be used for representing other data (e.g. geotechnical entities). GeotechML is the geotechnical equivalent of Extensible Mark-up language (XML) which will become the main form of data representation used on the World Wide Web.
GeotechML files make use of a simple text-based format. However, they can be viewed within an XML compliant web browser that can recognise the data structure within the file. Style sheets can be used to directly transform the XML into HTML (Hypertext mark-up language) which is currently the main language used on the World Wide Web. The style sheets can be easily configured to personal preferences without changing the underlying data format. The data in a GeotechML file can also be presented graphically using a Java program. A program is described that can display ground investigation data in the form of borehole logs, cross-sections and plots of test data.
GeotechML will make it possible to search all geotechnical data available on the web. In this way the World Wide Web will become an international repository of geotechnical information, available to the whole community, avoiding the need to establish national or international geotechnical databases. In addition, it could be used as an interchange format for all geotechnical software applications, not only on the internet.
References
 | |
| © 2003 ejge | |