Publishing Cadastral Data on the web

Dynamic Publishing of Cadastral Data on the Web Using GML Model Schemas Karkanis Manousos, Roussos Ioannis, Spanaki Maria, Sellis Timoleon, Tsoulos Lysandros Cartography Laboratory, Faculty of Rural and Surveying Engineering Knowledge and Database Systems Laboratory, Faculty of Electrical and Computer Engineering National Technical University of Athens H. Polytechniou 9, 157 80 Zographou Campus, Athens, Greece tel: +30 -210-7722730 fax: +30-210-7722734 [email protected], [email protected], [email protected], [email protected], [email protected]

Keywords: XML, GML, SVG, HTML, XSLT, Java Servlet 1. Introduction 2. Cadastral Data and Web Publishing 3. Application requirements 3.1 GUI Design – Functionality 3.2 System requirements 4. Implementation 4.1 RDBMS Operations 4.1.1 Database Design Implementation 4.1.2 Querying the database 4.1.3 Extracting queried datasets in XML 4.2 XSLT Processing Flow 4.2.1 XSLT Transformations Phase (1) 4.2.2 XSLT Transformations Phase (2) 4.3 Web based application development 4.3.1 The Application’s Servlet 4.3.2 Managing System results 5. Conclusions 6. Bibliography

Abstract As web content is increasingly generated dynamically, the development of web-based dynamic applications proves to be extremely beneficial for a wide range of social, scientific and commercial activities. The term “dynamic” actually refers to database-driven applications, which allow dynamic creation of web pages from information requested from the database. Examples of web applications with this functionality include E-commerce applications such as online stores, and business-to-business (B2B) support products. The integration of a Cadastral database with the web, based on the utilization of XML technology along with Java-Servlet web to database connectivity technology is the main objective of the present study. XSLT’s latest version transforming capabilities are thoroughly investigated with the view of properly generating SVG and HTML graphical and text web formats, which serve the application’s requirements for spatial and thematic cadastral data representation. Furthermore the implementation of a web browser based interface, allowing users to access and view spatial and thematic cadastral information through the use of HTML forms, is discussed.

1. Introduction The development of a web based Cadastral Information System, which will allow dynamic publication of cadastral data on the web based on standard user criteria is properly looked into through the present study. The overall procedure of building an application with this functionality is separated into four different phases. The first phase includes quering and retrieving cadastral data being initially stored in an RDBMS used by the application. Retrieved data, which concern spatial and thematic information of different cadastral data sets, are properly exported to XML, using an export function. XML exported documents are then subjected to a series of XSLT transformations, in order to be finally converted to the required web presentation and rendering formats of HTML and SVG. The XSLT transformations logic was extensively based on the strong similarities between XSLT and SQL processing languages, the detection of which significantly led the transformation flow. Furthermore GML cadastral parcel instance documents are generated through an intermediate transformation process, allowing the interchange of the retrieved data between different database systems. The overall mechanism is finally incorporated in a client-server architecture built on Java Servlet web-to-database connectivity technology, allowing access to processed data via frontend forms.

2. Cadastral Data and Web Publishing The time and cost benefits obtained by the integration of a Cadastral Database with the web are expected to be quite significant. Applications with similar functionality have been implemented in the past. However special emphasis was given on geometric cadastral data mapping and not on displaying associated attribute information concerning other properties of cadastral entities besides geometry. These applications basically provided cadastral web maps of certain areas based on the SVG standard, allowing efficient exploitation of SVG viewer’s built-in interactive capabilities through the use of quite sophisticated graphical user interfaces. Our approach, which uses a combination of open web standards such as XML, SVG, HTML and XSLT along with the Java-Servlet platform-independent methods for building web-based applications, aims at allowing a considerably higher amount of interactivity besides high cartographical quality. SVG’s built-in interactive functions along with supported linking capabilities are fully exploited through the use of XSLT, allowing each produced geometric object’s (cadastral parcel) information to be displayed by clicking on it. Besides geometric information about each parcel, information concerning other parcel properties, like joint owners and legal status of each parcel is made available to the user. In this sense, a GIS (Geographical Information System) like functionality is provided, extending interactivity beyond SVG’s built-in panning and zooming controls. A prototype has been developed based on a cadastral data set provided by Ktimatologio S.A, in charge of the Hellenic Cadastre Project. Application core data concerning a certain municipality of Athens was delivered in the form of seven tab delimited text files and one shapefile that maintained the understudied area’s attribute and spatial cadastral data. A significant number of attribute fields did not contain any information, given that the overall land registry process for the particular municipality was incomplete at the time of implementing our prototype [1].

3. Application requirements A typical architecture of a web database application involves three levels of application logic. The application’s Database Management System (DBMS) and the database occupy the base level, while at the top lies the client web browser used as an interface to the application. Most

of the application’s logic is included between these two outer levels, usually developed with web server-side scripting languages [2].

3.1 GUI Design - Functionality The current application’s web browser based interface consists of a simple HTML frame set, allowing available query types and corresponding query forms to be displayed in a single browser window [Fig 3.1].

Figure 3.1 HTML Query Frame Set The left frame displays potential query types among which, users are prompted to select and fill in the corresponding form displayed on the right frame. Each query form contains brief information about the special type of query to be executed, while predefined default values indicate valid data types for insertion. The submission of a query results to a dynamically created HTML page, properly guiding users through the rest of the query results management process, which is thoroughly discussed on section 4.3.2. The general guidelines followed for GUI design mainly concerned: • • •

Security and input control - Prevention of invalid data input. Performance - Support for handling extended amounts of retrieved data Diverse clients and client capabilities - Ensuring that the application supports the required client browsers

Issues of data input control are efficiently handled through the display of proper error messages which indicate the validity of inserted values, while issues of authorized access control were not taken under any consideration given the fact that processed information should be accessible to every potential user. However the downloading and installation of the Adobe SVG Viewer is a prerequisite for client browsers to display the resulting SVG images. Furthermore the system’s performance

was tested against the retrieval of the total geometry of the understudied area and proved quite satisfying.

3.2 System requirements The system’s functionality is based on a typical client-server architecture built on java-servlet technology. Most of the processing management resides on the server, which consists of the following basic components: •

Apache web-server

•

Oracle 9.2.1.0 RDBMS

•

Saxon XSLT Processor version 7.9, and

•

Java Development kit 1.4 (JDK 1.4)

Apache is a powerful, flexible, extensible and highly configurable HTTP/1.1 compliant web server. It can also run on several different operating systems including Windows and most versions of UNIX. A lightweight version of the specific web server software provided with Oracle 9.2.0.1 RDBMS was employed and proved quite adequate based on the current’s application’s requirements [3]. The installation of JDK 1.4 java development environment is mandatory given that javaservlets, on the use of which database communication is based, are written in java. A Servlet is a web component managed by a container that generates dynamic content. The servlet container or servlet engine can either be built into a host web server or installed as an add-on component to a Web Server via that server’s native extension API. The latter option was employed given that the Apache web server software used by the application, did not include a built-in servlet engine. Installing JDK 1.4 is also a prerequisite for Saxon 7.9, the java based XSLT processor used by the application. Saxon 7.9 no longer works with the Microsoft Java VM, contrary to previous versions. Saxon can be used either from the command line, or invoked from a Java application by use of JAXP 1.2 API, which is included as a standard feature of JDK 1.4. The Saxon package is a collection of tools for processing XML documents. This release of Saxon is 100% conformant to the mandatory requirements of XSLT 1.0 and XPath 1.0 recommendations and implements most of the features defined in the XSLT 2.0 and XPath 2.0 working drafts. The choice of Saxon against other commercial XSLT processors providing extensions with functionality similar to XSLT’s 2.0 provided constructs, was based on interoperability issues, given that the application would then entirely depend on the use of a specific product and not on a web standard. Saxon no longer includes a built-in XML parser. The current version uses by default the XML parser supplied with the Java VM. However the use of whichever SAX2-compliant XML parser is also allowed, as long as the relevant classes are installed on the java classpath [4].

4. Implementation Implementing the prototype was a process of individually managed tasks, briefly described in the following sections.

4.1 RDBMS Operations The overall process of dynamic data publishing is primarily based on standard operations performed by Oracle’s 9.2.0.1 RDBMS, which is used by the application. The main actions taken, mainly involved: •

Inserting application data into the Oracle database

•

Creating SQL Queries based on standard criteria

•

Extracting queried datasets in XML format

4.1.1 Database design ArcInfo’s Gateway ArcSDE was used for serving data into the Oracle database. The insertion of shapefiles containing the understudied area’s geometry was a straightforward process through the use of ArcSDE. However cadastral attribute information in the form of tab delimited text files, had to be primarily converted into ArcGIS Geodatabases in order to be finally inserted into Oracle. The process of cadastral database schema creation was based on the conceptual model of the cadastral database implemented by Ktimatologio S.A, which was maintained in the context of developing the current application. Figure 4.1 displays basic cadastral entities and defined relationships that constitute the application’s relational schema.

Figure 4.1. Application’s Relational Schema 4.1.2 Querying the database Five different SQL query types were defined for retrieving cadastral parcel information from the database. The definition of individual query categories was based on standard criteria that could be used as potential inputs to the system. The system basically supports: •

Querying cadastral parcels based on the unique identification parcel code

•

Querying cadastral parcels based on the Owner’s name

•

Querying cadastral parcels based on the legal document code

•

Retrieving cadastral parcels based on a coordinate query window defined by the user

•

Retrieving cadastral parcels and adjacent parcels based on Owner’s name

The last two query types utilize Oracle’s spatial functions and operators, allowing parcel information retrieval based on spatial criteria as well. Query results include both geometric and attribute (parcel’s full ownership and legal status) information for each individual parcel belonging to the queried parcel set. Furthermore, a new database table that maintains query results, is generated through query execution. 4.1.3 Extracting queried datasets in XML Oracle 9.2.0.1 provides several options for generating – exporting XML documents both from within and outside the database. Among them, the XML-SQL Utility (XSU) mechanism and the DBMS_XML_QUERY package in particular, was chosen for extracting parcel datasets in XML [5]. XSU is utilized through PL/SQL Oracle's procedural extension to industry-standard SQL, for creating a stored database procedure that enables the transformation of data retrieved from a

relational database table into XML. The resulting XML file properties such as name, encoding and place of export are properly handled through the procedure, allowing the file’s further efficient processing. The XML output structure consists of a XML root element that encapsulates a series of sibling (elements of the same hierarchical level) elements, each one of which represents an individual database table’s record. Every element contains a series of sibling elements named after the source database table’s columns. Furthermore each child element’s content equals the corresponding table’s field content, mapping this way the relational to the XML content. The XML structure described briefly above is properly transformed through the use of the XSLT processing language with the view of mapping the relational to the XML data model. A

B

C

a1

b1

c1

a2

b2

c2

a3

b3

c3

a1 b1 c1 a2 b2 c2 …

Figure 4.2. XML Extraction process

4.2 XSLT Processing Flow XSLT is a high-level expressly designed language for manipulating XML data structures and used in particular for bridging the gap between the two superficially different data structures used in SQL and XML. Actually XSLT and SQL have a lot in common. For starters, it’s the SQL SELECT statement and the equivalent XPath expression that allow processing of specific data through the use of these two processing languages [6]. Executing the stored database procedure for translating a cadastral query’s relational content to XML, results to a rather flat output XML structure. XSLT’s 2.0 transforming capabilities are fully utilized in order for this source structure to be properly transformed into SVG and HTML. The overall transformation process is separated in two sequential phases in the form of two different sets of XSLT stylesheet documents applied to the source XML document. The transformation flow chart is displayed on Figure 4.3. 4.2.1 XSLT Transformations Phase (1) Regardless of the query type utilized, among the available ones presented on section 4.1.2, each query is designed to produce a resulting dataset that includes both:

SourceXML

XSLT Stylesheets (1)

XSLT Stylesheets (2)

GML

HTML SVG

HTML

GML

SVG SVG SVG

HTML

HTML

HTML HTML

Figure 4.3. Overall Transformation process 1) cadastral parcels (geometrical and attribute information) based on the criteria that the specific query type utilizes (owner’s name or parcel’s code etc), and 2) potential joint owners’ cadastral parcels (geometrical and attribute information) in case of cadastral parcels being composed of divided properties, such as vertical or horizontal cadastral properties, that involve more than a single owner. According to the above, besides cadastral parcels satisfying the query specific criteria, an additional cadastral dataset concerning joint owner’s parcels (only if there are any) of the primarily queried parcels, is also retrieved. Both cadastral data sets are included in the source XML document generated through database XML extraction procedure. The first phase of XSLT transformations applied, aims at discriminating the two cadastral data sets, by properly extracting an XML subset of the overall source XML document that strictly represents parcels satisfying the query specific criteria. The transformation Stylesheet used to obtain the desired output simply performs an exclusion process concerning the parts of the source tree that represent joint owner’s parcel information, while copying the rest of the source to the output tree. The resulting XML being simply a selective subset of the Source XML is then subjected into additional XSLT transformations in order for a single SVG image rendering the queried parcels and the associated with each parcel’s geometry HTML page providing attribute parcel information, to be generated. As far as SVG creation was concerned, there were several issues taken into consideration, mainly involving: Utilization of the SVG Path instead of the SVG Polygon geometric element for representing polygon geometry. The particular choice was based on the application’s requirement for representing complex polygonal surfaces such as polygons with holes, a functionality that is exclusively provided by the specific SVG construct Exploitation of SVG’s built-in mouse-over effects, allowing interactive colour alternation based on the cursor’s position upon SVG geometric objects

VIEWBOX property calculations, providing a zoom – extents like view of the generated image based on the geometrical boundaries of the queried geometry Creation of HTML pages embedding the generated SVG image, utilizing this way HTML’s flexibility in text handling, contrary to SVG which manages text as a geometric entity. HTML embedding pages provide additional textual information that guides users through the process of managing the rendered SVG objects (zooming, panning, displaying associated attribute parcel information by clicking) Creation of proper links between SVG geometric entities and associated HTML pages (HTML tables) containing attribute parcel information. The connection is based on the unique identification parcel code explicitly distinguishing different cadastral parcels, which is also used for naming the associated HTML documents. Based on this concept, a one to one connection between rendered SVG objects and associated HTML pages is established. Creating SVG is a straightforward transformation process using the first transformation’s XML output as source document. However HTML creation is based on the intermediate generation of GML (Geographical Markup Language) instance documents. GML documents serve as the standardized means of expressing queried cadastral parcels in a manner that is shareable over the Internet [7].

Figure 4.4. GML Application Schema (1) The set of objects concerning the cadastral application domain is created in the form of a GML Application schema, an XML schema that makes use of the GML 3.0 schema components and complies with the GML semantic model and syntactic rules. Applying GML’s modeling rules allows for mapping the relational data model presented on section 4.1.1 to that of GML’s, built with XML SPY and displayed on Figures 4.4, 4.5. GML also provides for a hierarchically organized document structure suitable for applying the splitting mechanism supported by XSLT 2.0 version, which is of great importance for the particular application. HTML generation stylesheet utilizes XSLT’s 2.0 “result-document” feature for this cause, allowing the creation of multiple HTML output documents from a single GML source document, based on a single transformation [10]. Applying the particular XSLT Stylesheet results to the creation of one exactly HTML table for each discrete cadastral parcel, rendered on the generated SVG image. Furthermore SVG links are created on each generated HTML table allowing it’s connection with a set of SVG images produced through the second phase of XSLT transformations (Fig 4.3).

Figure 4.5. GML Application Schema (2) 4.2.2 XSLT Transformations Phase (2) XSLT Transformations applied so far, allow for creating a single SVG image and a number of associated HTML pages representing cadastral parcels that are retrieved based on the criteria of the specific query type executed. However these parcels may involve several joint owners. Furthermore, according to query design issues previously discussed, the dataset concerning all potential additional parcel properties of each individual joint owner involved in these parcels is also available through the querying procedure. XSLT transformations included in this second phase, aim at producing a set of SVG images along with associated HTML pages, strictly representing this additional dataset. This way, the overall set of parcels related to each owner involved in the parcels rendered on the primarily generated SVG image, will finally be available in SVG format. The process followed is quite similar to that of the first phase. The XML document primarily exported from the database containing the overall dataset is subjected again to a series of transformations that mainly concerned: •

Excluding parts of the source tree that represent parcels already processed and rendered on the single SVG produced so far, and copying all other parts to the output tree. This transformation results to a replicate structure being simply a selective subset of the source XML document.

•

Grouping elements of the output document by discrete owners instances. The particular transformation known as “Nested Grouping”, utilizes XSLT’s 2.0 provided construct and allows for grouping elements representing discrete geometric instances by elements representing discrete parcel owners instances [8], [9].

•

Chunking the resulting hierarchical structure with a view of creating an SVG image per discrete owner instance element. The “Document Chunking” XSLT’s 2.0 feature is once again utilized, for splitting the source document into multiple SVG, with the application of a single XSLT stylesheet.

•

Creating multiple HTML pages through the intermediate generation of GML parcel instance documents, one per each discrete parcel rendered on each generated SVG. The process of multiple HTML creation is identical to the one described in the previous section.

The completion of XSLT transformations applied through this second phase, results to a set of SVG images and associated HTML pages strictly representing joint owners parcel properties. It should be pointed however, that each one of these SVG images is also linked to one exactly HTML page produced through the previous transformation phase, allowing the connection between products of the two sequential phases (Fig 4.3).

4.3 Web based application development The overall set of operations discussed so far is finally incorporated in a client-server architecture built on java-servlets. Servlets are an extremely popular choice for extending and enhancing Web servers, providing a component-based, platform and server independent method for building web-based applications. Written in Java, Servlets have access to the entire family of Java APIs, including the JDBC API to access enterprise databases [10], [11]. Servlets interact with web clients via a request-response model implemented by the servlet container. A general view of the basic components comprising the overall application’s mechanism is presented in Figure 4.6.

HTTP requests

Oracle database ver. 9.2.0.5

ApacheWeb Server

HTML Forms HTTP responses ServletRunner

Internet Explorer

SQL

Container

Database

Servlets

Figure 4.6 Application’s architecture 4.3.1 The Application’s servlet The Servlet program written to meet the current application’s special requirements, actually manages the series of activities described in the previous sections. Submitting a filled-in HTML form, causes the Servlet code to execute, firing the overall mechanism which sequentially handles: •

Activation of the appropriate query type among available ones, based on hidden parameters contained in each form. The series of SQL queries involved in the particular query type is then executed, using values inserted in the submitted form as query criteria and the result dataset is properly stored in a newly created database table

•

Extraction of query results in XML by properly calling and executing the stored PL/SQL procedure

•

Application of XSLT transformation stylesheets to the XML output, by calling and executing a batch file containing the overall set of XSLT transformation commands

•

Creation of a dynamic HTML page, which notifies users about the successful execution of a submitted query and also guides them through the viewing query results process

4.3.2 Managing System results The query form displayed on the right frame of Figure 3.1 corresponds to the Query Type “Query parcels and adjacent ones based on owner’s name” and allows for adjacent cadastral parcels retrieval besides parcels that involve the owner whose name was used as input. The submission of the particular form results to the screen displayed on Figure 4.7, which prompts users to view the produced output, after pointing on the successful execution of the processed query.

Figure 4.7 Query execution message Activating the View Results hyperlink results to the HTML page displayed on the right frame of Figure 4.8, which embeds the generated SVG.

Figure 4.8 HTML embedding queried SVG geometry The produced SVG renders the entire parcel set retrieved, based on the specific criteria that the particular query type utilizes. Required parcels (based on the Owner’s name) are displayed with brown color while adjacent parcel properties are displayed with yellow. The single parcel displayed in red simply reflects the mouse-over color alternation effect, given the cursor’s current position on the particular parcel’s surface. The HTML embedding SVG structure finally serves for providing additional textual information, guiding users through the managing SVG objects process. According to the directions contained on the HTML embedding page, a simple click on a rendered SVG parcel’s surface results to the HTML table displayed in Figure 4.9, presenting the legal status of each discrete cadastral property involved in the particular parcel. Furthermore, the activation of the hyperlink contained in the PROPERTY_ID cell, causes for another interlinked HTML table to be displayed (Fig 4.10), presenting the overall set of discrete owners (joint owners) involved in each parcel property.

Figure 4.9 Parcel Properties HTML Table

Figure 4.10 Ownership Status HTML Table The activation finally of the SVG link contained in each OWNER_NAME table cell, causes for an SVG image (Fig 4.11), rendering the overall set of parcels related to a particular owner, to be displayed. Parcels displayed in brown, or yellow were also rendered on the SVG image of Figure 4.8, while blue parcels concern other parcel properties of a particular owner, which were not primarily retrieved based on the specific criteria that the executed query utilizes.

Figure 4.11 Overall set of Cadastral parcels related to a specific Owner (yellow colored) Information about other parcel properties (blue parcels) of an Owner involved in the primarily queried parcels is also available by clicking on each parcel’s surface and viewing linked HTML tables.

5. Conclusions The current approach, combining a series of web-standards along with platform independent methods, aims at developing a cadastral web application, which will provide both a high level of interactivity and cartographical quality. XSLT is used as the main tool for mapping the relational database schema to that of XML’s. Although XSLT and SQL operate on two superficially different data structures, specific mechanisms provided with each one allow for the creation of similar behaviors. XSLT in particular, managing XPath’s query results, allows for traversing the source tree in a way that hierarchical structures, equivalent to SQL innerouter join mechanism results, are created [12]. Further investigation of the analogies between the two processing languages, actually led the overall transformation procedure. It should also be noted that the use of XSLT’s 2.0 new supported features was mandatory given the application’s special requirements. Furthermore the usage of XSLT 2.0 instead of XSLT’s 1.0 extensions that specific commercial processors implement, was imposed for reasons of interoperability. The developed prototype’s performance is considered satisfactory, based on the response times of quite extensive queries. However embedding the Saxon XSLT Processor in the application’s servlet is expected to improve performance and therefore recommended in the case of a future larger scale implementation. Being a pure java application, Saxon is expected to run faster when invoked from the servlet than from the command line. Furthermore the use of orthophoto maps as raster backgrounds of the generated SVGs, is also recommended with the view of enforcing graphics vividness and easing navigation.

6. Bibliography 1. http://www.ktimatologio.gr/Project.htm 2. Yuetang Deng Phyllis Frankl Jiong Wang 04/28/2004 Testing Web Database Applications Polytechnic University Brooklyn – Long Island- Wetchester Department of Computer and Information Science 3. The Apache Software Foundation http://www.apache.org/dist/ 4. Saxon 7.9.1 XSLT Processor Download Area https://sourceforge.net/project/showfiles.php?group_id=29872 5. Oracle9i XML Developer's Kits Guide – XDK Release 2 (9.2) 1.Overview of XML Developer's Kits and Components 8. XML SQL Utility (XSU) 6. Michael Kay. 2001 XSLT Programmer’s Reference Wrox 7. British Columbia-Ministry of Sustainable Resource Management,15 May 2003 Developing and Managing GML 3.0 Application Schemas Galdos Systems Inc 8. Jenni Tennison, 2004-04-03 What’s New in XSLT 2.0 9. Jinyu Wang 2004 Five XSLT 2.0 Features that Simplify XML Document Transformations Oracle Corporation 10. Weigang Zhao. 1999 A study of web-based application architecture and performance measurements School of Information Systems Curtin University 11. Andy Bailey Technical Project Director Artec Securities GmbH 2004 Introduction to Java, Part 1—Servlets 12. Didier Martin, Mark Birbeck, Michael Kay, Brian Loesgen, Jon Pinnock, Steven Livingstone, Peter Stark, Kevin Williams, Richard Anderson, Stephen Mohr, David Baliles, Bruce Peat, Nicola Ozu. August 2000 Professional XML Wrox