Collecting and publishing massive geographic data

Transcription

1 Collecting and publishing massive geographic data December 20, 2006 N. R. Brisaboa 1, J. A. Cotelo-Lema 1, A. Fariña 1, M. R. Luaces 1, J. R. Parama 1, and J. R. R. Viqueira 2 Abstract We present in this paper our experience in the development of a geographic information system that includes a large database (over seven GB) with information about infrastructure and facilities of the municipalities in the province of A Coruña (northwestern Spain). Three interesting aspects of the whole project are described in some detail due to its intrinsic interest for the development of this kind of systems. These aspects are (1) the design of the data model and the system architecture, which is oriented to support some advanced features such as multiscale active maps, (2) the problem of designing appropriate workflows to populate the database, and (3) the design of a web-based application to exploit the geographic database through a user-friendly interface. keywords Geographic Information System, Multi-scale map, Workflow, GIS Web Service. 1 INTRODUCTION Much research work has been done in the areas of Geographic Information Systems (GIS) and Spatial Databases during the last two decades. Achievements of such research effort include the definition of data models and query languages, efficient algorithms for spatial analysis (usually based on computational geometry), efficient spatial access methods and user-friendly interfaces. Based on these achievements, both commercial and open source GIS development tools [13, 17, 26, 1, 2] provide general-purpose geographic data management functionality that can be incorporated in the development of GIS applications. Spatial data types, spatial operations and spatial index structures have also been incorporated in current commercial and open source Database Management Systems (DBMS) [39, 18, 3]. Finally, recent efforts led to the appearance of standards both from the International Organization for Standardization (ISO/TC 211) [21] and the Open Geospatial Consortium (OGC) [38], which try to improve the interoperability between components of geographic information systems. Specially relevant to the purposes of the present paper are those standards that define the interface of GIS Web Services [36, 33, 35] and XML-based languages for the representation of geographic information or visual styles [34, 32]. However, the aforementioned technology is still not broadly applied in many applications despite the fact that most of the entities managed by those applications do have a position and/or shape in geographic space. One of the main reasons that dissuade small companies and small public administrations, such as municipalities, from undertaking GIS projects is the high cost and the low quality of the geographic data sets available. Therefore, the existence of geographic data sets with a reasonable quality accessible through interoperable interfaces in the World Wide Web is an important catalyst for the incorporation of GIS technology in many application areas. Important efforts in this sense are the development of Spatial Data Infrastructures (SDI). Examples of such infrastructures are the Galician SDI ( the Spanish SDI ( the European SDI ( and the USA NSDI ( In this paper, we present our experience in the development of a Geographic Information System for the collection and publication in the Web of alphanumeric and geographic data resulting from the Survey on Local Infrastructure and Facilities of A Coruña (named EIEL from the Spanish Encuesta de Infraestructura y Equipamientos Locales). At the Database Laboratory of the University of A Coruña, we designed two data collection workflows, a set of disposable applications supporting these workflows that were not intended to survive the data collection phase, and two large end-user applications: GISEIEL to maintain and manage the database, and WebEIEL to publish and browse the whole database in the Web using a friendly and easy to This work has been partially granted by MCYT (FEDER and PGE), refs. TIC and TIN C03-03 and, Xunta de Galicia ref. PGIDIT05SIN10502PR. 1 Database Laboratory, Computer Science Department, University of A Coruña. Facultade de Informática, Campus de Elviña, A Coruña, Spain. 2 Systems Laboratory, Department of Electronics and Computer Science, University of Santiago de Compostela Instituto de Investigaciones Tecnológicas, Campus Sur, Santiago de Compostela, Spain. 1

2 use interface. The project started at the end of year 2000, and ended in June 2004 with the presentation of WebEIEL ( The development of the project involved many different problems related to many different aspects. We have identified three major areas of concern and we believe that the problems included in these areas are recurrent in GIS-based systems. Therefore, they are the focus of the paper. We describe the problems that we had to face, the possible solutions we evaluated, and the consequences of the decisions we took. We believe that sharing this knowledge will help people facing similar problems. We can briefly describe each area as follows: Data Model and General Architecture of the System: Designing the data model of such GIS-based systems implies specific concerns related to the use of geographic data. For example, if maps of different scales are required, more than one representation of each geographic object is needed. On the other hand, if a commercial tool is used to develop the system, as it was our case, the functionality provided by the tool affects the system in terms of available data types, architecture of the applications or database access. Finally. it is necessary to ensure that the resulting system is interoperable in the sense that it can be used not only by human users, but also by other computer applications. We describe some of the solutions we implemented in Section 4. Data Insertion Workflow: Organizing a very large group of people to collect and digitize a large amount of geographic and alphanumeric information is not a simple task. It is necessary to design a precise workflow in order to minimize the common errors and delays. This workflow can be defined following different strategies [41]. In our case, we designed two different data insertion workflows tailored to the type and complexity of geographic and alphanumeric data that were collected by the different teams. Section 5 describes in more detail the problem of designing the workflows and the solutions we implemented. Data Visualization in Web: Web applications are a great challenge for GIS because Web users expect very easy-to-use interfaces that are difficult to design if the usual functionalities of GIS must be provided. Furthermore, the big amount of geographic and alphanumeric data in a map has to be transmitted with little delay through networks with limited bandwidth. In order to enable the browsing of the geographic information collected in our project, we developed a web-based GIS (called WebEIEL) that is available at This application creates active maps transforming the geographic representations of the collected entities into graphic elements that respond to mouse events. For example, their color changes when the mouse moves over them, or relevant alphanumeric information is displayed when the user clicks on them. Moreover, to optimize the transmission of those maps through the Internet, the application chooses the appropriate precision of the geographic representations used for each map according to the graphical scale. Summarizing, WebEIEL uses multiscale active maps that are browsed using a very friendly user interface. This application is described in Section 6. The remaining sections of the paper are organized as follows. Section 2 introduces various preliminary GIS concepts required for subsequent discussion. An overview of the EIEL project is given in Section 3. Then, various issues related to the data model and the architecture of the system are described in Section 4. Section 5 follows with a description of the two data insertion workflows and Section 6 is devoted to the description of WebEIEL. Finally, conclusions and directions of future work are given in Section 7. 2 GEOGRAPHIC INFORMATION SYSTEMS BACKGROUND A geographic information system (GIS) is a collection of computer-based tools to model, represent, store, manipulate, query, analyze, and visualize information that has a geographic component. GIS are different from traditional information systems due to some specific characteristics of geographic information, and therefore, some preliminary GIS concepts required for subsequent discussions are introduced in the following subsections. However, an in-depth discussion of these issues is out of the scope of this paper. In fact, the discussion restricts to the minimum necessary to support both the description of the system and the explanation of the design decisions. First, we describe some issues regarding geographic data modeling. Then, we present some concepts related to multiscale maps. After that, we give an historical overview of the different system architectures used in GIS applications. Finally, we briefly describe the current efforts towards interoperability of GIS applications. 2.1 Geographic Data Modelling and Management Data models for GIS classify real-world entities such as roads, rivers and population centers into Geographic Entities. The relevant aspects of the real-world entities that are meaningful in the model are represented as properties of the geographic entities. The position and shape of the real-world entities in the geographic space (Earth surface) are represented by Geographic Properties. Given that the data types of traditional conceptual 2

3 Geometry p 1 c 1 s 1 p2 c 2 s 2 Primitive CompositeGeometry GeometryCollection p 3 c 3 Point Polyline CompositePolyline Polygon CompositePolygon MultiPoint MultiPolyline MultiPolygon (a) Geometric Data Type Hierarchy c 4 p 4 c 7 p 5 c 5 c 6 s 3 c 8 s 4 c 9 p 6 s 7 s 5 s6 (b) Geometric Objects Figure 1: ISO Geographic Information - Spatial Schema. (a) (b) (c) Figure 2: Simplification of Geometric Objects. models do not support such properties, the ISO Geographic Information - Spatial Schema [20] proposes a conceptual model for geographic data types (see Figure 1(a) for a simplification of such model for 2D geometry). The vectorial representation used to define these data types is illustrated by relevant examples in Figure 1(b). Point values p 1, p 2 and p 3 are represented by tuples of coordinates (x, y) of a Coordinate Reference System defined over the underlying geographic space. Polyline values (c 1, c 2 and c 3 ) are represented by sequences of points and line segments, i.e., linear interpolation is considered between each couple of consecutive points 3. Object c 2 is also said to be a cycle. Polygon values (s 1 and s 2 ) are represented by their bounding cycles. The types described above are said to be primitive. A GeometryCollection is either a homogeneous or a heterogeneous finite collection of primitive geometries, where a single primitive can be part of various collections. Homogeneous collections are composed of primitives of the same type. Examples are a collection of streetlights (MultiPoint), an electricity network (MultiPolyline), or an archipelago (MultiPolygon). A CompositeGeometry is a homogeneous collection of primitive geometries. However, the spatial union of the primitives must be representable by some single primitive geometry, i.e., the collection must represent a connected subset of the underlying 2D space. They are used in applications where either the sharing of pieces of geometry is important or a topological structure, composed of nodes, edges and faces, has to be exposed 4. To illustrate this, polylines c 4, c 5 and c 6 might be the edges of a road network. Whereas < c 4, c 5 > are the geometry (CompositePolyline) of one road, < c 6 > is the geometry of another road and p 4 is the geometry of a junction (node of the network). Polygons s 3 and s 4 conform another example. Their boundaries, defined respectively by composite polylines < c 7, c 8 > and < c 8, c 9 >, share polyline c 8. Sharing pieces of geometry eliminates undesirable redundances, however it may cause efficiency problems since geometries have to be built from their components every time they have to be displayed. Operations to manipulate values of the above data types are proposed in [20, 30, 19]. They include predicates to test topological relationships [12, 5] such as disjoint, touch, inside, cross and overlap, operations that build new spatial objects such as spatial union, spatial difference, spatial intersection, boundary, buffer and centroid, and operations that compute numeric properties of spatial values such as distance, length, area and perimeter. Not supported by the above standards and of special interest for the purposes of the present paper are the operations for the simplification of geometric objects (see Figure 2). As a result of the application of one of these operations, various points of the vector representation of the geometric objects in Figure 2(a) are eliminated 3 Non-linear interpolation is also supported in [20], but it is outside the scope of this paper. 4 Please note that a hierarchy of topological data types is also defined in [20]. 3

4 to produce the simplified representation in Figure 2(b). A further simplification of the same objects is shown in Figure 2(c). A commonly used algorithm for such an operation is proposed in [11]. Simplified geometries have lower precision, hence they require less storage space and they can be transmitted faster over the network. More advanced operations for the generalization of geometric objects are proposed in [28]. Different subsets of the above types and operations are supported by current GIS development tools. However, these tools do not provide general-purpose spatial query languages. Data types colored in grey in Figure 1(a) are included in the OpenGIS standard [30], which is implemented in the spatial SQL of current spatial DBMSs [39, 18, 3]. However, primitive geometries cannot be shared between collections. Composite polylines (again, not sharing components) are also supported in the spatial part of the draft of the future ISO SQL Multimedia standard [19]. 2.2 Multiscale Maps The generalization of geographic data to be displayed at lower levels of scale has been a problem since the first cartographic representations. With the application of computers to cartography and more specifically with the development of map servers, the automatic generalization of geographic data became a key problem to achieve really usable GIS interfaces. Much research efforts have been undertaken on this topic. A detailed discussion of GIS generalization [29] is definitely out of the scope of this paper. Instead, only the concepts of map and multiscale map are informally introduced here to support the discussion of decisions made during the design of both the data model (Subsection 4.1) and the WebEIEL application (Section 6). Finally, three strategies to achieve multiscale maps in GIS (according to [9]) are also briefly presented below. Broadly speaking, a map consist of the following elements: Bounding Rectangle: A rectangle specifying the limits of the geographic space to be displayed. Layers: A layer groups a collection of conceptually-related geographic entities, and it is used to ease the management of the information. An example is the road network layer that includes all road-related elements. Each geographic entity is represented in a layer with a cartographic object, which includes both a geometric object (point, polyline, polygon, etc.) and a visual style (fill and stroke colors, line weights, patterns, symbols, etc.). Thus, in the road network layer, national roads might be represented as red solid polylines of weight 3. It is common to associate the same visual style to all the geographic entities in a layer of the same type. Output Format: There are two different types of output formats, raster and vector formats. Raster formats such as JPG, PNG and GIF are easier to access in the sense that they can be included in web pages without the need of plug-ins or applets. However, in raster maps geometric objects are merged in a single image and therefore they cannot respond to mouse events as they can do in vector maps (see [4] for further details). To improve the usability of GIS applications, the concept of multiscale map is very important. In these maps, the cartographic object (both geometry and visual style) that is used to display each geographic entity depends on the scale of the requested map. Therefore, for each geographic entity there is a primary geometric representation (the original geometric object) and a collection of different secondary representations for different map scales, each scale also with a relevant visual style. Three different strategies for the generation of these primary and secondary representations are described in [9], according to the way in which secondary representations are computed: Unification: Only the primary representation of the geographic entity is stored in the database. Every time a map is requested, generalization operations are applied on-the-fly to compute the secondary representation. Derivation: Every time the relevant primary representation changes, secondary representations resulting from generalization operations are computed and recorded in additional properties of the same entity in the database. Replication: Both primary and secondary representations are inserted by the user in different properties of the same entity. Therefore, generalization operations are not required. 2.3 GIS Architectures The evolution of the GIS architectures [10] is depicted in Figure 3 and briefly described next. In the first generation, geographic data was recorded in files with proprietary formats. Therefore, the integration of such data with other conventional data required the development of applications on top of the GIS, and the advantages of the use of database technology were not incorporated. 4

5 st 1 Generation nd 2 Generation rd 3 Generation Dual Architecture Layered Architecture GIS DATA GIS Tool Geographic Data GIS DBMS Conventional Data GIS GIS Tool DBMS DATA GIS Spatial DBMS DATA Figure 3: Evolution of GIS architectures. Second generation architectures, which are either dual or layered, incorporate DBMSs. In dual architectures, geographic data is efficiently managed by a geographic subsystem, whereas database technology is only applied to conventional data. Therefore, combined access to geographic and conventional data is not efficient since no global optimization of queries is possible. On the other hand, layered architectures implement GIS functionality on top of a conventional DBMS that records both conventional and geographic data. However, the efficient management of geographic data is not possible in a conventional DBMS. A spatial query language is usually missing, therefore too much programming is required for sporadic issues. Third generation architectures are based on spatial DBMSs, which include spatial data types for the attributes, spatial operations in the query language [30, 19], and spatial indexing methods. Such DBMSs enable efficient management of geographic data. Current GIS development tools [13, 17, 26] are implemented using a second generation architecture (either dual [13] or layered [17]). If a spatial DBMS is available [39, 18, 3], then some GIS development tools use a third generation architecture. 2.4 Interoperability of GIS Applications Recent developments and trends in software interoperability have supported GIS development tools that no longer implement their functionality using monolithic modules. Instead, the functionality is structured into simple and well-defined services, which are often web-based. Both the OGC and ISO have proposed a three-tier architecture composed of such services [31], and they have defined the functionality and the operations of various general-purpose web-services for different levels of the architecture. The remaining of this subsection restricts to brief descriptions of the OGC standard interfaces and languages of those web services which are of relevance for our work. Further discussion on software interoperability and on OGC web service specifications is out of the scope of the paper. A first important OGC standard interface is given in the Web Feature Service specification (WFS) [33]. This specification defines an HTTP-based interface that enables uniform access to a heterogeneous collection of data sources that contain information on geographic entities. The OGC has also defined an XML-based language to represent filters on the information retrieved from WFS data sources [37] and another XML-based language (called GML) to represent geographic information [34]. A WFS client can access heterogeneous data sources implementing the WFS standard and the original data source format and its query language are no longer important because the WFS client can use the filter language for the queries and GML for the results. Another widely-used service is the Web Map Service (WMS) [36], which enables the generation of maps in either vector or raster format from a collection of available layers. Such layers can either be local to the WMS or generated from the geographic data retrieved from other data sources, possibly WFS services. The OGC has also defined an XML-based language called Styled Layer Descriptor (SLD) [32]. This language can be used to define WMS layers by describing the source of the geographic entities and assigning visual styles to them. SLD can also be used to define different visual styles for a layer according to the map scale. Therefore, it can be used for the implementation of both the derivation and replication strategies for multiscale maps defined previously in this section. An important functionality not supported by the current SLD specification is the definition of active layers. In these layers, behavior is assigned to each geometric object so that it responds to mouse events. Active vector formats such as Scalable Vector Graphics (SVG) [47] and Web Computer Graphics Metafile (WebCGM) [46] are required to represent active maps. 5

6 2.4.1 Developing interoperability In the area of GIS interoperability, probably the main developments and efforts are within the sphere of national spatial data infrastructures (SDIs). SDIs usually represent a challenge since they may involve many different GIS systems collaborating to provide a unified spatial data infrastructure. The term of spatial data infrastructure was coined in 1993 by the US National Research Council [6]. The US Federal Geographic Data Committee (FGDC) defined SDI as the totality of technology, policies, standards, human resources and related activities necessary to acquire, process, distribute, use, maintain and preserve spatial data throughout all levels of government, the private and non-profit sectors, and academia. SDIs exist at many scales from the global to national, state, regional and local. In the last decades, many SDI programs have been developed within and between many countries at local, regional, national and global scales [27, 7, 22, 23]. In the US the FGDC coordinates the implementation of the US SDI. It included three parallel fronts: a set of standards for describing, accessing and exchanging digital data; a clearinghouse network offering on-line access to metadata; and a set of framework data sets (e.g. administrative boundaries, orthophotography, and rivers) that cover the whole country [24]. The European Union is preparing the INSPIRE directive [14], which encourages to establish a SDI to guarantee the interoperability of spatial information systems along the European Union. This SDI should serve to support both national and European policies and to enable the public to access to geographic information. There are many national initiatives in accordance with the aims of this directive proposal. For example, the Spanish SDI ( [40], which follows the INSPIRE directive proposal, the OGC standards and the rule family ISO In parallel to SDIs, in the last years, many geoportals are emerging [25]. According to Tait [43], geoportals are a web site considered to be an entry point to geographic content on the web. Of especial interest are those that provide a point of unified access to geographic data, and these data are dispersed in several servers. For example, INSPIRE has a geoportal ( providing an access point to a collection of geographic information stored in several European SDIs [16]. This interoperability is achieved through European, International and industry consensus building processes (ISO, CEN, OGC, W3C), specially those of OGC (WMS, WFS, and others). INSPIRE geoportal does not store or maintain the geographic data. These are distributed in many national SDIs (Italy, Norway, Portugal, United Kingdom, Germany, Sweden, The Netherlands, and Spain). In turn for example, Spanish geoportal ( integrates 28 SDI servers from Spain collaborating to offer 560 layers of information in a central access point. 3 E.I.E.L. PROJECT OVERVIEW In order to discover the funding needs of each municipality in Spain and to propose special action programs to balance the living conditions in the different municipalities, the Provincial Council (Diputación Provincial) of each Spanish province needs information related to the situation and condition of the infrastructure and facilities in each municipality. For this purpose, the Spanish government requires every Provincial Council to conduct, every five years, a survey on local infrastructure and facilities, (named EIEL from the Spanish Encuesta de Infraestructura y Equipamientos Locales). The data required for the survey includes both alphanumeric data and cartographic data at scales of 1:5000 for urban areas and of 1:10000 for rural areas. The province of A Coruña is located in northwestern Spain. With more than one million inhabitants and almost eight thousand square kilometers, it is densely populated with more than a hundred and twenty-five inhabitants per square kilometer. The Provincial Council of A Coruña decided to broaden the goals of the EIEL for the year More particularly, these new goals were considered: To extend the information to be collected, both in terms of the different kinds of elements to be surveyed, and the amount of information for each particular item. To reference the items surveyed to its geographical location or extent, constructing a geographic database and applications for its management. To publish the data through a user friendly GIS web application to make it available to all the citizens of the province. The published data includes choropleth maps displaying the values of some aggregated indicators of the relative condition of each municipality. These goals were achieved through a four year project carried out by the University of A Coruña. In total, the geographic location and/or shape of more than 100 different types of entities were surveyed to construct a database of about seven gigabytes of alphanumeric and geographic information. A large and multidisciplinary team of experts from the schools of Civil Engineering, Architecture and Computer Science of the University of A Coruña collaborated in this project. A large group of students from the 6

7 Civil Engineering school and the Architecture school (about a hundred people) collected the data by direct observation or interviewing the responsible staff in each municipality. These students were divided into groups, each responsible for surveying and inserting a subset of the data. Each group was directed by a group of professors from the University who were responsible for the work of the group. A coordination committee was formed by the directors of each group, the director of the Computer Science group, and staff from the Provincial Council. All the computer science issues in the project were the responsibility of our group at the Database Laboratory of the University of A Coruña. Our task was to develop all the GIS applications required to insert, maintain, manage and publish all the collected data in the Web. The insertion of surveyed data into a geographic database posed some problems that had to be solved. The process to achieve these goals was as follows. First, the data model proposed by the Spanish government for the EIEL was extended with geographic properties. Then, two workflows were designed to enable the experts to insert the information in the system using one specific workflow depending on the task they had to accomplish. Therefore, applications supporting these two workflows were implemented. The design of such workflows and our experience using them is interesting and deserve a special section in this paper. Once the database was created and populated, the following task was the development of two applications to exploit the data. The first one (called GISEIEL) is a desktop application deployed at the Provincial Council and used by its staff to visualize, analyze and keep the alphanumeric and geographic data updated. The second one is a web-based GIS (called WebEIEL) that can be accessed over the Internet at This application is more interesting due to the design of its user interface and the use of multiscale active maps in a web environment. Therefore we describe it in some detail in this paper. All the applications developed in this project were implemented using the GIS development tools provided by Intergraph, particularly Geomedia Professional [17] and Geomedia Web Map. There were two main reasons for this decision. First, special time and cost requirements for the project forced us to use existing GIS development tools instead of implementing the applications from scratch using custom-developed modules. And second, when the analysis and design of the system started in the year 2000 the relevant international standards were not mature. Besides, in our opinion, the open source components for GIS applications were not reliable enough and did not implemented the functionality we needed (e.g., multiscale active maps). In this paper, we offer a reflection about the boundaries that the use of such commercial tools can introduce in the development of GIS applications. 4 DATA MODEL AND GENERAL ARCHITECTURE OF THE SYSTEM In this section we present some significant design decisions regarding the data model and the architecture of the system. We also describe the problems we found and the restrictions we faced due to the use of a commercial tool and the lack of standards when we started the project. 4.1 Data Model and Design Problems We do not describe here the complete data model because it has more than a hundred entities. Instead, we give only a rough classification of the information recorded. Therefore, we enumerate the more significative entities that were surveyed, and we describe only the most interesting geographic information collected together with the data type used to represent it. We also give some details regarding the data model for the multiscale maps that are used in WebEIEL. Territorial Structure: This consists of information about the 94 municipalities in the province of A Coruña, their population centers (more than 4000), and their urban planning. In addition to alphanumeric attributes including information about demographics and legal status of the urban planning (editors, approval date, etc.), the data model includes, as attributes for geographic information, the border of the municipality (MultiPolygon), the border and the center of each population center (Polygon and Point respectively), and the surfaces (MultiPolygon) devoted to each land use (urban, industrial, protected, etc.). Road and Street Network: The alphanumeric data were recorded for each road of the province and for each street of each population center. Both roads and streets are split into sections whose limits are defined by changes in the attributes of the section (e.g., surface, width, condition). Both alphanumeric and geographic data were recorded for those sections. In fact, each road section is represented both as a Polyline and as a Polygon to support different analysis techniques and visualization procedures. However, each street 7

8 section is represented only as a Polygon. Currently, the database contains more than road sections and more than street sections. Waste Disposal and Street Lighting: For each population center, alphanumeric attributes with data of waste disposal and street lighting were recorded. The position of each streetlight is stored either in a MultiPoint attribute of the municipality, or in a so-called light line, which associates an amount of streetlights (numeric value) with a Polyline to avoid recording each individual streetlight. Moreover, for each dumping site, some alphanumeric data and its border and center (Polygon and Point respectively) were recorded. Water Supply System: Alphanumeric data and its geographic location (Point) were recorded for each water catchment, water purification plant, water chloration station, water tank, and controlled and uncontrolled wells. The pipes of both raw water network and distribution network are split into uniform sections (same values for material, diameter, etc.), and both alphanumeric data and the geographic location (Polyline) were recorded. Approximately water supply pipe sections were recorded. Sewage Disposal System: Similarly to the water supply system, both alphanumeric data and the geographic location are recorded for waste water depuration stations, outfalls (both Point), outlet pipe sections, sewage main pipe sections and draining pipe sections (each Polyline). Approximately sewage disposal pipe sections were recorded in the database. Facilities: Alphanumeric and geographic data were collected for each of the facilities of each population center. We recorded both its land parcel (Polygon) and its centroid (Point). Currently, the database contains information about 700 education centers, 1200 sport centers, 1000 parks, 800 culture centers and 200 health centers, among other different types of facilities. Background Geographic Information: Finally, in order to display in maps the geographic information described above, background geographic entities are also required. They include railroad lines, landmarks, hydrography elements and contour lines. In order to enable the insertion of these geographic data, attributes of geometric data types had to be added to the conventional data model designed for the EIEL by the Spanish government. Furthermore, the data model had to be extended in order to support multiscale maps. To illustrate this issue consider the relations ROAD and ROAD SECTION in Figure 4, which record respectively data of roads and their sections. Initially, the user, i.e., the expert in charge of road data insertion, inserts the alphanumeric data of both roads and road sections. Besides, using as a reference the available 1:5000 CAD cartography, both a polygon and a polyline are digitized for each road section. These geometric objects are recorded respectively on attributes surface and line1 of the relation ROAD SECTION and are the most precise representation of roads available in the database. This is clearly a replication strategy for multiscale maps(see subsection 2.2). The precision of these geographic objects is too high for small map scales. Therefore, additional spatial representations have to be computed for these maps. In our data model, all the remainder spatial representations are computed using a derivation strategy. Thus, in our example, attributes line2, line3, line4 and line5 of ROAD SECTION are computed from attribute line1 by the application of geometric simplification [11]. Similarly, attribute line1 of relation ROAD is obtained from the spatial union of all the relevant polylines in attribute line1 of relation ROAD SECTION. Furthermore, attributes line2, line3, line4 and line5 of ROAD are computed by geometric simplification of attribute line1 of the same relation. Now, the appropriate representation for a specific map scale can be chosen from all the available spatial attributes. For example, as it is shown in Figure 4, at a given scale scale1 the road N-550 is represented by the polyline g2. At scale2 the road sections are displayed instead of roads, rendering for each section the polyline recorded in attribute line5 of ROAD SECTION. Finally, at scale3 the polygons in attribute surface are displayed. Subsection 6.3 describes the data model that enables the definition of multiscale maps, particularly which attributes of which relations are displayed at each scale. However, it is important to notice that the cartographic generalization implemented is very simple and automatic. In particular, only geometric simplification and centroid computation was done. Besides, the selection of the amount of simplification suitable for each scale was a matter of trial and error at some specific representative geographic areas. Therefore, distortions and inconsistences of the data, such as overlapping municipalities may be visible at some scales. The reasons for these decisions will be explained in Section 6. Some problems arose in the implementation of the above data model using the general-purpose GIS development tool Geomedia Professional. The first problem was that the data types supported by Geomedia Professional do not correspond to those defined by the standard proposed by ISO [20]. The only types supported by Geomedia Professional are Multi- Point, MultiPolyline, MultiPolygon and GeometryCollection. Therefore the required Point, Polyline and Polygon attributes had to be replaced by the relevant homogeneous geometry collections. For example, a Multipoint 8

9 ROAD code type... line1... line5 N-550 national g1 g2 derivation derivation ROAD_SECTION g2 code condition... surface line1... line5 N-550 good g3 g4 g5 N-550 fair g6 g7 g8 N-550 bad g9 g10 g11 g11 g8 g6 g6 scale3 g5 scale2 replication derivation scale1 Figure 4: Multiple Spatial Representations for Multiscale Maps. value had to be used instead of a Point value to record the position of water catchments. As a consequence, the implicit validation mechanism that avoids recording two or more points as the geometry of a single water catchment is lost with such implementation. The validation mechanism had to be implemented in the GIS applications developed to insert the geographic data. Another problem was that two or more pieces of geometry cannot be shared between geometric objects using the data types provided by Geomedia Professional. Thus, the boundary that is shared between adjacent geometry objects has to be recorded twice. This is the case of the boundary of population centers, municipalities and urban planning areas, the geometry of road sections and elements of the hydrography. Inconsistencies arise as a consequence of such redundant data. For example, when the boundaries of the municipalities are simplified, holes and overlapping areas appear between adjacent municipalities due to different simplifications performed at both sides of the boundary. A final problem was that, even though database tables with two or more geometric attributes are supported by the data model of Geomedia Professional, only one of them is considered the main geometry. The end-user interface of Geomedia Professional only supports spatial analysis using the main geometry of a table. Therefore, if some spatial analysis has to be performed between geometric attributes that are not the main geometry of a table, a program has to be written to implement it. 4.2 System Architecture In this subsection, we describe the architecture of the applications we developed and the problems we faced due to the use of a specific commercial tool to develop the system. We divide this description in two parts. In the first one, the architecture of the applications for data insertion and update is depicted. The second part is dedicated to the architecture of WebEIEL where no data updates are needed Architecture for Data Insertion and Update Applications The client-server architecture of the applications that support the data insertion workflows is depicted in Figure 5. This architecture is also used for the GISEIEL application, developed to maintain the whole database. In the server side, a conventional DBMS is used to manage all the databases required for the workflows. In the client side, conventional applications access alphanumeric data through a conventional data access library. Such a library is also used by GIS applications to access alphanumeric data. Regarding geographic data, GIS applications make use of the functionality provided by the libraries of a GIS development tool to access, manage and visualize it. Finally, end-user GIS and CAD tools are also used directly in some specific tasks of the workflows. Ad-hoc commands were developed to adapt the functionality of the end-user GIS tool to the specific task. We will describe in more detail the design and relationships of the different applications for data insertion in Section 5, which is devoted to the description of the data insertion workflows. For the implementation of the components of the above architecture we used the following commercial solutions. Intergraph Geomedia Professional provided both the GIS development tool library and the enduser GIS tool. ADO/OLEDB was used to access the conventional data. Bentley Microstation was the chosen end-user CAD tool. All the databases were implemented in Microsoft SQL Server. Finally, the modules and applications of the architecture were installed in one server and 30 clients. 9

10 CLIENT Conventional Applications Conventional Data Access Library GIS Applications End-User GIS Tool GIS Development Tool Library Ad-hoc Commands End-User CAD Tool CAD Files Conventional Database Management System SERVER Base Cartography Database Geometric Objects Database Data Insertion Database EIEL Database Figure 5: Client/Server Layered Architecture of the Developed Data Insertion GIS. Some important remarks related to the architecture of the data insertion applications are the following. First, the efficiency problems of second generation GIS architectures (see Section 2.3) appeared in the application when geographic operations were applied to large amounts of geographic data. Given that these operations cannot be performed by the conventional DBMS, the data had to be transmitted from the server to the client in order to be processed. Moreover, in some cases the computed results had to be transmitted back to the server in order to be recorded in the database. The use of a third generation architecture with a spatial DBMS would have avoided such problems since spatial operations could be expressed directly in SQL and executed in the DBMS. This would have also avoided the need to code many ad-hoc programs and Geomedia Professional commands. A second remark concerns the centralization of all the data in a single server. To digitize the position of a single streetlight, many other background geometric objects (roads, buildings, hydrography, etc.) had to be retrieved from the database and transferred to the client. These objects were only used as a reference and were never going to be updated. Therefore, recording redundantly in each client those elements that never change would have improved drastically the efficiency of the system Architecture of WebEIEL: Interoperability Concerns The web-based GIS application used to publish the information on the web (WebEIEL) is presented in more detail in Section 6. However, the use of the GIS development tools provided by Integraph influenced the architecture of this application and therefore we present here some brief remarks regarding this subject. Figure 6 gives an overview of the application architecture. The main difference with respect to the architecture of a standards-based application is that in the latter, the tiers of the architecture are completely independent and they only interact at the interfaces. However, the functionality of the tiers in WebEIEL was implemented using Intergraph Geomedia Web Map, which is structured using a single monolithic software module. This forced us to implement all the functionality that is not provided by Geomedia Web Map as an additional software tier on top of the product. These differences caused the following problems in WebEIEL: Flexibility. The architecture of the application cannot easily accommodate changes in the requirements. The functionality of the architecture is implemented in a single module with proprietary interfaces that are highly-interdependent. Therefore, it is not possible to change only parts of the system when the requirements vary, or to use third-party modules for specific problems. Reusability. Given that GIS development tools often define proprietary interfaces to access their functionality, custom-developed modules for a GIS application implemented using a GIS development tool cannot be used with an application developed using a different GIS development tool. This is because the modules are forced to use the proprietary interfaces, which are not present in other GIS development tools. Similarly, the information storage format is usually a proprietary one. The result is that the application is too heavily integrated with the technology and cannot be ported to other software platforms. Efficiency problems. Given that the functionality of the application has been implemented by the commercial product using a monolithic module, additional modules cannot be integrated at the appropriate places in the architecture. These problems are common to many GIS development tools. Traditionally, the main interest of vendors of GIS development tools has been to offer additional functionality as fast as possible, and to capture clients 10

11 Web Browser Presentation Functionality Map Display Plug-in Internet Web Server: Internet Information Server Activity Module Presentation Layer Application Logic Layer Data Layer Style and Generalization Module Geomedia Web Map DBMS: MS SQL Server Database Figure 6: WebEIEL Architecture. in such a way that they cannot switch to competitors. Building interoperable systems has not been a major concern until a few years ago. Nowadays, the vendors of GIS development tools are realizing that users and developers prefer open and modular tools over closed and monolithic ones. 5 DATA INSERTION WORKFLOWS There were three reasons that made us worry about the complexity of surveying and inserting the data: Creating a geographic object can be a very long and complex process. For instance, digitizing a municipality border can take hours. There were many different types of entities, and many different attributes to be surveyed and recorded for each type of entity. More than a hundred people were involved in the survey and insertion processes. Given these problems, defining and implementing a workflow for the process was mandatory. According to [41], two opposite strategies can be used to split a process into a sequence of tasks, namely Assembly Line and Once and Done. An Assembly Line strategy divides the work to be done into many very specialized tasks. The procedures that each task involves are homogeneous, and hence they are simple. Therefore, training is minimized and, in general, staffing is flexible because most of the tasks are simple, only some tasks require specialized skills or complex training. Additionally, due to the fact that there are many simple tasks, the delegation of responsibility is also minimized. On the other hand, a Once and Done strategy divides the work into a few complex tasks that involve heterogeneous procedures and require many different skills. Therefore they require highly trained staff able to handle more different procedures to perform the task and more training and delegation of responsibility. However, the overhead of the overall process is reduced since work has to be moved between fewer steps. As a consequence, less time is lost waiting at each step and chances to either lose or misplace work are also reduced. In practice, the characteristics of the work to be done must guide the election of the strategy, and a mixed solution is the best choice in many cases. In our project, we analyzed the tasks to be performed and their difficulty and we found big differences in the complexity among the digitization tasks of some entities. For instance the digitization of a pipe could be done very easily compared with the digitization of a council boundary. Therefore, we decided to design two different workflows each following one of the sketched strategies. 11

12 In the Once and Done-style workflow, after surveying the data over the field in a council, each student digitized both the geographical and the alphanumerical data at the same time. In general, the digitization of entities with simple geographical data (point or short lines) followed this workflow, but the overall task was complex because it involved not only the geographical digitization but also the alphanumeric data insertion. On the other hand, in the Assembly Line-style workflow the digitization of the geographical data was done separately of the insertion of the alphanumeric data, and therefore all the data of each entity needed to be linked in a posterior task. In general, the digitization of entities with complex geographical data (surfaces or complex polylines) followed this workflow. Students specialized in geographic digitization only inserted this type of data in the database, whereas other student performed the easy alphanumeric insertion and the linkage of geographical and alphanumeric data. All tasks were supported by specific applications that we developed. 5.1 Description of the Workflows The Civil Engineering and the Architecture students and professors were divided into four groups: Cartography Group (almost 40 people). They imported the available 1:5000 CAD cartography from the source DGN format to the spatial database and repaired all errors that they found. They were also in charge of digitizing all the geographic data except those related to the Water Supply System and the Sewage Disposal System, which was digitized by the Water Cycle Group. Water Cycle Group (about 10 people). They were responsible for the collection and insertion of all the data relevant to both the Water Supply System, and the Sewage Disposal System. Road and Streets Group (more than 40 people). They were responsible for the collection of all the information regarding roads, streets, waste disposal and street lighting. They also had to insert the alphanumeric data that they collected, and link them to the corresponding geographic data inserted by the Cartography Group. Facilities Group (more than 20 people). They were responsible for the collection of the information related to the territorial structure and the facilities. They also had to insert the alphanumeric data that they collected, and link them to the corresponding geographic data inserted by the Cartography Group. All the data collected by the Road and Street Group and the Facilities Group were inserted using an Assembly Line-style workflow. That is, the people in those groups collected the data visiting each municipality and then they inserted the alphanumeric data while people in the Cartography Group digitized the geographic data. On the other hand, the Water Cycle Group inserted their data following an Once and Done-style workflow. In Figure 7, both workflows are presented. The six different tasks are represented as columns with the task name at the top. The tasks performed by each group are denoted by rectangles. The name of the group in charge of the task is in the top part of each rectangle. When there is an application that supported the task, it is given in the bottom part of the rectangle. The figure also represents the different databases that we used at each stage. We will now describe each one of the tasks: Cartography Importing Task: Only people in the Cartography Group worked in this task. The objective of this task was to generate geometric objects from the available 1:5000 CAD cartography (in DGN format). Those objects were recorded in a geographic database in the proprietary format of Geomedia Professional. This task required the use of tools to clean up the cartography, fixing common problems such as line undershoots and overshoots, and to import the resulting geometric objects into the appropriate tables of the database. Microstation, a commercial CAD tool, was used to manage the CAD cartography, and Geomedia Professional was used to clean up and import the CAD cartography into the Base Cartography Database. Various ad-hoc commands that extended the functionality of Geomedia Professional were developed to ease the work of the Cartography Group. Printing Maps and Forms: The people that performed the survey needed some maps and forms to write down the data collected in the survey. The head of each group was in charge of printing them for each group according to the schedule of councils to be surveyed each week. Notice that maps were printed from the original CAD cartography. Data Surveying Task: Students of all groups, except those of the Cartography Group, surveyed the data. Obviously each group collected those data in its field of specialization. A careful planning of visits to the different councils was prepared in order to avoid delays in the schedule. Data collectors visited each municipality to obtain both alphanumeric and geographic data. In particular, alphanumeric data were filled in paper forms and geographic references were sketched in paper maps (both printed in the previous step). 12

13 Cartography import Map and forms print Field survey Aphanumeric insertion and geographic digitalizarion Data validation Data generation Head of Water cycle Group Geomedia Professional Water cycle G. Water cycle G. Water cycle application Head of Water cycle Group Water cycle validation application Temporal database Water cycle validation reports DGN CAD files Cartographic group Geomedia Professional Microstation Ad hoc commands Base cartography database Heads of Facilities and Roads & Strees Group Geomedia Professional Roads-Streets G./ Facilities G. Cartographic G. Geographic data digitalization Geographic digitalization application Cartographic object Temporal database Roads & Street G./ Facilities G. Linkage of geographical and alphanumeric data Head of Roads & Street G./ Facilities G. Validation application of Roads & Streets / Facilities Computer science Group Data generation application EIEL database Alphanumeric database Roads & Street G./ Facilities G. Geographic data digitalization Geographic digitalization application Roads-Streets linkage application and Facilities linkage application Validation reports of Roads & Streets/ Facilities Figure 7: Once and Done and Assembly Line Data Insertion WorkFlow Strategies. Data Insertion Task: This task was performed in a different way in each workflow. In the Once and Donestyle workflow, followed by the Water Cycle Group, the same person inserted at the same time the alphanumeric and the geographical data. They used the Water Cycle Data Insertion Application that allows the insertion of both types of data at the same time. In the Assembly Line-style workflow, people in the Cartography Group digitized the geographic data from the sketched maps, while the people who performed the survey introduced only the alphanumeric data. After the introduction of both the geographic and alphanumeric data for a specific entity, the person who inserted the alphanumeric data linked the geographic representation of each entity with its alphanumeric data using a specific Linkage Application. Initially, the precision required for the data was the one imposed by the Spanish government, i.e., spatial data to be printed at 1:5000 scale in urban areas and to be printed at 1:10000 scale at rural areas. The available 1:5000 cartography resulting from the Cartography Importing Task was used as the basis for the digitation of the required geographic data, both in urban and rural areas. The precision of such 1:5000 CAD cartography directly determined the spatial precision of the whole database. Data Validation Task: Once all data were introduced, a validation procedure was applied to analyze the data for completeness and correctness. This procedure was supported by a Data Validation Application for each of the groups and it was used by the head of the group. The validation procedure consisted of a collection of simple checks that were performed in a batch way. For example, each road section was checked to see whether it was connected to another one, and schools were checked to ensure that the number of students was a positive number. Beyond the automatic validation tests, the head of each group was responsible also of the verification of the quality of the data, i.e. its fitness for use. The result of the validation task was a Validation Report that was used by the person who previously introduced the erroneous data to correct the errors. The revision procedure was different in each workflow because the correction of data follows the same workflow of the data insertion. Data Generation Task: Derived data required for the survey were automatically generated by a batch process that was executed after the validation. To perform this task in an automatic way, we developed the Data Generation Application. The data generation procedures carried out by this batch application vary from simple operations on numeric data to complex calculations involving spatial operations. The former were directly implemented as SQL statements, whereas the latter required specific and complex applications. For instance, one procedure was developed to compute kilometric points and place them in the appropriate 13

14 coordinates of each road. Only people in the Computer Science Group were in charge of that task. The result of this task was the generation of the final geographic database of the EIEL project. 5.2 Evaluation of the Workflows It is clear that having a specialized Cartography Group was mandatory due to the complexity of importing and repairing the existing cartography in CAD format. Furthermore, it was sensible to use these trained people to digitize the complex geometries of the entities related to territorial structure, roads and streets. Therefore, we decided that it would be more efficient that the Cartography Group took charge of the digitization of all the geometries surveyed by the Facilities Group and by the Road and Streets Group. Similarly, we decided to use with these groups an Assembly Line-style strategy. As a result, the training of each student was minimized and it was feasible to incorporate new people into the workflow with a reasonable cost. On the other hand, the geometries to be digitized by the Water Cycle Group (mainly lines and points) were much simpler than those of the other two groups. This allowed the same person to handle both the geometric and alphanumeric data insertion. Therefore the overhead of the overall process was reduced with a reasonable training effort. It is worth noticing that the complexity of the geometries to be digitized was the main factor considered to choose the workflow strategy. After the project, it was clear that the Once and Done strategy was more efficient. Much time was wasted both by the Facilities Group and the Road and Streets Group waiting to start the linkage procedure because the Cartography Group did not end the digitization of the geographic data in time. On the other hand, many errors occurred in the digitization because the person that performed the task had to work using a sketch difficult to understand because it was done by someone else. Finally, even tough the linkage procedure was easy and fast because of the friendly linkage application that we developed, the time required by this task was completely saved in the Once and Done strategy because both the alphanumeric and the geographic data were introduced in the database at the same time. As a conclusion, we can say that in GIS projects an Assembly Line-style workflow strategy, specializing the data insertion task in geographic data and alphanumeric data tasks, is only useful the digitation task is difficult and suitable training for all workers is not possible. 6 VISUALIZATION OF GEOGRAPHIC INFORMATION: THE WEBEIEL There were three important requirements necessary in order to make the collected information available to all citizens. The first requirement was that the application had to be easily accessible from any computer. Therefore, a web-based GIS accessible over the Internet was developed. The second one was that the application had to be easy to use by non-expert end-users. Hence, a trade-off between functionality of the application and complexity of the user interface had to be reached. Moreover, a multilingual system had to be developed (Galician, Spanish, and English). Finally, the third requirement was that the bandwidth to access the application over the Internet was limited. Therefore, a compromise had to be reached between the amount and precision of the geographic information displayed and the bandwidth required to transfer it through the Internet. Among the strategies implemented to accomplish the requirement of building a user-friendly application, we can mention the following: The generated maps are active in order to provide the user with additional information when the mouse is moved over the map. Therefore a vector format is required for their representation (see relevant discussion in Section 2.4). The map contents must be appropriated for the map scale in order to control the density of information in the map and to avoid an overload that would lead to a cluttered map. Moreover, the appropriate symbolization for a layer is automatically chosen according to the map scale. For instance roads are represented as lines at small scales and as surfaces at large scales. Finally, the number of layers available to the end-user is limited. Hence, finding the layer relative to a particular topic is not difficult. With the same objective, similar layers are grouped into categories. In order to avoid the user the burden of defining the contents of a map from scratch, a number of predefined maps were created. Nevertheless, advanced users can create their own maps from those previously defined by adding and removing layers. Finally, the user interface of the application is intuitive and friendly. Many tasks are performed in the same way, which leads to a moderate learning curve. 14

15 (a) Accessing the Map Browser (b) Map Browser User Interface Figure 8: WebEIEL User Interface. To reach a compromise between the map quality and the map size, the following strategies were implemented: Simplification techniques were applied to the geographic entities in order to reduce the complexity of the geographic objects (see relevant discussion in Section 6.3). The appropriate representation was chosen for each geographic object according to the map scale. For instance, at small map scales, facilities are represented as points, whereas at large map scales, surfaces are used for the representation. It can be seen that many of these techniques require the implementation of a module for multiscale active maps. We describe these issues in more detail in the following sections. First, we give a brief description of the functionality of the user interface. Then, we present the architecture of the application, and we end this section with a description of the data model that supports the implementation of multiscale active maps. 6.1 WebEIEL Map Browser The WebEIEL user interface enables the user to browse the collected data in a multi-language (Galician, Spanish and English) web-based application. In order to access the browser, the user must first choose a predefined map and a range of visualization (province, municipality or village) in the window shown in Figure 8(a). Then, the map browser interface appears (an example is shown in Figure 8(b)). This map browser displays the selected map in ACGM format [46] in an applet in the center of the window. Some legends grouping the different available layers are displayed in the left part of the window. By clicking in any legend, the map browser interface displays the layers grouped into such legend (the last legend of Figure 8(b) is opened and then, it shows its 8 layers). For each layer, the map browser interface shows its name in the current language, an icon representing its style and a check box that allows the user to make visible or not the corresponding layer. General information about the current map is displayed in the bottom part of the window. It includes an overview map, the coordinates of the bounding rectangle, and the current scale. Finally, a toolbar in the top of the window provides typical map browser functionality, such as zooms, movements, measurements of distances and areas, refreshing the map and printing the map in a PDF document. The use of most of the above functionality implies subsequent requests of new compressed ACGM maps. The user can also visualize a number of choropleth maps of the province that illustrate the relative condition of each municipality with respect to a specific infrastructure, facility or service. These maps can also be downloaded in PDF format. Finally, predefined maps and reports are made available in PDF format to be viewed and downloaded. These documents consist of reports containing all the alphanumeric data, thematic maps covering the complete province at scale 1:10000, and thematic maps of each population center at scale 1: WebEIEL architecture The architecture of the WebEIEL application was designed to fulfill the requirements given at the beginning of this section. Figure 9 shows the final architecture of the application. It consists of two different subsystems: a server-side application that runs on a specific web server, and a client-side application that runs inside the web browser, using a Java applet and Dynamic HTML (DHTML). Geographic information is stored in the read-only Web EIEL Database. A Web Map Server is in charge of generating maps from such geographic information. Vector maps are required to display data on the web browser and raster maps are used to include in printed 15

16 CLIENT Web Browser Vector Map Applet HTTP Request [(DHTML + Compressed Vector Map) Printed Document] Web Server WebEIEL Map Browser End-user Interface SERVER Map Request [Compressed Vector Map Raster Map] Multiscale Active Map Generation Module Map Request DBMS [Vector Map Raster Map] Data Access Library Web Map Server Map Definition Repository Web EIEL Database Figure 9: Architecture of the WebEIEL Map Browser. documents. Regarding the vector format, it should support some kind of activity, i.e., changing visualization styles, displaying tooltips on mouse movements and executing client-side scripting functions on mouse clicks. In order to generate multiscale active maps from the data recorded in the Web EIEL Database, a Multiscale Active Map Generation Module is required on top of the aforementioned Web Map Server. A request to this module consists of a bounding rectangle, which defines the geographic borders of the map request, the size of the retrieved map in the output interface, and a collection of layer names. With these data, our module builds and issues a request to the Web Map Server. Multiscale maps are always in a vector format and they are compressed to speed up its transmission over the Internet. The definitions of the multiscale active layers supported for the construction of multiscale active maps are recorded in a Map Definition Repository, whose data model is described in the following subsection. The user interface of the application is partly implemented on the server-side using Active Server Pages (ASP), and on the client-side using DHTML and a Java applet. The server-side of the user interface is responsible for the map generation procedure described above. The client-side of the user interface manages the user interaction using DHTML and displays the maps using a Java applet. The implementation of the above architecture was driven by the following decisions. Intergraph Geomedia Web Map was used to implement the Web Map Server. The format of the vector and raster maps is respectively Active CGM (ACGM) and PNG. The reasons that guided the decision of using Intergraph Geomedia Web Map were two. First, at the beginning of the project (year 2000), tools implementing the OGC standards WFS and WMS, such as Geoserver, MapServer and Deegree, either did not exists or were not mature enough. Second, neither of the above tools enable the generation of active maps, which are a requirement of the system. Therefore, at that time Intergraph Geomedia Web Map provided a reliable solution for the generation of active maps with a reasonable cost both in time and human resources. The migration of the system to an open architecture based on standard OGC web services is currently an undergoing piece of further work (see Section 7). The Web EIEL Database is stored in files using a read-only proprietary format designed by Intergraph named SmartStore. This format was used because it includes a spatial access method that speeds up spatial queries and data retrieval. The Microsoft Jet Database Engine together with ADO/OLEDB data access libraries were used to access the Map Definition Repository. The multiscale functionality of the Multiscale Active Map Generation Module resembles the one provided by a standard OGC WMS equipped with SLD functionality. However, two reasons disallowed the use of a WMS-SLD tool. First, neither the SLD specification nor tools supporting it were available at the beginning of the project (year 2000). Second, SLD does not support the inclusion of activity in the defined layers (see Subsection 2.4). The definition of an Active Web Map Service (AWMS) based on the extension of SLD with activity functionality is current research work of the group. The incorporation of these research results to the EIEL project is also a piece of further work. Finally, the platform for the implementation of all the server-side components of the architecture was Microsoft Internet Information Server with Active Server Pages (ASP). The election of this platform was derived from the previous election of Intergraph Geomedia Web Map. Vector active maps are displayed in the web 16

17 LayerGroup Name : NameType Position : Integer 1 1..* Layer Name : NameType 1..* 0..* Map Name : NameType 1 1..* ScaleRange * * MinScale : Long MaxScale : Long Scales Feature Database : String Table : String GeoAttribute : String Filter : String ClickAction : String ToolTip : String Priority : Integer 1 1 Style Style 1 Highlight 1 Figure 10: Data Model of the Map Definition Repository. browser in the JMapView ACGM applet developed by Intergraph. 6.3 Data Model for Multiscale Maps Given that Geomedia Web Map provides no support for the generation of multiscale active maps, we designed a module for this task. Figure 10 shows a UML class diagram of the data model that supports the module. The main design goal of this module was to define multiscale active maps while hiding their complexity from the end-user. That is, we wanted the end user to manipulate a single layer (e.g., road network) even though geographic entities of various types (highways, national roads, etc.), each of them possibly with various geometric representations (point, polylines and polygons), were retrieved from the database and associated to different visual styles according to the requested map scale. This was achieved using two different classes: Layer and Feature. The class Layer represents a cartographic object, that is, the abstraction that represents a collection of information for the end user. For example, the layer national roads represents all sections of roads managed by the State. This layer can be used to display or remove all national roads in the user interface. Each layer is composed of a collection of objects of the class Feature, which represents a collection of geographic objects retrieved from the database. Each feature contains the definition of a geographic object to be retrieved from the database (database name, table name, and geometry attribute name), styling information, the scale ranges when this feature is visible, and the Javascript functions that have to be executed when the user clicks on the geographic objects in the user interface. As we described in Subsection 4.1, a single feature might have multiple spatial representations. Thus, for example, the Layer national roads, for scales smaller than 1:15000, is represented by a polyline with blue color, whereas when the scale is larger than 1:15000, the associated representation to national roads is a polygon with blue color as well. Layers are organized in categories (LayerGroup) that are used in the user interface to avoid presenting the user a long list of layers. Finally, the class (Map) represents a multiscale active map by aggregating a collection of layers. As a final remark, in order to support multiple languages in the user interface, a collection of names is associated to each layer, layer group and map, one for each of the languages supported by the application (currently Galician, Spanish and English) Currently, 6 maps and 104 layers organized in 12 layer groups are available in the WebEIEL. These layers make use of more than 650 features, each of them visible at one or various of the 10 available scale ranges. To illustrate the above data model let us consider the multiscale active map depicted in Figure 11 at four different scales. This map includes layers for the municipalities, population centers, various categories of roads (toll highways, national roads, autonomical roads, provincial roads and municipal roads classified by their material), streets classified by their material, contour lines and buildings. Figure 11(a) shows the map at municipality scale (approximately 1:70000). The features for this scale render the municipalities, population centers and roads (except municipal roads). Some population centers are rendered as points and some other are rendered as polygons, depending on their population. Polylines are used to render the roads at this scale. Figure 11(b) shows the map at settlement scale (approx. 1:14000). Features are defined to render all the population centers as polygons. Roads, including municipal ones, are now rendered as polygons. At village/settlement scale 17

18 (a) Municipality Scale (b) Settlement Scale (c) Village/Settlement Scale (d) Street Scale Figure 11: Multiscale Active Map at Four Different Scales. (approx. 1:6000) (see Figure 11(c)), street sections (classified by material) and contour lines every 25 meters are added automatically by the system to the map. The tooltip of one of these street sections is also shown in the map. Finally, buildings and contour lines every 5 meters are added to the map at the street scale (approx. 1:2000) (see Figure 11(d)). The screenshot shows also the alphanumeric data of a road section, displayed as a result of a mouse click. As a final remark, the administrator of the Map Definition Repository is the responsible of choosing the appropriate spatial representation of each feature to display at each scale of each map, i.e., it is responsible of the quality (fitness for use) of maps at non-data collection scale. A high quality of those maps was not an objective of the project, since they were build just to achieve an efficient navigation through the vector geographic data with a limited bandwidth. 7 CONCLUSIONS AND FURTHER WORK The experience of developing of a GIS for the collection and web publishing of a large amount of alphanumeric and geographic data was presented. A conventional data model was extended with attributes of geometric data types and various geometric attributes were inserted in some tables, following a hybrid Derivation/Replication approach for multiple representation. The objective of such multiple spatial representation was only the optimization of the bandwidth during the navigation through the GIS user interface, therefore advanced generalization techniques were not used. Limitations derived from the implementation of such model in Geomedia Professional were also identified, including unsupported geometric data types, the lack of complete support for various geometric attributes per table and the lack of composite geometry data types that made it impossible to share geometries between objects. Some of the problems that were found in the project are derived from the use of a commercial GIS development tool. These problems would not have appeared if we had implemented the functionality from scratch in custom-developed modules. However, this required much more time and resources. In the end, in this type of projects, there is always a trade-off between development time and cost and functionality that has to be carefully analyzed. A second generation centralized GIS architecture was used to develop the data insertion GIS applications. Limitations derived from the use of such an architecture were also discussed, including efficiency problems and the lack of a spatially-enabled general-purpose query language that forced a large amount of programming. Furthermore, we did not use international standards in the implementation of many modules of the system because they were not mature or even defined when the project started. This has caused some interoperability problems that are currently being solved. Two different data insertion workflows were implemented by a collection of data insertion GIS applications. 18