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
- Abstract
- Table of Contents
- Introduction
- Geographic coordinates
- Metadata
- Tiling
- Layering
- Tiling and Layering of bit-images
- 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
- Specifications to handle geographic coordinates
- Specifications to import and paste external SVG images
- Specifications to import and paste external bit images
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
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.
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 + fWhen 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.
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.9202And, 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.
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.
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.
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.
- User agent in accordance with this specifications should be able to do the importing the SVG files by 'animation' element.
- User agent in accordance with this specifications should be implementd the following daynamic loading logic at least.
It explains the mechanism in the following figure.
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.
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.
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.
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 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.
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. 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.
