Geospatial Information Service System for Browser-phones utilizing PSVG

PSVG Specification and Implementation

Shimada Shigeru
Tanizaki Masaaki
Hitachi, Ltd. Central Research Laboratory

Higashi koigakubo 1-280, Kokubunnji City, Tokyo, Japan
fax: +81-42-327-7856

Takagi Masaru
Kobayashi Arei
KDDI R&D Laboratories Inc.

Oohara 2-1-15, Kamihukuoka City, Sitama, Japan
fax: +81-492-78-7510

Keywords: Telematic Spatial Information Service with SVG; Map Summarization for SVG data compression; Portable Vectorgraphics PSVG


There is a great deal of growth in mobile services, especially location-based information services for cellular phone users. To cope with this, we propose a new spatial information service system, which consists of the mediating the multiple geo-spatial contents and the location & direction reflected summarizing spatial data. And moreover these processed spatial data is displayed on the browser phone under the J2ME/CLDC plus MIDP environment, by settled PSVG (Portable SVG) which is specially optimized for browser phones subset & extension of SVG Basic/Tiny. The evaluation results of the test-bed system will also be included.

1. Introduction

The purpose of this study is to allow spatial information services to be practically introduced under the mobile information infrastructure. In this paper, we use the word "Spatial Information" which is the general term for the hole information that describes spatial issues, such as navigational route, location, POI (Point of Interest), satellite imaging, and so forth. The kind of information service depends on the kind of spatial information required, such as that in car navigation, LBS (Location Based Services), shop guides, satellite imaging services, to name a few.

1.1 Background

It is not too much of an exaggeration to say that conventional thinking on methods of mobile access to the internet are rapidly changing. The existing mobile client system usually involves notebook PCs or PDAs that make heavy use of wireless modem cards, GPS positioning cards, and others. To get out of this heavy reliance on hardware in current mobile systems, it is necessary to technically develop cellular phone environments. The main requirements for these are: (1) A high-speed 3G wireless network infrastructure, (2) Improved performance of browser phones, (3) High-sensitivity and -resolution LBS support. Each of these is detailed below.

(1) A high-speed 3G wireless network infrastructure
The worldwide recession in the information technology market has delayed the 3G wireless communication network infrastructure from spreading. In spite of this situation, IT-advanced countries in Asia such as Japan, Korea, and Singapore have already started a great many multimedia services utilizing the 2.5G cellular phones that are still being developed or that are compatible with 3G phones. For example, the Japanese i-mode, which is a typical multimedia service for cellular phones, is already supporting over thousand orders of multimedia-content service sites. Recently, a Java based multimedia service was also started for the J2ME-embedded cellular phone (called a "browser phone"), and this kind of service supports moving pictures, LBS linked maps, mobile e-commerce, among others.
(2) Improved performance of browser phones
In order for browser phones to be of maximum use to internet clients, they need higher processing capabilities not only for the communication interface, but also for the high speed processing power required by HTML or XML formed multimedia, on the mobile client's local processing side. In the existing cellular phones, these multimedia processes are done by modem chip sets.[1] This architecture is supported by a CPU speed of only one or two MIPS. However, recently, dual processor architecture has been proposed for browser phones. In this architecture, a low powered DSP (such as SH-Mobile[2], OMAP, etc.) has been adopted, and this kind of processor has been designed for exclusive processing of multimedia applications. These kinds of DSPs have a CPU speed of over 100 MIPS, which is the same level of performance as conventional PDAs. As this new architecture allows high-speed local processing such as JVM (Java Virtual Machine), it is possible to provide multimedia services such as those required for vector graphics and moving pictures, based on browser phones, which have been impossible to achieve with cellular phones.
(3) High-sensitivity and -resolution LBS support
Synchronized with the launch of these 3G browser-phone-based multimedia services, has been the entry into LBS enterprises. The major LBS is being focused on, has been triggered by the fact that the locational detecting mechanisms of cellular phones during emergency calls have been based on US FCC recommendations since October 2001. To cope with these recommendations, the world-first LBS; gpsOne, which is the most widely and accurately supported, was introduced by the Japanese carrier company KDDI in December 2001. The gpsOne, which is different from conventional stand-alone-type GPSs, has the following features.[3]
First, the gpsOne uses quite a different method of calculation from the conventional one. That is, it adopts a server assisted GPS method whereby the client supports the satellite signal measuring process only, but most of the heavy duty calculation is processed by the server. This architecture creates a very simple system structure for gpsOne- equipped browser phones.
The GPS properties of sensitivity and convergence speed have also been greatly improved. The measuring server has databases that hold detailed locational information and upper satellite conditional information on each of the base stations. And these databases supply satellite orbital information and their Doppler-estimated positioning data to cope with the time and place of each mobile client. This means gpsOne can always start services rapidly, the same as under conventional hot-start conditions. Moreover, large-scale FFT calculations for detailed measurements are activated by strong server processes, so it is easy to enhance the measuring accuracy of mobile client locations.
However, even if mobile clients stand in locations where it is impossible for GPS satellite beams to reach them, gpsOne can change the method of calculation from GPS-based to triangulation-based. This utilizes three sets of locational information from base stations, and this method provides stable measuring accuracy to mobile clients. The advanced gpsOne technology has spread into the Japanese LBS market, and the number of licenses sold is already over one million. (from KDDI News, May 2002)

The latest or soon-to-be-introduced browser phones will bring rich multimedia internet services via wireless communication networks, the kinds of services that are conventionally considered to be supported by notebook PCs or PDAs.

1.2 Circumstances

This research & development was achieved by cooperation between KDDI Laboratory (KDDI Lab.) and Hitachi Central Research Laboratory (HCRL) The title of the project is "Development of a spatial information service system for browser phones" and the joint research has been undertaken since December 2000. Both organizations had already developed Web-based GIS quite a long time before the joint project. KDDI Labs. had developed a Java-based SVG supplying GIS named JaMaPs,[4] while HCRL had developed a CORBA-based interoperable GIS named AnyGIS [5] after joining the international interoperable GIS project settled by the OGC (OpenGIS Consortium). This experience and individual achievement created a smooth backdrop to this research & development.

2. System Concept for Mobile Spatial Information Services

This section describes the system concept for the spatial information service to browser phones as the mobile client. The beginning of this section explained the reasons we selected the mobile spatial information service area as for the GML [6] based interoperable GIS. We then explained the subject of this research and development by settling system requirement from user demands and by extracting core technology to realize these demands.

2.1 The reason we selected mobile spatial services

In the spatial information processing area, where GIS is a typical application many studies have already been conducted on interoperable database access methods. Parallel with this study, efforts to construct a digitized database have been made from an early period. Recently, OGC (Open GIS Consortium)[7] started to deliver GML, which are the standard interface specifications for interoperable GIS, and it has also arranged international testbed projects such as OLS (Open Location Services). These activities have opened up many developments for Web applications concerned with spatial information accessing.
Although these activities, utilizing GML based interoperable GIS, have been applied to large scale civil engineering such as city planning, facility management, and so on, there happen to be many problems where system performance is not sufficient on the practical level. The main reason for the problems is that the quantity of spatial information described by GML is much too large. That is, many conventional GISs, which operating on a practical level prior to adopting GML based interoperable GIS, had been designed for processing binary corded and special formatted data. However, GML is composed of ASCII character data and, moreover, it contains a great deal of tag data which describes the data structure. The quantity of GML corded data, then, is at least ten times larger than ordinal binary data.
In order to avoid these problems, we decided to concentrate on the mobile spatial information service area, where problems with data quantity do not cause as much trouble. The types of information service systems in this area are used in mobile-user navigational systems and they provide the minimum amount of information required to understand the situation. Further, they do not need to support a wide range of information to ensure various kinds of retrieval demands as well as conventional GIS. For more concrete applications, conventional GIS needs to support data for displaying a 1000x1000 pixel resolution at least, but , a mobile spatial information service only needs a 100x100 pixel resolution, that is, the data processing burden is down to one percent.

2.2 System Requirements and Problems

The next part of this section explains the system requirements that largely affect system design. These requirements derive from functional user demands and are itemized below, as are the problems and core technologies for these requirements.

(1) Supply inexpensive and data-rich content by reusing conventional spatial databases.
This requirement, as already mentioned, can be understood as a reusable function for interoperable retrieval from conventional spatial databases via the open internet environment. This problem involves the "Interoperable access method for legacy spatial databases".
(2) Supply spatial information as vector graphics to mobile clients, and locally process fundamental functions such as zoom in/out, scroll, and so forth.
Map services for browser phones have already started in over a dozen major sites in Japan. Most of these services supply maps as a image data such as GIF or JPEG, so this needs many server accesses via a wireless network even with simple zoom in/out operations. This client-server mechanism cannot support a sufficiently fast response speed, and, moreover, it is very costly, and this causes operational problems. This requirement can be satisfied by utilizing a local display mechanism, using open vector graphics such as SVG, under the very limited processing environment of browser phones. This problem involves the "SVG display method for mobile clients".
(3) Support a good looking and immediately recognizable spatial information service even for small display devices with limited memory buffers.
This requirement concerns the way the spatial information service handles data, the previously mentioned graphics data needs to be well compressed as the level of small size fit for easy transfer from server to client. The main technical problem is how to display good looking maps on the small displays of browser phones. This problem has not been resolved by direct extraction and display from spatial databases, but it can be resolved by grasping semantic meaning and emphasizing the features of maps. This problem involves the " High compression technique for spatial information."

3. Interoperable Access Method from Legacy Databases

In order to increase the quality of spatial information services, spatial content needs to be prepared, but this content is very expensive to produce, such as detail residential map sets. The information useful to users consists of not only detailed continuing content that reflects each direction, but also fresh maintained content that reflects the latest state of environments. To cope with this demand, it is necessary to utilize legacy datasets that are already worked on services, and to produce multi-databases that enable interoperable access to these legacy databases. The spatial information service is a practical course of processing whereby the location based retrieval from these multi-database constructions and retrieved results from this system can be supplied to browser phones. The next section explains in detail the way this multi-database system is constructed and the method we used to transform and integrate the legacy database structure.

3.1 Multi-database construction method

To keep effective retrieval processing from spatial databases, many legacy GISs have adopted a tiling system that manages blocks of map data where the map area is divided into small rectangles that holds parametric size on horizontal or vertical directions. However on the user side, it is necessary to neglect these tiling mechanisms in map retrievals and to be able to achieve access freely and quickly. The tiling boundaries are different even if we utilize the same scaled maps supplied from the legacy spatial databases. Moreover it is necessary to adjust the tiling boundaries of differently scaled map data. Ordinarily, this adjustment process is very difficult.
However, many legacy GISs introduce a layer control mechanism that makes group data access easier. It is made up of collectioned sets of the same geographical objects such as roads, buildings, and so on. To respond to service demand from mobile client for navigational maps, it is necessary to construct systems that can supply maps easily, of any kind or in any quantity, of geographical objects. Here, each spatial database has a slightly different layer structure even with the same kinds of geographical maps. Moreover, the layer structure of landmark databases is quite different from that of geographical databases.
There are many methods or techniques to access spatial databases freely without vertical or horizontal boundaries. We adopted the "Virtual Map Cube" which is generated and managed by the application server, to produce the multi-database in this study. This Virtual Map Cube must be maintained in real time, to realize interoperable access to legacy spatial databases, and this maintenance process can be achieved by real-time transforming and integrating processes, using standardized data forms, after converting them from the original form of data supplied from the legacy spatial databases. A typical candidate for this standardized form of data is GML, that is delivered from OGC. They started to deliver GML V1.0 in 2000, and this version of the specifications will be revised into V3.0 in September 2002. In section 6, we will describe the implementation method in detail and evaluate it as a service system for a multi-database using GML.

Virtual Map Cube for interoperable access

Figure 3.1: Virtual Map Cube for interoperable access

3.2 Transformation and Integration of Legacy Database Schema

Generally, a legacy spatial database has a special structuring fit for accessing ongoing databases, so there are some differences in structuring from those we expect for the structures of spatial information services. There is, so to speak, "Database Schema Mismatch" when accessing from legacy spatial databases, so it is necessary to convert and integrate schema. Many legacy spatial databases adopt a layer structure that simply archives various kinds of geo-spatial features to acquire more universal functions. However, to support summarized maps that have been designed for spatial information services, a hierarchical structure is frequently adopted to grasp meaning of maps by mobile users. "National Numerical map 2500" can be regarded as a candidate for legacy spatial databases. This map has the database schemas referred to in Fig. 3.2(a). It shows a rather flat structure equivalent to the layer structures. From our targeted spatial information service viewpoint, it is necessary to have a summarized map style, which is good looking even on the narrow display devices on browser phones. Figure 3.2(b) shows rather deep hierarchical structures of this database schema.

Virtual Map Cube for interoperable access

Virtual Map Cube for interoperable access

Figure 3.2: Database Schemas

To transform and integrate these database schemas effectively, the geo-spatial mediator, which is located on the application server, is equipped with transformation tables for different geo-spatial features, transform rules for different structure conversions, and a route compensation mechanism based on route search and topology analysis. However, in this study, we deal with a simple geographical feature level, not with the ontology level, which deals with the semantic meaning of symbols or names.

4. PSVG specifications

To enforce the SVG specifications across the board, a strategy of revising the specifications has been carried out. The SVG V1.1 specifications and SVG Basic/Tiny [7] profiles have been turned into recommendations and these were delivered in April 2002. The main features of this revision are making subsets and extending SVG specifications to mobile clients such as PDAs and browser phones. For example, SVG Tiny is described as tag selection and simplification of related attributes for 3G browser phones. These simplifications are necessary for implementation on browser phones that house a very narrow display device of 100 x 100 pixels with a very limited CPU.
As already mentioned in section 1.1, the latest Japanese browser phones which are positioned as 2.5 generation have very limited performance. For instance, their CPU speed is only 1-2 MIPS, and the activation area for Midlet (J2ME based Java Applet) must be under 50 Kbytes, among other limitations. For the SVG viewer to operate more smoothly based on the SVG-Tiny specifications that are based on the recent recommendations, it needs a CPU speed of at least 100 MIPS and an activation area for Midlet of 1 Mbytes. Therefore, if it is based on these specifications, 2.5G browser phones will only have very slow performance, which is far from being practical.

4.1 PSVG fundamental specifications

First, there is the problem of how to choose the PSVG tag set that must be selected as a subset of SVG. This process needs a consistent plan to select it as the subset of SVG-V1.1, and if we select tags and new specifications, it must be processed under PC implemented SVG viewers. If we try to roughly classify XML tags that are composed of SVG, they can be classified into two groups, the first is the element tag sets which define the shape or action of features, and the second is the attribute tag sets which define the properties of each element. Using these tag classifications, Table 4.1 describes the element-tag relationships between SVG, SVG-Basic/Tiny, and PSVG. This table also makes it is clear that PSVG adopts fundamental element tags that only relate to display methods such as lines, rectangles, circles, text, and images supported by J2Me, and PSVG adopts the g tag of SVG, which makes it possible to describe the hierarchical structure of tag sets.

Table 4.1: DTD based Tag set comparison.
Element Tag VocaburariesSVGSVG BasicSVG TinyPSVG
Document Structure99 / 02 / 60 / 4
Styling11 / 01 / 00
Paths11 / 01 / 00
Basic Shapes66 / 06 / 00 / 4
Text88 / 00 / 40 / 1
Color11 / 000
Gradients and Patterns44 / 000
Clipping, Masking & Composting21 / 100
Filter Effects250 / 1600
Interactivity11 / 000
Linking22 / 02 / 00
Scripting11 / 01 / 00
Animation66 / 06 / 00
Fonts1111 / 00 / 90
Metadata11 / 00 / 10
Extensibility11 / 01 / 00
Special Extensions0008

4.2 Extended PSVG Specifications

PSVG solves three SVG specification extension problems, so that vector graphics can be displayed effectively on the very narrow display areas of browser phones. These are: (1) Max/Min scale tags for area effectiveness, (2) Datum point tags for overlay displays, (3) Priority control tags for LOD (Level of Detail) The following section explains each of these in detail.

(1) Max/Min scale tags for area deformation
To define the effective area for the zoom in/out display, this kind of tag determines the upper or lower limits of the display scales. This tag set is expressed by following DTD.

	hms:max_scale; CDATA # REQUIRED 	<!-- Upper limit of effective area of scales -->
	hms:min_scale; CDATA # REQUIRED >	<!-- Lower limit of effective area of scales -->

(2) Datum point Tag for overlay displays
To overlap multiple content displays, this kind of tag establishes the datum point. This datum point delivers a state that is able to display multiple content, which have different kinds of coordinate systems, by using a universal morphing transformation mechanism. For example, measuring points that arrive from GPS can be mapped into different coordinate systems from geodetic coordinate systems, by a map summarizing process, which will be explained later. This tag set is expressed by following DTD.

<!ELEMENT defs (jm:transformation)>
<!ELEMENT jm:transformation (local,global)? >
<!ATTLIST jm:tranformation
	style CDATA; #FIXED "points"
	xlink:href CDATA; #IMPLIED>
<!ELEMENT jm:local (#PCDATA)>
<!-- Discriptive example of datum point for local coordinate value 
	(Example:135.324342,35.343243 135.424342,35.443243 135.524342,35.543243…)-->
<!ELEMENT jm:global (#PCDATA)>
<!-- Discriptive example of datum point for global coordinate value 
	(Example:1,8 5,2 6,4 …) -->
<!ELEMENT jm:globalunit (#PCDATA)>			<!-- value is fix as "px/HMS" -->

Morphing between two coordinate systems based on dataum point

Figure 4.1: Morphing between two coordinate systems based on dataum point

(3) Priority Control Tag for LOD
This tag set enables display priority to change the level of detail on the display object based on scales. And it enables objects to be displayed on the narrow displays of browser phones using an optimum-detail level of figures based on each scale. It also creates a better-looking screen and decreases the burden on the display process. Priority values are defined for figure components, figures, figure sets, where these tag sets belong to the attribute tag set, so they do not appear on the element tag set as Table 4.1 shows.

Point visibility:
Describe the priority value for each point which compose figures. The targets of the figure components are polyline or polygonal, which are composed of multiple component points.

Description Form: hms:point-visibility="Priority value 1, Priority value 2, ..."
Descriptive Example: Descriptive example priority value pn for the each point 
                     given as point attribute.
	<polyline points="x1,y1 x2,y2 … xn,yn"  hms:point-visibility="p1,p2, …pn"/>

figure visibility:
Describe the priority value for each figure. The targets of figure components are polyline, polygonal, textual, visual, and so on.

Description Form: hms:figure-visibility="priority value"
Descriptive Exmaple: Descriptive example of priority value p for the polyline figure itself.
	<polyline points="x1,y1 x2,y2 … xn,yn" hms:figure-visibility="p" />

group visibility:
Describe priority value for figure sets. The target component is the "g" tag.

Description Form: hms:group-visibility="Priority value"
Descriptive Exmaple: Descriptive example of describing priority value p for the group 
which contains multiple figures.
<g hms:group-visibility="p">
	<polyline points="x1,y1 x2,y2 … xn,yn" />		<!-- polygon 1 -->
	<polyline points="x1,y1 x2,y2 … xn,yn" />		<!-- polygon 2 -->
	<polyline points="x1,y1 x2,y2 … xn,yn" />		<!-- polygon n -->

5. Effective compression mechanism for spatial information

Japan already has a 3G wireless communication service and it can be used at a maximum speed of 384 Kbps (DoCoMo FOMA), 144 Kbps (KDDI cdma2000 1x), and the almost ordinal communication service speed is at the 9.6 Kbps level. As this wireless communication environment supports only 1/20 - 1/200 levels of speeds, compared with ordinal Internet communication speed, it is better to transfer small amounts of information. . From this point of view, it needs a radical technique to compress spatial information. For example, ASCII code is used for XML description and the data compression rate of SVG is at most 30%, utilizing an ordinal data compression mechanism such as ZIP or LHA. If we estimate the data volume of maps within an area (e.g. 1 square km) that is usually utilized for root guide etc., it becomes 1 Mbytes as XML forms. Therefore, if we obtain compressed map data for this area that is under 50 Kbytes, it will be necessary to improve compression methods.
To cope with this demand, we propose a data compression method from two viewpoints. The first method is map summarization that grasps the semantic meaning of maps and converts them into simpler ones, and the second is binary encoding that can generate interim binary code that omits the XML pursing process. By cascading these compression methods, we easily obtain well-compressed map data under 50 Kbytes. The next section has more detail on these methods.

5.1 Map Summarization

The summarizing process consists of the following media processes: First, features are extracted from spatial data which is the target of data compression, second, parts of the feature objects are extracted, and third, shape deformation is added to them. This series of processes produces simpler and better-looking maps than the originals. This process uses the semantic compression method within the wider meaning of the data compression method, but the process is not reversible and compressed objects cannot always be revived. The most important characteristic of this process is its conceptual grasp of spatial information where necessary objects are emphasized and redundant objects are omitted. As a result, we can expect drastic data compression rates. We will next explain the summarizing process in detail.

Step 1: Put in order of importance features that are contained in the spatial information for the processing target, and extract features until the allowable number of records is reached.
Step 2: Straight-line-oriented to simplify the shape of base features such as roads, railroads, rivers, that are contained in that area. The principles of straightening are based on thinning out redundant feature points, and determining the distance between the feature point and line composed of two feature points (refer Fig 5.1(a)).
Step 3: Shape deforms horizontally and vertically, for the straightened base features. This process involves a spring model that adds flexibility to the lines and angles, and it construct a convergent algorithm that optimizes shape deformation under horizontal and vertical limits and topology preservation (refer Fig 5.1(b)).
Step 4: Compensate for the remaining features except for base features to eliminate conflict of topology relations with the previously mentioned deformed base features. This compensation is based on the morphing algorithm that reserves linear relationships to the datum positions.
Step 5: Compensate using base features and remaining features as the summarized map. Moreover, add the media conversions for the various kinds of style such as figures, images, text, and voice. There is an example of automatic generation of summarized maps using these steps and a comparison of data quantities (refer Fig 5.2). This shows that the quantity of the map data that is extracted from the same area (here, Tokyo Station area) can be compressed under 1/5 using these summarizing processes.

Fundamental theory of summarizing mechanism

Fundamental theory of summarizing mechanism

Figure 5.1: Fundamental theory of summarizing mechanism

5.2 XML document binary encoding "XEUS"

XEUS (XML document Encoding Universal Sheet) is the nickname of the universal binary encoding method for XML documents that was developed by KDDI Lab. XEUS has the following features. It enables encoding of universal XML formed script language, by preparing an encoding rule description sheet (XEUS sheet) similar to DTD for XML. For the client and server system, XEUS enables a special encoding embedded in the XML parsing result processed by the server, so this omits the parsing process on the client. Adopting the XML Namespace mechanism, it is possible to encode data using a combination of multiple XML script language. These advantages mean that the data volume that is supplied from the server to the client is drastically reduced, so that the data transfer time is shortened. In addition, it does not need XML pursing on the client and this further reduces the processing time. Table 5.1 is a comparison of data compression rates using XEUS encoding and the ordinal encoding method. This shows that the data compression rate using XEUS encoding is comparable to ZIP encoding.

Table 5.1: Comparison of compression rate.
Kind of XMLZIP CodeXEUS Code

Comparison of data quantities

Figure 5.2: Comparison of data quantities

6. System implementation and evaluation

We developed a test-bed system by implementing the above concepts and methods on a spatial information service system using a real wireless infrastructure (KDDI cellular phone network and internet). [8] The following section explains the concrete structure and evaluates test-bed system.

6.1 Construction of the Test-bed System

To evaluate system response and display quality from the viewpoint of a user of spatial information services, we developed a test-bed system utilizing a real cellular phone network (KDDI cdma2000) and LBS (gpsOne). We used a 2.5G browser phone that was equipped with a local Java J2ME/CLDC (ez-plus) processor, and a server assisted GPS (gpsOne) that had high sensitivity and resolution properties. There was an application server between this browser phone and the legacy content servers that integrated and summarized the retrieved data that was supplied from various kinds of content servers via the Internet. Figure 6.1 shows the system structure for the complete test-bed system, which is a three-tier model. The following section explains details of this system's structures.

The systems architecture

Figure 6.1: System structure of test-bed system

(1) Legacy DB server
For the spatial content servers, we prepared two kinds. The first was a geographical map server and the other was a landmark server and we utilized them in the interoperable process under working on each service. These servers have independent in/out interfaces for each and we established restrictions whereby each server supplied standard GML coded data by settling GML wrappers at the front of each server. These GML wrappers convert each independent unit of formatted data to standard GML, and this makes it easy to construct a multi-database system. Concrete details on the construction of Legacy DB server are as follows.
a) Geographical Map Server: The vector data of "Numerical Map 2500", that was obtained from a geographical survey of Japan, is stored in an object-relational database management system (HiRDB/USR), and added to this is a spatial-index (SSP) which enables very high speed retrieval of vector data. GML wrappers are also implemented as plug-ins in front of them.
b) Landmark Server: Landmark data that are composed of buildings, stores, and so on, have two kinds of components, positional information and properties composed of name and attributes. They are stored in the relational database management system (ORACLER), and add a spatial index (Arc SDER) that enables high-speed retrieval of point data. The GML wrapper is also implemented in front of this.
(2) Application Server
Performing a series of processes involves an interoperable process with multiple legacy servers and a synthesizing process to generate a summarized map. This application server is composed of the following sub-parts (refer Fig. 6.1).
a) XML data cache part: This stores the GML data supplied from multiple legacy content servers, and the PSVG data supplied after the rendering process, and this part caches these data to respond quickly to the retrieval demand of the mediator, located at the upper part of this system. And this part has an inner XML repository that stores and retrieves XML code (such as GML or PSVG) directly, and this is achieved by adopting HiRDB/US-SSP for high speed retrieval of vector data.
b) XML Mediator: To extract user demanded data in any area, construct a Virtual Map Cube by integrating cached GML data, and integrate these after the transform schema mismatch which exists on the feature expressed by GML. These kinds of processes belong to the universal application server, but we focused on the effectiveness of spatial data processing, and, as a result, we utilized "AnyGISR", which is specialized in spatial data processing.
c) Summarized Map Generator:: This part generates the summarized map by extracting the main features that are necessary for guide, and by shape deformation using these extracted results. This process is a conversion from the real world to cyber space and that resulted in semantic data compression.
d) XEUS encoder:: To supply PSVG data to the browser phone, it is necessary to generate binary encoded PSVG code. In this process, a pursing pre-process is done by utilizing XEUS sheets, so this omits the pursing process on the client and the total system response becomes very fast.
(3) Mobile Client
To construct a practical mobile client server system, we utilized the following infrastructures: (1) a cellular wireless communication network (KDDI), (2) a gateway service from wireless to the internet (EZ-Access), (3) a Java Midlet management service for the 2.5G browser phone (EZ-plus), and (4) a highly sensitive and accurate LBS (gpsOne).
The inner system structure of the client is as follows. The base level is a Rex operating system supported by Qualcomm Ltd., the second level is a Java processor composed of J2ME/CLDC with KDDI's MIDP added, and the third level is the PSVG viewer supported by KDDI Lab. These applications were downloaded into the browser phone via Midlet forms, and executed under this J2ME environment.

6.2 Performance Evaluation

We implement an actual test-bed system using devices available in December 2001 and evaluated its performance. First, we will outline the results we obtained by measuring server-side performance.
Measured Performance:
PSVG generation time = 0.9 sec (Summarization: 0.7 sec, PSVG conversion: 02 sec)
Data Compression = 5.7% (Summarized and Encoded PSVG / Original SVG )
Measuring Conditions = Utilization of "Numerical Map 2500"
Location: Tokyo Station, range of area: 1 square kilometer.
PSVG server specifications:
OS = Windows 2000, CPU = Pentium IV 2.2 GHz, Main Memory = 1 G Bytes

Next, we will report on the results we obtained by measuring client-side performance. Here, we utilized three kinds of client systems, and the specifications of each client and their performance are shown in Table 6.1. We expected to be able to use Hitachi's newest model that adopted SH-Mobile as the media processor for the 3G browser phone, but it was not available at the time. So we utilize the evaluation board for the substitution.

Table 6.1: Evaluation of responce properties.
PSVG Rendering20 Sec16 Sec0.8 Sec
Local Process Responce1.7 Sec1.5 Sec0.25-0.3 Sec
gpsOne Responce15-30 Sec15-20 Sec --

We evaluated the system performance of each part of the test-bed system from a practical viewpoint. First, it may be said that a server response time of 0.9 sec is almost satisfied. This performance has a relation to the data compression rate which is found that an ordinal ZIP compression rate of 33% is drastically improved to 5.7%. However, as this response was measured under single-user conditions, it was necessary to measure and evaluate it in a multiple-user environment. To do this, we conducted a trial where we measured the inclination of response time by using a load increasing simulator, but as the results depended on the properties of the hardware and software, we have omitted detailed reporting in this paper.
However, we were able to evaluate the response of a 2.5 G browser phone, representative of the mobile client. It is obvious that the PSVG rendering time of 16-20 sec is too long; however, pursing time is not necessary and the rendering process is executed directly by ZEUS encoding. Also, the local display response time of 1.5-1.7 second is too slow. This means that the valence between the processing power and processing burden do not match sufficiently. Here, the processor of the browser phone was an MSM 3300 made by Qualcomm Ltd. (estimated CPU power of about 1-2 MIPS).
As previously mentioned, we could not use the Hitachi 3G browser phone because it was not available. It is equipped with dual processors: the first is for ordinal modem processing, and the second is specialized for multimedia processing and it is planned for delivery soon. We will measure its performance when it arrives, but as the product announcement for this model has been delayed, we have had to change plans to utilize the evaluation board of the SH-Mobile instead of the browser phone. The measured performance results are shown to Table 6.1; the PSVG rendering time is 0.8 sec, and the local display response is 0.25- 0.3 sec. These results are very fast, exhibiting good properties, so there are prospects for practical use, and we expect these characteristics to appear in real products.

7. Conclusions

In this paper, we discussed specifications and how to implement mobile vector graphics (PSVG), to achieve a spatial information service for 3G browser phones. We arrived at the following conclusions.
(1) To supply ample and inexpensive spatial content, it is necessary to activate multiple legacy content. To do this, we developed an interoperable spatial server access system, and effectively evaluated the implemented test-bed system.
(2) To effectively process spatial data on the browser phone, it is necessary to provide vector graphics that are able to be processed locally. To do this, we used PSVG specifications, which are a subset and extension of SVG for mobile use, in the emulator of a 3G browser phone. The performance was very good (0.25 sec per action), there is a prospect for practical vector graphics to be introduced on browser phones.
(3) To solve the problems of slow communication speeds in wireless networks and narrow displays in browser phones, we developed an effective spatial data compression method (compression rate of 2.5%) that made use of the semantic compression technique using a summarized map and the XML binary encoding technique.
(4) We can make good connections between the spatial information service and LBS, by utilizing 2.5G browser phones and gpsOne, which has higher sensitivity and resolution than ordinal GPS. This system architecture will be inherited by the 3G browser phones, so it is easy to achieve standard LBS.

8. Future work

From an evaluation of this research and development for the spatial information service, we realized that the following need to be done in future projects.
(1) Tune up the PSVG processing engine by utilizing exclusive media processors such as SH-Mobile to speed up responses from browser phones.
(2) Support a non-graphic interface such as voice recognition and synthesis utilizing VoiceXML for the former cellular phones.
(3) Apply an augmented reality technique to allow this spatial information service is realized on the wearable computers to eliminate the problem of narrow displays in browser phones.

9. References

[1] "QUALCOMM CDMA Technologies Delivers World's First CDMA Multimedia Chipset and System Software Solution for Handsets", Qualcomm news release, 16 Aug 2000
[3] Mark Moeglein and Norman Kraser: "An Introduction to SnapTrack Serve-Aided GPS Technology", White Paper of SnapTrack Inc.,

ORACLER: Registered Trade Mark of Oracle Corp.
ArcSDER: Registered Trade Mark of ESRI.
HiRDB/US-SSPR: Registered Trade Mark of Hitachi, Ltd.
AnyGISR: Registered Trade Mark of Hitachi Software Engineering Co., Ltd.
gpsOneR: Registered Trade Mark of Qualcomm Inc.
EZ-AccessR, EZ-plusR: Registered Trade Mark of KDDI Corp.
J2ME/CLDCR: Registered Trade Mark of Sun Microsystems, Inc.