SVG MAP Lab

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のレベルではかなりきびしいようです。

Storage efficiency of SVG Map

We compared the store efficiency between a SVG Map format, a shapefile format, and GML (GML2).

2008.07.30 update: GeoJSON and KML were added. (They were converted from shapefile respectively with a free converter. )

When there is little information content of a property (metadata), the size of a SVG Map data is almost comparable as Shapefile. The store efficiency of SVGMap falls as the information content of a property increases. Since it is an XML format, the size of SVG Map is likely to become large, but since SVGMap describes almost all informations as not an element but the property of XML, it is relatively efficient.

On the other hand, the size of a GML data is more than double precision compared with them. It will be because GML has specifications which express almost all informations as a hierarchical XML element.

The efficiency of GeoJSON seems to be better than that of GML though it is lower than SVG Map. The efficiency of KML seems not to be good, for it is designed based on GML and is included the drawing style.

	Shapefile			GML	SVG Map		GeoJSON		KML
	shape (.shp)	property (.dbf + .shx)	summary	(shape + property)	graphic (shape + rendition style )	graphic + property （embedded metadata）	shape	shape + property	graphic (shape + rendition style )	graphic +property
１	1,025	58	1,083	2,446	910	1,175	1,613	1,990	2,322	5,446
２	10,741	7,361	18,102	59,940	10,136	21,475	14,914	28,572	29,639	160,980
３	156	97	253	1,093	136	405	216	527	437	2,793

Unit: KB

1. The coastline in Japan which makes the GLOBAL MAP an origin (It has 7 properties)   
2. The road in Japan which makes the GLOBAL MAP an origin (It has 11 properties)
3. The building shape of the Toyonaka digital map sample (It has 13 properties)

SVG Mapの格納効率

SVG Map形式とshapefile形式、それとGML(GML2)の間で、格納効率を比較してみました。

2008.07.30更新：GeoJSONとKMLも追加しました。（それぞれ、共通のShapefileから変換されたものです。変換はWeb上でフリーで提供されているツールで行っています。）

SVG Mapは、Shapefileと比べて属性(メタデータ)の情報量が少ない場合はほぼ同程度のサイズです。属性の情報量が多くなるとサイズは増加していきます。XML形式のため、サイズが大きくなりそうですが、SVGMapは、ほとんどの情報をXMLの要素ではなく属性として記述するので健闘してます。ただし、属性値だけでなく属性名の記述も個々に必要な分、メタデータの量が増えると分が悪くなります。

一方、GMLは、それらと比べて２倍以上サイズが大きくなってしまいます。GMLはほとんどの情報をXMLの要素として階層的に表現する仕様のためでしょう。

GeoJSONはSVG Mapほどではありませんが、GMLよりは効率が良さそうです。KMLは基本的にGMLベースの設計で描画スタイルも含まれるので効率は良くないようです。

	Shapefile			GML	SVG Map		GeoJSON		KML
	形状 (shp)	属性 (dbf+shx)	合計	(形状+属性)	図形 (形状+描画スタイル)	図形+属性 （メタデータ埋込）	形状	形状+属性	図形 (形状+描画スタイル)	図形+属性
１	1,025	58	1,083	2,446	910	1,175	1,613	1,990	2,322	5,446
２	10,741	7,361	18,102	59,940	10,136	21,475	14,914	28,572	29,639	160,980
３	156	97	253	1,093	136	405	216	527	437	2,793

単位：KB

1. 地球地図起源の日本の海岸線(7項目の属性) 
2. 地球地図起源の日本の道路(11項目の属性)
3. 豊中市デジタルマップサンプルの建物形状(13項目の属性)