Figure 1: System Overview
Keywords: goSVG, Web GIS, Server-side SVG generation, LBS
Biography
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.
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
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). |
The system architecture consists of two major functions:
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/.
<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.
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.
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&r=480&aspect=0.75&position=+35.6508+139.6857/"
width="640" height="480" />
<image xlink:href="http://overdose.indigo.co.jp/poi-svg/POI2004/icon.svg?w=640&r=480&aspect=0.75&position=+35.6508+139.6857/"
width="640" height="480" />
</svg>
|
Figure 5: Container SVG
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.
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
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.
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:
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.
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.
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 .
Figure 10 illustrates higher scale image than Figure 9 . On the other hand, Figure 11 is relatively lower scale one.
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.
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.
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.
XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.
