SVG MAP Lab

ENGLISH

• Download SVG Map Toolkit
• SVG Map Profile 1.0

JAPANESE

• SVG Map Toolkitダウンロード
• SVG Map プロファイル1.0

SVG Map Toolkitの0.8.0 がリリースされました

SVG Map Toolkitの0.8.0がリリースされました。

ダウンロードは、今までと同じhttp://blog.svg-map.com/2007/09/svgmaptoolkit.htmlから。

この版では、有効期限が2009年3月31日に延長されています

---

The SVG MAP consortium is pleased to announce the SVG Map Toolkit 0.8.0 release.

The latest release is now available here:
http://blog.svg-map.com/2007/09/svg_map_toolkit.html

The expiration date of the SVG Map Toolkit is extended to 2009-03-31.

The Hyper-Layering

This page is English Version of the Japanese article of this blog.

The most important function of SVG Map as the Web Map platform is the Hyper-Layering.
This function was standardized as SVG1.1 of W3C. However, the arranged explanation concerning this function is not performed in the SVG1.1 specifications. Then, to clarify the behavior of the function, this chapter explains the Hyper-Layering function.

Introduction:
Hyper-Layering is a function to succeed to the basic philosophy of WWW. Therefore, let's reconfirm WWW for the understanding of its meaning.

World Wide Web is an information platform designed under the basic idea that the Internet can be used as a huge database by connecting the information stored computers in over the world (World Wide) connected to the Internet in the shape of a cobweb (Web).

To achieve this, the following unique system architecture was given to WWW.
It offers the cooperation characteristics (or interoperability) that had high versatility with simplicity by giving priority to human understandability in substitution for machine processibility. And, HTML, HyperText and URL realizes it.

1. HTML : Document expression information for person to understand
   It is a document information with the format. It can put graphics data ancillary.
2. Hyper text : Information connection method by user interface
   It is a text where the hyperlink is set up. However, the meaning to which the machine can be understood is not given to the hyperlink.
3. URL+HTTP : Simple access means of each document
   It doesn't use an advanced query language like DBMS, and be an access means to the file on the Internet.

Purpose of Hyper-Layering:
The document which conventional WWW handled was letter information with a format. On the other hand, main document of geographic information is "Map" to abstract geographical features by figure. Moreover, the information connection means that conventional WWW used was HyperText. On the other hand, technique to understand connection of the information by making a comprehensive survey by plural information composed as a "map" is used for geographic information. It is technique to be called "layering". Thus, the method of an expression and cooperation unlike conventional WWW had been adopted for geograohic information from its peculiar characteristics.

Then, it is the Hyper-Layering to enable the use of the technique used by such a geographic information by enhancing WWW. Hyper-Layering connects the geographic informations by the layering of two or more maps indicated by the hyperlink.

Specification of Hyper-Layering:
Hyper-Layering is expressed by the SVG data. Its meaning is that an SVG format takes a function of inter-operation role (the Hyper-Layering) as well as expression of a map (map expression by figures). By the way, the HTML takes document expression (a formatted document) and inter-operation (HyperText), too.

Hyper-Layering is basically executed on the browser in accordance with SVG Map Profile by the following procedures.

1. A SVG data (which called container) that directs Hyper-Layering is read.
2. It accesses the map layers according to the hyperlink described in the container.
3. The acquired map layer data is synthesized (layered), and the desirable map presentation is obtained.

These processing can be executed by the browser, and open standardization of this procedure for WWW is promoted. That is a reason why we say that only SVG Map is Web Map. And there are many map services that it is not appropriate to call "Web Map" as follows.
* The cooperation of geographic information by the hyperlink cannot be done.
* Even if it is possible to cooperate, the complicated procedure different from a mere hyperlink is used.
* Or, it can be executed only on the server side.
* Open standadization is not promoted. (It tends to use an exclusive browser by Javascript etc.)
In other words they are map service which merely borrowed communication environment of the Web. And, these might promote making of sterilization of WWW. (See also:http://yupnet.org/zittrain/)

image : XML element that executes Hyper-Layering
An image element is an element prescribed by SVG1.0 and offers a function to stick other graphics documents ordered in the hyperlink attribute (xlink:href) on an SVG document. Therefore Hyper-Layering is carried out by image element by appointing a document to compose. We call SVG data with hyperlink to the map layer to carry out hyper layering the "container".
In addition, the order of composition (layers) obeys the drawing order of SVG documents. That is, the element described before than the image element is piled below, and the element described later than the image element is piled up.

Geographical coordinates : Required meta data for Hyper-Layering
The individual SVG document has an individual coordinate system, but they have to be composed while merging the geographical position. Therefore geographical coordinate must be shown in each SVG map document. The specifications about the setting of the geographical coordinate are mentioned here.

width, height attributes of image element : Attributes that is omissible for Hyper-Layering
With the normal SVG specifications, we cannot omit the width,height attribute of the image element. On the other hand, the first purpose of the Hyper-Layering is to layer a map definitely. It may be carried out an SVG map having geographical coordinate meta data without those attributes. Therefore it is assumed that SVG Map Profile can omit these attributes so that hyper layering is more easily used. In addition, a new function will be carried out when these attributes were described.

Example:
<svg  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:go="http://purl.org/svgmap/" viewBox="122.93 -45.52 20 20" >
<metadata>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs="http://www.ogc.org/crs" xmlns:svg="http://www.w3.org/svg" >
  <rdf:Description>
   <crs:CoordinateReferenceSystem rdf:resource="http://purl.org/crs/84"  svg:transform="matrix(1.0,0.0,0.0,-1.0,0.0,0.0)" />
  </rdf:Description>
</rdf:RDF>
</metadata>
<image xlink:href="http://www.svg-map.org/svg/basemaps/cyberJpN35.svg"/>
<image xlink:href="http://www.svg-map.org/wms/smap.svg?dataset=bosai"/>
</svg>

ハイパーレイヤリング

WebMapプラットホームとしてのSVG Mapの最も重要な機能がハイパーレイヤリングです。この機能はW3CのSVG1.1において標準化されました。しかしそのSVG1.1仕様書では、この機能を中心に整理された説明がなされていません。そこで、その機能の振る舞いを明確にするため、この章ではハイパーレイヤリング機能を整理して説明します。

はじめに：
ハイパーレイヤリングはWWWの基本理念を継承した機能です。その意義の理解のためにWWWを再確認したいと思います。
WWW（World Wide Web)は、インターネットに接続された世界中(World Wide)のコンピュータの情報を蜘蛛の巣(Web)状に連結することで、インターネットを巨大なデータベースとして使えるようにしようという基本理念のもとで設計された情報プラットホームです。

これを実現するために、WWWには高度な機械処理の代わりに人が理解できることを優先することで、単純でしかも高い汎用性（融通性ともいえる）を持った連携性を提供するという設計思想が与えられました。それを実現するのが、HTML・ハイパーテキスト・URLです。

1. 人が理解するための文書表現情報：HTML
   書式付きの文書情報。補助的に(挿絵として)グラフィックスデータを貼り付けることもできる
2. ユーザインターフェースによる情報連結：ハイパーテキスト
   ハイパーリンクが設置されたテキスト。ハイパーリンクには機械が理解できる意味は与えられない
3. 文書単位の単純なアクセス手段：URL+HTTP
   DBMSのような高度な問い合わせ言語を用いず、インターネット上のファイルへのアクセス手段のみ

ハイパーレイヤリングの目的：
従来のWWWが扱ってきた文書は書式付きの文字情報でした。一方地理情報の主要な文書は図形によって地理的特徴を抽象する「地図」です。
また、従来のWWWが利用する情報連結手段はハイパーテキストでした。一方地理情報では複数の情報を地図上に（合成）重畳し総覧することで情報の関連を知る手法が使われます。このように、地理情報はその特性から従来のWWWと異なる表現と連携の方法が採られてきました。

WWWを拡張することで、このような地理情報で用いられる表現と連携の手法を利用可能にしたのがハイパーレイヤリングです。ハイパーレイヤリングは、ハイパーリンクによって指し示された複数の地図レイヤーを重畳して表現することで、地理情報を連結します。

ハイパーレイヤリングの仕様：
ハイパーレイヤリングはSVGデータ形式によって表現されます。その意味は、地図の表現(図形による地図表現)だけではなく、連携の機能(ハイパーレイヤリング)をもSVG形式が担うということです。ちなみにHTMLでも文書表現(書式付文書)と連携(ハイパーテキスト)を一つのデータ形式が担っています。

ハイパーレイヤリングは以下の手順でSVG Map Profileに準拠したブラウザ上で実行されます。
①ハイパーレイヤリングを指示するSVGデータ(コンテナ)を読み込む
②同データに記載されるハイパーリンクに従って、地図レイヤーデータにアクセスする
③取得した地図レイヤーデータを合成して、所望の地図表現を得る

＃これらの処理が、サーバではなくブラウザで実行されることと、それをWWWのオープンスタンダード化していることが、私どもがSVG MapこそがWeb Mapであると言う所以です。
＃巷にはハイパーリンクによる情報連携ができなかったり、（連携できても、単なるハイパーリンクではない複雑な連携手順を使っていたり）、できているようでサーバでしか実行できなかったり、オープンスタンダード化していなかったり（独自のブラウザ(最近ではJavascriptによる)を使うものが多い)する、ただWebの通信環境を間借りしただけの地図サービスが多く存在しますが、それらを"Web Map"と呼ぶのには疑問が残ります。　ご参考

ハイパーレイヤリングを実施するXML要素：image
　image要素はSVG1.0から規定されている要素であり、そのハイパーリンク属性(xlink:href)で指示された他のグラフィックス文書をSVG文書に貼り付ける機能を提供します。
そこで、このimage要素によって重畳する文書を指定することで、ハイパーレイヤリングが実施されます。ハイパーレイヤリングのための地図レイヤーのハイパーリンクが設定されたSVGデータを「コンテナ」と呼ぶことにします。

また、重なりの順序はSVG文書の描画順序に従います。すなわち、そのimage要素より前に記述された要素は下に、後に記述された要素は上に重なります。

ハイパーレイヤリングのための必須のメタデータ：地理座標
　個々のSVG文書は個別の座標系を持っていますが、地図では地理的な位置を合わせて重畳する必要があります。そのため、重畳される各々のSVG文書には全て地理座標が設定されていなければなりません。地理座標の設定に関する仕様はこちらに記載されています。

ハイパーレイヤリングのために省略が許容される属性：width,height
標準のSVG仕様では、image要素のwidth,height属性は省略できません。一方、ハイパーレイヤリングの第一の目的は地図を正しく重ね合わせることです。これは地理座標が設定されたSVG地図であれば、それらの属性が無くても実行できるでしょう。そこで、より簡単にハイパーレイヤリングを使えるように、これらの属性を省略可能とします。
なお、x,y属性を含め、width,height属性を省略せず記述した場合には、別に規定される新たな機能が実行されます。

サンプル：
<svg  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:go="http://purl.org/svgmap/" viewBox="122.93 -45.52 20 20" >
<metadata>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs="http://www.ogc.org/crs" xmlns:svg="http://www.w3.org/svg" >
  <rdf:Description>
   <crs:CoordinateReferenceSystem rdf:resource="http://purl.org/crs/84"  svg:transform="matrix(1.0,0.0,0.0,-1.0,0.0,0.0)" />
  </rdf:Description>
</rdf:RDF>
</metadata>
<image xlink:href="http://www.svg-map.org/svg/basemaps/cyberJpN35.svg"/>
<image xlink:href="http://www.svg-map.org/wms/smap.svg?dataset=bosai"/>
</svg>

SVG Map Toolkitの0.7.0 がリリースされました

SVG Map Toolkitの0.7.0がリリースされました。

ダウンロードは、今までと同じhttp://blog.svg-map.com/2007/09/svgmaptoolkit.htmlから。

この版では、有効期限が2008年12月31日に延長されています

---

The SVG MAP consortium is pleased to announce the SVG Map Toolkit 0.7.0 release.

The latest release is now available here:
http://blog.svg-map.com/2007/09/svg_map_toolkit.html

The expiration date of the SVG Map Toolkit is extended to 2008-12-31.

Base map of japan with 1:25000 resolution

This page is English Version of the Japanese article of this blog.

We open a base map of Japan that uses Digital Map 25000(Spatial Data Framework).
This map is tiled maps divided equally based on "Grid Square of Third Area Partition". The tiling is achieved by the hierarchical SVG Map container data with three hierarchies.

Amount of files: About 350,000 tiles
Total data size: About 1.2GB (They are totally static data.)

Please access following URL by using PC in which SVG Map Toolkit is installed.
URL: http://www.svg-map.org/svg/basemaps/worldNm25k.svg

The high-resolution map will be displayed if expanded to some degree.
#Note: A part of data of Ishikawa Prefecture is missing.

Base map with auxiliary-line of Secondary Area Partition is also opened.
URL: http://www.svg-map.org/svg/basemaps/worldNm25kmesh2.svg

「この地図の作成に当たっては、国土地理院長の承認を得て、同院発行の数値地図25000(空間データ基盤)を使用したものである。(承認番号 平成15総使、第229号)」

数値地図25000ベースのSVGベースマップ

数値地図25000(空間データ基盤)を使ったSVG Map形式の日本の基盤地図を公開します。
3次メッシュ単位に等分割した地図を3段階の階層的なコンテナによりタイリングしています。

総ファイル数　約35万個、合計ファイルサイズ　約1.2GB、完全に静的なデータです。

ＵＲＬ：http://www.svg-map.org/svg/basemaps/worldNm25k.svg

SVG Map ToolkitがインストールされたPCでお試しください。ある程度拡大すると、数値地図25000レベルの地図が表示されます。
＃注：石川県の一部にデータ欠落があります。

2次メッシュの補助線入りの地図も公開します。
ＵＲＬ：http://www.svg-map.org/svg/basemaps/worldNm25kmesh2.svg

「この地図の作成に当たっては、国土地理院長の承認を得て、同院発行の数値地図25000(空間データ基盤)を使用したものである。(承認番号 平成15総使、第229号)」

The system which performs hyper-layering of a landslide map and a 1:25000 topographical map

This page is English Version of the Japanese article of this blog.

We release the SVG Map based web map mashupping system which performs a composite view (Hyper-Layering) of landslide map data base which National Research Institute for Earth Science and Disaster Prevention releases and 1:25000"DENSHI-KOKUDO" topographical SVG map which released Geographical Survey Institute.

Please access the following URL with PC in which SVG Map Toolkit was installed.
http://www.svg-map.org/svg/wmsGw/CJ_BOSAI.svg

Supplement :
In this system, the SVG-ize server which enables it to treat the map services provided by the WMS specifications of OGC as SVG Map is used.
# The server of an original landslide map has a WMS interface.

The SVG-ize server is only a server which generates the container SVG data which refers to a WMS server instead of a gateway which performs the reworking of the data of a WMS server. Therefore, the processing is light and constructing as a static data is also easy.  (See Also: Relationship between WMS and SVG Map )

Although some characteristic mechanisms are further included in this server, I would like to explain in full detail separately about those mechanisms.

Rendering performance of SVG Map

This page is English Version of the Japanese article of this blog.

We achieved the rendering performance comparison of the mapping platform following the article on the storage efficiency. The data used for it are as follows.

1. The coastlines in Japan which makes the GLOBAL MAP an origin
   SVG:0.9MB, GeoJSON: 1.6MB, KML: 2.3MB
2. The roads in Japan which makes the GLOBAL MAP an origin
   SVG: 10MB, KML: 29MB
3. The river lines in Australia which makes the GLOBAL MAP an origin
   SVG: 54MB

Among these, the data of 1 and 2 is the one having used it in the article before.

The environments used are as follows.

SMT	SVG Map Toolkit 0.6
FFX	FireFox3.0.1
OPR	Opera9.5
ASV	Adobe SVG Viewer 3.0
REN	Renesis Player 1.0
OLI	OpenLayers 2.6 / Internet Explorer6
OLO	OpenLayers 2.6 / Opera9.5
OLF	OpenLayers 2.6 / FireFox3.0.1
GMI	Google Maps / Internet Explorer6
GEO	Google Earth 4.3

Everythings are operated on Pentium M 1.1GHz 768MB WindowsXP(JP).

Performance measurement results concerning data "1" (unt:[seconds])

SVG					GeoJSON			KML
SMT	FFX	OPR	ASV	REN	OLI	OLO	OLF	OLI	GMI	GEO
0.6	1.5	1.2	1.7	0.7	Hang up	9	11	Hang up	Stall	2.5

Performance measurement results concerning data "2"
(OpenLayers and GoogleMaps dropped out. )

SVG					KML
SMT	FFX	OPR	ASV	REN	GEO
2	19	11	17	6	43

Performance measurement results concerning data "3"
(KML dropped out. )

SVG
SMT	FFX	OPR	ASV	REN
11	51	34	48	17

Processing speed of SVG Map Toolkit was the highest among these. It is because it is tuned by paying attention to the rendering performance of map data.

On the other hand, though this was expected, viewers coded with javascript (OpenLayers and Google Maps) seems to be far behind native code viewers, in the point of the performance. It seems that a lot of various resources were consumed, and operation was also unstable.

The display of the vector data may be very important for the map services. And, we are considering that drawing of the vector data at "1" level should be able to be executed easily. (If it is a compressed format (.svgz), such data is a suitable size for today's WWW.) However, it might be considerably difficult for today's ordinary PC as long as it depends on javascript viewers.

SVG Mapの描画性能

先日の格納効率の記事に続き、描画性能の比較を行ってみました。

使用したデータは、

1. 地球地図起源の日本の海岸線
   SVG:0.9MB, GeoJSON: 1.6MB, KML: 2.3MB
2. 地球地図起源の日本の道路
   SVG: 10MB, KML: 29MB
3. 地球地図起源のオーストラリアの河川
   SVG: 54MB

このうち、１と２は先日の記事でも使用したデータです。（ただし、属性データは除いてあります）

使用した環境は、以下になります。

SMT	SVG Map Toolkit 0.6
FFX	FireFox3.0.1
OPR	Opera9.5
ASV	Adobe SVG Viewer 3.0
REN	Renesis Player 1.0
OLI	OpenLayers 2.6 / Internet Explorer6
OLO	OpenLayers 2.6 / Opera9.5
OLF	OpenLayers 2.6 / FireFox3.0.1
GMI	Google Maps / Internet Explorer6
GEO	Google Earth 4.3

なお、全てPentium M 1.1GHz 768MB WindowsXP(JP)上で動作させています。

１のデータの測定結果（以下、単位は全て[秒])

SVG					GeoJSON			KML
SMT	FFX	OPR	ASV	REN	OLI	OLO	OLF	OLI	GMI	GEO
0.6	1.5	1.2	1.7	0.7	Hang up	9	11	Hang up	Stall	2.5

2のデータの測定結果 (OpenLayersとGoogleMapsには脱落してもらいました)

SVG					KML
SMT	FFX	OPR	ASV	REN	GEO
2	19	11	17	6	43

3のデータの測定結果 (KMLには脱落してもらいました)

SVG
SMT	FFX	OPR	ASV	REN
11	51	34	48	17

SVG Map Toolkitは、地図データの描画性能に着目してチューニングされているので、最も高速に処理できています。

一方、予測はしていましたが、javascriptでコーディングされたビューア(OpenLayersやGoogleMaps)の性能はネイティブコードのビューアには遠く及びません。様々なリソースを多く消費しているようで、動作も不安定です。"1" 程度のベクトルデータの描画は一般的にこなせる必要が有ると考えています(ZIP圧縮形式".svgz"にすれば、現代のwwwではごく普通のファイルサイズになります)が、普及しているPCのレベルではかなりきびしいようです。

Relationship between WMS and SVG Map

This page is English Version of the Japanese article of this blog.

WMS has weak points as pointed out in the article before. SVG Map can offer a complementary solution. Then, a concrete adjustment point of the specification of SVG Map and WMS is described as follows.

Cross-reference of specification:

• In the specification of WMS, SVG is provided for as one of the format of map drawing.
• In the specification of SVG Map, the GetMap request of WMS can be treated as one of the enhanced query part of URL.

Therefore, they have adjusted mutually.

Geographic coordinates of map:

• SVG Map buries geographic coordinates as metadata in map data.
• Geographic coordinates for the map appear on query part of the protocol in WMS.

Therefore, it is necessary to memorize the requested parameter in WMS to maintain geographic coordinates for the downloaded map. SVG Map will solve this problem.

Tiled map:

• SVG Map supports tiling by preparing container SVG data. Container SVG data refers to the tile data by URL.
• WMS can generate the tile of the arbitrary division. The tile can be accessed by enhanced URL (GetMap request).

SVG Map client doesn't know the access method to the map server excluding URL of tile data described in container SVG data. That is, the accesses other than these URL do not occur. Then, the server of WMS can achieve speed-up by caching URL described in container SVG data.

• Example data
• Reference system implementation

Layering:

• SVG Map supports layering by preparing container SVG data. Container SVG data refers to each layers by URL. (That is the Hyper-Layering.)
• WMS can generate the arbitrary layer. The layer can be accessed by enhanced URL.

On the other hand, the support of layering function on the server side is a difficult in the point of the performance.

Therefore, the WMS protocol and SVG Map adjust well, and will be able to have a supplementary relation.

Special purpose XML languages for WMS:

On the other hand, SVG Map doesn't basically support data other than the SVG format. (However, PNG and JPEG are supported. ) That is, the interpretation of data by proper XML languages for WMS (response data of GetCapability and GetFeatureInfo request) is outside the specification of SVG Map.
However, a considerable functions that those languages aims will be able to be converted into container SVG of SVG Map. This conversion will be able to be achieved by processing by javascript on the client side, or batch processing at data origination, or dynamic processing on server side etc. Convertible functions are as follows.

• Notification of range of map that server offers
  SVG Map client doesn't know the access method to the map server excluding URL of tile data deployed in container SVG data. That is, the range of the map service can be transmitted to the client by deploying as URLs of container SVG.
• Notification of kind of layers that server offers
  SVG Map client doesn't know the access method to the map server excluding URL of tile data deployed in container SVG data. That is, the kind of the layers that provides the map service can be transmitted to the client by deploying as container SVG.

GetMap Protocol:

On the other hand, there might be a lots of use cases that tells the server the value of a geographic view box of the viewer for the SVG Map platform. Therefore, sharing the means for it might be significant. And, it is appropriate to use query part of http GET as this means. The GetMap request of WMS will be able to be used as the concrete specification. We plan to establish this function as one of the specifications of SVG Map Profile.