Cranfield University School of Applied Sciences. MSc Geographical Information Management Academic Year: 2006/2007. Michael Owonibi

Transcription

1 School of Applied Sciences MSc Geographical Information Management Academic Year: 2006/2007 Michael Owonibi The Development of a Prototype Soils Archive Information System to Publish World Soil Data and Metadata (WOSSAC) Holdings, Using Proprietary and Open (Public) Standards Supervisor: Dr Stephen Hallett Submitted on 5th September, 2007 This thesis is submitted in partial fulfilment of the requirements for the degree of MSc Geographical Information Management, All rights reserved. No part of this publication may be reproduced without the permission of the copyright holder.

2 ii ABSTRACT This study investigates methods of publicising data from the World Soil Survey Archive and Catalogue (WOSSAC) to ease both its accessibility and use. The research focuses on redesigning the WOSSAC database, and generating output of data and metadata via Google Earth, a proprietary Internet mapping standard, and the implementation of an OGC-compliant Web Mapping Service (WMS), a public Internet mapping standard. To make the WOSSAC s metadata database compliant with geospatial metadata standards the database was redesigned. This involved ensuring that each item s catalogue entry conforms to the appropriate metadata standards such as ISO 19115, UKGemini, Dublin Core and Marc 21. Using the redesigned and standards-compliant WOSSAC database together with digitised maps, an OGC-compliant Web Map Service was implemented. This Web map service was designed using MapServer. Web applications, written in ColdFusion and Python Programming Languages, were then used to produce dynamic output, such as Google Keyhole Markup Language (KML) files containing both the WOSSAC metadata and the WMS service, into Google Earth. A comparison of the proprietary and public standards was also made. This study highlights the deficiency of the currently available geospatial metadata standards in handling historical, legacy archival data such as that held in WOSSAC. It also reveals that a standards-compliant geospatial database, a Web Map Service, and Google Earth used cooperatively can be used to publish the catalogue and maps of a geospatial data collection. This led to a series of recommendations, some of which include the digitisation of WOSSAC items to make them more standards-complaint and ultimately more interoperable in web mapping applications, as well as the further investigation of the capabilities of Google Earth for data discovery. ii

3 iii ACKNOWLEGDEMENTS I am grateful to my supervisor, Dr Stephen Hallett, for his support, constructive comments and encouragement. I also want to thank Andrew Rayner, Caroline Keay and Katie Green. I also want to appreciate my parents, Mr & Mrs S.A. Owonibi, and my siblings for their love and care. iii

4 iv TABLE OF CONTENTS ABSTRACT ii ACKNOWLEGDEMENTS iii TABLE OF CONTENTS iv GLOSSARY OF TERMS... vi INTRODUCTION INTRODUCTION AIM AND OBJECTIVES... 1 LITERATURE REVIEW INTEROPERABILITY THE INSPIRE EXAMPLE METADATA STANDARDS MARC Standard Dublin Core DCLite4G FGDC CSGDM e-gms ISO 19115/ Gigateway UK GEMINI CEN/TC OPEN INTEROPERABILITY STANDARDS OGC WMS (Web Map Service) Specification OGC WFS (Web Feature Service) Specification OGC WCS (Web Coverage Service) Specification DATA / SERVICES DISCOVERY Clearinghouse Portals (Or Geo-Portals) GOOGLE EARTH AND GEO-DATA SHARING PUBLICISING WOSSAC DATA AND METADATA. 13 METHODOLOGY WOSSAC DATABASE RE-DESIGN The Present WOSSAC Database Schema and its Disadvantages The Proposed Prototype Database Schema Entering Prototype Dataset Digitising Sample WOSSAC Data Georeferencing of the Scanned Maps PUBLICISING USING GOOGLE EARTH IMPLEMENTATION OF MAPSERVER WMS Web Map Service Creation for WOSSAC MapServer Configuration using a Wrapper Script DYNAMIC KML CREATION WITH PYTHON.. 27 RESULTS AND DISCUSSION DATABASE RE-DESIGN AND DATA ENTRY RESULTS Proposed Database Schema s Conformance to Bibliographic Metadata Standards Proposed Database Schema s Conformance to Geospatial Metadata Standards. 32 iv

5 v Data Entry Findings, and Causes and Resolutions Possible Reasons for Non-Compliance of WOSSAC Data Items to ISO19115 and UKGemini WMS SERVICE IMPLEMENTATION RESULT AND DISCUSSION GOOGLE EARTH MAPPING RESULT AND DISCUSSION Google Search and its Implementation COMPARISON OF THE OGC WMS AND GOOGLE EARTH MAPPING. 39 CONCLUSIONS AND RECOMMENDATIONS CONCLUSIONS RECOMMENDATIONS Recommendations With Regards to the Database design and WOSSAC Data Recommendations With Regards to Google Earth mapping implementation Recommendations with regards to OGC WMS Implementations. 43 REFERENCES APPENDIX. 48 APPENDIX A- PROPOSED DATABASE DICTIONARY 48 A-1 WOSSAC _ITEMS Table.. 49 A-2 WOSSAC_MAP AND WOSSAC_IMAGE Tables.. 53 A-3 WOSSAC_DOCUMENTS Table. 58 A-4 WOSSAC_RECORD_UPDATES TABLE.. 60 A-5 WOSSAC_LOCATION_LUT TABLE 60 A-6 Modification to WOSSAC_WORLD_CITIES Table 61 A-7 COORD_REF_SYS Table: 62 A-8 COORD_REF_SYS_AREA Table 62 A-9 WOSSAC Look Up Tables Mapping to ISO Code Table.. 63 A-10 WOSSAC Look Up Tables and Fields/Elements with Their Description.. 63 APPENDIX B SCRIPTS WRITTEN.. 64 B-1 CFML Script to Create Google Earth Placemark KML Files from Proposed WOSSAC Database Query 64 B-2 CFML Script to Create MapServer s Mapfile from Proposed WOSSAC Database Query. 73 B-3 Coldfusion Component Script Containing Database Queries. 77 B-4 MapServer Wrapper Script for Web Mapping Service (WMS) written in PHP. 80 B-5 Python Script Returning Dynamic Google Earth Polygon KML from URL GET Variables.. 81 B-6 Python Script Returning Dynamic Google Earth Image Ovelay KML from URL GET Variables 82 APPENDIX C INSTRUCTIONS TO CLIENT/USER 84 C-1 Using Google Earth to View Wossac Items. 84 C-2 Using the Web Mapping Service v

6 vi GLOSSARY OF TERMS CEN: Comité Européen de Normalisation CFML: ColdFusion MarkUp Language CGI: Common Gateway Interface CSDGM: Content Standard for Digital Geospatial Metadata DCMES: Dublin Core Metadata Element Set EU: European Union FGDC: Federal Geographic Data Committee GE: Google Earth GIS/GI: Geographic(al) Information System/ Geographic(al) Information GML: Geography MarkUp Language GeoRSS: GeoGraphically- encoded Really Simple Syndication INSPIRE: Infrastructure for Spatial Information in Europe ISO: International Standards Organisation KML/KMZ: Keyhole MarkUp Language/ Keyhole MarkUp Language (Zipped) LMO: Legally Mandated Organisation MARC: Machine Readable Cataloguing Record NGDF: National Geospatial Data Framework NSDI: National Spatial Data Infrastructure NSRI: National Soil Resources Institute OGC: Open Geospatial consortium SDIC: Spatial Data Interest Community SDI: Spatial Data Infrastructure SRS/CRS: Spatial Reference System/ Coordinate Reference System URL: Universal Resource Locator WCS: Web Coverage Service WMS: Web Mapping Service WFS: Web Feature Service WOSSAC: World Soil Survey Archive and Catalogue XML: Extensible MarkUp Language vi

7 1 INTRODUCTION 1.1 INTRODUCTION WOSSAC (world soil survey archive and catalogue) is a repository of archival store for soil survey reports, maps and photographs produced by British companies and surveyors overseas in the last 80 years in 250 countries, with a view to ensuring their enduring availability and protection (Hallett et al., 2006; WOSSAC, 2004) 1. There are more than 13,000 items in WOSSAC, including maps, reports, monographs, satellite images - all in either hard or soft copy. The value of these items is put at over 200 million. Due to the fact that soil information varies slowly with time, there is a need to preserve the costly soil survey projects data (maps, images, and reports). But beyond preserving these records, there is a need to put them into effective use, and for them to be put into effective use, the data holdings must be publicised. Thus this project looks at means of publicising WOSSAC database items. This involves studying the means of publicising spatial and /or aspatial data using proprietary standard (Google Earth KML standard) and using the open standards. This involves reviewing various standards from metadata standard to interoperability standards with respect to the different types of the spatial and aspatial data present in the database. Also, publicising WOSSAC is viewed in the perspective of Directive 2007/2/EC, Infrastructure for Spatial Information in the European Community (INSPIRE), which came into force on May 15, 2007, which recommends all organisations producing spatial data of a specific theme to be part of the Spatial Data Infrastructure (SDI) in Europe. This is to ensure that data and metadata can be shared seamlessly between organisations. 1.2 AIM AND OBJECTIVES This project aims to demonstrate and compare the capabilities of Google Earth and OGC- compliant Web Map Server in publicising a UK Gemini compliant WOSSAC metadata database, and data. The objectives include: Objectives: Demonstrate the potentials of OGC WMS and Google Earth as a medium for accessing Soil maps held in the WOSSAC database; 1 See the project website at

8 2 Modify the WOSSAC database schema to be compliant with Geospatial metadata standards and populate it with prototype data; Deploy a written program to generate dynamically KML from modified WOSSAC metadata database; Implement a Web Mapping Service that will serve dynamically the WOSSAC server s mapping capabilities, the scanned maps (based on clients interaction), and the information about the maps in OGC WMS compliant format; Compare critically the Open Standard and Proprietary standards, and make recommendations with regards to the mode of publishing the soils map in WOSSAC database.

9 3 LITERATURE REVIEW 2.1 INTEROPERABILITY According to Abel D.J., et al., (1998), Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged, while with regards to GIS, interoperability refers to the ability of [heterogeneous] digital systems to freely exchange all kinds of spatial information; and cooperatively, over networks run software capable of manipulating such information (OGC, 2004). This refers to the ability of GI systems to share seamlessly geospatial data, services and functionalities. Due to the increasing number of different organisations producing and using different types of geospatial data, there has been a parallel increasing need for integration and sharing of the datasets that each organisation produces among different organisations. This is important to enable each organisation to focus on producing a particular type of data (thus, increasing their efficiency in the data collection process), to remove duplication of geodata; and to reduce data search and data collection costs and effort. Other reasons as given by Chongjun Yang (2003) includes facilitation of application and model development; reduction in cost and effort associated with data acquisition, management, maintenance, and conversion; and provision of flexible computing environment with access to computing resources from desktop machines to high performance computers (supercomputers). Geospatial interoperability is implemented through web services and this is based on standards and specifications for metadata structure; and interfaces for the discovery of the data, sharing the data, representing the data, modifying the data and downloading the data. Using web services (software which makes itself available over the Internet and uses a standard extensible Markup Language (XML) messaging system) normalizes the GIS operations independent of operating system, programming language, and development environment (T. Kralidis & Y. Assefa, 2004). Web services are implemented by a process whereby a server (or image/feature server) with a properly structured metadata and spatial database publishes its capability on the Internet and the interested client can connect to it and request geospatial data from it. The process of server-client interaction requires both the server and client to have interfaces compliant to interoperability standards, such as OGC standards, that can connect each other. The process of geospatial interoperability is illustrated in figure 2.1 below.

10 4 CLIENTS -PC - PDA s -Mobile Phones CLIENT INTERFACE BASED ON INTEROPERABLE SPECIFICATION SERVICES REGISTRY (SDI) -Registers Services -Output the available services and metadata to INTERNET SERVICE INTERFACE BASED ON INTEROPERABLE SPECIFICATION SERVER OF SPATIAL DATA IN FORMAT A HELD BY ORGANISATION Z SERVICE INTERFACE BASED ON INTEROPERABLE SPECIFICATION SERVER OF SPATIAL DATA IN FORMAT B HELD BY ORGANISATION Y SERVICE INTERFACE BASED ON INTEROPERABLE SPECIFICATION SERVER OF SPATIAL DATA IN FORMAT C HELD BY ORGANISATION X Figure 2.1 Analogy of Geospatial Interoperability through web services One of the important implementations of the GIS interoperability is in the creation of Spatial Data Infrastructure (SDI) (defined by FGDC (2007a) as the technologies, policies, and people necessary to promote sharing of geospatial data throughout all levels of government, the private and non-profit sectors, and the academic community ). This is a means of bringing together spatial data across a region and serving them to different types of users. The major concepts upon which the SDI is built include: How the SDI should be disaggregated and structured using the data themes the data represents, e.g. Cadastral, hydrographic, transportation, environment, geodetic, soil etc; and that this data and metadata are managed by the most appropriate authority. Each SDI consists of network of nodes (which are spatial data servers) from which clients can request spatial data (image and query) and a portal for publishing the services on each node or at least, a clearing house for publishing data held by each organisation/node within the structure. (FGDC, 2007a); How the SDI should be able to allow servers an/or clients (Workstation computers, PC s, PDA, mobile phones, GPS operating any software that can connect to the Internet) to share, view and combine data seamlessly from various sources;

11 5 How the SDI should be able to allow other servers and/or clients to discover services and evaluate the use of the discovered service. Also, according to FGDC (2007b), The building blocks of an SDI are metadata, clearinghouse/portal, standards, framework, geospatial data, and partnerships, and some of these are discussed shortly. Example of SDI includes Global SDI (GSDI - Canada SDI (CSDI), Australia SDI (ASDI), European SDI (INSPIRE), United Nations SDI ( Global Monitoring for Environment and Security (GMES) SDI ( GEOSS SDI( 2.2 THE INSPIRE EXAMPLE The INfrastructure for SPatial Information in Europe (INSPIRE) initiative intends to trigger the creation of a European spatial information infrastructure that delivers to the users integrated spatial information services. These services should allow the users to identify and access spatial or geographical information from a wide range of sources, from the local level to the global level, in an inter-operable way for a variety of uses. (INSPIRE, 2007). According to INSPIRE (2007) Directive, each EU country is to set up a national spatial data infrastructure to be subdivided by region and data theme which are mapped to Topic Categories of ISO19115 specifications. Some of the important components of INSPIRE include the INSPIRE geoportal, the experimental form of which can be found online at the LMO (Legally Mandated Organisation, which are the public authorities, institutions and bodies who have a legal mandate to collect and serve/publish spatial data of a particular theme) and the SDIC (Spatial Data Interest Community which comprises of the organisation from both public and private sector organised by data themes or region which produces uses or transforms spatial data. The SDIC and LMO are to register their services and dataset they provide on the INSPIRE geo-portal. 2.3 METADATA STANDARDS Metadata can be described as data about data (Hillman, 2005). Also, the National Information Standards Organization describes metadata as structured

12 6 information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource. (NISO, 2004) Geospatial data metadata can be used to describe a data, organise and manage a database. It can also be used to publish an organisation s data holdings to clearing houses, geo-portals and data catalogues; and provide information to aid transferring of data. Levels of metadata vary from discovery level (which is a basic form of metadata which to find out the potentially available data that meets some specific criteria during a search), evaluation level (checking the quality of the information to ascertain the fitness of the data for the intended purpose) to usage level (information to use to configure a system to process the data). Due to heterogeneity in the type and use of data at various times by various organisations, there are a variety of metadata standards, national and international. Although it might be seen as preferable to have only one standard, there cannot be a single universal standard that can be adapted to all forms of data. The main standards in use relevant to geospatial datasets are discussed below MARC Standard The Machine readable cataloguing (MARC) standard was developed and managed by US library of congress and it is designed to store information about bibliographic materials. It stores information in machine (computer)-readable form using alpha-numeric field identifier. MARC has a large number of fields, and it can be easily extended to accommodate more fields. Although, it has fields that can store geospatial information, it is not well adapted to storing spatial information, and the large number of fields and its characteristic no-domain restriction make it less cost effective Dublin Core This was developed and managed by DCMI (an international open forum with participants from Academic institutions, library groups etc.). Its simple form has 15 free text elements with no mandatory fields. It was originally designed for handling bibliographic records. Although it has additional elements refinements, it is very poor in handling geographic aspect of data.

13 DCLite4G DCLite4G, which stands for Dublin Core Lightweight Profile for Geospatial" is a proposed extension of Dublin Core that will handle geospatial metadata. It defines minimal information model for metadata exchange, (Go-Geo, 2006). It has all the elements of Dublin core, together with some elements for description of spatial data and namespace used to define extra properties needed to usefully specify the properties of geospatial data (Osgeo wiki, 2007) FGDC CSGDM The Content Standard for Digital Geospatial Metadata (CSDGM) is the Metadata standard developed and maintained by the FGDC (Federal Geographic Data Committee) for the US spatial data user community. The elements are organised hierarchically. It was originally published in 1994, and revised in 1998 to produce the version 2 of it. According to FGDC (2007c), A key feature of the CSDGM Version 2 is the ability of geospatial data communities to customize the base CSDGM. Extensions are a set of added elements that extend the standard to better serve the community or data type. Although its use has been superseded by the ISO standard, there have been efforts to improve it to meet the ISO specifications. (FGDC, 2007c) e-gms The UK e-government Metadata Standard (e-gms) lays down the elements, refinements and encoding schemes to be used by government officers when creating metadata for their information resources or designing search interfaces for information systems. This forms part of the e-government Interoperability Framework (egif) (Cabinet office, 2003). The e-gms standard is based upon Dublin core and so, it represents geospatial data poorly, but it does ensure uniformity of metadata across the UK s public sector ISO 19115/19139 These are the two key international standards developed by the ISO for geospatial metadata. ISO19115 was published in 2003, and has more than 300 elements (most of which are optional) for describing all aspects of geospatial data. It is widely used as the basis for geospatial metadata services. However, because of the large number of metadata elements and the complexity of its data model, it is difficult

14 8 to implement (B Oates & J Rapaport, 2007). It should be noted that IS series specifies the standards for geographic data representation, while the XML implementation of the ISO19115 is the ISO 19139, published in Due to the fact that ISO19115 standard does not sufficiently enough, represent remotely sensed imagery and gridded data metadata and, (Geographic information Metadata Part 2: Extensions for imagery and gridded data) is being developed and is due to be released soon Gigateway The Gigateway Discovery Metadata Specification was created as part of the National Geospatial Data Framework (NGDF). It was developed from the FGDC standard, and was formerly known as the NGDF Metadata Specification (Cabinet Office, 2003), and like FGDC, this is not fully compliant to ISO standard, and it is not also fully compliant to e-gms standard UK GEMINI The UK GEMINI (GEo-spatial Metadata INteroperability einitiative) Discovery Metadata Standard is a metadata standard derived by combining e-gms and ISO19115 in the UK. Its element set can be used for describing geo-spatial, discovery level metadata. It was produced by the Association for Geographic Information (AGI), the e-government Unit of the Cabinet Office and the UK Data Archive (Cabinet Office, 2003), it has all the core elements of ISO19115 and e-gms, and will replace the existing NGDF standard in Gigateway CEN/TC 287 Comité Européen de Normalisation (CEN) is the European standard of geospatial metadata representation. It was operational from February, 1992 until September, 1999 when it became dormant, although it has been revived again. CEN/TC 287 will decide how to adopt and apply ISO standards to Europe (ISO/TC 211, 2003) thereby, producing a European metadata standard for the INSPIRE project. 2.4 OPEN INTEROPERABILITY STANDARDS An open GIS system allows for the sharing of geographic data, integration among several GIS technologies, and integration with other non-gis applications.

15 9 Due to the integration of the GIS into mainstream IT, attention have been shifted from data to services which is the means of achieving interoperability in GIS system (ESRI, 2003). Interoperability of GIS systems through web services is dependent on specifications/standards the specifications includes standard for interfaces (between on system and the other), encodings and schemas. This, according to ESRI (2003) allows a system to manage its own data using best methods and formats for their tools in whatever database environment they choose. The OpenGIS Consortium (OGC) has emerged as a major body promoting GIS openness, exchange of GIS services and interoperability standards. It is a consortium of GIS vendors, agencies, and academic institutions. The standards it has published includes web map service (WMS), web coverage service (WCS), web feature service (WFS), GML, catalogue service for the web (CSW), Simple feature access, Style layer descriptors etc. Some of these specifications relevant to the soils archive case study for this project, are discussed below OGC WMS (Web Map Service) Specification This standard specifies spatial data server-client interaction in serving up, viewing and interacting with spatial data/ maps of an area in form of images. This service provides three operations (GetCapabilities, GetMap, and GetFeatureInfo) in support of the creation and display of registered and superimposed map-like views of information that come simultaneously from multiple remote and heterogeneous sources (ESRI, 2006). The functions of these operations are: GetCapabilities specifies how to request and return service level metadata/ capability of a service; GetMap specifies how to request and return maps in image form of a particular area; GetFeatureInfo specifies how to send and return query about a particular object in a layer. A Web Map Service consists of series/stages of interaction between the server and the client. This starts from the client s discovery of the service after which comes a series of interactions between the server and the client to determine which version of WMS/WFS the server is implementing, then the client sends a GetCapabilities request, and the server returns a capabilities xml which contains information about the service especially the map layers

16 10 available and their bounding box, output image formats and Spatial Reference Systems (SRS s). This information is used by the client to request for map layers by specifying the map layers, SRS, bounding box, map styles (optional), etc. using the GetMap statement. This information is also used by the client in querying the returned map using the GetFeatureInfo statement. An analogy of this process is shown below in Figure 2.2. Returns Query results OGC WMS SERVER OGC WMS CLIENT Send Queries about the Layers Returns Requested layers in image format Request Map Layers based on returned XML Returns Capabilities XML Request Capabilities Interact to know WMS Version Discover service Web Mapping Services (WMS) Discovery Figure 2.2 Interaction between WMS server and Client in implementing WMS service OGC WFS (Web Feature Service) Specification This standard specifies spatial data server-client interaction in serving up, viewing and interacting with spatial data in a Geography MarkUp Language (GML) encoded data features (OGC, 2005) OGC WCS (Web Coverage Service) Specification This standard specifies spatial data server-client interaction in serving up, viewing and interacting with spatial data (originally in coverage format) in a Geography Mark Up language (GML) encoded format. In addition, the Web Coverage Service returns coverages representing space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties (OGC, 2006).

17 11 It should be noted that all OGC standards are based on ISO standards, and the ISO helps standardise the OGC specifications. 2.5 DATA / SERVICES DISCOVERY The ways in which metadata, data and services can be discovered online are highlighted below: Clearinghouse A clearinghouse can be defined as a public or private entity that processes and facilitates the processing of non-standardized information into standardized structured data (MHCP, 2006). With regards to GIS, this is a website that coordinates the publishing and access to geospatial data. It provides services such as the publishing of metadata, data searches/query, and data acquisition coordination. Sample online clearing houses include: Gigateway; the Geography network; the Alexander digital library; and the IOWA geospatial clearing house. These focus more on the data and metadata than services as is the case with portals Portals (Or Geo-Portals) A geo-portal can be seen as an online web super-site that can provide Search, Discovery, and Brokering services for organised access to geospatial Resources such as Data, Applications/services, Web sites and Documents. They can also be seen as a gateway to publishing, sharing and disseminating data and GIS services across an organised SDI. It is more focussed on services than the data (as against clearing houses). The major functions of a geo-portal include: Searching Discover, connect to, and utilize GIS data and Web services; Awareness Organize geospatial resources in one place for the enterprise; Categorization Catalog GIS data and web services within the context needed. (David Danko, 2006) The portal is the gateway to an SDI. Both the services and metadata are to be registered in the portal. The services are to be compliant to OGC catalog services standards which formerly used UDDI (Universal Description, Discovery and Integration) specifications, but now increasingly uses ebrim (ebxml Registry

18 12 Information Model) specifications in the publishing of the services. This allows a client to build maps online by combining services from many sources. Examples of such portals online include (FGDC portal), (European soil portal), (Environmental information portal), and (INSPIRE test portal). 2.6 GOOGLE EARTH AND GEO-DATA SHARING Google Earth (GE) is a virtual globe program that maps the earth by the superimposition of images obtained from satellite imagery, aerial photography and GIS 3D globe. It is an application developed by Google Inc. (Wikipedia, 2007). The resolution of GE varies from one point on the earth to another, thus there are some inaccuracies in how it displays the earth features. Although Google Earth is not a full GIS, it has a growing number of GIS capabilities which are being developed continuously. Google Earth provides information about boundaries, roads, environment, businesses, recreational centers, government facilities and lots of custom community content from users. Over the years, Google earth has grown in popularity and the number of users has been on the increase. Google Earth supports managing three-dimensional geospatial data through Keyhole Markup Language (KML) (Wikipedia, 2007) which is Google s proprietary XML format for describing geospatial data. This is similar in syntax/schema to the OGC s GML (used for WFS) especially in the representation of points, lines, polygons, but with some differences due to the applications focus. Although not a GIS, it is worth looking at Google Earth as a means of geospatial interoperability in future. This is due to the fact that it allows sharing of both static and dynamic geospatial data (through network links ) from various sources. Also, with the recent announcement in Feb 2007 of Google s KML search capabilities (B Oates & J Rapaport, 2007), then discovery of geospatial data and metadata in Google s proprietary KML format is made much easier. This thus makes search of a wide variety of unstructured sources possible as against the search of a structured network in an SDI. SDI search through the portal, though, is more focussed and targeted (B Oates & J Rapaport, 2007). A study of Google Earth shows that it has the potentials of WMS through its image overlay object and the potential to support fully WFS through the Placemark, Path and Polygon objects (which are equivalent of point, line and polygon GIS vector

19 13 data). Google Earth also has the potential of being an equivalent unstructured internetworked SDI through the KML search capabilities. 2.7 PUBLICISING WOSSAC DATA AND METADATA Danko (2006) stated that Metadata fuels clearinghouses (for data publicity), portals (for services discovery) and GIS interoperability. So, to properly publish the items of the WOSSAC database, the metadata must be up to standard. Previous work done by Koyanagi (2005) and Guillermo (2006) show that the present metadata schema does not currently appropriately represent spatial data. This is due to the complexity of the items recorded, and the item s media types in the database. Each item comprises of sub-items of varying media types (e.g. reports and maps). The set of media types of items/ sub-items currently includes soft and hard copy map sheets, map albums, soft and hard copy satellite imageries, digital and paper reports, monographs and map albums. The composition of an item in WOSSAC is complex as it is different forms/patterns of combination of maps, images, and reports, e.g. an item may be a combination of a report and a CD that contains different formats of two maps and some other reports including the original hardcopy report in the item in soft copy form. Effort is also being made to digitise the items in WOSSAC. The WOSSAC metadata database is designed using Dublin Core Standard; it also, has some MARC 21 elements. Due to this fact, Koyanagi (2005) pointed out that the database does not accurately represent the geospatial metadata (as the metadata standard does not accurately support spatial data) and Guillermo (2006) proposed another schema for the metadata database, such that will properly represent the spatial data, but this too does not solve the problem due to the complexity of the entities/ subitems contained in each item in the database, and due to the though it is simple, it is not extensible, and it is also, not normalised. Guillermo (2006) also used Google Earth for publishing the WOSSAC database, but this was not fully implemented, and the code presented is not efficient as it takes an extensively long time to run. Also, this project intends to look at the possibility of sharing and publishing the WOSSAC data in using Google earth (proprietary standard) and open standard (in an interoperable format and registering it in a portal such as the INSPIRE portal as soil is one of the main themes in the INSPIRE data types in SDI).

20 14 METHODOLOGY The general outline of the methodology of for the implementation of this project is: Re-Designing the existing WOSSAC database schema to conform to UKGemini/ ISO19115 standards; Input of prototype WOSSAC datasets metadata into the re-designed database to test its applicability to WOSSAC; Digitising a selection of representative WOSSAC materials; Writing of interactive web applications that create dynamically KML files; Implementation of OGC WMS service using MapServer software. 3.1 WOSSAC DATABASE RE-DESIGN The existing WOSSAC catalogue database holds more than 13,000 items, with each item having different combinations of sub-items (objects) such as Maps, Reports, microfilms (microfiches) and images. These may be in either hardcopy or digital format or both (although majority are in hard copy format) and are stored in different media types. The WOSSAC collection is presently held physically in the NSRI building in The Present WOSSAC Database Schema and its Disadvantages. WOSSAC s metadata database is a relational database and it was designed in Microsoft Access and mirrored to a distribution table held in the Cranfield s Land Information System (LandIS) Oracle installation from where the information is published to the existing online web-based catalogue. Its present schema is such that it conforms to MARC 21 metadata standard, and it is also extended to include elements and tables that help in management of the data. The elements of this schema can also be mapped directly to the 15 elements of DCMES - Dublin core metadata standard ( These standards were designed for cataloguing bibliographic materials, and not spatial data. This database schema has some disadvantages such as: It does not properly represent/catalogue the hierarchical nature of the WOSSAC items as it does not properly account for the sub-items; It does not properly catalogue the geospatial data items in the database and also, it does not conform to any standard used to catalogue geospatial data;

21 15 It is not extendable, i.e. the database s structure can not be extended to incorporate changes in metadata standards without major modification to the database; It does not check some unnecessary spelling errors which, thus, fraught the database. This is shown by Guillermo (2006) using example of the different spellings of the word Perfect Bound in the database, thus, making it difficult to automate record classification; It does not check inconsistent description of the same object by different individuals; Some of the fields in the tables of the present schema database are not necessary; they are likely to be repeated which will lead to confusion. e.g. material extent, material description, material type, material characteristics fields are confusing; It does not appropriately account for the total number of each sub-items type in WOSSAC database as it not properly accounted for these at each items level; The present schema, as it is, can not be used to publish the WOSSAC s geospatial item in an OGC-compliant manner. Due to the above reasons, the WOSSAC s metadata database was re-designed as part of this thesis research project to correct the above outlined inconsistencies of the present schema, as described below The Proposed Prototype Database Schema In redesigning the database, several factors including the realities of WOSSAC data were taken into consideration. The modifications to the database schema and important points taken to consideration in modifying the database are outlined below: 1. Three new tables (WOSSAC_IMAGE, WOSSAC_MAP, AND WOSSAC_DOCUMENT) were created for cataloguing images, maps and documents respectively (WOSSAC s item s sub-item). Also, fields in the WOSSAC_ITEMS table are the ones containing metadata information that are always common to all the sub-items in an item. These new tables were related to the WOSSAC_ITEMS table through the ID of the parent item to which they belong. The fields in the WOSSAC_IMAGE, WOSSAC_MAP, AND WOSSAC_DOCUMENT, together with the fields in other tables in

22 16 the database are such that, will conform to various standards for representing remotely sensed images, maps and bibliographic documents respectively. This structure is shown in figure 3.1 below. WOSSAC Item Table u 1 1 WOSSAC Images Table 0 n 0 n 0 n WOSSAC Maps Table WOSSAC Documents Table Other Tables Figure 3.1. The newly created WOSSAC s sub-items tables and their relationship with WOSSAC items 2. The Dublin Core Metadata Element Set (DCMES) standard was used to catalogue WOSSAC s bibliographic items; and redundant and/or confusing MARC 21 elements in the present schema were removed. 3 The UK Gemini standard (which is an abridged version of ISO19115 for UK), with slight modifications was used in cataloguing WOSSAC s spatial data/maps. Additional ISO19115 elements not present in UK Gemini were used in the cataloguing. This is due to the fact that WOSSAC is a global database of soils data with particular reference to those made by British companies, and the fact that the database is held in a UK-based repository. So, a UK-based standard (UKGEMINI) derived from, and further modified to conform to a global standard (ISO19115 ) was used. 4 The Images table was also designed based on UKGemini standard with some elements from ISO19115 Also, some elements which are not in ISO19115 not present in UKGemini elements set. but are useful in describing remotely sensed images were included in the table s field. This is done pending the time the ISO (which is the extension of ISO19115 specifying standard for image cataloguing) will be published. 5 The UKGEMINI standard s implementation was modified to reflect the balance struck between: (a) the number of elements to enter; (b) the usefulness of the element to WOSSAC user; (c) the availability of the

23 17 information on WOSSAC data, given the fact that WOSSAC is an archival store of data and so a lot of cataloguing information may not be available; (d) the time for entering the data which should not be more than ten minutes according to the 10-minute rule (CGD, 2007); and (e) the compulsoriness of the element in the standard specification. Thus, not all optional elements were used. 6 Another modification to the implementation of UKGemini/ISO19115 was the change of obligation of the Spatial Referencing System (SRS) element due to fact that the information can often not be found in many of the historical maps. Therefore, the SRS field was made not to be mandatory as against it being mandatory in UK Gemini standard, and the SRS used was the most likely SRS for a dataset, and if that is not known too, then, the unprojected /geographic SRS of the dataset s country is used. Therefore, the unprojected SRS or CRS (Coordinate Referencing System) was compiled for each country and added as a field to the WOSSAC_WORLD_CITIES table. This ensures that each dataset has most likely SRS information attached to it. Also, the SRS field was to be made to be filled with EPSG (European Petroleum Survey Group) codes only so as to ensure consistency in the way the SRS information was entered. Two new tables to provide information about the available EPSG codes and their area of use were added to the database, and the SRS field of WOSSAC_MAP and WOSSAC_WORLD_CITIES tables were linked to them. 7 Another modification to the UKGemini standard s implementation was the change in the Obligation of the data collection period because again, it is not available for all the maps in WOSSAC. 8 Some look-up tables from ISO19115 standards related to ISO19115 elements in the database were added to the database. These tables include WOSSAC_RIGHTS_LUT, and WOSSAC_TOPIC_CATEGORY_LUT. This was done in order to remove spelling errors, reduce data redundancy and to normalise the database. 9 A drop down list was used in entering data for some fields in order to reduce spelling errors.

24 18 10 Some elements not present in any standard were included. This was for the management of WOSSAC items. The added fields include the BROWSE_THMB field which specifies name of the thumbnail of a scanned copy of WOSSAC item. 11 The ISO19115 / UKGEMINI and DCMES standard elements are not just found in WOSSAC_MAP, WOSSAC_IMAGES and WOSSAC_DOCUMENTS table respectively but they can be found in other tables in the database. They can be found where their use is more relevant e.g. WOSSAC_METADATA_UPDATE_DATE which is a ISO19115 / UKGEMINI mandatory element is found in the WOSSAC_REVIEW table as its use is more relevant there. A list of WOSSAC tables, their fields, the descriptions of their fields and how they map into the ISO19115, UKGEMINI and DCMES standard can be found in the data dictionary in Appendix A (Data Dictionary) Entering Prototype Dataset A series of representative sample/prototype datasets were entered into the newly proposed database in order to: Test the ease and possibility of using the newly database schema with regards to time of data entry, the availability of information for some mandatory fields, the usefulness of some fields, and the appropriate definition of each field with respect to the WOSSAC. This was to further aid the designing of the database schema to suit WOSSAC data; Define the appropriate nomenclature of the datasets and each field/elements in the database schema; Test the ease and possibility of using the re-designed database in the publicising of WOSSAC data using Google Earth and OGC WMS. To test how well WOSSAC data conforms to the new proposed database, 21 WOSSAC items metadata were entered. This included 14 document records from 13 WOSSAC items, and 48 map records belonging to 12 WOSSAC items.13 maps to be used for OGC WMS were also scanned, and georeferenced as described below. These sample data represent the various combinations of WOSSAC sub-items that could be anticipated in each WOSSAC items in future.

25 19 In data entering, the bounding coordinates used are in the geographic (i.e. unprojected coordinate system) coordinates. So, maps having their coordinates in projected SRS have their coordinates re-computed to geographic coordinate system using TatukGIS Calculator Software, an service freely downloadable from This is to aid the output of the information into Google Earth which uses only geographic SRS Digitising Sample WOSSAC Data Some WOSSAC maps and documents/reports were scanned using an HP A0 ScanJet device operating at a resolution of 300dpi, with optimum settings for different kind of media on which the map is plotted. Thumbnails were created from the scanned image., Low resolution images were also created from the scanned image when its file size is too large so as to ensure that the image is more manageable and useable. The path to the scanned maps/thumbnails was entered in the database Georeferencing of the Scanned Maps The scanned maps were georeferenced using ArcMap Software. This is due to the facts that: OGC WMS can only use georeferenced maps as input; ISO19115 /UKGemini are actually standards for georeferenced digital data; There is uncertainty about how best the modified SRS element in WOSSAC database can be used in georeferencing, hence there is a need to test its usefulness.. The decision-flow for the georeferencing of maps with regards to the fact that SRS information is not always available is given in the figure 3.2 below

26 20 IMAGE NO SRS information available on Map? YES Enter SRS information in WOSSAC database and Georeference the map using the coordinates of points on the dataset Coordinates in Geographic or Projected SRS? Geographic SRS Projected SRS Convert coordinates of the control points (points of known coordinates) on the map into geographic SRS for the country in which the dataset is. Georeference the map using the converted coordinates of the control points on the dataset Assign the geographic SRS of the country it is in (Most likely SRS) to the dataset s projection. Georeference the map using control points (points of known coordinate) on the dataset Assign the geographic SRS of the country it is in (Most likely SRS) to the dataset s projection. END Figure 3.2. Process flow in choosing SRS for the Georeferencing of WOSSAC Maps 3.2 PUBLICISING USING GOOGLE EARTH Google Earth was used as one of the mediums to publicise the catalogue of data held in WOSSAC. The average point position, area covered by, and image map of a WOSSAC item can be shown in Google Earth Client by using Google Earth objects such as Placemark, Polygon and Image overlay respectively (see figure 3.3). Google Earth s objects are encoded in Keyhole Markup Language (KML) which is Google Earth s proprietary XML format for managing three-dimensional spatial data. Also, using the CDATA in the description tag in KML, each WOSSAC item s information was embedded within the KML in HTML format and viewed in Google Earth Object s information box. The metadata element of KML can also be used to store metadata in any XML format about a data item. Also, Google Earth can display point, linear, polygon and 3D data; and WMS services.

27 21 Information Box Placemark Image Overlay Polygon/Area Feature Path/Linear Feature Figure 3.3 Diagram showing Google Earth Objects/Feature types In implementing this project, Adobe Inc. s ColdFusion Markup Language- CFML (an Internet application development language designed for ColdFusion Application Server) was used to create dynamic KML and KMZ (which is the compressed form of the text KML) files using data obtained from querying WOSSAC database. A Google Earth client can connect either directly to and load these created files, or connect to and load these files through GE s Network link object (which is a Google Earth object for loading another KML/KMZ file, an image or a model file through an absolute URL or local file specification). A KML file having Network Link and the screen overlay (another KML object for showing an image/icon on the GE client screen) was also created manually for this project Due to the fact that it may take a long time for the KML/KMZ file-creation script to run (hence, server overload and connection error due to response time-outs) and the fact that WOSSAC database does not change very often, the KML/KMZ files creation was batch processed offline using time interval updating. Thus, the KML/KMZ files are not dynamically created at client request but at a set interval of time or when the database changes and they are saved into a container where they can be served to a client. This process of using ColdFusion to create KML from the metadata database,

28 22 and the process of viewing the created KML files in Google earth is shown in figure 3.4 below. WOSSAC DATABASE SERVER Timer-Based Connection Network Link KML KML/KMZ CONTAINER Google Earth Client Web Server ColdFusion Server Figure 3.4 The Process of Creating KML from the database and viewing in Google Earth Guillermo (2006) wrote a CFML script to dynamically create KML/KMZ files but his script was modified due to the following reasons: 1. Its runtime was found to be unacceptably slow; 2. The script has some errors (some of the output were not in KMLconformant format); 3. The modification of the database also, necessitates a change in both the ColdFusion - Database interaction (Query) and the output KML structure, hence, the script has to be re-written; 4. The need to include more information in the KML output. CFML has the capacity to interact with XML objects using tags such as CFXML. This was used to create KML (an XML-format) from the query returned from the database. A KML Placemark was created for each WOSSAC object (Maps, Images, and Documents/Reports) with a related information box providing summary information about the object. Due to the fact the bounding coordinate information is not available for all WOSSAC reports, a decision was made that information about all those reports should be contained in a Placemark s information box linked spatially to the capital city of the country represented by the Document/Report. This approach allows a useful spatial context to be included for all items held. The information box should

29 23 contain enough information to describe the object and hyperlinks to images, PDF s, dynamic polygon and image overlay KML creating scripts, if they are available for the WOSSAC object. Also, all WOSSAC objects for a given continent are saved in a single KML file and they are subdivided into various object types (such as image, maps, and reports) in the file using the KML folder tag. The flowchart for the creation of the KML/KMZ file is outlined in the figure 3.5 below. The ColdFusion code can be found in the Appendix B-1 KMZ files for each continent were created from their respective KML files using a ColdFusion component extension. This uses Java Zip file API, and can be downloaded from ColdFusion support page (NewSight, 2006).

30 24 Continent_test Query to Select only Continent and Loop Set Variable continent Test = Continent in Loop Start cfxml tag and KML header Start folder tag to keep WOSSAC Reports Start/Continue Loop over Report Query (Query to retrieve report) Continent_Test = Query Report s continent AND Record has bounding Coordinates?? NO YES Create Placemark tag with all the necessary data filled using the Query variables for the single record End Query More Query Records? YES NO Loop over Report Query (Query to retrieve report), Group by Country Continent_Test = Query Report s continent AND Record has bounding Coordinates?? NO YES Process 1 Start a Placemark tag positioned at the Capital of the Country At CDATA tag Section, Start/Continue Loop over all Grouped Record for a Country YES Record has bounding Coordinates?? NO Output Information for record in the CDATA section YES More Grouped Country s Item Query Records? NO Close CDATA and Placemark for a Country YES More Country s Record?? NO End Query Close the Report Folder Tag REPEAT PROCESS 1 FOR MAP USING MAP TABLE S QUERY REPEAT PROCESS 1 FOR IMAGES USING IMAGES TABLE S QUERY Close CFXML tag, Write the Continent s data in a Directory as.kml and Zip as.kmz Loop Over Next Continent Figure 3.5. Flowchart for the creation of the KML/KMZ

31 IMPLEMENTATION OF MAPSERVER WMS The creation of OGC WMS standard-compliant service was implemented using MapServer software. This is a primarily a CGI (Common Gateway Interface) program that uses Mapfiles and CGI variable values passed to it via the URL GET format to create and return map images legends, scale bars etc. The software was developed as a result of a joint project between University of Minnesota, NASA and the Minnesota Department of Natural Resource and can be downloaded freely from MapServer implements OGC WMS 1.1.x /WFS specification in addition to its web/internet mapping capabilities. It is configured for services using a mapfile. The Mapfile contains a list of MapServer program variables and their values that describe a service. This defines data sources, output image formats, projections, layers available, symbols and text to be used. It is saved with.map extension An example of a mapfile is given below in figure 3.6 LAYER NAME "Nigeria Land" PROJECTION "init=epsg:4263" END TYPE RASTER DATA data/1854_m01_nigeria_agricultural_potential.tif METADATA "ows_title" "Nigeria" "wms_keywordlist" "Land Classification, Land Resources" END END Figure 3.6 Diagram showing part of a Mapserver mapfile created for WOSSAC MapServer can be further configured using mapscript, which is its scripting interface. It is a loadable module that adds MapServer capability to different scripting languages (such as Php, Perl, and Python) and can be used independently of CGI MapServer. MapServer s main PHP mapscript possesses all the functionalities of the MapServer CGI and so can be used in place of it. A number of OGC WMS standard-compliant servers (a list of which can be obtained from were considered for use in this project but MapServer was chosen because it is free (open source software), programmable/customizable, easily implemented, flexible and has a high performance (see for more).

32 Web Map Service Creation for WOSSAC A Web Map Service (WMS) was created for this project due to the fact that most of WOSSAC items are in raster format. In this project, a single mapfile was created for all the prototype georeferenced maps in WOSSAC from the WOSSAC Metadata database. The mapfile s metadata element (see figure 3.7) variables map directly to the GetCapabilities XML elements and are used to populate the GetCapabilities XML by MapServer. Also, the GetCapabilities XML elements are ISO19115 compliant (i.e. they are derived from ISO19115 specification), so, a metadata database compliant with ISO 19115, such as WOSSAC, will be able to return the GetCapabilities XML by assigning values to Mapfiles directly from the database. This is illustrated in the figure. 3.7 GetCapabilities Elements Maps Directly to Maps Directly to Map Files Element ISO 19115compliantDatabase Populates Figure 3.7 Relationship between Mapfile elements, GetCapabilities XML and ISO19115 Therefore, ColdFusion was used to automatically create a mapfile by assigning values from the query of WOSSAC metadata database (for a particular WOSSAC map) to Mapfile configuration variables (which in turn, populate the GetCapabilities XML). This was done in Offline Batch Processing mode due to the reasons outlined in Section 3.2. The code for this process can be found in Appendix B-2. The following points were taken into consideration while creating the mapfile: Given the fact that WOSSAC has possibility of having more than 13,000 maps, the size of GetCapabilities XML document returned for the WOSSAC data will be very large if all the OGC GetCapabilities elements were to be used. Therefore, the elements used for the implementation of this project were the compulsory elements and the ones that carry important information about the WOSSAC and the data. Some of which includes: Layers names and its SRS information, Abstract, Keyword list, Bounding coordinates.;

33 27 Also, the SRS used was the most likely SRS for the dataset and if this is not available, then the dataset s countries unprojected SRS was used; Due to the fact the number of maps in WOSSAC database is large and, in order to make search and use of map layers easier, the map layers returned are grouped by the country to which the dataset represents using the group element of the mapfile MapServer Configuration using a Wrapper Script In the basic implementation of WMS services by the MapServer software, the path to the mapfile and mapserv.exe (MapServer s main CGI program) are always passed in the URL GET variables. So, in order to hide these paths from the URL, a wrapper script was written in PHP (the programming language of the web application server on which MapServer was implemented). This calls the PHP Mapscript (the main MapServer s mapscript written in PHP) and passes the path to the mapfile to it. It also returns the appropriate object s MIME-type depending on the request it receives. This wrapper script is thus, the gateway to the web mapping service. 3.4 DYNAMIC KML CREATION WITH PYTHON The Python programming language is object-oriented and can be used to write different forms of software including web applications. In the implementation of this project, scripts using Python were written to return dynamically-created KML directly to the Google Earth Client as against returning the KML to the internet browser as the CFML script does. The Python scripts create dynamically the KML files from the values passed via the URL GET variables. The URL s to the scripts, together with their URL GET variable and value pair for a WOSAAC item, were embedded in the CDATA section /Information Box of each WOSSAC item Placemark s KML. The values of each of the URL GET variables for a WOSSAC item were assigned automatically to the variables during the process of creating the Placemarks KML. The functions of the two Python scripts written respectively are to: (1) Create and return polygon KML (showing area covered by a WOSSAC item) from the name and bounding box coordinates of the project area covered by a WOSSAC item passed to the Python script via the URL GET variables;

34 28 (2) Create and return Image Overlay KML (of a particular WOSSAC map) from the bounding box coordinates and the GetMap service URL of the WOSSAC map passed to the script via the URL GET variables. Thus, from the systems perspective, the overall methodology (assuming that Google Earth is the WMS Client) can be summarized as shown in figure 3.8 below.

35 29 DATABASE SERVER -Oracle or Microsoft Access GOOGLE EARTH CLIENT WEB SERVER WOSSAC Placemark KML Grouped by MAPS KML Files Network Link (KML File) Thumbnail Image IMAGES DOCUMENTS WOSSAC PDF s Scanned Images Polygon Python Scr Placemark Wms Python Script Creates and Saves KML files Placemark Information Box COLDFUSION Document PDF (Batch ProcessingTimer Based) Thumbnail served by the Web server Request for PDF of documents having digital copies Creates and Saves Map files Manually move map file to MapServer Polygon KML MAPSERVER Image Overlay KML- Request Map in WMS Call Python Script to return Polygon KML covering area of project Call Python Script to return Image KML calling WMS Map File Image Map Wrapper Script Figure 3.8 Diagram showing the overall system process- where Google Earth is the WMS client

36 30 RESULTS AND DISCUSSION The results of this project are discussed under the following headings: 4.1 Database Re-Design and Data Entry Result and Discussion; WMS implementation Results and Discussion; Google Earth Mapping Results and Discussion; Comparison of Google Earth and OGC WMS. DATABASE RE-DESIGN AND DATA ENTRY RESULTS The schema of the proposed database is shown in figure 4.1 below. The list of tables, and their fields/elements and how they map to the Dublin Core, Marc 21, UKGEMINI and ISO19115 are given in the data dictionary in Appendix A. The proposed database table s fields/elements, and their structure/format, were compared with the specifications of the standards to test how well it conforms to the Standards, and the summary of the results is shown in the Table 4.1 below. Standard No. of Elements in the Standard Dublin Core 15 ISO19115 (all elements) Over 300 ISO19115 (core elements) 25 ISO19115 (core elements) 7 Mandatory UKGEMINI - All elements 32 UKGEMINI - Mandatory 17 No. of elements in correct format in Proposed WOSSAC Database Table 4.1 Summary of the conformance of the proposed database s schema to standards The findings of this are elaborated upon in the following sections.

37 31 Figure 4.1 Schema of the proposed database

38 Proposed Database Schema s Conformance to Bibliographic Metadata Standards From the Table 4.1 and data dictionary in Appendix A, thirteen elements of the Dublin Core Standards are present in the new schema. Also, some Marc 21 elements for cataloguing bibliographic data are present too. The two Dublin Core elements not present, and the reasons for this are outlined in Table 4.2 below. Element Type Source Description Reason for Not being in Re-Designed Schema The nature or genre This is not explicitly used because all WOSSAC of the resource bibliographic items are of one type, which is Text. The resource from This is not included because WOSSAC is which the described secondary keeper of these data, and WOSSAC resource is derived items are old. Table 4.2: Shows the reason for the non-use of some Dublin core elements in new design. Since none of the elements of Dublin Core are mandatory and the proposed schema consists of almost all of them, the new database schema conforms to the DCMES (although not fully because the proposed schema does not contain all the DCMES elements) Proposed Database Schema s Conformance to Geospatial Metadata Standards Table 4.1 shows how well the re-designed database conforms to the ISO19115 and UKGemini standard. With regards to the ISO19115 standard, all the mandatory elements of the ISO19115 CORE ELEMENTS are present and in the right format, so, the schema conforms (though not fully, as some of the optional core elements are not present) to the ISO19115 standard. Also, compared with UKGemini, the re-designed database schema has 28 out of the all the 32 UKGEMINI elements. The elements not present are shown in Table 4.3 below Element Description Reason for Not being in Re-Designed Schema It is strictly for digital data, and it is not compulsory. So, in order to reduce data entry time, it was not included It is not compulsory, so, in order to reduce data entry time, it was not included It is not compulsory, so, in order to reduce data entry time, it was not included Spatial resolution Measure of the granularity of the data (in metres) Metadata Name of the standard name metadata standard u Metadata Version (profile) of standard the metadata information standard used Vertical extent Vertical domain of It is not compulsory, so, in order to reduce information the dataset data entry time, it was not included Table 4.3 Reasons for the non-inclusion of some UK Gemini elements in the new schema.

39 33 Also, 2 out of 17 UKGEMINI mandatory elements were made non-mandatory in the proposed schema. These elements, together with the reason they can t be made mandatory are given in Table 4.4 below. Element DATE Spatial Reference system Description Reason for Not being in Re-Designed Schema Data collection This is due to the fact the information is not available period on every map and also, due to the fact that WOSSAC is a secondary data keeper. Also, lack of clarity of the definition of data collection period, e.g. Does it include the dates the source data for a base map (whose details may not be given) was collected, if the map to be catalogued was compiled from another base? Or the date the aerial photo was taken if it was used in the analysis to compile the map to be catalogued. The coordinate Information about the SRS is not usually available on system of the the WOSSAC maps, but the algorithm for the geospatial data intelligent guess of the most probable SRS as stated in the methodology helps associate every map with an SRS. Table 4.4 Reasons for the modification of obligation of some UK Gemini elements in the new schema. Thus, since not all the mandatory UK Gemini elements are mandatory elements in the new WOSSAC database schema, the database design is not seen as being fully compliant with the UKGemini. Also, since UK Gemini and ISO19115 do not properly represent remotely sensed images, the comparison of the database schema with the standards with regards to remotely sensed imagery may not be useful until the proposed ISO is published in the future Data Entry Findings, and Causes and Resolutions This data entry process demonstrates how well the proposed schema can catalogue WOSSAC data. It also raised some issues, which are discussed below: Definition and differentiating of Images, Maps and Reports. This is about defining what a map or image is and differentiating them from illustration in a report, e.g. how to classify a map or aerial photograph where all the photogrammetry and map information respectively have been cut away? What minimum information should be available on a map/image to classify it as such? Catalogue Entry for a Map/Image available in both hard copy and digital format: This is about how best to catalogue a map or image that is available in

40 34 both hardcopy and digital format without necessarily entering redundant information. Catalogue entry for maps in PDF format: This is about how well to catalogue a map in PDF format, although the decision taken for this project was to convert the map to image format before georeferencing it for use in WOSSAC. Language Problems: This is due to the fact that item languages vary, and this raises the issue of whether they should be documented in their language or English. This also raises the issue of who is to catalogue them. Entering multiple unrelated information on a CD: e.g. a CD whose contents includes different formats of each of several different maps; and reports- the CD itself having a hard copy report to explain its contents. For this project, the CD was not documented, but the data held on it was saved in another location (such as hard disk) before being catalogued. Data entry time: This may be large if the cataloguer needs to calculate/convert the bounding box, find the right EPSG code for the SRS, and look for other hidden information in the text. Scanning settings: This is about what standard setting to use for WOSSAC items be e.g. the resolution, the image format. Georeferencing: The issues here include defining the SRS of the map, minimum accuracy required for the georeferencing and map resampling method. Concatenating small maps: This is with regards to whether to join small maps (that are describing the same thing in adjacent areas, but are made in small pieces in order to for them to fit into suitable paper size) together. And if they are to be joined together to form a single one, how well to catalogue the map formed by concatenation, given the fact that it was made from small bits of maps Possible Reasons for Non-Compliance of WOSSAC Data Items to ISO19115 and UKGemini A number of reasons exist as to why there might be non-compliance to ISO19115 by the WOSSAC data schema, including the following: WOSSAC is an archival store of data and so, a lot of spatial data metadata may not be there as this may not have been important at the time of data collection;

41 35 WOSSAC comprises of data from different countries (over 250 territories) that may have different standards for compiling metadata; WOSSAC is the Secondary holder/distributor of data and not the primary data collector/complier - WOSSAC does not have first hand information about the items; The standards were designed for digital data but WOSSAC has both digital and hard copy, this highlights the need for defining a more flexible schema for archival data and the need for a metadata standard for hardcopy. 4.2 WMS SERVICE IMPLEMENTATION RESULT AND DISCUSSION The service was implemented using a prototype URL which is The final service URL can be registered in an SDI Portal such as INPIRE and GEOSS for data access and sharing. It can also be registered in a clearinghouse portal that is OGC-Catalogue Service compliant for metadata services. The disadvantage of using it for data discovery/publicising is that it uses the GetCapabilities document to publish the data available. And the GetCapabilities document only outputs only the georeferenced digital data, as against a large number of WOSSAC items which are non-spatial data, hardcopy spatial data and nongeoreferenced digital spatial data. The GetCapabilities XML document can be requested via the URL and a sample cut-out of the GetCapabilities XML returned is shown below in figure 4.2 <Layer queryable="0" opaque="1" cascaded="0"> <Name>Chafe Geology Sheet20</Name> <Title>Chafe Geology Sheet20</Title> <Abstract>Geological Map of Chafe, showing the different rock types and their uses.</abstract> <KeywordList> <Keyword>Geology</Keyword> <Keyword> Chafe</Keyword> <Keyword> Rocks</Keyword> <Keyword> Nigeria</Keyword> </KeywordList> <SRS>EPSG:4263</SRS> <LatLonBoundingBox minx="6" miny="11" maxx="7" maxy="12" /> <BoundingBox SRS="EPSG:4263"minx="6" miny="11" maxx="7" maxy="12" /> </Layer> Figure 4.2 Cut-out of the GetCapabilities xml document for WOSSAC

42 36 Detailed GetCapabilities XML for the prototype site implemented can be requested from the site and viewed. Image maps can be requested using a correctly formatted OGC GetMap URL. Some of the compulsory variables in the GetMap request URL include layer(s), SRS, bounding box and output format. A sample request is given as: PSG:4326&bbox=7.2,11.9,9.05,13.5&format=image/png&layers=Kano%20Plains%20 Land%20Systems%20Map%201a&transparent=true&width=500&height=300. The MapServer processes the request and serves an image according to the request made. This service was implemented and tested by the author on a number of OGC WMScompliant client software packages including ArcGIS, CadCorp SIS, MapBrowser, and standard web-browsers (by using correctly formatted GetMap and GetCapabilities URL in a browser), as well as the Google Earth Client. This latter client software implements the services differently and the schematic structure of the implementation of the service by ArcGIS and SIS CadCorp is outlined in the figure 4.3 CADCORP SIS MAP BROWSER/ GOOGLE EARTH ARCGIS VIEWER INPUT SERVICE SOURCE INPUT SERVICE SOURCE MAPSERVER REQUEST CAPABILITIES REQUEST CAPABILITIES RETURNS CAPABILITY XML DISPLAYS CAPABILITIES REQUEST ALL LAYERS IN SERVICE AT FIRST INSTANCE DISPLAYS ALL LAYERS IN SERVICE May Crash the Server if the number of layers in a Service is large RETURNS IMAGES OF LAYERS SELECTED DISPLAYS CAPABILITIES REQUEST SELECTED LAYERS IN SERVICE AT FIRST INSTANCE DISPLAYS RETURNED LAYERS Figure 4.3 Implementation of WOSSAC WMS Service in different client CadCorp SIS Map Browser or Google Earth viewer (through the Image Overlay object) software allows users to select layers from a service. But in ArcGIS software, all the layers in the service are requested in the first instance, and if the number of layers in the service is large, the processing time will be long and may result in server timeouts, thus, the server will return an error. This is simply a feature of the way the service handler is

43 37 implemented by ESRI in their software, but is something to be aware of in any future implementation of WOSSAC. 4.3 GOOGLE EARTH MAPPING RESULT AND DISCUSSION In implementing this system, the user needs to download the network link KML file (from the WOSSAC website or any website on which it can be published like soil blogs, Google earth user communities, or through Google KML search) and open it in Google Earth. This calls and loads the WOSSAC items Placemarks KML files from the web server into Google earth. The user can further interact with the Placemarks information box to return PDF files for WOSSAC documents; dynamic Polygon KML showing areas covered by a WOSSAC Item s project; and dynamic Image overlay KML (used to request dynamically images from the WMS implemented) files for WOSSAC maps and images. A screenshot of the implementation of the system GE below shows Placemarks, image overlay (output from a WMS), polygon (showing area covered) and information box for a WOSSAC items in figure 4.4 below, note also the customisation of the client interface with the WOSSAC logo: Fig 4.4 Screenshot of the implementation of the system in Google Earth The process flow of using this system is illustrated below in fig 4.5 below

44 38 GOOGLE EARTH VIEWER WOSSAC Placemarks WOSSAC Website CLICK NETWORK LINK (Launches Google Earth Viewer) Continents MAPS IMAGES NETWORK LINK hyperlink DOCUMENTS CLICK... CONTINENT -> DOCUMENT - > PLACEMARK CONTINENT -> IMAGE - > PLACEMARK CONTINENT -> MAP - > PLACEMARK GOOGLE EARTH VIEWER GOOGLE EARTH VIEWER GOOGLE EARTH VIEWER Information Box Information about the Report and Document PDF URL hyperlink Area of Interest of Project hyperlink Information Box Information about the Image Map Image Hyperlink Area of Interest of Project hyperlink Information Box Information about the Map Map Image hyperlink Area of Interest of Project hyperlink REPORT PLACEMARK IMAGE PLACEMARK MAP PLACEMARK CLICK... CLICK... PROJECT AREA POLYGON PDF URL GOOGLE EARTH VIEWER PDF Document in Web Browser MAP/ IMAGE OF PROJECT AREA GOOGLE EARTH VIEWER PROJECT AREA POLYGON Image Overlay Map from WMS Service Figure 4.5 Process flow of using this system for google earth mapping Google Search and its Implementation The GE KML search capability will enable the WOSSAC items KML files (created through timer-based batch processing) to be more easily accessible online. The website where these KML files are located may need to be registered with GOOGLE Inc. for Google Search web crawler to quickly search and index the KML items there. A GeoRSS feed can also, be authored to drive traffic to the KML files so as to increase chances of being easily found and used in GE (Google Earth, 2007). In addition, the metadata tag in KML can be used to store metadata about any geospatial

45 39 item in any XML format. Although the GE viewer will not output this directly, importantly the Google search engine web-crawler can still parse it and use the information in it for its search returns. One major setback in the use of Google Earth search is that it searches only static KML s and so, the dynamic KML s created in this project will not be searched, another reason to generate the KML files on a periodic basis (linked to the anticipated frequency of data updates), storing then the static file versions on the WOSSAC website. Google Earth can be used to search and view metadata encoded in KML (as it was implemented in this project). It also can serve as a WMS client using its image overlay object, although, it can not search for nor publish the service. 4.4 COMPARISON OF THE OGC WMS AND GOOGLE EARTH MAPPING The GetCapabilities document returned from a WMS server limits the data discovery service to georeferenced maps only, but a KML will be able to output full metadata about any form of object that has spatial reference/dimension, such as WOSSAC items as shown in this project. In this sense, the Google Earth approach is superior for the WOSSAC requirements. Also, OGC WMS needs an SDI for its data catalogue to be discoverable but with the Google search capability, data and metadata encoded in KML can be crawled, parsed, indexed and searched by Google server (thus, Google server is an equivalent of a global, unstructured SDI for KML data). A possible advantage of using SDI search over a KML search is that SDI searches are more organised, intelligent and structured based upon the services registered in it, which may not be so in Google KML search. However, a Google Earth KML search can be used to support an SDI s data discovery given its public appeal compared with an SDI whose appeal is limited to expert users presently, ideally then, both approaches should be supported. It should be noted that presently, Google Earth mapping capability is limited, as its KML tag cannot support complex GIS data representations (although it is continually being developed to support this), it can be used as a web client to OGC WMS using its image overlay object. Thus, OGC WMS and Google Earth Mapping capability can be used cooperatively for data discovery and use. This is demonstrated in many servers serving both KML (MapServer, AutoDesk MapGuide) and OGC WMS now, together with clients being

46 40 able to view KML and OGC services (Examples of which includes ArcExplorer, Google Earth Viewer and World Wind).

47 41 CONCLUSIONS AND RECOMMENDATIONS 5.1 CONCLUSIONS In order to publicise WOSSAC data and to make the data available in an interoperable format, the use of OGC WMS and Google Earth mapping platform were considered. For the implementation of OGC WMS, and to output enough discovery, evaluation and usage metadata about a WOSSAC item in Google Earth, the current database, which previously did not meet the metadata standards for cataloguing spatial data, was redesigned. The re-designed database satisfies the majority of the Dublin Core standard, and in part, the ISO19115 standard, but it did not meet the UK Gemini standard. This is primarily due to the fact that: WOSSAC is an archival store of data; WOSSAC is not the primary data collector; ISO19115, and UKGemini do not represent properly archival geospatial data item. Therefore, there is a need for other metadata standards that can correctly handle this. Also, the database was re-designed such that it minimises data entry errors and redundancies (through related tables), and optimises the time for data entry. Using the almost-standards-compliant re-designed database, OGC WMS can be implemented using MapServer. This was then used in this project to output both the WOSSAC records data and its metadata in an interoperable format. The metadata published were for only the georeferenced digital data. To further create awareness of the existence of the WOSSAC data and services, there is need to register the service with an SDI or a site with list of OGC WMS service providers. Although the WMS can only publish metadata of georeferenced digital data, Google Earth can be used to publish metadata about WOSSAC items both the maps and documents. It can also be used to publish WOSSAC maps too, but its mapping capability is limited due to its accuracy problems and the fact that its KML tags only support basic/simple data representation. In order to enhance Google Earth s mapping capability, it can be used as a client to a WMS. Google Earth s KML search capability can also be utilized in the discovery of a data if the metadata about the data is properly encoded in a static KML file. The fact that

48 42 Google searches only static KML s infers that dynamically-created KML s (for this project) may not be searchable. Thus, given the popularity and KML search capability of Google Earth, it can be used cooperatively with an SDI in data discovery as against using the OGC services such as WMS alone (which is used at present by those in the GI industry). Also Google Earth can serve as a client for OGC s services. 5.2 RECOMMENDATIONS These recommendations are made with regards to the different segment of implementation of this project and these are outlined below Recommendations with Regards to the Database design and WOSSAC Data A number of recommendations may be made with respect to the database re-design, thus: There should be formal rules with regards to entering data into the new database. Perhaps in the form of data-entry manual or comprehensive validation help in the data entry screens. Thus, rules should be established which define what a map is and how to differentiate it from all other data types such as an ordinary graphical illustration, and rules specifying whether a CD should be entered or its contents only; The current geospatial metadata standards do not correctly represent archival data, so there should be further research into another standard able to represent more flexibly archival geospatial data; The database schema for representing remotely sensed images should be changed to satisfy ISO standard when it is published; Scanning/Digitization of the WOSSAC items (Maps, documents and Images) at optimum resolution and format. This will help in management and storing of the data. This will make the items more easily accessible online. The Jpeg image format (due to its small file size) and resolution of 300 dpi is recommended for Maps and Images, while the documents can be scanned and saved as PDF format with a resolution of 150dpi. These resolutions are considered to be optimum in terms of size of file compared with the item s details captured.

49 Recommendations With Regards to Google Earth mapping implementation A number of recommendations may be made with respect to the use of the Google Earth client, thus: There should be further research into the use of Google Earth s KML search for easier data (encoded in KML) discovery and use. This should include investigating the right KML tags to use (either the metadata tag or the CDATA embedded in description tag) and how to get an overall high search index in Google Earth server so that WOSSAC items will be easily returned in a KML search; KML can be held in a static output files to facilitate the Google search tools, as opposed to dynamically-created output. This is also consistent with the likely low frequency needed for data update. Further researches into how KML tags can be used to represent features (vector data) so that it can be used to represent and publicise WOSSAC vector data; The current database should be used at the moment to generate KML for WOSSAC items until the proposed database is adopted and populated with a sizable number of data Recommendations with regards to OGC WMS Implementations A number of recommendations may be made with respect to the implementation of the OGC WMS implementation, thus: The geospatial items should also be georeferenced. This will represent them in a format that can be used interoperably, and their metadata more compliant to geospatial metadata standards. The algorithm in Section project should be used in the choice of the SRS; The georeferenced items should be saved separately from the scanned map. This is to allow the user to have access to the ungeoreferenced scanned maps, and so, be able control the georeferencing process in a way that best suits their purpose; The file size of the georeferenced maps should be as small as possible without compromising details of the map. This makes for easier image processing by MapServer. This can be achieved by utilising different resolutions of the source mapscan- as embodied in the new database schema

50 44 Data access rights, security, and revenue generation should be considered in making the data interoperable. This may be done by passwording access to some layers in a service, or not making the layer publicly available at all. Although, the service capability should still include those layers; A WMS client should be created on WOSSAC website where the WOSSAC maps can be viewed and other datasets from other services using OGC WMS/WFS can be viewed.

51 45 REFERENCES Abel, D.J., et al, (1998), Towards Integrated Geographical Information Processing, International Journal of Geographic Information Science, Vol. 12, No. 4, 1998, pp Brooks-Bilson, R. (2003), Programming ColdFusion, 2nd Ed., O Reilly Media Inc Sebastopol California Cabinet Office (2003), E-Government Metadata Standard, Version 2.0: with XML Syntax Office of the e-envoy, Cabinet Office, UK, < >, accessed Cabinet Office (2004), UK GEMINI Standard Version 1.0, Office of the e-envoy, Cabinet Office, UK. CGD (2007), Metadata White Paper v3, Commons of Geographic Data, University of Maine, Orono, ME, < Paper%20v3.pdf> accessed Chongjun YANG (2003), Interoperability of Spatial Data Service, at Joint WGISS16/Subgroup-15 Meetings September 15-19, 2003, Chiang Mai, Thailand < accessed David Danko (2006), Interoperability and Metadata, at Standards Workshop Standards into Action, Cairo, Egypt < ppt> accessed ESRI (2003), Spatial Data Standards and GIS Interoperability An ESRI White Paper, ESRI, Redlands, California, < accessed ESRI (2006), ESRI's Support for Standards January, ESRI, Redlands, California, < 0Standards.pdf >, accessed FGDC (2007a), National Spatial Data Infrastructure < >, accessed FGDC (2007b), Components of the NSDI < accessed FGDC (2007c), Geospatial Metadata Standards, < accessed

52 46 Go-Geo (2006), Metadata in the News, Go-Geo!Metadata News Issue 2, < accessed Google Earth, 2007, KML Geo Search, < accessed Guillermo, A. (2006), Investigation into the use of the Google Earth mapping platform for presenting a World Soil Survey Archive and catalogue (WOSSAC) Unpublished MSc by Research,, Cranfield, UK Hallett, S.H. & Bullock, P. & Baillie, I. (2006) "Towards a World Soil Survey Archive and Catalogue", Soil Use And Management. June 2006, 22, Hillman, D. (2005), Using Dublin Core, < accessed INSPIRE (2007), Directive 2007/2/Ec of the European Parliament and of the Council, Official Journal of the European Union, < accessed ISO19115 (2003), Geographic information Metadata, International Standards Organisation, Geneva, Switzerland ISO/TC 211 (2003), Re-activation of CEN/TC 287 Geographic Information, Geographic information / Geomatics Newsletter No 2, < wsletter_01.pdf>, accessed Koyanagi, Y. (2005), Proposal for a new metadata schema for world soils survey archive and catalogue (WOSSAC) Unpublished MSc by Research, Cranfield University, Cranfield, UK Kralidis, T. & Assefa, Y. (2004) MapServer and OGC Web Services, at Carleton University, Ottawa, Canada June 9-11, 2004 < accessed NISO (2004), Understanding Metadata, National information Standards Organization Press Bethesda, Maryland Oates, B. & Rapaport, J. (2007), Technology for a UK Metadata Service Research Report, Atkins Plc Surrey, UK, < accessed OGC (2004), OpenGIS Web Map Server Cookbook Version 1.0.2, Open Geospatial Consortium Inc. < accessed

53 47 OGC (2005), Web Feature Service Implementation Specification Version 1.1.0, Open Geospatial Consortium Inc, < accessed OGC (2006), Web Coverage Service (WCS) Implementation Specification Version 1.1.0, Open Geospatial Consortium Inc, < accessed OGC (2006), OpenGIS Web Map Service (WMS) Implementation Specification Version 1.3.0, Open Geospatial Consortium Inc, < accessed Osgeo Wiki (2007), DCLite4G, < accessed Wikipedia (2007), Google Earth, < accessed WOSSAC (2004), World Soil Survey Archive and Catalogue < accessed

54 48 APPENDIX A- APPENDIX PROPOSED DATABASE DICTIONARY

55 49 A-1 WOSSAC _ITEMS Table This is a table of WOSSAC items (which is group of maps, tables, and images that relate specifically to a particular project) ELEME NT NO 1 ITEM_ID UKGEMINI EQUIVALENT ELEMENT NAME (AND OBLIGATION) Not Described 2 MARC_ID Not Described Not Described Not Described 3 UDC_CLAS S_NUM Not Described Not Described Not Described 4 COLLECTIO N_ID Not Described 5 COLLECTIO N_REF LOCATION _ID 6 7 ELEMENT NAME DISTRIBUTOR(M ) TITLE ISO19115 EQUIVALENT No DUBLIN CORE EQUIVALENT Comment and MARC 21 equivalent Domain Example of Metadata Not Described Not Described Primary Key, generated by automatically generating numbers in ascending order Foreign Key to MARC_ID_LU T Helps identify the physical location of the item {MARC 084$a} Foreign Key to WOSSAC_COL LECTION_LUT {MARC 084$a} Auto 1 Fixed List 1 Free Text :626.8 (677) Fixed List 1 Free Text Saudi Arabia 216M Fixed List 3 Free Text Riyadh Additional Water Resources Study ELEMENT NAME No Not Described 23 MD_Distribution > MD_Distributor.distri butor.contact 280 Not Described Not Described Foreign Key to WOSSAC_LOC ATION_LUT Generalized title of the Item

56 50 ELEME NT NO ELEMENT NAME 8 LANGUAGE _CODE UKGEMINI EQUIVALENT ELEMENT NAME (AND OBLIGATION) DATASET LANGUAGE(M) ISO19115 EQUIVALENT No ELEMENT NAME No DUBLIN CORE EQUIVALENT 3 MD_Metadata > MD_DataIdentificati on.language 3 LANGUAGE 9 SUBJECTS SUBJECT(M) 6 MD_Identification > MD_Keywords.keyw ord 53 SUBJECT 10 PUBLISHER _NAME ORIGINATOR (O) 9 29 PUBLISHER 11 PUBLICATI ON_PLACE Not Described Not Described 12 PROJECT_S PONSOR Not Described Not Described 13 MATERIAL _DESCRIPTI ON Not Described Not Described MD_Identification. pointofcontact Comment and MARC 21 equivalent Domain Example of Metadata Foreign Key to WOSSAC_LAN GUAGE_LUT {MARC 041$a} Topic of the content of the dataset {MARC 650$a} Person or organisation having primary responsibility for the intellectual content of the data{marc 260$b} Fixed List eng Free Text Irrigation, Ground Water Hydrology Free Text Hunting Technical Services Ltd. Where the data was published{mar C 260$a} The sponsor of the projection Free Text London, UK Free Text International Bank for Reconstruction and Development Ring bound report with four maps Description of material used in making the Item Free Text

57 51 ELEME NT NO ELEMENT NAME UKGEMINI EQUIVALENT ELEMENT NAME (AND OBLIGATION) Not Described 14 SUMMARY 15 COUNTRY_ THEN Not Described 16 COUNTRY_ NOW EXTENT(M) 17 REGION Not Described ISO19115 EQUIVALENT No ELEMENT NAME No Not Described 15 EX_GeographicDes cription.geographici dentifier > MD_Identifier.code 34 9 DUBLIN CORE EQUIVALENT Comment and MARC 21 equivalent Domain Example of Metadata Not Described Generalised summary of the item s content Free Text Not Described The name of the country when the data was created{marc 534$n} Foreign key to WOSSAC_WO RLD_CITIESname of the countries existing now{marc 043$a} extent of dataset by subdivision of country{marc 052$b} Major City around the area of the item {MARC 052$d} Free Text Programme for the Development of Irrigation, Agriculture, Power and Surface Water Storage in West Pakistan Gold Coast Fixed List Ghana Free Text West Pakistan Free Text Wynyard COVERAGE Not Described COVERAGE 18 MAJOR_CIT Y Not Described Not Described COVERAGE

58 52 ELEME NT NO ELEMENT NAME 19 ACQUISITI ON_SOURC E_ID 20 TOPIC_CAT EGORIES_I D UKGEMINI EQUIVALENT ELEMENT NAME (AND OBLIGATION) LINEAGE(O) ISO19115 EQUIVALENT No TOPIC CATEGORY(M) ELEMENT NAME No 10 DQ_DataQuality.lin eage > LI_Lineage.stateme nt 83 5 MD_DataIdentificat ion.topiccategory 41 DUBLIN CORE EQUIVALENT Comment and MARC 21 equivalent Domain Example of Metadata CONTRIBUTO R Foreign Key to WOSSAC_AQ UISITION_SO URCE_LUT information about the events or source data used in the construction of the dataset Foreign Key to WOSSAC_TOP IC_CATEGOR Y_LUT - main theme(s) of the dataset Fixed List 4 Fixed List 6

59 53 A-2 WOSSAC_MAP AND WOSSAC_IMAGE Tables This table contains elements that exclusively describe WOSSAC Map and Images. These share all elements except for the last 4 elements which belong exclusively to image table. There are still other elements that describe these images and maps in other tables ELEM ENT NO ELEMENT NAME 1 MAP_ID UKGEMINI EQUIVALENT ELEMENT NAME Not Described 2 ITEM_ID Not Described 3 TITLE Title (M) 4 ALTERNATIVE_TI TLE Alternative Title (O) 5 ABSTRACT Abstract (M) 6 SHELFMARK Not Described 7 DATA_COLLECTIO N_PERIOD_FROM Date(M) Domain Example Primary Key To be generated by concatenating ITEM_ID value and a number assigned to the map in a particular ITEM_ID objects Foreign key that links to the WOSSAC_ITEMS table 360 Name given to the dataset Free TextAutomatically generated Free Text The Wadi Yutum Soil Map 361 Short name, other name, acronym or alternative language title Free Text Geophysical survey in the Lower Wadi Yutum, South Jordan 25 Brief narrative summary of the dataset Free Text Not Described The shelf the map can be found Fixed List Characteristics of the geology, climate, soils, forest, water resources, agriculture, population, transports, water supply, sanitation, education, telecomunication in the Study 42 7 EX_TemporalExten t.extent 351 Start date and time for the content of the dataset Free Text 25/09/1976 No. ISO19115 EQUIVALENT ELEMENT NAME Not Described Not Described 1 MD_DataIdentifica tion.citation > CI_Citation.title 2 MD_DataIdentifica tion.citation > CI_Citation.alternat etitle 4 MD_Identification. abstract Comment No. 45

60 54 ELEM ENT NO ELEMENT NAME UKGEMINI EQUIVALENT ELEMENT NAME Date(M) ISO19115 EQUIVALENT No ELEMENT. NAME 7 EX_TemporalExten t.extent 8 DATA_COLLECTIO N_PERIOD_TO 9 NORTHERNMOST_ LATITUDE North Bounding Coordinate(M) 10 SOUTHERNMOST_ LATITUDE South Bounding Coordinate(M) 11 EASTERNMOST_L ONGITUDE East Bounding Coordinate(M) 12 WESTERNMOST_L ONGITUDE West Bounding Coordinate(M) 13 MD_DataIdentifica tion.geographicbox > EX_GeographicBo undingbox.northbo undlatitude 14 MD_DataIdentifica tion.geographicbox > EX_GeographicBo undingbox.southbo undlatitude 11 MD_DataIdentifica tion.geographicbox > EX_GeographicBo undingbox.eastbou ndlongitude 12 MD_DataIdentifica tion.geographicbox > EX_GeographicBo undingbox.westbo undlongitude Comment Domain Example 351 End date and time for the content of the dataset Free Text 09/12/ Northern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north) Number Southern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north) Number Eastern-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east) Number Western-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east) Number No.

61 55 ELEM ENT NO ELEMENT NAME 13 SPATIAL_RESOLU TION UKGEMINI EQUIVALENT ELEMENT NAME Spatial Resolution (O) 14 SPATIAL_REF_SYS TEM Spatial Reference System(O) 15 PRESENTATIN_TY PE_ID Presentation Type (O) 16 PUBLICATION_YE AR 17 PUBLISHER_NAME Dataset Reference Date (M) Originator (O) 18 PUBLICATION_PL ACE MAP_SCALE 19 Not Described ISO19115 EQUIVALENT No ELEMENT. NAME 18 MD_DataIdentifica tion.spatialresoluti on > spatial resolution.distance 17 MD_ReferenceSyst em.referencesyste midentifier 20 MD_MaintenanceI dentification.citatio n> CI_Citation.Present ationform 8 MD_Identification. citation > CI_Citation.date 9 MD_Identification. credit MD_DataIdentifica tion.spatialresoluti on > spatial resolution.equivale ntscale Comment Domain Example Number Name or description if the system of spatial referencing, whether by coordinates or geographic identifiers, used in the dataset Free Text WGS To choose from List of presentation types whether it is hardcopy, softcopy or both. Foreign key to WOSSAC_PRESENTATION_TYP E_LUT 362 Year of publication of the data Fixed List HardCopy Free Text 1893 Free Text Hunting Technical Services Ltd Free Text London, UK Free Text 1:5000 No. 61 Measure of the granularity of the data (in metres) 27 Person or organisation having primary responsibility for the intellectual content of the data 60 Scale of the hard copy map

62 56 ELEM ENT NO ELEMENT NAME 20 ACCESS_TERMS_I D UKGEMINI EQUIVALENT ELEMENT NAME Access Constraint(O) Domain Example 70 Foreign Key to WOSSAC_RIGHTS- details the restrictions and legal prerequisites for the access of the data 277 Information about the online sources from which the resource can be obtained a URL Fixed List ONLINE_RESOURC E Online Resource(O) 22 ADD_INFO_SOURC E Additional Information Source(O) 28 MD_Distribution > MD_DigitalTransfe Option.onLine > CI_OnlineResource 27 MD_DataIdentifica tion.supplementalin formation Free Text egyptsoilmap.htm 46 Source of further information about the dataset, may be a URL, or a book Free Text ews/index.htm# USE_CONSTRAINT _ID Use Constraints(O) 26 MD_Constraints.us econstraints 71 Foreign Key to WOSSAC_RIGHTS_LUTRestrictions and legal restraints on using the data Fixed List SPATIAL_REP_TYP E_ID Spatial Representation Type (O) 19 MD_DataIdentifica tion.spatialreprese ntationtype Fixed List 004 BROWSE_MAP_TH UMB Browse Graphic (O) Free Text C:\ wossac\nigeria_thmb BROWSE_MAP_LO W_RES Browse Graphic (O) 29 MD_Identification. graphicoverview > MD_BrowseGraphi c 29 MD_Identification. graphicoverview > MD_BrowseGraphi c 37 Foreign Key to WOSSAC_SPATIAL_REP_TYPE_ LUT- method used to represent the spatial aspect of the data 31 Directory location of the map s thumbnail digital image Directory location of the map s low resolution digital image Free Text C:\ wossac\nigeria_low_res ISO19115 EQUIVALENT No ELEMENT. NAME 25 MD_Constraints.ac cessconstraints Comment No.

63 57 ELEM ENT NO ELEMENT NAME 27 BROWSE_MAP_FU LL_RES UKGEMINI EQUIVALENT ELEMENT NAME Browse Graphic (O) 28 DATA_UPDATE_F REQUENCY_ID Frequency Of Update (M) 29 SUPPLY_MEDIA Supply Media (O) 22 MD_Distribution.o ffline > MD_Medium.name 30 DATA_FORMAT Data Format (M) 31 SENSOR Not Described 21 MD_Distribution > MD_Format.name Not Described 32 PLATFORM Not Described Not Described 33 SPECTRAL _RESOLUTION RADIOMETRIC RESOLUTION Not Described Not Described 34 ISO19115 EQUIVALENT No ELEMENT. NAME 29 MD_Identification. graphicoverview > MD_BrowseGraphi c 24 MD_MaintenanceI nformation.mainten anceandupdatefre quency Comment Domain Example 31 Directory location of the map s full resolution digital image Free Text C:\ wossac\nigeria_full_res 143 Foreign Key to WOSSAC_MAP_UPDATE_FREQ _LUT- frequency with which modifications and deletions are made to the data after it is first produced 292 Foreign Key to WOSSAC_SUPPLY_MEDIA_LUT - type of media in which the data can be supplied Fixed List 008 Fixed List Free Text 005 Sensor used to capture the image Free Text AVHRR Free Text SPOT4 Not Described Platform on which the sensor used to capture the data is Spectral Resolution of the image Number 4 Not Described Radiometric resolution of the image Number 5 No.

64 58 A-3 WOSSAC_DOCUMENTS Table This table contains elements that exclusively describe WOSSAC s bibliographic items. There are other elements / fields in other tables that still further describe the bibliographic items ELEME NT NO ELEMENT NAME 1 DOC_ID 2 ITEM_ID 3 Comment Domain Example of Metadata Auto 1 RELATION Primary Key, generated by automatically generating numbers in ascending order Foreign key that links to the WOSSAC_ITEMS table ITEM_ISBN IDENTIFIER ISBN number of the Document {MARC 020$a} Free Text ISBN TITLE TITLE Title of the Document Free Text Report on WOSSAC 5 SUBTITLE TITLE The Document s subtitle Free Text Details of WOSSAC 6 SHELFMARK The shelf in which the document can be found Fixed List 45 7 SERIES_TITLE Title of the Series {MARC 440$a} Free Text WOSSAC Documents 8 SERIES_SECTI ON_NUM SERIES_SECTI ON_NAME PUBLICATION_ YEAR PUBLISHER_N AME PUBLICATION_ PLACE CORPORATE_A UTHOR_SERIE S PERSONAL_AU THOR Section Number of the Series {MARC 440$n} Free Text 21 Section Name of the Series {MARC 440$p} Free Text Journal of WOSSAC DATE Year of Documents Publishing {MARC 260$c} Date 1998 PUBLISHER Name of Publisher{MARC 260$b} Free Text University Press Place of Publication {MARC 260$a} Free Text Surrey, UK CREATOR Corporate Author Series {MARC 110$a} Free Text Laot E, Wells A CREATOR Personal author of the report/document{marc 100$a} Free Text Wells A DUBLIN CORE EQUIVALENT 34

65 59 ELEME NT NO ELEMENT NAME DUBLIN CORE EQUIVALENT Comment Domain Example of Metadata 15 MATERIAL_EX TENT SUMMARY FORMAT Description of the material in terms of pages and volumes {MARC 300$a} Summary/Abstract of the document{marc 520$a} Free Text 25pp report Free Text Soil Data of Cranfield 17 NORTHERNMO ST_LATITUDE COVERAGE Number SOUTHERNMO ST_LATITUDE COVERAGE Northern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north) {MARC 034$f} Southern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north) {MARC 034$g} Number EASTERNMOS T_LONGITUDE COVERAGE Eastern-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east) {MARC 034$e} Number WESTERNMOS T_LONGITUDE ONLINE_RESO URCE COVERAGE Western-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees{marc 034$d} Information about the online sources from which the resource can be obtained the name of the Documents PDF {MARC 530$u} Directory location and name of the document s scanned front page thumbnail digital image Foreign Key to WOSSAC_RIGHTS- details the restrictions and legal prerequisites for the access of the data Number 34 Free Text 1_DOC01_wossac.pdf Free Text 1_DOC01_wossac.jpg Fixed List BROWSE_DOC _THMB ACCESS_TERM S_ID DESCRIPTION RIGHTS

66 60 A-4 WOSSAC_RECORD_UPDATES TABLE This table shows the record updates, but more importantly, it shows the Metadata update date which is a compulsory element in UKGEMINI and ISO ELEME NT NO ELEMENT NAME RECORD_UPDATES_ID ITEM_ID UPDATE_DATE 4 REVIEWER_ID UKGEMINI EQUIVALENT ELEMENT NAME Date of update of metadata No 30 ISO19115 EQUIVALENT ELEMENT NAME MD_Metadata.da testamp COMMENTS EXAMPLE Date on which the metadata was last changed 23/09/1999 No 9 A-5 WOSSAC_LOCATION_LUT TABLE The location of the WOSSAC Items and how the fields map to ISO19115 elements ELEMENT NO ELEMENT NAME ISO19115 EQUIVALENT ELEMENT 1 LOCATION_ID LOCATION_NAME LOCATION_ADDRESS1 LOCATION_ADDRESS2 LOCATION_ADDRESS3 LOCATION_TOWN LOCATION_COUNTY LOCATION_POSTCODE COMMENTS Example Primary key representing the distributor 1 NO Not Described MD_Distribution > MD_Distributor.distributorContact > CI_ResponsibleParty. organisationname 376 Name of distributor MD_Distribution > MD_Distributor.distributorContact > CI_ResponsibleParty.contactInfo > CI_Contact.address 389 Postal Address of the distributor

67 61 ELEMENT NO ELEMENT NAME ISO19115 EQUIVALENT ELEMENT COMMENTS Example NO LOCATION_COUNTRY 9 10 LOCATION_PHONE 11 LOCATION_FAX 12 LOCATION_ LOCATION_WEB LOCATION_NOTES MD_Distribution > MD_Distributor.distributorContact > CI_ResponsibleParty.contactInfo > CI_Contact.phone > CI_Telephone.voice MD_Distribution > MD_Distributor.distributorContact > CI_ResponsibleParty.contactInfo > CI_Contact.phone > CI_Telephone.facsimilie MD_Distribution > MD_Distributor.distributorContact > CI_ResponsibleParty.contactInfo > CI_Address.electronicMailAddress MD_Distribution > MD_Distributor.distributorContact > CI_OnlineResource.linkage Not Described 408 Phone number of the distributor 409 Fax Address of the distributor address of distributor URL Address of the distributor A-6 Modification to WOSSAC_WORLD_CITIES Table WOSSAC_WORLD_CITIES was modified to include these fields ELEMENT NAME LIKELY_CRS_NAME LIKELY_CRS_CODE LIKELY_CRS_DEFINITION AREA_CODE COMMENT Name of the most likely CRS for the country in the record Most likely Unique code (integer) of the Coordinate Reference System (CRS); primary key. Description of CRS Code of the Area wossac@cranfield.ac.uk

68 62 A-7 COORD_REF_SYS Table: Information about Coordinate Reference System (CRS) to aid CRS ESPSG code data entry into WOSSAC_MAP table ELEMENT NAME COORD_REF_SYS_CODE COORD_REF_SYS_NAME AREA_OF_USE_CODE COORD_REF_SYS_KIND COORD_SYS_CODE DATUM_CODE SOURCE_GEOGCRS_CODE CRS_SCOPE REMARKS COMMENT Unique code (integer) of the Coordinate Reference System (CRS); primary key. Name of the CRS. The code of the Area of Use this CRS uses. Foreign key to CRS_AREA Table The type of CRS: "compound"; "engineering";"geocentric";"geographic 2D";"geographic 3D";"projected";"vertical". The code of the Coordinate System (=set of re-usable axes) this CRS uses. The code of the datum on which this CRS is based. Not used for projected or compound CRSs For projected CRS s only, the code for the associated base geog CRS The applicability of the CRS. A-8 COORD_REF_SYS_AREA Table Information about Area a Coordinate Reference System (CRS) is used, to aid CRS data entry ELEMENT NAME AREA_CODE AREA_NAME AREA_OF_USE AREA_SOUTH_BOUND_LAT AREA_NORTH_BOUND_LAT AREA_WEST_BOUND_LON AREA_EAST_BOUND_LON ISO_A3_CODE COMMENT Unique code (integer) of the area of use; primary key. Name of the area of use Description of the area of use The southern latitude of a bounding arc-rectangle The northern latitude of a bounding arc-rectangle, Longitude (WGS 84) of the left side of a bounding arc-rectangle The longitude (WGS 84) of the right side of a bounding arc-rectangle ISO digit alpha country code

69 63 A-9 WOSSAC Look Up Tables Mapping to ISO19115 Code Table The following WOSSAC database tables are copied from the ISO19115 codes tables and adapted to the WOSSAC database by changing the table with its elements names. The Mapping of the WOSSAC tables to the equivalent ISO19115 codes tables WOSSAC DATABASE TABLES WOSSAC_SPATIAL_REP_TYPE_LUT WOSSAC_TOPIC_CATEGORY_LUT WOSSAC_SUPPLY_MEDIA_LUT WOSSAC_MAP_UPDATE_FREQ_LUT WOSSAC_RIGHTS_LUT EQUIVALENT ISO19115 TABLES MD_SpatialRepresentationTypeCode MD_TopicCategoryCode MD_MediumNameCode MD_MaintenanceFrequencyCode MD_RestrictionCode A-10 WOSSAC Look Up Tables and Fields/Elements with Their Description The mapping of the element names of each above mentioned code tables elements name to the WOSSAC_SPATIAL_REP_TYPE_LUT, WOSSAC_TOPIC_CATEGORY_LUT, WOSSAC_SUPPLY_MEDIA_LUT, WOSSAC_MAP_UPDATE_FREQ_LUT and WOSSAC_RIGHTS_LUT in WOSSAC_DATABASE ELEMENT NAME Spatial_Rep_Type_ID, Topic_Category_ID, Supply_Media_ID, Map_Update_Freq_ID And Rights_ID as the equivalent field names in the WOSSAC database tables mentioned above for the field called Name in the code list ISO19115 tables NAME DEFINITION Code to represent the Field element COMMENT The code of the items in items List Name of the items in record in code Description of each record code Name of the Items List in the table Description of the items in the List

70 64 APPENDIX B SCRIPTS WRITTEN B-1 CFML Script to Create Google Earth Placemark KML Files from Proposed WOSSAC Database Query This is the main ColdFusion script that creates KML files. It calls different database queries (from the written ColdFusion components files, see Appendix B-3) and creates Placemark KML files (one for each continent) that shows the WOSSAC maps, reports and images holdings for the continent using the returned queries. It also zips the created KML files into KMZ using a function called from another ColdFusion component. The created Placemarks are populated with information from the database about the WOSSAC Item it represents. <!--- Name: WossacWOSSAC_Items_KML.cfm---> <!--- Author: Michael Owanabi,, June > <!--- File version > <!--- Description: CFM code to generate Placemarks KML entities from the WossacWOSSAC items catalogue ---> <!--- Invoke functions for retrieving the data from the database ---> <cfsilent> <!--- Returns image's metadata ---> <cfinvoke component="components.wossacwossaccontinent" method="func_wossacwossac_continents_image" returnvariable="databaseorderedimage"></cfinvoke> <!--- Returns Map's metadata ---> <cfinvoke component="components.wossacwossaccontinent" method="func_wossacwossac_continents_map" returnvariable="databaseorderedmap"></cfinvoke> <!--- Returns Documents Metadata ---> <cfinvoke component="components.wossacwossaccontinent" method="func_wossacwossac_continents_doc" returnvariable="databaseordereddoc"></cfinvoke> <!---Returns each individual continent in WossacWOSSAC items <cfinvoke component="components.wossacwossaccontinent" method="func_wossacwossac_distinctcontinents" returnvariable="distinctcontinents"></cfinvoke> ---> <!--- Creation of KML files ---> <!--- Loop through the individual distinct continents returned from the database. The code within the loop creates the KML file for each continent it loops about at a particular time ---> <cfloop query="distinctcontinents"> <Cfset CONT_TEST = #DISTINCT_CONTINENT#>

71 65 <!--- Assigns the value of the continent being looped to a variable ---> <!--- Creation of KML by using the cfxml tag to output the XML based on the KML schema---> <cfxml variable="wossac"> <!--- Header for the kml file ---> <kml xmlns=" <Document> <name>wossacwossac.com KML item data source for <cfoutput>#distinct_continent#</cfoutput></name> <!---Create a folder tag for the Image placemarks item in KML --> <Folder> <name><cfoutput>#distinct_continent#</cfoutput>'s Images</name> <open>0</open> <!--- End of header ---> <!--- Creation of placemarks by looping over each record of the returned query (databaseorderedimage) and testing whether it satisfies the conditions for being in the continent and of being either a placemark linked to the country's capital or a placemark with its own knwn coordinates if the data permits---> <cfoutput query="databaseorderedimage"> <!--- This tests whether the returned continent is the same as the current continent being looped and if it is the code below executes, if not, it passes on to the next record---> <cfif CONT_TEST is #CONTINENT#> <!--- This test whether the record returned has bounding coordinate values, if it does, a polygon is created for each record using the kml schema for drawing polygon ---> <cfif NORTHERNMOST_LATITUDE neq "" AND SOUTHERNMOST_LATITUDE neq "" AND EASTERNMOST_LONGITUDE neq "" AND WESTERNMOST_LONGITUDE neq ""> <Placemark> <name>#image_id#</name> <!---Output into the information box of the Placemark for the image, Information box contains links to various items as it is in the CDATA section of the KML ---> <description> <![CDATA[ <table width="383" height="274" align="center"> <tr> <td height="67" colspan="2"><div align="center"> <a href=" ><font color="##cc2211" size="4">#title#</font></strong></a> <cfif len(#alternative_title#) GT 0 > <h4> #ALTERNATIVE_TITLE# </h4></cfif> </div></td> </tr> <tr> <cfif len(#browse_image_thmb#) GT 0 ><td width="116" rowspan="3" align="center" valign="top"><img src=" width="107" height="136" /></td></cfif> <td width="248" height="89" align="left" valign="top"><p> <strong><font color="##cc2211" size="3">abstract:</font></strong><br />

72 66 #ABSTRACT# <br/><cfif len(#online_resource#) GT 0 > <a href=" Click me to View Report</a></cfif> </p></td> </tr> <tr> <td height="39" align="left" valign="top"><cfif len(#subjects#) GT 0 > <br/> <strong>subjects:</strong> #SUBJECTS#</cfif> <cfif len(#sensor#) GT 0 Or len(#platform#) GT 0 > <br/> <strong>platform and Sensor:</strong> #PLATFORM#- #SENSOR#</cfif> <br/><strong> Publisher: </strong> <cfif len(#publisher_name#) GT 0 >#PUBLISHER_NAME# <cfif len(#publication_year#) GT 0 > (#PUBLICATION_YEAR#)</cfif><cfelse> Unknown Publisher</cfif> <cfif len(#language_desc#) GT 0 > <br/> <strong>map's Language: </strong> #LANGUAGE_DESC#</cfif> </td> </tr> <tr> <td height="23"><a href=" THERNMOST_LATITUDE#,#WESTERNMOST_LONGITUDE#,#NORTHERNMOST_LATITUDE#&pn ame=#image_id#">view Area Covered by Project</a> </td> </tr> </table>]]> </description> <!---End of Information box ---> <Style id="sn_ylw-pushpin_copy1"> <IconStyle> <Icon> <href> </Icon> <hotspot x="20" y="2" xunits="pixels" yunits="pixels"/> </IconStyle> <BalloonStyle> <bgcolor>ff5286bb</bgcolor> </BalloonStyle> </Style> <Point> <coordinates> #(EASTERNMOST_LONGITUDE + WESTERNMOST_LONGITUDE)/2#,#(NORTHERNMOST_LATITUDE + SOUTHERNMOST_LATITUDE)/2#,0 </coordinates> </Point> </Placemark> </cfif> </cfif> </cfoutput> <!--- End of loop over the polygon- creating loop ---> <!--- Creation of placemark for each country's capital, populating each with descriptions from image records that have no specific coordinates. Achieved by looping over each record of the returned query (databaseordered) and testing whether it satisfies conditions for being in the continent and that of either being a placemark in country's capital or a polygon ---> <!--- The Cfelse tag was not used here because of the way each record was used in the former cfoutput tag is different from the the way it is being used in this new cfoutput tag ---> <cfoutput query= "DatabaseOrderedImage" group="country_now">

73 67 <!--- Output now grouped by country now to ensure each country has only one placemark placed on its capital ---> <!--- NOTE: For the group to work as plannned the returned query should be sorted by COUNTRY_NOW ---> <cfif CONT_TEST is #CONTINENT#> <!--- This tests whether the returned continent is the same as the current continent being looped over and if it is, the code belows executes, if not, it passes on to the next record---> <cfif NORTHERNMOST_LATITUDE is "" OR SOUTHERNMOST_LATITUDE is "" OR EASTERNMOST_LONGITUDE is "" OR WESTERNMOST_LONGITUDE is ""> <!--- This tests whether the record returned has a bounding coordinate value and if it doesn't, a placemark is created for each country, populated with the description of the record using the kml schema for drawing placemark ---> <Placemark> <name>#xmlformat(country_now)#</name> <description> <!--- cfoutput loop within another grouped cfoutput loop to output the image record by country ---> <cfoutput> <cfif NORTHERNMOST_LATITUDE is "" OR SOUTHERNMOST_LATITUDE is "" OR EASTERNMOST_LONGITUDE is "" OR WESTERNMOST_LONGITUDE is ""> <![CDATA[ <table width="383" height="274" align="center"> <tr> <td height="67" colspan="2"><div align="center"> <a href=" ><font color="##cc2211" size="4">#title#</font></strong></a> <cfif len(#alternative_title#) GT 0 > <h4> #ALTERNATIVE_TITLE# </h4></cfif> </div></td> </tr> <tr> <cfif len(#browse_image_thmb#) GT 0 ><td width="116" rowspan="3" align="center" valign="top"><img src=" width="107" height="136" /></td></cfif> <td width="248" height="89" align="left" valign="top"><p> <strong><font color="##cc2211" size="3">abstract:</font></strong><br /> #ABSTRACT# <br/><cfif len(#online_resource#) GT 0 > <a href=" Click me to View Report</a></cfif> </p></td> </tr> <tr> <td height="39" align="left" valign="top"><cfif len(#subjects#) GT 0 > <br/> <strong>subjects:</strong> #SUBJECTS#</cfif> <cfif len(#sensor#) GT 0 Or len(#platform#) GT 0 > <br/> <strong>platform and Sensor:</strong> #PLATFORM#- #SENSOR#</cfif> <br/><strong> Publisher: </strong> <cfif len(#publisher_name#) GT 0 >#PUBLISHER_NAME# <cfif len(#publication_year#) GT 0 > (#PUBLICATION_YEAR#)</cfif><cfelse> Unknown Publisher</cfif> <cfif len(#language_desc#) GT 0 > <br/> <strong>map's Language: </strong> #LANGUAGE_DESC#</cfif> </td> </tr>

74 68 <tr> <td height="23"><a href=" THERNMOST_LATITUDE#,#WESTERNMOST_LONGITUDE#,#NORTHERNMOST_LATITUDE#&pn ame=#image_id#">view Area Covered by Project</a> </td> </tr> </table><hr>]]> </cfif> </cfoutput></description> <Style> <IconStyle id="khiconstyle639"> <color>ff7faaff</color> <Icon> <href> </Icon> </IconStyle> <BalloonStyle> <bgcolor>ff5286bb</bgcolor> </BalloonStyle> </Style> <Point> <coordinates>#longitude#,#latitude#,0</coordinates> </Point> </Placemark> </cfif> </cfif> </cfoutput> </Folder> <!---Creates a folder tag containing the Report items in the KML, The code here outputs the placemarks KML for each document item ---> <Folder> <name><cfoutput>#distinct_continent#</cfoutput>'s Reports</name> <open>0</open> <!--- End of header ---> <!--- Creation of polygons by looping over each record of the returned query (databaseordered) and testing whether it satisfies the conditions for being in the continent and of being either a placemark linked to the country's capital or a polygon if the data permits---> <cfoutput query="databaseordereddoc"> <!--- This tests whether the returned continent is the same as the current continent being looped and if it is the code below executes, if not, it passes on to the next record---> <cfif CONT_TEST is #CONTINENT#> <!--- This test whether the record returned has bounding coordinate values, if it does, a polygon is created for each record using the kml schema for drawing polygon ---> <cfif NORTHERNMOST_LATITUDE neq "" AND SOUTHERNMOST_LATITUDE neq "" AND EASTERNMOST_LONGITUDE neq "" AND WESTERNMOST_LONGITUDE neq ""> <Placemark> <name>#doc_id#</name> <description> <![CDATA[ <table width="383" height="274" align="center"> <tr> <td height="67" colspan="2"><div align="center">

75 69 <a href=" ><font color="##cc2211" size="4">#title#</font></strong></a> <cfif len(#subtitle#) GT 0 > <h4> #SUBTITLE# </h4></cfif> </div></td> </tr> <tr> <cfif len(#browse_doc_thmb#) GT 0 ><td width="116" rowspan="3" align="center" valign="top"><img src=" width="107" height="136" /></td></cfif> <td width="248" height="89" align="left" valign="top"><p> <strong><font color="##cc2211" size="3">abstract:</font></strong><br /> #SUMMARY# <br/><cfif len(#online_resource#) GT 0 > <a href=" Click me to View Report</a></cfif> </p></td> </tr> <tr> <td height="39" align="left" valign="top"><cfif len(#subjects#) GT 0 > <br/> <strong>subjects:</strong> #SUBJECTS#</cfif> <br/><strong> Publisher: </strong> <cfif len(#publisher_name#) GT 0 >#PUBLISHER_NAME# <cfif len(#publication_year#) GT 0 > (#PUBLICATION_YEAR#)</cfif><cfelse> Unknown Publisher</cfif> <cfif len(#language_desc#) GT 0 > <br/> <strong>map's Language: </strong> #LANGUAGE_DESC#</cfif></td> </tr> <tr> <td height="23"><a href=" THERNMOST_LATITUDE#,#WESTERNMOST_LONGITUDE#,#NORTHERNMOST_LATITUDE#&pn ame=#doc_id#">view Area Covered by Project</a> </td> </tr> </table>]]> </description> <Style id="sn_ylw-pushpin_copy1"> <IconStyle> <Icon> <href> </Icon> <hotspot x="20" y="2" xunits="pixels" yunits="pixels"/> </IconStyle> <BalloonStyle> <bgcolor>ff5286bb</bgcolor> </BalloonStyle> </Style> <Point> <coordinates> #(EASTERNMOST_LONGITUDE + WESTERNMOST_LONGITUDE)/2#,#(NORTHERNMOST_LATITUDE + SOUTHERNMOST_LATITUDE)/2#,0 </coordinates> </Point> </Placemark> </cfif> </cfif> </cfoutput> <!--- End of loop over the polygon- creating loop --->

76 70 <!--- Creation of placemark for each country's capital, populating each with descriptions from records that have no specific coordinates. Achieved by looping over each record of the returned query (databaseordered) and testing whether it satisfies conditions for being in the continent and that of either being a placemark in country's capital or a polygon ---> <!--- The Cfelse tag was not used here because of the way each record was used in the former cfoutput tag is different from the the way it is being used in this new cfoutput tag ---> <cfoutput query= "DatabaseOrderedDoc" group="country_now"> <!--- Output now grouped by country now to ensure each country has only one placemark placed on its capital ---> <!--- NOTE: For the group to work as plannned the returned query should be sorted by COUNTRY_NOW ---> <cfif CONT_TEST is #CONTINENT#> <!--- This tests whether the returned continent is the same as the current continent being looped over and if it is, the code belows executes, if not, it passes on to the next record---> <cfif NORTHERNMOST_LATITUDE is "" OR SOUTHERNMOST_LATITUDE is "" OR EASTERNMOST_LONGITUDE is "" OR WESTERNMOST_LONGITUDE is ""> <!--- This tests whether the record returned has a bounding coordinate value and if it doesn't, a placemark is created for each country, populated with the description of the record using the kml schema for drawing placemark ---> <Placemark> <name>#xmlformat(country_now)#</name> <description> <!--- cfoutput loop within another grouped cfoutput loop to output the record by country ---> <cfoutput> <cfif NORTHERNMOST_LATITUDE is "" OR SOUTHERNMOST_LATITUDE is "" OR EASTERNMOST_LONGITUDE is "" OR WESTERNMOST_LONGITUDE is ""> <![CDATA[ <table width="383" height="274" align="center"> <tr> <td height="67" colspan="2"><div align="center"> <a href=" ><font color="##cc2211" size="4">#title#</font></strong></a> <cfif len(#subtitle#) GT 0 > <h4> #SUBTITLE# </h4></cfif> </div></td> </tr> <tr> <cfif len(#browse_doc_thmb#) GT 0 ><td width="116" rowspan="3" align="center" valign="top"><img src=" width="107" height="136" /></td></cfif> <td width="248" height="89" align="left" valign="top"><p> <strong><font color="##cc2211" size="3">abstract:</font></strong><br /> #SUMMARY# <br/><cfif len(#online_resource#) GT 0 > <a href=" Click me to View Report</a></cfif> </p></td> </tr> <tr> <td height="39" align="left" valign="top"><cfif len(#subjects#) GT 0 > <br/> <strong>subjects:</strong> #SUBJECTS#</cfif> <br/><strong> Publisher: </strong> <cfif len(#publisher_name#) GT 0

77 71 >#PUBLISHER_NAME# <cfif len(#publication_year#) GT 0 > (#PUBLICATION_YEAR#)</cfif><cfelse> Unknown Publisher</cfif> <cfif len(#language_desc#) GT 0 > <br/> <strong>map's Language: </strong> #LANGUAGE_DESC#</cfif></td> </tr> </table><hr>]]> </cfif> </cfoutput></description> <Style> <IconStyle id="khiconstyle639"> <color>ff7faaff</color> <Icon> <href> </Icon> </IconStyle> <BalloonStyle> <bgcolor>ff5286bb</bgcolor> </BalloonStyle> </Style> <Point> <coordinates>#longitude#,#latitude#,0</coordinates> </Point> </Placemark> </cfif> </cfif> </cfoutput> </Folder> <!---Closes the folder element tag for Documents data ---> <!---Folder tag for Maps KML opens, and the code here returns Placemarks KML for each recorrd ---> <Folder> <name><cfoutput>#distinct_continent#</cfoutput>'s Maps</name> <open>0</open> <!--- End of header ---> <!--- Creation of polygons by looping over each record of the returned query (databaseorderedmap)and testing whether it satisfies the conditions for being in the continent and of being either a placemark linked to the country's capital or a polygon if the data permits---> <cfoutput query="databaseorderedmap"> <!--- This tests whether the returned continent is the same as the current continent being looped and if it is the code below executes, if not, it passes on to the next record---> <cfif CONT_TEST is #CONTINENT#> <!--- This test whether the record returned has bounding coordinate values, if it does, a polygon is created for each record using the kml schema for drawing polygon ---> <cfif NORTHERNMOST_LATITUDE neq "" AND SOUTHERNMOST_LATITUDE neq "" AND EASTERNMOST_LONGITUDE neq "" AND WESTERNMOST_LONGITUDE neq ""> <Placemark> <name>#map_id#</name> <description> <![CDATA[ <table width="383" height="274" align="center"> <tr> <td height="67" colspan="2"><div align="center"> <a href=" ><font color="##cc2211" size="4">#title#</font></strong></a> <cfif len(#alternative_title#) GT 0 > <h4> #ALTERNATIVE_TITLE# </h4></cfif>

78 72 </div></td> </tr> <tr> <cfif len(#browse_map_thmb#) GT 0 ><td width="116" rowspan="3" align="center" valign="top"> <!--- Note the Directory to which the image source should map to--><img src=" width="107" height="136" /></td></cfif> <td width="248" height="89" align="left" valign="top"><p> <strong><font color="##cc2211" size="3">abstract:</font></strong><br /> #ABSTRACT#</p></td> </tr> <tr> <td height="39" align="left" valign="top"> <cfif len(#subjects#) GT 0 > <br/> <strong>subjects:</strong> #SUBJECTS#</cfif> <br/><strong> Publisher: </strong> <cfif len(#publisher_name#) GT 0 >#PUBLISHER_NAME# <cfif len(#publication_year#) GT 0 > (#PUBLICATION_YEAR#)</cfif><cfelse> Unknown Publisher</cfif> <cfif len(#language_desc#) GT 0 > <br/> <strong>map's Language: </strong> #LANGUAGE_DESC#</cfif></td> </tr> <tr> <td height="23"><a href=" THERNMOST_LATITUDE#,#WESTERNMOST_LONGITUDE#,#NORTHERNMOST_LATITUDE#&pn ame=#map_id#">view Area Covered by Project</a> <cfif Len(#BROWSE_MAP_FULL_RES#) GT 0><br/> <!---Creates GET URL hyperlink to the python script returning image, one of the URL variables is another URL, so it is formatted so that it wont be able to be recognised as URL by the URL---> <a href= " OUTHERNMOST_LATITUDE#,#EASTERNMOST_LONGITUDE#,#NORTHERNMOST_LATITUDE#& Item_name=#MAP_ID#&url_name=http%3A%2F%2Fstellar%2Ecentral%2Ecranfield %2Eac%2Euk%2Fowanabi%2Fwossac%2Ephp%3FVERSION%3D1%2E1%2E1%26amp%3BREQU EST%3DGetMap%26amp%3BSRS%3DEPSG%3A4326%26amp%3BWIDTH%3D512%26amp%3BHEI GHT%3D512%26amp%3BLAYERS%3D#TITLE#%26amp%3BTRANSPARENT%3DTRUE%26amp%3B FORMAT%3Dimage%2Fpng%26amp%3B">Click to View Map using WMS Service</a></cfif></td> </tr> </table>]]> </description> <Style id="sn_ylw-pushpin_copy1"> <IconStyle> <Icon> <href> </Icon> <hotspot x="20" y="2" xunits="pixels" yunits="pixels"/> </IconStyle> <BalloonStyle> <bgcolor>ff5286bb</bgcolor> </BalloonStyle> </Style> <Point> <coordinates> #(EASTERNMOST_LONGITUDE + WESTERNMOST_LONGITUDE)/2#,#(NORTHERNMOST_LATITUDE + SOUTHERNMOST_LATITUDE)/2#,0 </coordinates> </Point>

79 73 </Placemark> </cfif> </cfif> </cfoutput> <!--- End of loop over the polygon- creating loop ---> </Folder> </Document> </kml> </cfxml> <!--- end of outputting the KML using cfxml tag ---> <!--- Writting of the KML file to a directory ---> <!--- Directory instantiated to the current directory the cfml template is located in. The name of the file is set to the name of the current continent being looped around ---> <cfset kmlfile = ExpandPath("/wossac2/kml/") & "Kml_" & #CONT_TEST# & ".kml"> <!--- Writing of the KML file with the name specified to the directory specified ---> <cffile action="write" file="#kmlfile#" output="#tostring(wossac)#"> </cfloop> <!--- End of loop for each particular continent ---> <!--- Creation of KMZ files starts ---> <cfloop query="distinctcontinents"> <cfset kmlfile=""> <!--- First identify the file to convert ---> <cfset kmlfile=expandpath("/wossac2/kml/") & "Kml_" & "#DISTINCT_CONTINENT#" & ".kml"> <!--- Create filename an directory address to the zip file ---> <cfset kmzfile=expandpath("/wossac2/kml/") & "Kml_" & "#DISTINCT_CONTINENT#" & ".kmz"> <!---Invoke the component to create the zipped KMZ file ---> <cfinvoke component="components.zip" method="addfiles" returnvariable="addfilesret"> <cfinvokeargument name="zipfilepath" value="#kmzfile#"/> <cfinvokeargument name="files" value="#kmlfile#"/> </cfinvoke> </cfloop> </cfsilent> <!--- Hyperlink to Network Link KML file manually written to load WossacWOSSAC kml files ---> <body><a href=" Click Me To View in Google Earth</a></body> <!--- EOF: WossacWOSSAC_Items_KML.cfm ---> B-2 CFML Script to Create MapServer s Mapfile from Proposed WOSSAC Database Query This script creates the Mapfile for the configuration of the MapServer dynamically from the database. It calls the function returning query from the ColdFusion component file in appendix B-3 and uses the returned query to create the file.

80 74 <!--- Name: WossacWOSSAC_Items_KML.cfm---> <!--- Author: Michael Owanabi,, June > <!--- File version > <!--- Description: CFM code to generate Placemarks KML entities from the WossacWOSSAC items catalogue ---> <!---Invoke Database Query to return records to be used in the dynamic creation of MapFile---> <cfinvoke component="components.wossacwossaccontinent" method="func_wossacwossac_continents_mapserver" returnvariable="databaseorderedmapserver"></cfinvoke> <!--- creates a variable to hold the all the content of the mapfile and fill the contenet with the appropriate data---> <cfsavecontent variable = "wossac_map"> MAP # all temp files get prefixed with this string NAME "WOSSAC MAP" # always returns a map STATUS ON #Output Projection System PROJECTION "init=epsg:4326" END # image format options OUTPUTFORMAT NAME jpeg DRIVER "GD/JPEG" MIMETYPE "image/jpeg" IMAGEMODE RGB EXTENSION "jpg" END OUTPUTFORMAT NAME png DRIVER "GD/PNG" MIMETYPE "image/png" IMAGEMODE RGB EXTENSION "png" END OUTPUTFORMAT NAME GEOTIFF_RGB DRIVER "GDAL/GTiff" MIMETYPE "image/tiff" IMAGEMODE RGB EXTENSION "tif" END # minx miny maxx maxy # sets: @maxx) EXTENT # World # Start of web interface definition WEB

81 75 # this is the real filepath to the temp dir for intermediate file creation IMAGEPATH "/ms4w/tmp/ms_tmp/" # this is the web-accessible path to IMAGEPATH IMAGEURL "/ms_tmp/" METADATA "map" "ms4w/apache/htdocs/owanabi/config.map" # generic OWS specific info sets base URL for OGC Schemas so the root element in the Capabilities document points to the correct schema location to produce valid XML "ows_schemas_location" " # sets: # /WMT_MS_Capabilities/Service/Title # /WMT_MS_Capabilities/Capability/Layer/Title "ows_title" "World Soil Survey Archive and Catalogue" # /WMT_MS_Capabilities/Service/Abstract "ows_abstract" "'s 'World Soil Survey Archive and Catalogue' (WOSSAC) is an archive and catalogue of all substantial soil surveys, reports and maps made overseas, with particular reference to those by British companies and personnel, to provide a safe repository for endangered copies, and to make the accrued information widely available for consultation by interested parties.and here are some of the maps of the WOSSAC" # /WMT_MS_Capabilities/Service/KeywordList/Keyword[] "ows_keywordlist" "soil map, soil report, soil survey, agriculture,geology, sopl" # /WMT_MS_Capabilities/Service/OnlineResource "ows_service_onlineresource" " # /WMT_MS_Capabilities/Service/Fees "ows_fees" "Contact WOSSAC for the Charges" # /WMT_MS_Capabilities/Service/ContactInformation/ContactPersonPrimary/C ontactperson "ows_contactperson" "Dr Steve Hallett" # /WMT_MS_Capabilities/Service/ContactInformation/ContactPersonPrimary/C ontactorganization "ows_contactorganization" "WOSSAC, " # /WMT_MS_Capabilities/Service/ContactInformation/ContactPosition "ows_contactposition" "Manager NSRI" # /WMT_MS_Capabilities/Service/ContactInformation/ContactAddress/Address Type "ows_addresstype" "Postal" # /WMT_MS_Capabilities/Service/ContactInformation/ContactAddress/Address "ows_address" "Building 53 " # /WMT_MS_Capabilities/Service/ContactInformation/ContactAddress/City "ows_city" "Cranfield" # /WMT_MS_Capabilities/Service/ContactInformation/ContactAddress/StateOr Province "ows_stateorprovince" "Bedfordshire" # /WMT_MS_Capabilities/Service/ContactInformation/ContactAddress/PostCod e "ows_postcode" "MK43 0AL" # /WMT_MS_Capabilities/Service/ContactInformation/ContactAddress/Country

82 76 "ows_country" "UK" # /WMT_MS_Capabilities/Service/ContactInformation/ContactVoiceTelephone "ows_contactvoicetelephone" " ext 3323" # /WMT_MS_Capabilities/Service/ContactInformation/ContactElectronicMailA ddress "ows_contactelectronicmailaddress" "s.hallett@cranfield.ac.uk" # /WMT_MS_Capabilities/Capability/Layer/SRS, /WMT_MS_Capabilities/Capability/Layer/Layer[*]/SRS, /WFS_Capabilities/FeatureTypeList/FeatureType[*]/SRS unless differently defined in LAYER object "ows_srs" "EPSG:4326" END END <cfoutput query="databaseorderedmapserver"> LAYER #name of layer NAME "#TITLE#" #name of group of layers, layers are grouped by country GROUP "#CNTRY_NAME#" #input CRS of the input data PROJECTION "init=epsg:<cfif Len(#MOST_LIKELY_SPATIAL_REF_SYSTEM#)GT 0>#MOST_LIKELY_SPATIAL_REF_SYSTEM#<cfelseif Len(#LIKELY_CRS_CODE#) GT 0>#LIKELY_CRS_CODE#<cfelse> 4326 </cfif>" END #type of image TYPE RASTER DUMP TRUE STATUS ON #location and name of data file to use DATA data/#browse_map_full_res# METADATA "ows_title" "#TITLE#" "wms_abstract" "#ABSTRACT#" "wms_keywordlist" "#SUBJECTS#" "wms_opaque" "1" "wms_group_title" "#CNTRY_NAME#'s data" "wms_extent" "#WESTERNMOST_LONGITUDE# #SOUTHERNMOST_LATITUDE# #EASTERNMOST_LONGITUDE# #NORTHERNMOST_LATITUDE#" "wms_metadataurl_format" "text/html" "wms_metadataurl_href" " END END </cfoutput> END <!---end of the content file used to save the mapfile---> </cfsavecontent> <!---- Writing the Mapfile to a directory ---> <cffile action="write" file="c:\inetpub\wwwroot\wossac2\config.map" output="#wossac_map#">

83 77 B-3 Coldfusion Component Script Containing Database Queries This is a subsidiary script (component) and it consists of different functions that can be called to perform different functions. In this case, it returns different form of queries of the database for the creation of both the KML files and Mapfiles. <!--- Name: WossacWOSSACContinent.cfc ---> <!--- Author: Michael Owonibi, at Silsoe, June > <!--- File version > <!--- Description: Component for the WossacWOSSAC_Items_KML.cfm script that will return the main query of information from the WossacWOSSAC database. Querys the database with item records for different types of geospatial information. ---> <cfcomponent displayname="wossacwossac Continent Data functions" hint="queries returning data for the WossacWOSSAC and Google Earth program"> <!--- Function: func_wossac_continents_doc ---> <!--- Purpose: Returns Continents reports and documents---> <cffunction name="func_wossacwossac_continents_doc" displayname= "WossacWOSSAC Continent Document/Report Data" hint="list of all WossacWOSSAC Document records with any type of geospatial data, latitude, longitude or country" access="public" returntype="query" output="false"> <cfquery name="getwossacwossaccontinentdoc" datasource="#request.app.dsn#" > SELECT WOSSAC2_DOCUMENT.DOC_ID, WOSSAC2_DOCUMENT.TITLE, WOSSAC2_DOCUMENT.SUBTITLE, WOSSAC2_DOCUMENT.PUBLISHER_NAME, WOSSAC2_DOCUMENT.PUBLICATION_YEAR, WOSSAC2_DOCUMENT.SUMMARY, WOSSAC2_DOCUMENT.NORTHERNMOST_LATITUDE, WOSSAC2_DOCUMENT.SOUTHERNMOST_LATITUDE, WOSSAC2_DOCUMENT.EASTERNMOST_LONGITUDE, WOSSAC2_DOCUMENT.WESTERNMOST_LONGITUDE, WOSSAC2_DOCUMENT.ONLINE_RESOURCE, WOSSAC2_DOCUMENT.BROWSE_DOC_THMB, WOSSAC2_ITEMS.SUBJECTS, WOSSAC2_ITEMS.ITEM_ID, WOSSAC2_ITEMS.SUBJECTS, WOSSAC2_ITEMS.COUNTRY_NOW, WOSSAC2_WORLD_CITIES.LONGITUDE, WOSSAC2_WORLD_CITIES.LATITUDE, WOSSAC2_WORLD_CITIES.CONTINENT, WOSSAC2_LANGUAGE_LUT.LANGUAGE_DESC FROM WOSSAC2_LANGUAGE_LUT INNER JOIN (WOSSAC2_WORLD_CITIES INNER JOIN (WOSSAC2_ITEMS INNER JOIN WOSSAC2_DOCUMENT ON WOSSAC2_ITEMS.ITEM_ID = WOSSAC2_DOCUMENT.ITEM_ID) ON WOSSAC2_WORLD_CITIES.CNTRY_NAME = WOSSAC2_ITEMS.COUNTRY_NOW) ON WOSSAC2_LANGUAGE_LUT.LANGUAGE_CODE = WOSSAC2_ITEMS.LANGUAGE_CODE_ID WHERE (((WOSSAC2_DOCUMENT.NORTHERNMOST_LATITUDE) Is Not Null)) OR (((WOSSAC2_DOCUMENT.SOUTHERNMOST_LATITUDE) Is Not Null)) OR (((WOSSAC2_DOCUMENT.EASTERNMOST_LONGITUDE) Is Not Null)) OR (((WOSSAC2_DOCUMENT.WESTERNMOST_LONGITUDE) Is Not Null)) OR (((WOSSAC2_ITEMS.COUNTRY_NOW) Is Not Null)) ORDER BY WOSSAC2_ITEMS.COUNTRY_NOW, WOSSAC2_DOCUMENT.NORTHERNMOST_LATITUDE, WOSSAC2_DOCUMENT.SOUTHERNMOST_LATITUDE, WOSSAC2_DOCUMENT.EASTERNMOST_LONGITUDE, WOSSAC2_DOCUMENT.WESTERNMOST_LONGITUDE; </cfquery> <cfreturn GetWossacWOSSACContinentDoc> </cffunction> <!--- End of function --->

84 78 <!--- Function: func_wossac_continents_map ---> <!--- Purpose: Returns Continents Map data ---> <cffunction name="func_wossacwossac_continents_map" displayname ="WossacWOSSAC Continent Map Data" hint="list of all WossacWOSSAC Map records with any type of geospatial data, latitude, longitude or country" access="public" returntype="query" output="false"> <cfquery name="getwossacwossaccontinentmap" datasource="#request.app.dsn#" > SELECT WOSSAC2_ITEMS.ITEM_ID, WOSSAC2_MAP.MAP_ID, WOSSAC2_MAP.TITLE, WOSSAC2_MAP.ALTERNATIVE_TITLE, WOSSAC2_MAP.ABSTRACT, WOSSAC2_ITEMS.SUBJECTS, WOSSAC2_MAP.NORTHERNMOST_LATITUDE, WOSSAC2_MAP.SOUTHERNMOST_LATITUDE, WOSSAC2_MAP.EASTERNMOST_LONGITUDE, WOSSAC2_MAP.WESTERNMOST_LONGITUDE, WOSSAC2_ITEMS.COUNTRY_NOW, WOSSAC2_MAP.PUBLISHER_NAME, WOSSAC2_MAP.PUBLICATION_YEAR, WOSSAC2_MAP.BROWSE_MAP_THMB, WOSSAC2_MAP.BROWSE_MAP_FULL_RES, WOSSAC2_WORLD_CITIES.CONTINENT, WOSSAC2_WORLD_CITIES.LONGITUDE, WOSSAC2_WORLD_CITIES.LATITUDE, WOSSAC2_LANGUAGE_LUT.LANGUAGE_DESC FROM WOSSAC2_LANGUAGE_LUT INNER JOIN (WOSSAC2_WORLD_CITIES INNER JOIN (WOSSAC2_ITEMS INNER JOIN WOSSAC2_MAP ON WOSSAC2_ITEMS.ITEM_ID = WOSSAC2_MAP.ITEM_ID) ON WOSSAC2_WORLD_CITIES.CNTRY_NAME = WOSSAC2_ITEMS.COUNTRY_NOW) ON WOSSAC2_LANGUAGE_LUT.LANGUAGE_CODE = WOSSAC2_ITEMS.LANGUAGE_CODE_ID WHERE (((WOSSAC2_MAP.NORTHERNMOST_LATITUDE) Is Not Null)) OR (((WOSSAC2_MAP.SOUTHERNMOST_LATITUDE) Is Not Null)) OR (((WOSSAC2_MAP.EASTERNMOST_LONGITUDE) Is Not Null)) OR (((WOSSAC2_MAP.WESTERNMOST_LONGITUDE) Is Not Null)) OR (((WOSSAC2_ITEMS.COUNTRY_NOW) Is Not Null)) ORDER BY WOSSAC2_ITEMS.COUNTRY_NOW, WOSSAC2_MAP.NORTHERNMOST_LATITUDE, WOSSAC2_MAP.SOUTHERNMOST_LATITUDE, WOSSAC2_MAP.EASTERNMOST_LONGITUDE, WOSSAC2_MAP.WESTERNMOST_LONGITUDE; </cfquery> <cfreturn GetWossacWOSSACContinentMap> </cffunction> <!--- End of function ---> <!--- Function: func_wossac_continents_image ---> <!--- Purpose: Returns Continents Image data ---> <cffunction name="func_wossacwossac_continents_image" displayname="wossacwossac Continent Image Data" hint="list of all WossacWOSSAC Image records with any type of geospatial data, latitude, longitude or country" access="public" returntype="query" output="false"> <cfquery name="getwossacwossaccontinentimage" datasource="#request.app.dsn#" > SELECT WOSSAC2_ITEMS.ITEM_ID, WOSSAC2_IMAGE.IMAGE_ID, WOSSAC2_IMAGE.TITLE, WOSSAC2_IMAGE.ALTERNATIVE_TITLE, WOSSAC2_IMAGE.ABSTRACT, WOSSAC2_IMAGE.SENSOR, WOSSAC2_IMAGE.PLATFORM, WOSSAC2_IMAGE.NORTHERNMOST_LATITUDE, WOSSAC2_IMAGE.SOUTHERNMOST_LATITUDE, WOSSAC2_IMAGE.EASTERNMOST_LONGITUDE, WOSSAC2_IMAGE.WESTERNMOST_LONGITUDE, WOSSAC2_ITEMS.COUNTRY_NOW, WOSSAC2_IMAGE.PUBLISHER_NAME, WOSSAC2_IMAGE.PUBLICATION_YEAR, WOSSAC2_IMAGE.BROWSE_MAP_THMB, WOSSAC2_WORLD_CITIES.CONTINENT, WOSSAC2_WORLD_CITIES.LONGITUDE, WOSSAC2_WORLD_CITIES.LATITUDE, WOSSAC2_LANGUAGE_LUT.LANGUAGE_DESC FROM WOSSAC2_LANGUAGE_LUT INNER JOIN (WOSSAC2_WORLD_CITIES INNER JOIN (WOSSAC2_ITEMS INNER JOIN WOSSAC2_IMAGE ON WOSSAC2_ITEMS.ITEM_ID = WOSSAC2_IMAGE.ITEM_ID) ON WOSSAC2_WORLD_CITIES.CNTRY_NAME =

85 79 WOSSAC2_ITEMS.COUNTRY_NOW) ON WOSSAC2_LANGUAGE_LUT.LANGUAGE_CODE = WOSSAC2_ITEMS.LANGUAGE_CODE_ID WHERE (((WOSSAC2_IMAGE.NORTHERNMOST_LATITUDE) Is Not Null)) OR (((WOSSAC2_IMAGE.SOUTHERNMOST_LATITUDE) Is Not Null)) OR (((WOSSAC2_IMAGE.EASTERNMOST_LONGITUDE) Is Not Null)) OR (((WOSSAC2_IMAGE.WESTERNMOST_LONGITUDE) Is Not Null)) OR (((WOSSAC2_ITEMS.COUNTRY_NOW) Is Not Null)) ORDER BY WOSSAC2_ITEMS.COUNTRY_NOW, WOSSAC2_IMAGE.NORTHERNMOST_LATITUDE, WOSSAC2_IMAGE.SOUTHERNMOST_LATITUDE, WOSSAC2_IMAGE.EASTERNMOST_LONGITUDE, WOSSAC2_IMAGE.WESTERNMOST_LONGITUDE; </cfquery> <cfreturn GetWossacWOSSACContinentImage> </cffunction> <!--- End of function ---> <!--- Function: func_wossac_distinctcontinents ---> <!--- Purpose:Return names of distinct continents in the database---> <cffunction name="func_wossacwossac_distinctcontinents" displayname="wossacwossac Distinct Continents" hint="list the distinct continents for which WossacWOSSAC data is held" access="public" returntype="query" output="false"> <cfquery name="getdistinctcontinentdata" datasource="#request.app.dsn#" > SELECT DISTINCT CONTINENT AS DISTINCT_CONTINENT FROM WOSSAC2_WORLD_CITIES; </cfquery> <cfreturn GetDistinctContinentData> </cffunction> <!--- End of Query ---> </cfcomponent> <!--- Function: func_wossacwossac_continents_mapserver ---> <!--- Purpose: Returns Values to be used in populating mapfiles for ghoereferenced spatial data---> <cffunction name="func_wossacwossac_continents_mapserver" displayname ="WossacWOSSAC Continent Document/Report Data" hint="list of all WossacWOSSAC Document records with any type of geospatial data, latitude, longitude or country" access="public" returntype="query" output="false"> <cfquery name="getwossacwossaccontinentmapserver" datasource="#request.app.dsn#" > SELECT WOSSAC2_ITEMS.ITEM_ID, WOSSAC2_MAP.TITLE, WOSSAC2_MAP.BROWSE_MAP_FULL_RES, WOSSAC2_MAP.MOST_LIKELY_SPATIAL_REF_SYSTEM, WOSSAC2_WORLD_CITIES.LIKELY_CRS_CODE, WOSSAC2_WORLD_CITIES.CNTRY_NAME, WOSSAC2_MAP.ABSTRACT, WOSSAC2_ITEMS.SUBJECTS, WOSSAC2_MAP.NORTHERNMOST_LATITUDE, WOSSAC2_MAP.SOUTHERNMOST_LATITUDE, WOSSAC2_MAP.EASTERNMOST_LONGITUDE, WOSSAC2_MAP.WESTERNMOST_LONGITUDE FROM (WOSSAC2_ITEMS INNER JOIN WOSSAC2_MAP ON WOSSAC2_ITEMS.ITEM_ID=WOSSAC2_MAP.ITEM_ID) INNER JOIN WOSSAC2_WORLD_CITIES ON WOSSAC2_ITEMS.COUNTRY_NOW=WOSSAC2_WORLD_CITIES.CNTRY_NAME WHERE WOSSAC2_MAP.BROWSE_MAP_FULL_RES Is Not Null; </cfquery> <cfreturn GetWossacWOSSACContinentMapserver> </cffunction> <!--- End of function ---> <!--- EOF: WossacWOSSACContinent.cfm --->

86 80 B-4 MapServer Wrapper Script for Web Mapping Service (WMS) written in PHP This script is a wrapper script for MapServer in implementing WMS. It hides the directory path to the CGI-executable and Mapfile from the URL GET variables. It does this by calling the mapscript and passing the path to the Mapfile to it in the code. It also specifies MIME types of the returned data. //Name: WossacWOSSAC.php //Author: downloaded from // Modified by Owonibi Michael E,, June 2007 for the WMS service //Description: Wrapper Script for Mapserver WMS implementation (hides the path to map file and CGI executable. <?php //Calling an loading Mapscript dl("php_mapscript.dll"); $request = ms_newowsrequestobj(); $request->loadparams(); //Changing all WMS parameter to OGC WMS Specification $request->setparameter("version","1.1.1"); ms_ioinstallstdouttobuffer(); //Loading map file, specifies mapfile s directory $omap = ms_newmapobj("config.map"); $omap->owsdispatch($request); $contenttype = ms_iostripstdoutbuffercontenttype(); //checking and testing returned object type and giving the returned file appropriate header if ($contenttype == 'image/png') header('content-type: image/png'); ms_iogetstdoutbufferbytes(); } elseif ($contenttype == 'image/tiff') { header('content-type: image/tiff'); ms_iogetstdoutbufferbytes(); } elseif ('Content-type: application/xml') { $buffer = ms_iogetstdoutbufferstring(); header('content-type: application/xml'); echo $buffer; } ms_ioresethandlers();?>

87 81 B-5 Python Script Returning Dynamic Google Earth Polygon KML from URL GET Variables This script creates dynamically polygon KML files from URL GET variables containing values for the polygon creation and returns the created KML directly to the Google Earth Client. #Name: kml.py # Author: Owonibi Michael #Description: Python Script to return Polygon KML file from the URL GET variables #Path to python executable file on the system #!C:\Python21\python.exe import cgi #Gets the Values passed via URL GET and assigned them to a variable url = cgi.fieldstorage() bbox = url['bbox'].value Pname = url['pname'].value bbox = bbox.split(',') west = float(bbox[0]) south = float(bbox[1]) east = float(bbox[2]) north = float(bbox[3]) polyname = str(pname) #Start a KML file to be returned dynamically kml = ( '<?xml version="1.0" encoding="utf-8"?>\n' '<kml xmlns=" '<Document>\n' '<Style id="sn_ylw-pushpin_copy1">\n' '<LineStyle>\n' '<color>ff0000aa</color>\n' '</LineStyle>\n' '<PolyStyle>\n' '<color>24ddffd4</color>\n' '</PolyStyle>\n' '</Style>\n' '<StyleMap id="msn_ylw-pushpin_copy1">\n' '<Pair>\n' '<key>normal</key>\n' '<styleurl>#sn_ylw-pushpin_copy1</styleurl>\n' '</Pair>\n' '</StyleMap>\n' '<Placemark>\n' '<name>%s</name>\n' '<styleurl>#msn_ylw-pushpin_copy1</styleurl>\n' '<Polygon>\n' '<outerboundaryis>\n' '<LinearRing>\n'

88 82 #Coordinates of the KML Polygon bounding box as a variable '<coordinates>%.6f,%.6f,%.6f, %.6f,%.6f,%.6f, %.6f,%.6f,%.6f, %.6f,%.6f,%.6f, %.6f,%.6f,%.6f</coordinates>\n' '</LinearRing>\n' '</outerboundaryis>\n' '</Polygon>\n' '</Placemark>\n' '</Document>\n' '</kml>' #End KML file and Passes values of obtained from the URL get variables to the formatting variables in the KML according in the order they appear in kml ) %(polyname, east, north, 0, east, south, 0, west, south, 0, west, north, 0, east, north, 0) #return the KML file with the application type for Google Earth, this ensures that the file opens as a GE file against opening in web browser print 'Content-Type: application/vnd.google-earth.kml+xml\n' print kml B-6 Python Script Returning Dynamic Google Earth Image Ovelay KML from URL GET Variables This script creates dynamically image overlay KML files from URL GET variables containing values for creating GE s image overlay using WMS service and returns the created KML directly to the Google Earth Client. #Name: wms_server.py # Author: Owonibi Michael #Description: Python Script to return Image Overlay KML file (which can call mapserver to return image of the area) from the URL GET variables #Path to python executable file on the system #!C:\Python21\python.exe import cgi #Gets the Values passed via URL GET and assigned them to a variable url = cgi.fieldstorage() bbox = url['bbox'].value Uname = url['url_name'].value Iname = url['item_name'].value bbox = bbox.split(',') west = float(bbox[0]) south = float(bbox[1]) east = float(bbox[2]) north = float(bbox[3]) U_name = str(uname) I_name = str(iname) #Start a KML file to be returned dynamically kml = ( '<?xml version="1.0" encoding="utf-8"?>\n' '<kml xmlns=" '<GroundOverlay>\n' '<name>%s</name>\n' '<Icon>\n'

89 83 '<href>%s</href>\n' '<viewrefreshmode>onstop</viewrefreshmode>\n' '<viewboundscale>0.85</viewboundscale>\n' '</Icon>\n' '<LatLonBox>\n' '<north>%.6f</north>\n' '<south>%.6f</south>\n' '<east>%.6f</east>\n' '<west>%.6f</west>\n' '</LatLonBox>\n' '</GroundOverlay>\n' '</kml>' #End KML file and Passes values of obtained from the URL get variables to the formatting variables in the KML according in the order they appear in kml ) %(I_name, U_name, north, south, east, west) #return the KML file with the application type for Google Earth, this ensures that the file opens as a GE file against opening in web browser print 'Content-Type: application/vnd.google-earth.kml+xml\n' print kml

90 84 APPENDIX C INSTRUCTIONS TO CLIENT/USER C-1 Using Google Earth to View Wossac Items In using the Google Earth client to view WOSSAC items, the user should follow the instructions below: Click on the network link file in any website it can be found to launch the Google Earth Viewer. This loads the five (5) continents KML files into Google Earth Places Panel. The continents are Africa, Asia, America, Oceania and Europe (see Fig. C-1). Fig C-1 Screenshot of the implementation of the system in Google Earth Click on each Continent in the Places Panel to see the Maps, Images and Documents folders. Click on Maps, Images, or Documents folder to see WOSSAC maps images or document s holdings for each continent in the Places Panel. Either Click on the name of the WOSSAC item in the places panel or the icon representing the image, map or document in the viewer to see the Placemarks information box. The information box contents for different WOSSAC items varies depending on what type of item it is and whether the particular