Home Articles Oracle 9iAS map viewer

Oracle 9iAS map viewer

Liujian Qian, Frank Lee, and Jayant Sharma
Spatial Products, Oracle Corporation
1 Oracle Drive, Nashua, NH 03062, USA
{lj.qian, frank.lee, jayant.sharma}@oracle.com

Introduction
Geographic data has traditionally been managed in proprietary files and displayed using special GIS applications. Oracle Spatial, a component of the Oracle server since, provides an open geographic data management solution. MapViewer complements Oracle Spatial by providing a generic web-based means of delivering and viewing any geographic data managed by Oracle Spatial. E-business applications developed by Oracle and other parties can now better utilize the massive amount of geographic data available. Location-based services developers, local public data publishers, and other users can easily integrate MapViewer into their web-based solutions.

A map request submitted to MapViewer must contain a data source name, a map name, a location indicating the center point of the map, a map size or scale, and a result format. The data source and map name identify the map metadata.

Mapping metadata is crucial in determining the looks and styles of generated maps. It includes map symbols, text fonts, area and line patterns, styling rules that associate spatial tables with map layers or themes, and base map definitions. Different users can define their private metadata, or can share other user’s mapping metadata. For instance, an organization can define a set of commonly used map symbols to be shared by many departments’ users. Each department can then define its own map layers and base maps using the shared map symbols. The Map Definition Tool is a standalone Java program that should be used to create, modify, and manage a user’s mapping metadata stored in a database.

The remainder of the paper is structured as follows. Section 2 describes how MapViewer is accessed from a client program, Section 3 explains the various map metadata (styles, themes, and maps) required by MapViewer, Section 4 describes the XML request and response format. Section 5 describes the Map Definition Tool used for creating and maintaining map metadata and finally Section 6 summarizes this paper.

Accessing MapViewer from a client
This section then illustrates how to interact with MapViewer from a client (a Java program or a JSP page). For illustrative purposes, we assume that MapViewer is up and running, and that a data source named mvdemo has been defined for MapViewer. Once a MapViewer instance is running in Oracle 9iAS or OC4J, it can be accessed through a service URL, for example .

 

Assume also that the data source mvdemo has a base map named demo_map defined as part of its mapping metadata. To obtain a map centered at the San Francisco area (longitude/latitude: -122.40, 37.80), 400 by 360 pixels in width and height, and covering an area of 5.0 decimal degrees, one must submit the following XML request: -122.4, 37.8 The XML Response from MapViewer will be: -125.17777777777778,35.3 -119.62222222222222,40.3 The URL to the generated map image and an MBR (minimum bounding rectangle) of the area covered by the map are returned as part of the XML response. Once the program retrieves the response, it can then parse its XML content and extract the URL to the map image and other information.

The following sections describe in greater detail the basic concepts for MapViewer, the XML API, and the rendering process.

Mapping Metadata: styles, themes, and base maps
In MapViewer terminology, a map consists of one or more themes. Each theme consists of a set of individual geographic features that share certain common attributes. Each feature is rendered and (optionally) labeled with specific styles. Themes can be predefined inside a database user’s schema, or can be dynamically defined as part of a map request. Predefined themes can be grouped to form a predefined base map that can also be stored in a user’s schema. Styles, predefined themes, and base maps are collectively called mapping metadata for MapViewer. This scheme provides a clear separation between the presentation of data and the spatial data itself. For instance, any modifications you make while manipulating the mapping metadata will have no effect on the corresponding spatial data, and vice versa.

  1. Styles
    A style is a visual attribute that can be used to represent a spatial feature. The basic map symbols and legends for representing point, line, and area features are defined and stored as individual styles. Each style has a unique name and defines one or more graphical elements in an XML syntax.

    Each style is of one of the following types:

    • COLOR: a color for the fill or the stroke (border), or both.
    • MARKER: a shape with a specified fill and stroke color, or an image.
    • LINE: a line style (width, color, end style, join style) and optionally a center line, edges, and hashmark.
    • AREA: a color or texture, and optionally a stroke color.
    • TEXT: a font specification (size and family) and optionally highlighting (bold, italic) and a foreground color.
    • ADVANCED: a composite used primarily for thematic mapping.

    Styles should be created or modified using the Map Definition Tool as it checks for the referential integrity between styles, themes, and (base) maps. Any geographic feature, such as a road, can be displayed differently if different styles are assigned or applied, even though its underlying geometric structure remains the same.

  1. Themes
    A theme is a visual representation of a particular data layer. Conceptually, each theme is associated with a specific spatial geometry layer. For example, a theme named US_States might be associated with the GEOM column with type MDSYS.SDO_GEOMETRY in a STATES table.

    There are two types of themes, static or dynamic, supported in MapViewer. The static ones are called predefined themes and their definitions are stored in the USER_SDO_THEMES view. Dynamic themes (or JDBC themes) are defined on-the-fly within each map request.

    The actual definition of a predefined theme consists of the following: name of a base table or view, name of the geometry column, and one or more styling rules that associate styles to rows from the base table.

    Similarly a dynamic theme definition consists of the SQL query, the name of the geometry column, the JDBC database connection information, and one or more styling rules.

    The styling rules are discussed in the next section.

    1. Styling Rules
      A predefined theme can have one or more styling rules. Each styling rule tells MapViewer two things:
      • Which rows from the base table belong to a theme, and what feature style should be used to render the geometries from those rows. What this really means is that you can select only the desired rows (features) from the base table of a theme.
      • Optionally, whether the geometries in the selected rows should be annotated or labeled. If the answer is yes, then the rule must specify a column whose values will be used as the annotation text, as well as a label style for drawing the labeling text. The placement of the labeling text as relative to the geometry is however automatically determined by MapViewer at run time.

      Each styling rule is encoded in XML. The following rule is part of a theme named theme_us_airports, whose base table contains airports data, and has such columns named GEOM, NAME, and RUNWAY_NUMBER. runway_number > 1 1 In this rule, as in any other styling rules, there are two parts. The first is the element, which tells MapViewer which rows should be selected and which style to use when rendering the geometries from those rows. Any valid WHERE clause (minus the keyword WHERE) can be specificed as the value of the node. In this case, all rows that satisfy the SQL condition “runway_number > 1 ” will be selected, and a color style c.black gray will be used to depict the airport geometry for those rows.

      The second part of the preceding styling rule is the element. In this case, since the value of this element is a nonzero value of 1, MapViewer will attempt to label the airports when generating a map. The label text will come from the column NAME, and the TEXT style will be ‘t.airport name’. Specifying ‘0’ as the value of the node means no label should be applied.

      When referencing a feature or label style, the name of the style can take a form of :, such as MDSYS:t.airport name. This means the named style will be fetched from the specified user’s schema, which in this case MDSYS. Thus, a designer can define all of an organization’s basic map symbols under a common user scheme, and have all other users share it without storing the same set of map symbols multiple times.

    2. Dynamic themes in a map request
      For dynamic themes defined on a per-map request basis, there can only be one styling rule. It is implicitly specified by giving the entire SQL query and the required feature and label styles in the theme definition in a slightly different way from predefined themes. An example of such a dynamic theme as part of a map request is: — select region, sales, manager from foo_sales_2001 — In the preceding example, we are defining a dynamic theme named sales_by_region. The query that selects rows/features for this theme is SELECT REGION. SALES, MANAGER FROM FOO_SALES_2001. The feature and label style names are specified as render_style and label_style attributes, respectively. The database connection information is explicitly listed as part of the theme definition.

      Finally, although the actual data for the theme may be from a different database (as indicated by the database connection information), the referenced styles will always be retrieved from the data source as indicated in the overall map request.

    3. Thematic mapping through Advanced Styles
      Simple thematic mapping can be achieved through the use of Advanced type styles in a theme. For example, one may define an advanced style that has a series (buckets) of colors each associated with a range of (population density) values. Assume that this style is named V.POP DENSITY.

      Next we define a theme that uses V.POP DENSITY as the feature style as illustrated below. Once such a theme has been defined, one can use it just as any other predefined theme, and when rendered it will appear as shown in Figure 1.

    4. Figure 1. A simple thematic map

    5. Base Maps
      Predefined themes can be grouped together to collectively form a base map, which serves as a convenient way of including multiple themes in a map request. The base map definitions are stored in a user’s USER_SDO_MAPS view. Each theme listed in a base map has a minimum and maximum scale. This provides a powerful mechanism of selectively displaying themes based on the current map’s scale. For example, at a smaller map scale one may want to display only the major roads.
    6. MapViewer XML API
      MapViewer exposes its services through an XML API, which application developers can use when formulating map requests and processing its response.

      Through the XML API, an application can:

    • Customize a map’s data coverage, background color, size, image format and title et al.
    • Display a map with predefined or dynamic themes.
    • Display a map with one or more individual features obtained from other sources.
    • Obtain the URL to the generated map image, or the actual binary image data itself, plus the minimum bounding rectangle of the data covered in the generated map.

    Map Definition Tool
    The reccomended way to create, update, and delete mapping metadata (styles, themes and base maps) is through the supplied Map Definition Tool (MDT). The MDT is a standalone interactive Java program that provides a visual interface for manipulating mapping metadata stored in a user’s schema.

    Figure 2 shows a display from the MDT.

    Figure 2. Map Definition Tool

    On the left side of the MDT display is a list of metadata types that you can operate on. To the right of the metadata types a list of individual items of the selected metadata type (LINE type styles in Figure 2), and on the right side are details of the selected item (a style named L.RAILROAD in Figure 2).

    Summary
    Oracle MapViewer provides a Java component that lets one easily generate maps to display data. This enables more effective communication and analysis of information for applications. The primary benefit is tight integration with the Oracle platform, that is, the 9i data and application servers and their application development and deployment infrastructure. A secondary benefit is that MapViewer maintains a clear separation between the presentation of data and the data itself. This facilitates customizing the look and feel of generated maps so that they best suit a particular region, department or organization.