21 posts categorized "SVGMapProfile"

2011年12 月27日 (火)

SVG Map対応ブラウザの公開とW3Cへの標準化提案

SVG MapコンソーシアムメンバーのKDDIは、SVG Mapの仕様に準拠したウェブブラウザをオープンソースとして公開しました。実装は、スマートフォンなどで大きなシェアを持つウェブブラウザライブラリ(WebKit)をベースに行われたもので、ライセンスはLGPLです。SVG Mapを実装したWebKitを使用した、Windows上で動作するChromiumベースのブラウザ(実行モジュール)も公開されています。

http://sourceforge.net/projects/wwwmap/

また、これに先立ち、KDDIは本年6月W3Cに再加入し、SVG Mapの国際標準化活動を開始しています。

こちらのほうでは、今夏に標準化提案を実施、W3C事務局から受理され、標準化の議論が進められています。なお、提案内容は本サイトのSVG Map仕様書をベースとしています。

SVG MapのW3C標準化活動に関する関連URL:

Tiling and Layering Module for SVG 1.2 Tiny Submission

(W3C Staff Comment)

2010年11 月18日 (木)

Tiling and Layering Module 1.0 Specification for SVG 1.2 Tiny (DRAFT)

NOTE

This document is a draft of the specification for web map platform by SVG that the SVG Map consortium is proposing. At present, SVG Map Toolkit doesn't support a part of this specification. It supports the older specification.

1 Abstract

This specification defines the features and syntax for Tiling and Layering Module for SVG 1.2 Tiny. This specification is focusing on Web Mapping.

2 Table of Contents

  1. Abstract
  2. Table of Contents
  3. Introduction
  4. Geographic coordinates
  5. Metadata
  6. Tiling
  7. Layering
  8. Tiling and Layering of bit-images
  9. Visibility controlling according to zooming

3 Introduction

For background, please refer this article. (Backup)

Tiling and layering features are especially useful for the construction of an open platform for map services based on the hyper document. And, this features may be useful for publishing and sharing huge CAD data or other various illustrations. These features should be considered as one of a module for SVG.

For the map service platform on Web, two functions are requested for SVG.

  • Functions to unite two or more services by hyperlink
  • Functions to deliver huge map efficiently by hyper-document based architecture
The majority of specifications for these functions are provided for in SVG 1.2 Tiny itself.

However, it is a little insufficient to fulfill the requirements as map platform. Therefore, in spite of being based on SVG 1.2 Tiny specifications, in order that this specification may improve the applicability to a map services, the following restricts and extensions are carried out.

  • A methodology to relate a geographical coordinate with the graphics primitive of SVG (this makes the geographoc coordinates specifications of SVG 1.2 Tiny precise)
  • The extension which realizes a free scrolling map (the description methodology and the methodology of the processing in a user agent of the map data divided in the shape of a mosaic tile (or meshed shape))
  • Extension which realizes a free zooming map (functionality which displays a map with the resolution according to a scale automatically)
  • A methodology to embed the geographical metadata to a graphics elements
These functions are considered to be Tiling and Layering from the viewpoint of the functionality of SVG not the viewpoint of map services. And this specification is considered, to apply it even by the usages other than the map service.

4 Geographic coordinates

It is necessary to set geographic coordinates to each contents for the composition (Layering or Tiling) of two or more map contents based on geographic coordinates. The specification to describe geographic coordinates has already been provided for by SVG 1.2 Tiny (Geographic Coordinate Systems). However, in order to reduce the ambiguity of specifications and to simplify a implementation, this specification introduces a new element named 'globalCoordinateSystem' in place of SVG 1.2 Tiny's original specifications which is based on RDF/XML metadata.

4.1 The 'globalCoordinateSystem' element

Contents with geographic coordinates have a 'globalCoordinateSystem' element under the 'svg' element. This element substitutes the function of Geographic Coordinates of original SVG 1.2 Tiny.

4.1.1 Attribute definitions

srsName="<IRI for Geographic Coordinate System>"

This attribute specifies the geographic coordinates reference system of the SVG document.
Note: This attribute corresponds to the srsName attribute of GML.

transform = "<transform-list>" | "<ransform-ref>" | "none"

This transform attribute specifies the conversion parameters from geographic coordinates to coordinates of the document. And, it corresponds to the parameters for the map projection in the following figures.

Fig4_1_1_2

The transformation is as follows.

  SVG_X: X coordinate of a SVG data 
  SVG_Y: Y coordinate of a SVG data 
  Geo_X: The first parameter of geographic coordinates (By restriction of a CRS type instance, it is a Longitude.)
  Geo_Y: The second parameter of geographic coordinates (By the restriction of a CRS type instance, it is a Latitude.)
  a , b , c , d , e , f:  The applicable values of parameters(SVG transform(a,b,c,d,e,f) )

  SVG_X = a * Geo_X + c * Geo_Y + e
  SVG_Y = b * Geo_X + d * Geo_Y + f
When this properties is not declared, it is considered that that value is matrix (1, 0, 0, 1, 0, 0).

Note1: Map projection for SVG
The geographic coordinate transformation property of SVG is limited only the first affine transformation. Therefore, the projection that can be used with SVG is limited to the equirectangular projection (And, Plate Caree that is the derived form that takes the standard parallel on the equator).
It is also possible to use the drawing with non-diagonal section of the affine transformation. (It corresponds to a drawing that rotated equirectangular projection. )
This limitation will offer a practicable drawing in most use cases. However, it might be inconvenient in the map of the high latitude region etc. However, the function built into beforehand by the rendering system of SVG can be used and because it is a simple linear transformation, implementation on user agent is facilitated. As a result, the scalability (especially, small terminal) will be improved.

Note2: Consideration of accuracy
It is necessary to build map data in consideration of the range of <number> data type of SVG 1.2 Tiny (-32,767.9999 to +32,767.9999) that is used to describe each coordinates.
matrix(100.0,0.0,0.0,-100.0,0.0,0.0) can be used as transforom attribute to obtain the accuracy of about 10cm in the entire earth.

4.2 <IRI for Geographic Coordinate System>

For the moment, only a following IRI is recommended.

http://purl.org/crs/84

Generally this IRI is called WGS-84. However, it is a two-dimensional coordinate system, the first parameter (X) of that is a Longitude and the second parameter (Y) is a Latitude. And the unit is a "degree", respectively.

Note: This coordinate reference system (http://purl.org/crs/84) is equivalent to "CRS:84" (Annex B3) which OGC defined for WMS1.3.0.
"EPSG:4326" is known as one of the coordinate reference systems of WGS-84. However, the first parameter (X) of that is a Latitude and the second parameter (Y) is a Longitude. That is, "CRS:84" which SVG Map uses has a reverse sequential order of a parameter compared with it.

Restriction of CRS is because it is the advantage that an interoperability can be improved, making the implementation to a user terminal easy by setting CRS to one. For example, when superimposing two or more maps, it becomes unnecessary to take into consideration the difference in a coordinate reference system as a matter of fact. WGS-84 coordinate system may be used by the geographic information of the majority on an internet. Furthermore, it is also a native coordinate reference system of GPS which many portable terminals are implementing. Consequently, the inconvenience by this restriction will not occur in a majority of applications.

4.3 Example

  <?xml version="1.0" encoding="UTF-8"?>
  <svg xmlns="http://www.w3.org/2000/svg">
  <globalCoordinateSystem
    srsName="http://purl.org/crs/84"
    transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>
    <circle cx="258.1401" cy="185.1558" r="10.0" stroke="none" fill="green"/>
  </svg>
In this example, the geographic coordinate reference system is expressed in the followinThe parameters of the SVG coordinate transformation property are as follows.
  a=15.3631
  b=0.0
  c=0.0
  d=-18.6994
  e=-1889.2916
  f=849.9202
And, geographic coordinates that correspond to SVG coordinates (258.1401,185.1558) at the center of 'circle' figure become as follows.
  258.1401 =  15.3631(a) * Geo_X - 1889.2916(e)
  185.1558 = -18.6994(d) * Geo_Y + 849.9202(f)

  Geo_X(Longitude) = 139.7694
  Geo_Y(Latitude) =  35.5500

5 Metadata

There are use cases of storing the metadata (or semantics) in the SVG Map contents. Some describing methods for metadata are provided for by SVG 1.2 Tiny. (The 'title' and 'desc' elements , The 'metadata' element)

Nevertheless, this specification adds the description method with higher storage efficiency. Because a large amount of graphics primitive might have geographical metadata respectively for the map case.

  • Metadata can be set up in each container elemnts and graphics elements.
  • Metadata can be set to each elements as an attribute based on SVG 1.2 Tiny (19.1 Foreign namespaces and private data).
  • It is necessary to declare the namespace to the metadata's attribute respectively.
  • The attribute based on two or more vocabularies can be set by declaring two or more namespaces.

5.1 Example

  <svg  xmlns="http://www.w3.org/2000/svg"
    xmlns:dc="http://purl.org/dc/elements/1.1/" 
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <path id="t1" 
      foaf:nick="O-BUILDNG" 
      rdf:type="http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing" 
      dc:title="OOX company building" 
      stroke="green" d="....." />
 </svg>

6 Tiling

This specifications offers format and processing method for SVG Map data divided into mosaic tegular.

The map tile files will be composed to one map with the SVG file that settles them as shown in figure. Thus, the SVG file that importing of other files is called "container SVG file", and each imported SVG files are called "import SVG files" in this specification.
Fig6

Here, the function for importing of the file is achieved by 'animation' 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 area (viewport) 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 data.

Container.svg

  <svg xmlns="http://www.w3.org/2000/svg" viewBox="20 110 120 85">
    <globalCoordinateSystem
      srsName="http://purl.org/crs/84"
      transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>
    <animation   x="0"   y="0" width="100" height="70" xlink:href="0_0.svg"/>
    <animation x="100"   y="0" width="100" height="70" xlink:href="1_0.svg"/>
    <animation x="200"   y="0" width="100" height="70" xlink:href="2_0.svg"/>
    <animation   x="0"  y="70" width="100" height="70" xlink:href="0_1.svg"/>
    <animation x="100"  y="70" width="100" height="70" xlink:href="1_1.svg"/>
    <animation x="200"  y="70" width="100" height="70" xlink:href="2_1.svg"/>
    <animation   x="0" y="140" width="100" height="70" xlink:href="0_2.svg"/>
    <animation x="100" y="140" width="100" height="70" xlink:href="1_2.svg"/>
    <animation x="200" y="140" width="100" height="70" xlink:href="2_2.svg"/>
  </svg>

6.1 Rendering of import SVG data with geographic coordinate system

Import SVG data with a geographic coordinate system should be converted into coordinates of container SVG data by the following transformations.
Fig6_1a

That is, import SVG data is reversely converted to a geographic coordinate system once by its conversion parameter. And, it is converted to coordinates of container SVG data by the conversion parameter of container SVG data.

The parameters with suffix (i) are parameters of matrix of the 'transform' attribute of a 'golbalCoordinates' element of the import SVG data. The parameters with suffix (c) are parameters of matrix of the 'transform' attribute of a 'golbalCoordinates' element of the container SVG data.

The x,y,width,height attribute of the 'animation' element of container SVG data doesn't take part in the calculation of coordinates to arrange the figure of import SVG data in container SVG coordinates.
Fig6_1b

6.2 Dynamic data loading that depends on position of viewBox and import SVG data

The requirements on the user agent side for this spcifications is newly provided.

  1. User agent in accordance with this specifications should be able to do the importing the SVG files by 'animation' element.
  2. User agent in accordance with this specifications should be implementd the following daynamic loading logic at least.
When the area of 'animation' element (It is specified with w, y, width and height property ) of the SVG document comes in contact with the viewbox of the user agent, the data to which 'animation' element refers are dynamically acquired.

It explains the mechanism in the following figure.
Fig6_2
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 user agent 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 user agent implementation whether maintains as long as the memory permits or throws.

6.3 Cascading Container

Cascading container SVG can be constructed. In this case, all mechanisms of dynamic loading and following layering are also applied.
Fig6_3

7 Layering

The only difference between layering and tiling is whether positions of import SVG data that container SVG data reads are shifted to tegular or overlayed.
Fig7

The order of the layer conforms to the specification of SVG. That is, import SVG data referred to by the first animation element in container SVG data is arranged in the bottom part.
Note: Import SVG data that are independently maintained and managed are often combined for the case of layering. And, those import SVG data will have a different SVG coordinate system. Therefore, import SVG data used by the layering should have geographic coordinates for proper layering processing.

8 Tiling and Layering of bit-images

The bit image file itself doesn't have geographic coordinates. However, import SVG data that can be treated as a bit-image with geographic coordinates can be constructed by preparing the SVG data that is importing of the bit image using 'image' element.
Fig8

On the other hand, when the area and size of importing data are already-known, container SVG data that is referring to data without geographic coordinates can be constructed. In that case, tiling is achieved only by using the 'image' element instead of the 'animation' element.

9 Visibility controlling according to zooming

SVG is vector graphics data which can be expanded and contracted without a degradation of a rendition. However, since the same data is only expanded and contracted, an information content does not change following it. On the other hand, in digital map application, the functionality to change the information content displayed with expansion and contraction is often offered. There may be general-purpose functionality which can control the visibility of each graphics primitive according to the scaling factor of a view to realize this functionality.

9.1 Attribute definitions

  • visibleMinZoom="<MinimumZoomingFactor>"
  • visibleMaxZoom="<MaximumZoomingFactor>"
When a current view scale exceeds <MaximumZoomingFactor> the graphics primitive is not displayed. When a current view scale falls below <MinimumZoomingFactor>, the graphics primitive is not displayed.
When each attribute is not declared, the primitive is displayed in each scale direction.

9.1.1 view scale definition

View scale is defined by the following expressions.
viewScale = 100 x ( [Length in the screen-coordinates system of the graphic] / [Length in the SVG coordinate system of the graphic] ) [%]
A stricter definition is provided for by the following figures and expressions.
Fig9_1_1

9.2 Examples

  <svg>
    <circle cy="100" cy="100" visibleMinZoom="100" visibleMaxZoom="200"/>
  </svg>
A circle is displayed between the scaling factors 100 to 200.
Fig9_2

9.3 Dynamic data loading according to zooming

The mechanism which loads map data dynamically according to a view scaling factor is realized by extending the 6.2.

When this property is organized in the 'animation' or 'image' or its parent container 'g'element, the import SVG data is loaded dynamically according to zooming factors. When the 'animation' or 'image' element enters into the zooming factor span which should be displayed, the viewer must implement at least the logic which loads dynamically the graphics data resource which the 'animation' or 'image' is referring to.

9.3.1 Example:

Please refer to the map data that GIS-soken publishes.

2009年9 月14日 (月)

Tiling and Layering Module for SVG Tiny 1.2

SVG Map Profile 1.0 was a specification based on SVG 1.1. Then, to adjust better to SVG Tiny 1.2 that is the latest SVG specification that W3C recommended, we revise the specification for SVG Map.
This revised specification may be standardized as a standard of W3C and JIS.
Please refer to the page of SVG IG Japan of W3C and the page of GIS of JIPDEC for the progress report of standardization.  

DRAFT Tiling and Layering Module 1.0 Specification for SVG 1.2 Tiny  (UPDATED)

Draft specification contributed to SVG Interest Group Japan ML (outdated)

Explanation of revision

Name of specification:

  • The name is changed to "SVG Tiling and Layering".
  • Change point:
    • The position is renewed as a module of SVG1.2.
    • It changes to the name that explains not the usage but the function.

Namespace:

  • Namespaces of provided element and attribute are integrated into SVG.

Declaration of geospatial coordinates:

  • It declares by the 'globalCoordinateSystem' element.
  • Change point:
    • The element that enables a simpler description is newly established in place of the RDF/XML script with 'crs:CoordinateReferenceSystem' element under the 'metadata' element.
  • Original specifications:
  • Available attributes:
    • 'srsName':(REQUIRED)
      • Equivalence to 'resource' attribute in past 'coordinateReferenceSystem' element
      • Remarks:
        • IRI of the space reference system is described as a property value.
        • Equivalence to 'srsName' property of GML
    • transform:
      • Equivalence to 'svg:transform' property in past 'coordinateReferenceSystem' element
      • Remarks:
        • This attribute shows the linear transformation parameter from geographic coordinates specified with srsName to local coordinates of this SVG document.
        • It evaluates as matrix(1,0,0,1,0,0) when there is no description.

Importing of graphics contents by hyperlink (Hyper-Layering and Tiling):

  • The 'animation' element or the 'image' element can be used.
  • Change point:
    • It is necessary to use the 'animation' element for importing SVG.
    • It is necessary to use the 'image' elemant for importing bit image (JPEG, PNG).
    • Remarks:
      • The property value applies to specifications of SVG Tiny 1.2.
      • It is necessary to set an appropriate value to 'x', 'y', 'width', and 'height' to achieve the purpose of layering and tiling.

Display control corresponding to magnification:(Level of detail control)

Metadata:

  • There is no change.
  • Original specification
  • However, this is not intended to prohibit the notation of the metadata (1, 2) provided for in SVG Tiny 1.2.


Tiling and Layering Module for SVG Tiny 1.2 - SVG Tiny 1.2に対応するためのSVG Map Profileの変更点

SVG Map Profile 1.0はSVG 1.1をベースにした仕様でしたが、W3Cが勧告した最新のSVG仕様書であるSVG Tiny 1.2とよりうまく整合するように、仕様を改訂します。
この改訂された仕様は、W3CおよびJISの規格として標準化を進める予定です。
標準化の進捗状況については、W3CのSVG IG Japanのページや、JIPDECのGISのページ等も参照ください。

Tiling and Layering Module 1.0 Specification for SVG 1.2 Tiny (UPDATED)

SVG Interest Group Japan MLに投稿した素案 (OUTDATED)

改訂内容

仕様の名称:

  • "SVG Tiling and Layering"に名称を変更する
  • 変更点:
    • SVG1.2のモジュールとして、位置づけを改める
    • 規定する仕様の機能がわかりやすい名称にする

ネームスペース:

  • 規定される要素や属性のネームスペースをSVGに統合する

地理座標系の宣言(地理的な座標による空間参照方法):

  • 'globalCoordinateSystem'要素により宣言する
  • 変更点:
    • 'metadata'要素内の'crs:CoordinateReferenceSystem'要素を用いたRDF/XMLスクリプトに代え、よりシンプルな記述を可能にする要素を新設する
    • 'metadata'要素内のRDF/XMLスクリプトによって記述した情報と、この方法によって記述した情報は、以下の属性値の等価関係に基づき、等価に扱うことができる
  • 元の仕様:
  • この要素が取り得る属性:
    • 'srsName':(必す)
      • 従来の'coordinateReferenceSystem'要素の'resource'属性と等価
      • 備考:
        • 属性値として、空間参照系のIRIを記述
        • WMS(Annex B3)における、CRS:84と等価のhttp://purl.org/crs/84を推奨(経度,緯度並びのWGS-84座標系)
        • GMLのsrsNameと等価
    • 'transform':
      • 従来の'coordinateReferenceSystem'要素の'svg:transform'属性と等価
      • 備考:
        • この属性は、'srsName'属性で指定した座標系の地理座標から、このSVGドキュメントの座標への1次変換パラメータを示す
        • 属性値のフォーマットは、SVGの'traneform'属性を参照
        • 記述がない場合は、matrix(1,0,0,1,0,0)が指定されたものとして評価

ハイパーリンクによるグラフィックスコンテンツのインポート(ハイパーレイヤリング及びタイリング):

  • 'animation'要素もしくは'image'要素を用いる
  • 変更点:
    • SVGのインポートには'animation'要素を用いる
    • ラスターグラフィックス(jpeg,png)のインポートには'image'要素を用いる
    • 備考:
      • 属性値はSVG Tiny 1.2の規定に従う
      • レイヤリングやタイリングの目的を達成するためには、適切に'x','y','width','height'の属性値を設定する必要がある

倍率に応じた表示制御:

メタデータ:

  • 変更無し
  • 元の仕様
  • ただし、SVG Tiny 1.2で規定されたメタデータの記法(その1その2)を禁止するものではない

2008年12 月 4日 (木)

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.

Photo_2

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>

2008年11 月20日 (木)

ハイパーレイヤリング

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でも文書表現(書式付文書)と連携(ハイパーテキスト)を一つのデータ形式が担っています。
Photo_2
ハイパーレイヤリングは以下の手順で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>

2008年7 月25日 (金)

Supplementation: SVG Map data divided into mosaic tegular

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

In the explanation of SVG Map data divided into mosaic tegular, all tiles were assumed to be an equal size for the simplification. However, the arrangement of the tile can be arbitrarily specified in SVG Map according to the (x,y,width,height) attributes of the image element of the container file. Therefore, an individual tile need not be an equal size.
#Please refer to this article about the compare with other architectures.

The figure below is an appearance of the tile division of the coast lines data of Japan used with Tiny SVG Base Map content.
URL of the container is the following.
http://www.svg-map.org/svg/basemaps/GMapJpz/jpCoast.dbf.svgz
Because all contents of Tiny SVG Base Map are static files, you might understand the dividing mechanism by reading the source code.

Rtile

2008年7 月24日 (木)

Embedded metadata

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

There are use cases of storing the metadata (or semantics) excluding drawing in the SVG Map data, and doing processing that uses it. These processing corresponds to the processing done with GIS in general. Needless to say, the conspicuous processing of GIS is mapping of geospatial information.

Here, the object of the metadata might have the case of the entire document and the case of an individual graphics primitive in the document.

There is a geographic coordinates reference system description of SVG as an example of the former. The method of putting information described by RDF/XML in the metadata element right under the svg element is used as the notation.

And, the method similar to the former can be adopted for latter metadata. (However, it will use xlink to specify an individual graphics primitive. ) (Reference information) In addition, there is a method of storing the metadata of RDF/XML by setting up the metadata element as a child element of each graphics primitive, too. However, these methods are disadvantageous in the storage efficiency of data and processing efficiency of the viewer.
On the other hand, it seems that the microformats-like method of setting up metadata in each graphics primitives as attributes is effective in this viewpoint. (Reference information) This method doesn't violate the recommended specification of SVG, though this method doesn't conform to the notation of RDF/XML.
Especially, the following advantages are pointed out for processing efficiency.

  • Connection processing of separating information is unnecessary in the processing stage, because neither the graphics primitive nor metadata are separate in the document.
  • The optimization of the processing performance is easy, because the assumption of the insertion of an unspecified data structure (There are metadata structure below < metadata > elements. ) in individual graphics primitives is unnecessary.
  • It is easy to set the style to an individual figure based on metadata, by a simple tool such as text editors. (Of course, it is also possible to use XSLT. )
  • # Please refer to this article about the advantage of a storage efficiency side.

Moreover, the utilities of simple techniques such as microformats and GRDDL are acknowledged.
The SVG Map consortium will support metadata by this simple method by occasion of above.

Specification for embedment of metadata in individual graphics primitives

  • Metadata can be set up in each graphics primitive as attributes.
  • The data structure by corresponding RDF is as follows.
    <graphicsPrimitiveName id="ID" attributeName="attributeValue" .../>
    ==
    [ID]:(subject) -- attributeName:(predicate) --> [attributeValue]:(object)
    It is likely to be declared at the same time as follows.
    [ID]:(subject) -- rdf:type:(predicate) --> [graphicsPrimitiveName]:(object)
  • It is necessary to declare the namespace to the metadata's attribute respectively.
  • The attribute based on two or more vocabularies can be set by declaring two or more namespaces.
  • Literal (character string and numerical value, etc.) and resources (URL,URI) can be used as a property value. The limitation of the value is assumed to be dependence on the schema (RDF Schema is assumed as it. ) specified for a namespace declaration.
  • Two or more property values can be given to one attribute by using the comma separated value.
  • In the graphics primitive to which metadata is set, it is desirable that the id attribute is set. (When it is not set, it might be considered an anonymous node in the data structure of RDF. )

    Example:
     <svg  xmlns="http://www.w3.org/2000/svg"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:foaf="http://xmlns.com/foaf/0.1/"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
      <path id="t1"
          foaf:nick="O-BUILDNG"
          rdf:type="http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing"
          dc:title="OOX company building"
          stroke="green" d="....." />
     </svg>

2008年7 月22日 (火)

The extension which realizes a free zooming map

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

SVG is vector graphics data which can be expanded and contracted without a degradation of a rendition. However, since the same data is only expanded and contracted, an information content does not change following it. On the other hand, in digital map application, the functionality to change the information content displayed with expansion and contraction is often offered.

There may be general-purpose functionality which can control the visibility of each graphics primitive according to the scaling factor of a view to realize this functionality. It seems that it is pended for the moment although the specifications which realize this were examined in the disputation stage of SVG1.2 temporarily (source). Then, the SVG Map consortium considered that this functionality was indispensable in a Web map services, and was made to extend as SVG Map Profile.

Property to extend  :   figure-visibility
The property which sets the parameter for controlling the visibility according to a view scale to a graphics primitive 
The target containing element: Basic Shapes, <path>, <text>, <use>, <g>, <image>, <animation>

Format  :   figure-visibility="[minimum scale], [maximum scale]"
When a view scale is between A and B, the graphics primitive is displayed.
# Definition of a view scale
100x ([Length in the screen-coordinates system of the graphic] / [Length in the SVG coordinate system of the graphic]) [%]

Name space  :   The specifications extended as SVG Map Profile are embedded to a SVG data using Namespaces in XML specifications.
Namespace URL for SVG Map Profile  :   http://purl.org/svgmap/profile
Recommend prefix :   go

Example :
 <svg ... xmlns:go="http://purl.org/svgmap/profile">
  ....
  <circle cy="100" cy="100" go:figure-visibility="100,200"/>
 </svg>
A circle graphic is displayed between the scaling factors 1. to 2..

Figvis

The viewer which reads a map dynamically according to a view scaling factor

The mechanism which reads map data dynamically according to a view scaling factor is realized by extending the implementation requirements specification 2 of "SVG Map data divided into mosaic tegular" based on this extension.

The implementation requirements specification of a viewer
When this property is organized in the <image> (or <animation>) element, the map services which obtains map data dynamically according to a scale is constructed.
When the <image> element enters into the scaling-factor span which should be displayed, the viewer must implement at least the logic which obtains dynamically the graphics data which the <image> element is referring to.

Example:   Please refer to the map data (http://www.svg-map.org/svg/basemaps/worldMapZ.svg) introduced by "Tiny SVG Base Map Content".

2008年7 月15日 (火)

SVG Map data divided into mosaic tegular

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.

Tile2_3

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.

See also:  one of the characteristic applications of this specification