Activities for realization of interoperability of location based services using SVG

Keywords: GIS, JaMaPS, paper, svg, interoperability, LBS, layering

Satoru Takagi, Mr.
Research Engineer
KDDI R&D Laboratories
Internet Applications Laboratory
Kamifukuoka-shi
Saitama
Japan
takagi@kddlabs.co.jp
http://www.jamaps.org/

Biography

My research theme is web applications and spatial information systems. Our controlling company KDDI is a communication career which offers an international phone call, a long-distance call, a cellular phone, etc. I developed the mapping system for the underwater robot for submarine commnunication cable construction. From 1995, I applied web technology to this system. From such circumstances, the development of spatial information service platform based on web technology is one of the main research themes of mine. I developed SVG (Scalable Vector Graphics) browsers for embedded computers. One of the concrete target is a cellular phone. I have standardization activities about the spatial information systems in Japan. Moreover, KDDI R&D Laboratories Inc. is the member of W3C, and we are cooperating in the standardization of SVG.

Arei Kobayashi, Mr.
Research Engineer
KDDI R&D Laboratories
Internet Applications Laboratory
Kamifukuoka-shi
Saitama
Japan
takagi@kddlabs.co.jp
http://www.jamaps.org/

Biography

My research theme is Mobile Computing field. Especially, I am researching and developing graphics information sharing platform by using XML based graphics format SVG. Until now, I developed SVG browsers for PC,PocketPC, and Palm device. And now, My target device is cellular phone. I am researching and designing extended SVG specification for cellular phone, and I am developing SVG browser for cellular phone. Moreover, KDDI R&D Laboratories Inc. is the member of W3C, and I am the member of SVG Working Group.

Takaya Tanaka, Mr.
Research Engineer
KDDI R&D Laboratories
Internet Applications Laboratory
Kamifukuoka-shi
Saitama
Japan
takagi@kddlabs.co.jp
http://www.jamaps.org/

Biography

.


Abstract


Introduction: Realization of interoperability has been a major problem of geographic information systems for many years. In order to solve this problem, KDDI R&D Laboratories has been developing a map distribution system called JaMaPS (Jammed MaPping System) since 1996. The architecture prepared by JaMaPS differs from conventional types.

Outline of JaMaPS: JaMaPS is designed based on the architecture of WWW. It arranges various maps on WWW servers. A map is figurized geographic information. For example, those map contents are the SVG contents of a road map, a weather bulletin, traffic information, etc. A client downloads maps from WWW servers, and overlays and displays them. This simple technique makes it possible to distribute geographic information as parts. And they are combinable. Therefore, the interoperability of a geographic information system is realizable.

The feature of WWW which we especially thought as important is that WWW distributes visible presentation data rather than informational structures or meanings. In order to actually offer an interoperable system, it is a major premise that the system is widely used. WWW offers system flexibility, and ease of understanding by the distribution of presentation data. We thought that this feature led to the rapid growth of WWW. Therefore, we also provided this feature to JaMaPS.

One of the typical presentations of geographical information is a map. We thought that the problem could be solved without being highly dependent on the standardization of complicated and difficult geographic information by distributing a map, instead of geographic information. Since vector graphics format was suitable for map distribution, we initially used PostScript.

Standardization activities: Then, in response to the standardization activities of SVG, we continued the development of JaMaPS based on SVG. In order to overlay maps, information which enables the arrangement of each map on geographic space was necessary to be added. The information necessary to achieve map overlaying are the description of the spatial reference system which specifies geographic space, and transformation parameters for projecting a map on the geographic coordinate system. SVG is able to describe arbitrary transformation parameters. Therefore, the lone information which needs to be referred to from the standardization activities of geographic information is the description method of a spatial reference system. The result of GML of OGC can be applied for this description. As mentioned above, resources for the realization of the architecture of JaMaPS was prepared by 2001. Then, in order to reflect JaMaPS' architecture in SVG1.1, we participated in standardization activities. Consequently, use of the architecture of JaMaPS was attained in SVG1.1.

Location based services: Our company offers several mobile information services, represented by the cellular phone. Among these mobile information services, location based service is expected to be one of the most important services. Therefore, we are participating in standardization activities in order to introduce SVG1.1 specifications into the JIS (Japan Industrial Standard) of location based services in Japan. Standardization members are considering extension of point information caled POI (Point of Interest) . POI is a framework of position information and its attributes. Standardization members believe that this is indispensable information for location based services. POI is compatible with SVG1.1, and is examined as a specification which can be displayed as SVG. Based on our experience, we believe that SVG1.1 is the most realistic and optimal format to realize interoperability of geographic information systems. In addition, another report will be presented by Tanaka of KDDI R&D Laboratories regarding experiments of location based services using SVG.


Table of Contents


1. Introduction
2. Interoperability in spatial information systems
3. The concept of JaMaPS
4. The specification of JaMaPS
5. Standardization activities
     5.1 Standardization activities in Japan
     5.2 Standardization activities at W3C
6. Browser for mobile phones
7. Extended functions
     7.1 Display control based on scale
     7.2 Map request protocol
     7.3 Deformation map with geographic coordinates
     7.4 Data compression
8. Base map server
9. Summary
Acknowledgements
Bibliography

1. Introduction

Along with the progress of information technology, the diversification of information processing devices has been accelerated and gradually started expanding their targeted area from offices or households into a new real world. With this change of applications, we are now facing the necessity of processing various types of information existed in the real world.

As each of all real world information has its own assigned location, it has become necessary for us to handle location information when using recent information systems. We call this type of information systems as, in a broad sense, spatial information systems. Today, these spatial information systems are no longer used only by particular organizations or groups, but rather used widely by the general public. In other words, we can safely say that spatial information systems have started acting the role of infrastructure. Here, we will call such widely used spatial information systems as location based services.

To use special information systems or location based services, we need to have such functions as acquiring location information, processing, and outputting toward the user. With traditional information systems, we have used some sentences to output information. However, when using spatial information systems, we are to use, in many cases, graphical maps for outputting, which enables us to use graphics formats to display maps. SVG is a very promising format having such capability.

At the same time, information systems are required to secure interoperability. The more fundamental and essential the function becomes or the more the targeted systems exists in number, the more demands there are for the interoperability of information systems. Therefore, it is strongly requested for the needs of the interoperability of spatial information systems, (i.e., location based services), which has become widely used as infrastructure. To secure the interoperability as infrastructure, its standardization is indispensable, and the implementation of interoperability in spatial information systems has long been an issue to be solved. Now, against the background of widespread use of location based services, a demand for the implementation of interoperability in spatial information systems is getting bigger and bigger.

This article is written for the purpose of indicating that SVG is a most suitable platform to provide interoperability in spatial information systems acted as infrastructure, and to explain how vigorously we have been or will be working on the realization of interoperability.

2. Interoperability in spatial information systems

The reason why we provide interoperability in information systems is to modularize several overlapped processing, make them interchangeable, and finally enhance the efficiency of information systems operated in various locations, through sharing or diverting such parts. To modularize several processing as interchangeable parts, we need to set up common rules among individual systems and make all of the systems interchangeable, and by doing so, we can obtain our seeking optimal efficiency of the system, thanks to interoperability. In short, what we need most is its standardization.

In spatial information systems, at first glance, it seems that we can easily make several location processing interchangeable, but in fact, it is nothing but an abstract concept.

In all information systems, it is possible to configure them by specifying its concrete contents. Therefore, we cannot provide the concrete interoperability of information systems only with the standardization of abstract concepts.

Here, we would like to list some of the specific contents for spatial information systems as follows.

First, we think it necessary to grasp the specific contents of what kinds of processing we should perform. However, the problem is that we need to process different kinds of location information, because each of spatial information systems is configured with different purposes in mind. Therefore, we are required to define the specific contents of this location information processing to provide its interoperability.

Second, when digging though what location information actually means, our research findings clearly shows that it is the abstract concept, representing the aggregation of a large number of complicated data schema. Therefore, in order to specifically define all concepts recognized as abstract location information, we have to define a large number of complicated data schemas.

However, we found it rather impractical to define these all contents, because it involves four difficult issues to be solved, as follows.

  1. The application scope of spatial information systems is still expanding, which means that the number of specific contents is steadily increasing. Obviously, the more specific contents increases, the more resources for human, material or time is required to create such specifications as containing all of them, resulting in not enabling you to promptly deal with actual demands. As an example, we can take up standardization activities of spatial information systems currently being underway at OGC (Open GIS Consortium) and ISO. At present, these activities has continued over a long period of time, and despite of their being still on the way, their systems or specifications have turned out to be huge ones, compared with SVG .
  2. Even if they could manage to define all of them, the more there are specifications defined in such a way, the less there are the number of specific information systems using such specifications, resulting in less efficient in interoperability. For example, assuming that there are one thousand pieces of definitions, against which we use one thousand units of information systems, then there is a possibility that, in worst-case scenario, we cannot have any interoperability among the systems. To prevent such diversified specifications like this case, standardization activities in recent years have shown a tendency to recommend an abstract dominant concept containing these specifications as well as the establishment of structured specifications.
  3. Even if we could establish such structured specifications by building an abstract dominant concept, it is obvious from Issue # 2 that we can not obtain interoperability only through the standardization of part of an abstract concept. This is quite simply a dilemma for us. Moreover, as we have to take abstract concepts into consideration whenever we describe a concrete specification, the data structure or system results in becoming unnecessarily complicated. For example, when describing a certain data, it forces us to describe starting from the concept, which renders the data into abstract ones in multi-stages. In other words, it looks like compiling a dictionary rather than building data, leading to an unpractical enormous amount of data. In short, we can say that the significance of abstraction in the standardization process would be no more than just sorting out issues to be solved.
  4. Even if we could provide a versatile system supporting all of such huge specifications, there still remains a question whether or not the user can master such huge specifications, obviously being not an easy task. As a result, only some particular organizations or groups will benefit most from this situation, leading to the occurrence of what we call "Digital divide". Therefore, in order for an interoperable spatial information systems to function not only for particular organizations or groups, but also as infrastructure used widely by the general public, we think it very important to make specifications as easy and understandable as possible.

By the way, XML is a high-level descriptive language, enabling us to describe a versatile and yet complicated data structure. Therefore, XML makes it possible for us to describe the complicated data structure of location information. Thanks to this great advantage, recently the standardization activities of location information using XML has been actively promoted. The standardization work of GML (Geography Markup Language) [GML] at Open GIS Consortium is one of typical examples. However, the issue mentioned earlier regarding the standardization of location information cannot be solved only through the use of XML with high-level descriptiveness, because all XML can do is just to make complicated data structures readable. We would like to point out here that, as a result of the excessive expectations and misunderstandings for XML in recent years, the issue regarding the standardization of spatial information seems to have been neglected, and consequently the standardization of location information via XML has been in progress, embracing the same problem. Therefore, if these standardization activities should aim at the general public rather than particular industries, we strongly suspect its practicability.

3. The concept of JaMaPS

We started working on a new architecture that meets all requirements described in the previous chapter, which fits the standardization and can be widely used by the general public.

While working on this project, we set up three design policies on our envisaged architecture to solve the issues mentioned before, as follows.

  1. Aims at a simple specification by limiting the processed contents and functions.
  2. Defines specific contents to be processed, while securing a high versatility.
  3. Defines functions to provide interoperability, while securing a high versatility.

As a possible candidate platform fulfilling these requirements, we paid attention to WWW, which emerged in 1991 and started being explosively popularized around 1995.

Undoubtedly, HTTP, as one of protocols for WWW, will be categorized as a very simple specification. Also, HTML, as one of information scripting languages, will be regarded as basically a simple specification.

The purpose of WWW is to open documents that can be viewed by the human. To enable computers to understand the meanings of data with various purposes and to process the contents, we need to define a huge number of rules. However, if it is limited to the understandings by the human, all information will be expressed as presentation data, and the roles of a WWW server and its terminals will be confined to the distribution of presentation data and the processing of such data. That is, the presentation data has versatility, and the contents to be processed are simple and clear.

HTML, as one of WWW data formats, can describe only data for presentation. In other words, HTML does not have schema or ontology used to describe the information contents. Therefore, the specification and its data size are small. From these points, we can say that WWW will meet our first and second policies described above.

Next, the interoperability of WWW is provided by the hyperlink specification, which is used to relate URI with a part of a document, and the hypertext function to use the hyperlink specification.

Hyperlink is used to point to its associated information unable to be provided by your viewing information, as reference information.

Hypertext is a user interface that expresses the reference information as GUI (graphical user interface) .

For the information system handling presentation as documents, both hyperlink and hypertext are regarded as the realization of a versatile interoperability.

Thus, we can say that WWW has, for the first time, archived to provide information systems with a versatile interoperability, thanks to HTML as presentation data and the interoperability provided by hyperlink and hypertext. However, because WWW aims at the circulation of WWW documents, we thought that WWW was not be suitable as a platform to provide the interoperability of spatial information systems. Therefore, we tried hard to enable WWW to effectively function as the platform for spatial information systems, by taking over the concept as being a provider for interoperability via presentation data and by extending WWW.

Also, we took note of maps made up of graphics data, which are used for the presentation for location information. Maps have a versatility applied to all spatial information systems. On the other hand, the specification of graphics is, just like HTML, very clear and simple as verified in the SVG specification. So, we thought that maps would fulfill the requirements indicated in our first two design policies.

However, we needed to provide a versatile interoperability suitable for maps. Because hypertext in HTML is basically an effective scheme targeted at texts, we cannot use its function for maps.

Even so, in HTML, the clickable map function is provided as a user interface scheme to refer to hyperlinked graphics such as maps. So, here we would like to examine the interoperability provided by the clickable map function.

Suppose a hyperlink using the clickable map function is provided in a certain area on the map, how to use this hyperlink is roughly divided into two categories. One is to link to HTML documents information. This method can be used, for example, for indicating statistical results data of a certain area. The other is to link to another map. This method can be used, for example, for further linking to the detailed map of a certain area.

By using these two methods, it is possible for us to provide a slight interoperability, but we thought it would be completely inadequate, because it did not apply to interoperability that is most important for location information.

The most effective use method for interoperability of spatial information systems is to obtain new information by means of concurrently using information associated with multiple locations. For example, by concurrently using both rainfall prediction information and farmlands information, we can predict the growth status of farm produce.

This is one of typical use methods for GIS (geographical information systems) . In GIS, geographical information with various semantics or data structures, all of which can be interpreted by the computer, are fed into the computer. GIS analyzes and processes such geographical information, based on the data structures or semantics, and then outputs the results. Generally, the interoperability of spatial information systems required the distribution of geographical information matching its processing. However, with this method, we had faced many difficulties in the process of standardization for data used with this method, and furthermore we found that those data could not be used for presentation.

On the other hand, we can point out layering as one of fundamental use methods for GIS. To use the layering, we need to have information related with multiple location figurized beforehand and to render them by matching their coordinates, resulting in the display of one-piece map. This is a classical method that has been used even before the emergence of GIS. That is, the human can enhance its cognitive power by visualizing location information as a map. So, by visualizing multiple information as one-piece map, the human's visual information processing ability is brought out to its full power. As a result, the human can analyze and process such information. Put it briefly, this is a method to exploit the human's information processing ability, not the computer' s processing power.

Layering can be said to be an expensive method, because it does not use the computer as an analytic device. However, it has a big advantage to enables us to use concurrently the information related with multiple locations. In addition, any location information can be figurized and layered. That is, we can say that layering is a versatile and single concept of interoperability for location information. Also, the data needed for layering are basically presentation data, which means all three requirements described before are fulfilled.

A WWW server operated independently on the network will transmit all types of figurized location information. At the client side, such information are accessed and displayed via layering. Like hypertext in HTML, this is a method to provide interoperability by means of presentation. Perhaps, we think that we should call this method as hyperlayering, because it would show this function more appropriately. Figure 1

Access information needed for layering can be described by using hyperlink. There are several ways to describe the hyperlink referring to multiple layers. First one is a case for linking the contents of location information to another contents to be layered. Next is a case for there being multiple contents to be layered, and, the last one is a case for linking the contents with no location information to a group of contents to be layered.

Even though these links is capable of lining multiple regular hyperlinks (XLINK), we can also use an extended link of XLINK.

This is a WWW mechanism that was designed by our team in 1996 and extended for spatial information systems. We named this architecture as JaMaPS. [JaMaPS]

jamaps.svg

Figure 1: JaMaPS architecture

This architecture enables us to facilitate the modularization of spatial information systems. For example, we can offer such distribution services independently as maps, town, or weather information.

To date, it has been only possible to use these services in combination, on the condition that some forms of cooperation among the service providers was established as a business model, because it necessitated a close cooperation among servers. However, it turned out to be not an easy task to have them agreed on such a business model.

Even so, this architecture enables us to very easily use multiple servers in combination, because all information needed to interoperate them is only hyperlink, that is, URI. So, if you know URIs of multiple severs you intend to use, it is possible even for end-users to directly select services and to use them in combination.

This is what makes a big difference between our architecture and the traditional mechanism used to realize the interoperability of spatial information systems. We think our architecture will become a most basic architecture to provide interoperability for spatial information systems using the Internet.

4. The specification of JaMaPS

To realize the concept of JaMaPS, first we started examining a presentation data format, which would act as the base.

Map presentation data are graphics, and there are two types of graphics formats, i.e., the bitmap graphics format and the vector graphics format. Since spatial information systems mainly handle data based on survey results, it has a high compatibility with CAD. For this reason, we selected the vector graphics format created from CAD as our primary graphics format.

However, at that time, SVG has not yet come into being. So, we decided to use PostScript for the time as a versatile graphics format, having a high compatibility with WWW, and to wait for the start of standardization activities of vector graphics at W3C or other organizations. Then, later, the SVG specification was published, we earnestly started working on the realization of the JaMaPS concept based on SVG.

To have our concept realized, we thought it needed to extend the existing vector graphics format. Layering on the map can be realized by matching coordinates of each graphics and by drawing them on a canvas. For coordinates to be matched, it is desirable to use coordinates in common geographical space. However, the problem is that there exists no geographic coordinate in ordinary map graphic data.

So, we needed to relate the coordinates of map graphics data with the matching geographic coordinates. The easiest way to do that is to use coordinates of graphics data as they are, as the matching geographic coordinates.

However, when using this method, for example, we need to describe all numeric values above five places of decimals, to secure the accuracy of "one meter" in the measurements in latitude and longitude.

On the other hand, when describing the coordinate values of ordinary vector graphics, the integer part is used, and the same is applied to SVG.

Moreover, when figurizing geographical coordinate space, generally we use a projection transformation. If it is figurized without the use of projection transformation, the resulting map gets distorted and visually undesirable. For this reason, we concluded that this method was not what we had sought for.

Then, we decided to add parameters for coordinate transformation to graphics information, which serves as the metadata to relate the coordinates of graphics data with those of geographical space.

Since parameters supporting various projection transformations are complicated, we decided to limit the usage to a primary affine transformation.

As you know, the primary affine transformation cannot be applied to, for example, an accurate Mollweide projection. More specifically, it can only deal with limited projections, such as Polyhedron projection, Equirectangular projection, and some of Eckert projections. Even so, because it is possible to figurize maps locally with sufficient accuracy, we thought that there would be not so large practical problems for use of the primary affine transformation.

Besides, the spatial reference system, meaning the coordinate system of geographical coordinate space, had not yet been standardized. So, we decided to add the name of the spatial reference system for the purpose of identification.

To be sure, it is not an easy task for us to perform map layering for different spatial reference systems but never impossible if we use the identifier. In addition, we thought that it would practically possible to realize a usable layering, considering that at that time, the spatial reference system, such as WGS-84 of GPS, had been in progress for standardization.

Furthermore, we thought, if layering based on the spatial reference system was realized, it would enable us to use such a function as one always keeping displaying one's own location at the center on the screen via a positioning system built in the terminal. This is a basic function of spatial information systems using maps on mobile terminals. Figure 2

Basically, we needed only these two extended functions of graphics data to have the JaMaPS architecture workable.

ktai_lbs.svg

Figure 2: Functions of LBS

5. Standardization activities

We thought that the concept of JaMaPS should be widely popularized as a new platform to distribute location information. Based on this policy, we started working on the standardization process, after applying for the patent. (U.S. Patent No. 6,107,961)

The concept of JaMaPS is based on WWW, which naturally makes it most appropriate to realize its standardization at W3C. However, in the 1990's, mobile computing technology was still in its infancy, and the computer have not yet arrived at the stage of full utilization in the real world. Since location based services targeted at information in the real world, we felt at that time that there would be not so much compelling reasons to hurry up the standardization at W3C.

5.1 Standardization activities in Japan

So, before making any suggestions regarding our concept at W3C, we thought we should participate in standardization activities in Japan. Back then, the standardization work called G-XML [G-XML] had started from 1999 in Japan, which aimed at the standardization related with spatial information system using XML. By the way, the G-XML specification has already been standardized and published as JIS [JIS] X.7199. At the G-XML working group, we made a proposal for the concept of JaMaPS, which indicated an extension of the descriptive specifications of both the spatial reference system and coordinate transformation based on the draft specification of SVG 1.0.

Currently, the G-XML working group is working on the examination and standardization of SVG and point information called POI , in which GML of OGC and the concept of JaMaPS are incorporated.

In G-XML, it assumes to use SVG and POI to distribute information between terminals and its server. It also assumes to use GML for exchange of data between servers.

Though the G-XML specification was originally created by means of extending SVG 1.0 uniquely, today, however, it is compatible with Tiny profile of SVG 1.1, except that it absolutely needs to describe the geographic coordinate system. Also, the POI specification is an extension of SVG and is used to add geographical locations to various kinds of information.

Therefore, POI is compatible with display software for SVG, and the use element of SVG is used as POI. For geographic coordinates of POI, geographic coordinates of the use element of SVG are used. That is, these values are the ones that transform x,y attributes of the use element into the geographical coordinate space, and other POI attributes are described in the desc element under the use element. For such attributes, a basic ontology related to some spatial information has been suggested. They include a category string, location string (i.e., address), and time, and the others are described as arbitrary property. For hyperlink, basic functions in SVG are diverted. These attributes can be used as basic functions of a location information browser for displaying, and with using them, it becomes possible to implement a sophisticated geographical information processing function. Figure 3

Because the use element of SVG is defined as POI, and attributes of POI are described as the desc element under the use element, it makes it possible to provide the compatibility with SVG. Therefore, even a SVG browser unable to interpret POI can retain the functions of POI display and hyperlink.

poi.svg

Figure 3: Example of POI over SVG

5.2 Standardization activities at W3C

SVG 1.0 was issued as a W3C Recommendation in September 2001, and along with the maturity of mobile computing technology, there was an increased demand for systems to handle information in the real world. After that, the standardization work of SVG was followed with SVG 1.1, and as one of issues to be solved in SVG 1.1, a new function supporting location based services was taken up at the working group.

Against this background, we put forth the concept of JaMaPS at the SVG working group and started working on the realization of the standardization. During the standardization process, it was decided to use the namespaces of GML to describe the spaceial reference system, because, if what is needed should be limited to just referring to the descriptive method of the spatial reference system, there is no need to worry about issues on GML , such as its complexity. Also, as pointed out, the coordinate transformation between geographic coordinates and SVG coordinates was limited to the primary affine transformation, which led to the realization of a simple specification, as we had desired. Figure 4 Figure 5 Figure 6 Figure 7 Of course, we have agreed with the royalty policy of W3C and declard royalty free concerning the architecture of JaMaPS only use with SVG.

matrix.svg

Figure 4: Transformation parameters (Expression)

projection.svg

Figure 5: Transformation parameters (Direction of conversion)

CRS.svg

Figure 6: Geographic coordinate system

container.svg

Figure 7: Example of hyperlayering by using container SVG.

6. Browser for mobile phones

We are a carrier of both mobile and fixed types of phones in Japan, and mobile phone services are a big income earner for us. Also, location based services serve many uses especially in mobile information communication terminals. Figure 8 As recent mobile phones are mounted with the Internet access and graphic display functions, these devices can be described as typical information communication terminals. To support such terminals, SVG 1.1 defines SVG Tiny profile.

gpsktai.svg

Figure 8: The number of GPS celluar phone

On the other hand, in Japan, proprietary platforms in vector graphics form, such as Shock Wave Flash, has already been adopted and implemented in mobile phones.

Also, the distribution of vector graphics has been already realized on such platforms. However, it is difficult for us to provide location based services by using these engines, because they are not architecture for geographic coordinates or JaMaPS. In addition, we think it impossible to provide interoperability by using these proprietary platforms.

We think that what enables the merits of SVG 1.1 to exploit to the full is location based services. Also, we believe that what plays a central role, as a core in providing the interoperability of location based services using SVG is a browser, because all location based services are to be consolidated by the browser. Right now, we are working on the development of a SVG browser compliant with SVG Tiny profile.

In SVG Tiny, the support for the geographic coordinate system that is needed to realize location based services is defined as optional, but its browser supports the geographic coordinate system. The reason for it, as described earlier, lies in the recognition that this function is most important for SVG Tiny.

The browser is being developed using the C++ high programming language and has such functions as basic graphics drawing, SVG objects management, animation management, and browser applications.

KDDI's mobile phones take advantage of the CDMA 2000 technology of Qualcomm and are operated on BREW, one of its application running environments. Also, because the browser was developed in C++, it has a high portability, making it possible to easily transport into other running environments, such as Windows PCs, T-Engine Figure 10 [T-Engine] , or the Intent.

Also, some of KDDI's mobile phones support the running environment of J2ME CLDC. Though we have not yet incorporated a full set of SVG Tiny into mobile terminals due to the limited J2ME CLDC drawing function, we have developed a SVG browser fully capable of offering location based services.

ktai_hardcopy.svg

Figure 9: Experimental screens of LBS by SVG with celluar phone

t_engine.jpg

Figure 10: SVG Tiny Engine for T-Engine

7. Extended functions

Our developed browser has five extended functions, and these functions are implemented to upgrade the functionality of map applications used mainly on mobile terminals. However it also has a versatility enabling them to be used for other applications.

The five functions are made up of display control based on scale, map request protocol, deformation map with geographic coordinates, data compression, and POI.

POI is implemented based on the POI specification of G-XML as described before, and to enable it to use on mobile phones, is extended to add new attributes, such as the telephone number.

Here, we would like to explain other functions one by one, as follows.

7.1 Display control based on scale

In map applications, we often use zoom-in and/or zoom-out functions. If we want to see the whole view, we will display the map on the screen by zooming it out, whereas, if we want to see a certain area in more detail, we will have the map zoomed-in and display it on the screen.

Therefore, it is quite essential for us to be able to display detailed information when zoomed-in, summarized information when zoomed-out. This is a function that we actually added in our browser. For the realization of this function, we made it possible to describe the scale range attribute visible to all graphic objects of SVG , and the displayed areas of graphic objects is limited by the scaling range within this attribute value. For example, a graphic object to display detailed information has an attribute value to be displayed when zoomed in, whereas a graphic object to display summarized information has an attribute value to be displayed when zoomed out. Figure 11 We think that this function is one of the so-called LOD (Level of Detail) .

ginza_anim.svg

Figure 11: Display control based on scale

figvis.svg

Figure 12: Scale range attribute

7.2 Map request protocol

To display a map conforming to the scaling, we need to update the map's contents whenever it is zoomed in, zoomed out, or scrolled. A server providing this type of maps tends to first decide on the map's scaling and area to be output and then carry it out according to parameters of a search part. At terminals, it becomes necessary to calculate parameters to use this server. Therefore, we need to have a SVG browser that can work with JavaScript etc. As this series of processing is very popular in spatial information systems, we added an extended function to enable us to transmit this request for SVG. Figure 14 More specifically, we describe re-request methods in the metadata at the times of zoom-in/out and scrolling, and parameters-added-requests as shown in the Figure 13 are transmitted.

mapr_protocol.svg

Figure 13: Map request protocol

mapreq_script.svg

Figure 14: Extended script for map request protocol

7.3 Deformation map with geographic coordinates

A map is not necessarily always created based on its accurate location survey. For example, we often use a "rough map" that is simplified and deformed. However, this type of map cannot be transformed between graphical coordinates and the coordinates of map contents by using parameters of affine transformation.

To solve this problem, we made it possible for us to describe in a discrete way the information, relating geographic coordinates with the coordinates of map contents. Figure 15 Figure 16

Our method is as follows. First sets several optional reference points in the SVG contents and describe the coordinates of the reference points as the local attribute.

Next, describes the geographic coordinate matching each reference point as the global attribute. Then, based on this information, performs the coordinate transformation.

For example, this enables us to map the GPS positioning information contained in the terminals onto a deformed map. As for the coordinate transform method, we adopted the one explained below.

First, selects three reference points (p1(x1,y1),p2(x2,y2),p3(x3,y3)), the closest to the survey result (x,y).

Next, by assuming these three points as vertices of a triangle, finds its area coordinate (S1, S2, S3) related to the survey result.

Sets the coordinates of reference points on the coordinate space of the SVG contents matching each reference point as (p1(x1',y1'),p2(x2',y2'),p3(x3',y3')), and the coordinate of positioning data on the contents as (x',y'). Then, the following equation is given.

x'=S1*x1'+S2*x2'+S3*x3'

y'=S1*y1'+S2*y2'+S3*y3'

We have not yet done any strict evaluation on the results, but, when moving along the road based on the "rough map" with four reference points as shown in the figure, we could perform a practical tracking without experiencing any large deviations from marks on the road.

tokyo_def.svg

Figure 15: Deformation map with geographic coordinates

deformation.svg

Figure 16: Transformation parameters for deformation map

7.4 Data compression

Since SVG is an XML-based text data format, its data size is larger than binary data like Flash. To solve this problem, we have developed a new codec called XEUS (XML document Encoding with Universal Sheet) [XEUS] . Figure 17

This codec makes it possible to transform not only SVG but also all other XML data into binary format. The outline is like this: XEUS can encode XML data based on the data adding encoding information to DTD (Document Type Difinition) of XML data (we call it the XEUS encoding table.) Decoding will be done in the opposite way. In addition, it is possible to generate SVG DOM (Document Object Model) directly from encoded SVG data, and in this case, no XML parse is needed. We think that this compression method will be suitable for mobile phones with constrained resources. Our developed SVG browser can display the encoded SVG via this method.

xeus.svg

Figure 17: System configuration chart of XEUS

8. Base map server

We have developed a server to provide map data in SVG 1.1 Tiny format, which uses digital map data issued by the Japanese government as its database. Needless to say, the data include the geographic coordinate system. Also, depending on the map request protocol described before, it can generate maps dynamically according to the scaling or area.

This server has the map generalization function to omit or simplify graphic objects according to the scaling, and with this function, we can reduce the contents size to be output. More specifically, for all ranges of scaling, we can generate map contents fitting within the VGA size, as a SVG file with 100 KB memory consumption. Figure 18 Figure 19

mapdata.svg

Figure 18: Example of SVG data that base map server outputs.

akibamap.svg

Figure 19: Example of SVG contents that base map server outputs.

9. Summary

We have developed JaMaPS, which is our architecture that enables us to realize the interoperability of spatial information systems in the real world, and then we have been working on standardization activities of it. Our efforts borne fruits when our architecture was incorporated in a W3C Recommendation of SVG 1.1.

Now, we have just embarked on the promotion activities of interoperable location based services in the real world, based on the SVG 1.1 Recommendation. Figure 20 [KDDI R&D Labs's activity about SVG]

At the same time, we are still being engaged in R&D activities to extend functions toward SVG and to have spatial information systems much sophisticated based on SVG. We plan to publish our R&D results at http://www.jamaps.org/ and http://www.svgmobile.jp.

webmapping.svg

Figure 20: Interoperable web mapping platform by SVG

Acknowledgements

This research was supported by TAO (Telecommunication Advancement Organization ) of Japan.

The authors would like to thank Dr. Shimada, Hitachi Co., and our colleagues for their encouragement and discussions.

Bibliography

[JaMaPS]
Interoperable web mapping system ,that development started in 1996 by KDDI R&D Labs. (http://www.jamaps.org/JaMaPS/English/jamapsindex.html)
[G-XML]
Spatial data exchange protocol, created and maintained by DPC(Database Promotion Center, Japan) (http://gisclh.dpc.or.jp/gxml/contents-e/).
[GML]
GML(Geography Markup Language) , created and maintained by OGC(Open GIS Consortium Inc. (http://www.opengis.org/)
[JIS]
JIS(Japan Industrial Standard), maintained by Japanese Standard Association.(http://www.jsa.or.jp/default_english.asp)
[XEUS]
The Graphics Information Sharing Platform for Mobile Computing based on SVG, Arei Kobayashi, XML conference 2001, December 9-14,2001. (http://www.idealliance.org/papers/xml2001papers/tm/web/05-05-05/05-05-05.htm)
[T-Engine]
Real-time operating system development environment.(http://www.t-engine.org/)
[KDDI R&D Labs's activity about SVG]
Press release, released in Janualy 14,2003.(http://www.jamaps.org/press/eng.html)

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