This page is English Version of the Japanese article of this blog.
This specifications offers format and processing method for SVG Map data divided into mosaic tegular
Free scrolling map services are provided by a lot of Web Map services including google Maps. The technology that achieves it will be classified into two.
One is a type that dynamically generates the map corresponding to the display area of the user agent from the geospatial data base. Its specifications are provided for as a open and standard like WMS. However, it tends to become heavy because of dynamic map generation process. (See also an article of NASA's OnEarth)
On the other hand, there are type that displays the data divided into mosaic tegular prepared beforehand after clipping and sticking together. This method is advantageous for making to higher performance. In addition, it is advantageous also for the simplification and the lowering the cost of the server. It might be also possible to serve by ordinary httpd without DBMS and dynamic data generation. Therefore, many of services of the map on Web uses this kind of method. However, this method tends to be hard coded and is made for exclusive use at each services. Because a desirable segmentation methodology of the map tile and the access method to it might be different at each service, and the mechanism was achieved by exclusive ECMA SCRIPT program, and it becomes hard code and proprietary so far.
Then, SVG Map profile offers an open latter mechanism by securing the freedom of the segmentation methodology and generalizing the access method. And it is also possible to apply former method like WMS because the access method is ordinary HTTP.
This mechanism is achieved by applying a basic specification of SVG. It explains the method of achieving it as follows.
SVG Map data divided into mosaic tegular
The map tile files will be synthesized to one map with the SVG file that settles them as shown in figure. Thus, the SVG file that importing of other files and settles is called container SVG file.
Here, the function for importing of the file is achieved by <image> element that SVG originally has. Example of container SVG file is shown as follows. The storage structure of each tile is free according to URL. The arrangement place of each tile is also free according to the (x,y,width,
height) attribute. However, it is necessary to describe the arrangement of all tiles into the container SVG file.
Container.svg
<svg ... viewBox="20 110 120 85">
<metadata ... />
<image x="0" y="0" width="100" height="70" xlink:href="0_0.svg"/>
<image x="100" y="0" width="100" height="70" xlink:href="1_0.svg"/>
<image x="200" y="0" width="100" height="70" xlink:href="2_0.svg"/>
<image x="0" y="70" width="100" height="70" xlink:href="0_1.svg"/>
<image x="100" y="70" width="100" height="70" xlink:href="1_1.svg"/>
<image x="200" y="70" width="100" height="70" xlink:href="2_1.svg"/>
<image x="0" y="140" width="100" height="70" xlink:href="0_2.svg"/>
<image x="100" y="140" width="100" height="70" xlink:href="1_2.svg"/>
<image x="200" y="140" width="100" height="70" xlink:href="2_2.svg"/>
</svg>
It is possible to display it by sticking the map tile together by such a description according to an original SVG specification. Moreover, the segmentation methodology of the tile is considerably free. That is, the map where tiling was done can be displayed within the range of the original SVG specification for which W3C provides.
Note 1: However, this is a story in the specification. It actually depends on the content of the viewer implementation. For instance, because svg cannot be referred in < image > element in the SVG viewer of Firefox at present yet, the tiling of SVG cannot be done. (If the tiles are jpeg, it seems to be able to do it. )
Note 2: Even as for hyper-layering that is the function for the main interoperability of SVG Map, container SVG file is important. In tiling, the importing data is arranged. On the other hand, they are piled up in hyper-layering. There are no changes in importing and the display of two or more data.
Implementation specification of viewer
The specification on the viewer side as the SVG Map profile is newly provided.
Requirement 1: First of all, the viewer in accordance with the SVG Map profile should be able to do the importing the SVG files by <image> element.
When the SVG viewer not devised reads container SVG, all the tile data to which the image element refers might try to be downloaded. The problem might be not brought up to the operation of the viewer because there are only nine pieces in the example above. However, a serious problem might occur for data from which is divided into 100x100 tiles for instance. Then the SVG Map viewer should have the following logics corresponding to the above-mentioned container SVG data.
Requirement 2: The viewer in accordance with SVG Map profile should be implementd the following logic at least.
When the area of <image> element (It is specified with w, y, width, and height property ) of the SVG document comes in contact with the view box of the viewer, the data to which <image> element refers are dynamically acquired.
It explains the mechanism in the following figure. [Explanatory drawing of display logic(swf animation)]
Green tiles are tile data that should be loaded.
- First, because viewBox of the container is "20 110 120 85", lower left four files (0_1.svg, 1_1.svg, 0_2.svg, 1_2.svg) are acquired.
- Here, it is assumed that the user did scrolling in an upper right direction. Then, the view box of the viewer moves. As a result, (0_0.svg,1_0.svg) and (2_0.svg,2_1.svg) are loaded one after another.
- Yellow tiles are the data that became unnecessary because it came off from viewBox though loaded once. It depends on the viewer implementation whether maintains as long as the memory permits or throws.
Note: Only by this specification, when a wide view box where all tiles are displayed is specified, reading all tiles will start. In the article in the future, the explanation of the profile that enables the expansion and the reduced display is scheduled.
