SVG Tiling and Layering [DRAFT]

高木です

か・な・り ドラフト状態ですが、前回の第6回SVG IG Japanミーティングでいただいた私の宿題の仕様書案を作ってみました。

章立ては、できるだけJIS案に近づけてあります。

〜〜〜〜〜〜〜〜〜〜〜

SVG Tiling and Layering

1 Abstract:
This specification defines the Tiling and Layering features for SVG Tiny 1.2.

2 Background:
See (http://esw.w3.org/topic/SVG_Map)

3 Introduction:
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. 

* Function to unite two or more service by hyperlink
* Function to deliver huge map efficiently

The majority of specifications for these functions are provided for in SVG Tiny 1.2 itself.
* Specifications to handle geographic coordinates (http://www.w3.org/TR/SVGTiny12/coords.html#GeographicCoordinates)
* Specifications to import and paste external SVG images (http://www.w3.org/TR/SVGTiny12/multimedia.html#AnimationElement)
* Specifications to import and paste external bit images (http://www.w3.org/TR/SVGTiny12/struct.html#ImageElement)

 However, it is a little insufficient to fulfill the requirements as map platform. Therefore, in spite of being based on SVG Tiny 1.2 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 Tiny 1.2 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 Tiny 1.2 (Geographic Coordinate Systems:http://www.w3.org/TR/SVGTiny12/coords.html#GeographicCoordinates). 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 Tiny 1.2'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 Tiny 1.2. (http://www.w3.org/TR/SVGTiny12/coords.html#GeographicCoordinates)

4.1.1 Attribute definitions
4.1.1.1 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(http://www.opengeospatial.org/standards/gml).

4.1.1.2 transform = "<transform-list>" | "<transform-ref>" | "none" 
This transform(http://www.w3.org/TR/SVGTiny12/coords.html#TransformAttribute) 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.jpg>

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).  

Note: 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. 
.

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(http://portal.opengeospatial.org/files/?artifact_id=4756). 
"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 Tiny 1.2. (http://www.w3.org/TR/SVGTiny12/struct.html#TitleAndDescriptionElements , http://www.w3.org/TR/SVGTiny12/metadata.html#MetadataElement)
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(http://www.w3.org/TR/SVGTiny12/intro.html#TermContainerElement) and graphics elements(http://www.w3.org/TR/SVGTiny12/intro.html#TermGraphicsElement). 
*Metadata can be set to each elements as an attribute based on SVG Tiny 1.2 (19.1 Foreign namespaces and private data http://www.w3.org/TR/SVGTiny12/extend.html#ForeignNamespacesPrivateData). 
*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.jpg>

Here, the function for importing of the file is achieved by 'animation'(http://www.w3.org/TR/SVGTiny12/multimedia.html#AnimationElement) 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.jpg>

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.jpg>

6.2 Dynamic data loading that depends on position of viewBox and import SVG data
The specification on the user agent side as the SVG Map profile is newly provided. 

Requirement 1: User agent in accordance with this specifications should be able to do the importing the SVG files by 'animation' element. 

Requirement 2: User agent in accordance with SVG Map profile should be implementd the following 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.jpg>

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.


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.jpg>
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.jpg>

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
visibleZoomRange="<zoomingFactor_A>,<zoomingFactor_B>"

When a view scale is between A and B, the graphics primitive is displayed. 

9.1.1 <zoomingFactor> definition
zoomingFactor is defined by the following expressions. 
100x ([Length in the screen-coordinates system of the graphic] / [Length in the SVG coordinate system of the graphic]) [%]


9.2 Examples
 <svg>
  <circle cy="100" cy="100" visibleZoomRange="100,200"/>
 </svg>
A circle is displayed between the scaling factors 100 to 200.

<fig9_2.jpg>

9.3 Dynamic data loading according to zooming
The mechanism which reads 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' element, the import SVG data is loaded dynamically according to zooming factor.
When the 'animation' or '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 'animation' or '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". 

Received on Tuesday, 6 October 2009 10:52:04 UTC