Development of location based search engine service using goSVG

Keywords: goSVG, Web GIS, Server-side SVG generation, LBS

Yuzo Matsuzawa
Indigo Corporation
3-15-1-8F Higashiyama, Meguro
Tokyo
Japan
yuzo@indigo.co.jp
http://www.indigo.co.jp

Biography


Abstract


We have been developed search engine service which focuses on position information. Our search engine collects HTML documents which include position information called 'PI (Place Identifier)', and publish them as goSVG document. Collected HTML documents are represented by tiny icons on the map, which enables users to grasp the location-based relationship between documents.

When relatively narrow area is required, this approach works well, but problem occurs when user needs relatively wide area map. The wider the user specified area becomes, the larger number of icons are included in a map. Too many icons may generate lower usability for users and significant performance degradation for svg rendering engine. To solve this problem, we have introduced idea of mesh layer, which summarize number of icons, and represents the density of icons by color.

These features have been implemented easily by using goSVG, and it was proved that goSVG is useful to build location based services.


Table of Contents


1. Introduction
2. System architecture
     2.1 Collection of g-Contents
     2.2 SVG
         2.2.1 Container
         2.2.2 Basemap
         2.2.3 Icon layer
3. Implementation
     3.1 Database
     3.2 Application server
     3.3 SVG Browser
4. Results
     4.1 Narrow area
     4.2 Wide area
5. Summary
Acknowledgements
Bibliography

1. Introduction

A large number of potential g-Contents are available on the internet. Popular HTML contents like news, event information pages and landmark information pages are typical g-Contents. Increasing moblog contents which are transmitted from cell phone are regarded as potential g-Contents. Moreover, cell phones equipped with GPS and digital camera are used to transmit jpeg photo images with location information. We expect that the number of potential g-Contents will raise continuously.

If we could represent these g-Contents as icons on the digital map, users can grasp location based relationship between g-Contents easily and visually. These features may be achieved by HTML using clickable map, but raster image generation on the server has a potential performance problems, and the coordination among generated images and clickable map definitions is hard to maintain. We think that SVG makes it possible to develop such a system easily and effectively.

The purpose of this paper is to introduce our system, which collects location based HTMLs from internet, and publishes them as goSVG document.

NOTE: "G-Contents" is a generic term for digital contents which include location information. This concept is advocated by Database Promotion Center, Japan (http://www.dpc.or.jp).

2. System architecture

The system architecture consists of two major functions:

99.png

Figure 1: System Overview

2.1 Collection of g-Contents

HTML with PI (Place Identifier) was selected as a target g-Contents format. " PI " is a specification to add location metadata in HTML document. Figure 2 is an example of HTML with PI . With inserted metadata, we can judge that this HTML has relation to N35, E139.

<html>
<head>
    <title>foo</title>
    <meta name="POI" content="PI:ISO6709(+35.000+139.000/)"/>
</head>
...

Figure 2: Header part of HTML with PI

NOTE: " PI " is a draft specification by g-Contents Exchange Promotion Association (http://www.g-contents.jp). Not only latitude and longitude expression based on ISO6709 (http://en.wikipedia.org/wiki/ISO_6709), various expressions like address based description are under consideration.

Commonly used method is preferred to indicate icon by which g-Contents is represented on the digital map, For this purpose, We featured favicon. Normally, favicon can be seen in the web browser's address bar, tab bars, and bookmarks. Content providers can set up favicon by following method :

For more details, please refer to http://www.favicon.com/.

12.png

Figure 3: Screen Shot of favicon

<html>
<head>
    <title>Misyuku elementary school</title>
        <link REL="SHORTCUT ICON" HREF="http://overdose.indigo.co.jp/ico/elementary_school.ico">
</head>
...

Figure 4: Header part of HTML with favicon

We prepared over 100,000 of g-Contents as HTML with PI , each document describes a public facility in Japan. These contents were generated from Digital Map 25000 (Geographical Names & Public Facilities) which is available from Japan Map Center (http://www.jmc.or.jp/). In addition, each document has definition for favicon associated with category of public facilities like school, post office, police station and so on.

It would be ideal if prepared contents were collected automatically by robot, but actually we gave some instructions which enable our application to retrieve and analyze g-Contents.

2.2 SVG

When users send requests which indicate target area and resolution, server dynamically generates goSVG document which meets user's demand. Reponsed SVG consists of Container, Basemap, and Icon layer. Each SVG has CRS (Coordinate Reference System) definition, which enables hyper-layering of SVGs on SVG browsers based on hyper-layering-architecture.

2.2.1 Container

Container, SVG1.1 compliant SVG, consists of followings :

User specified parameters are used to calculate CRS, and transmitted to basemap and icon layers as GET parameters of hrefs.

<svg xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:au="http://www.kddilabs.jp"
     width="640" height="480" viewBox="0 0 640 480">
  <metadata>
    <au:lbs protocol="maprequest" />
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns">
      <rdf:Description>
        <crs:CoordinateReferenceSystem
            xmlns:crs="http://www.ogc.org/crs"
            rdf:resource="http://www.svg.ne.jp/wgs84"
            xmlns:svg="http://www.w3.org/svg"
            svg:transform="matrix(45143.57308,0.00000,0.00000,-55555.55556,-6305591.60609,1980840.00000)" />
      </rdf:Description>
    </rdf:RDF>
  </metadata>
  <image xlink:href="http://jamaps3.kddlabs.co.jp/jamaps/japan/japan.svg?w=640&amp;r=480&amp;aspect=0.75&amp;position=+35.6508+139.6857/" 
        width="640" height="480" />
  <image xlink:href="http://overdose.indigo.co.jp/poi-svg/POI2004/icon.svg?w=640&amp;r=480&amp;aspect=0.75&amp;position=+35.6508+139.6857/" 
        width="640" height="480" />
</svg>

Figure 5: Container SVG

2.2.2 Basemap

Basemap, SVG1.1 compliant SVG, consists of followings :

To meet these requirements, we used JaMaPS basemap server (See http://www.jamaps.org/). This basemap server publishes suitable map images depended on map scale.

2.2.3 Icon layer

Icon layer, SVG1.1 compliant SVG, consists of followings :

Hyperlink is set to URL of g-Contents, and image tag refers to URL of favicon (see Figure 6 ). Generally, svg browser dose not support ico format, so we prepared simple gateway to convert ico into png. In Figure 6 , gateway url is abbreviated.

<svg xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:au="http://www.kddilabs.jp"
     width="640" height="480" viewBox="0 0 640 480">
  <metadata>
    <au:lbs protocol="maprequest">
      <au:zoomin th="70" xlink:href="." />
      <au:zoomout th="120" xlink:href="." />
      <au:scroll th="10" xlink:href="." />
    </au:lbs>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns">
      <rdf:Description>
        <crs:CoordinateReferenceSystem 
             xmlns:crs="http://www.ogc.org/crs"
             rdf:resource="http://www.svg.ne.jp/wgs84"
             xmlns:svg="http://www.w3.org/svg"
             svg:transform="matrix(45143.57308,0.00000,0.00000,-55555.55556,-6305591.60609,1980840.00000)" />
      </rdf:Description>
    </rdf:RDF>
  </metadata>
  <a xlink:href="http://overdose.indigo.co.jp/jamaps/resource.jsp?id=34776" target="_blank">
    <image height="40.0" x="87.82520652748644" width="40.0" y="2.099999999627471"
           xlink:href="http://overdose.indigo.co.jp/ico/senior_high_school.ico" />
  </a>
  <a xlink:href="http://overdose.indigo.co.jp/jamaps/resource.jsp?id=34757" target="_blank">
    <image height="40.0" x="87.82520652748644" width="40.0" y="2.099999999627471"
           xlink:href="http://overdose.indigo.co.jp/ico/junior_high_school.ico" />
  </a>
  
  ...

  <a xlink:href="http://overdose.indigo.co.jp/jamaps/resource.jsp?id=34184" target="_blank">
    <image height="40.0" x="505.4032575106248" width="40.0" y="458.8888888885267"
           xlink:href="http://overdose.indigo.co.jp/ico/junior_high_school.ico" />
  </a>
</svg>

Figure 6: Icon Layer SVG

3. Implementation

Our experimental system is based on client server model. SVG browser plays a role as client, and server consists of application server and database server.

3.1 Database

We used relational database to store summary data of g-Contents. PostgreSQL 7.4.2 was used for this system. A simple table was created on database to store summary data, which consists of followings:

3.2 Application server

Our application is web application, built on java servlet architecture. Jakarta-tomcat-5.0.27 was used as application server to deploy application, and as web server to serve static resources like HTMLs, and favicons.

3.3 SVG Browser

SVG1.1 compliant SVG browser which support hyper layering architecture is required. We used goSVG browser presented by KDDI R&D Laboratories Inc. This goSVG browser is available for several platforms.

4. Results

4.1 Narrow area

Figure 7 is a screen capture of basemap svg rendered by ActiveX version goSVG browser. Figure 8 illustrates icon layer, where each icon size is adjusted to occupy approximately 20 x 20 meters square on the map. These individual layers are hyper-layered by container svg. The result is shown in Figure 9 .

10.png

Figure 7: Screen shot of basemap

01.png

Figure 8: Screen shot of icon layer

09.png

Figure 9: Screen shot of hyper-layered image

Figure 10 illustrates higher scale image than Figure 9 . On the other hand, Figure 11 is relatively lower scale one.

03.png

Figure 10: Screen shot of hyper-layered image (high scale)

04.png

Figure 11: Screen shot of hyper-layered image (low scale)

4.2 Wide area

When user specified area is narrow, we can get good-looking icon images, as illustrated above. But the wider the user specified area becomes, the lager number of icons are included in a map. This causes serious performance problem for SVG browser. Suppose that the number of icons is not so big, the size of icon becomes too small for map to identify.

To solve this problem, the idea of mesh layer was introduced. Figure 12 , Figure 13 ,and Figure 14 illustrate the mesh layer examples. Mesh layers are published under conditions where the size of rendered icon becomes less than 10 pixel or the number of icons included in a layer becomes more than 100. In this layer, specified area is divided into 12 x 12 partition, and each partition has label to display number of icon included in itself. When user specified more wider area, area is divided into 36 x 36, and label is ommitted (See Figure 13 , Figure 14 ).

Each partition is filled with transparent color which reflects the number of icons included in itself. Red one is high density area, and blue one is low density area.

05.png

Figure 12: Screen shot of hyper-layered image (12 x 12 mesh)

06.png

Figure 13: Screen shot of hyper-layered image (36 x 36 mesh)

07.png

Figure 14: Screen shot of hyper-layered image (very wide)

5. Summary

We introduced simple system to realize a kind of location based system, with which location based HTMLs were successfully located onto digital map. Consequently, this experiment proved that goSVG was useful to build the location based services easily. In the future, when location based metadata specification like PI becomes popular, we expect that the service discussed in this paper will act as location based search engine.

In this experiment, each icons was treated equally. When it comes to actual service, icons should be categorized by domain, keywords, and any metadata to meet user's demands.

Acknowledgements

This work was conducted as a part of goSVG Working group activity. The author is grateful for the goSVG working group members for ideas, basemap and browsers.

Bibliography

[SVG11]
Scalable Vector Graphics (SVG) 1.1 Specification Jon Ferraiolo, Fujisawa Jun and Dean Jackson, January 2003, http://www.w3.org/TR/SVG11/coords.html#GeographicCoordinates

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.