SVTiles format vector tiles |
SVTiles is a type of storage format customized by SuperMap, which stores the vector tile data with the SQLite database. The svtiles file use metadata and tiles data to manage the vector tiles.
The name of the SVTiles file is composed of the map name, Hashcode, width and height of tiles, and the .svtiles suffix like China_-678451788_256X256.svtiles.
From iServer 8C(2017) , vector tile adds style information. When caching vector tiles, it will generate the SVTiles file, and the style information file with ".resources" suffix to store the style attribute information of the vector tiles.
The style information file also uses SQLite database. And it is named in the same way as SVTiles.
.svtiles file and .resource file use the following tables and views to store and manage vetor tiles.
Metadata table adopts key-value pairs for storing settings of vector tiles, including name and value. The structure of the table is shown in the figure:
Below shows an examples of metadata table..
Table 1 Example of metadata table
name |
value |
name | China |
version | 201401 |
bounds |
-20037508.342787,-20037508.342787,20037508.342787,20037508.342787 |
tile_origin | -20037508.342787,20037508.342787 |
crs_wkid |
3857 |
crs_wkt |
PROJCS["User Define", GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984", SPHEROID["WGS_1984",6378137.0,298.2572235630001, AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0.0,AUTHORITY["EPSG","8901"]], UNIT["DEGREE",0.017453292519943295],AUTHORITY["EPSG","4326"]], PROJECTION["Popular Visualisation Pseudo Mercator", AUTHORITY["EPSG","1024"]], PARAMETER["False_Easting",0.0], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",0.0], PARAMETER["Latitude_Of_Origin",0.0], PARAMETER["Scale_Factor",1.0], UNIT["METER",1.0], AUTHORITY["EPSG","3857"]] |
tile_height | 256 |
tile_width | 256 |
scales | 1.690163e-9,3.380327e-9 |
resolutions |
156543.033928,78271.516964 |
geometry_storage_type |
SuperMapJson |
attribute_storage_type |
Json |
layer_infos |
[ {"Capitals": { "expand_pixels": 2 }, "Road": { "expand_pixels ": 2 }, "Provinces": { "expand_pixels ": 2 } } ] |
Table 2 shows the fields' description of metadata table.
Table 2 Description of fields in metadata table
Field name | Description |
name | Name of map. |
version | The version of the vector tiles, and the current version is 201401. |
bounds | The tiling extent of the map whose unit is consistent with that of the map. Formats of bounds in iServer are left, down, right and up, like -180, -85, 180 and 85. |
tile_origin | The position of the tiling origin. |
crs_wkid | EPSG Code of the coordinate system (-1000 indicates the custom coordinate system and 0 indicates common planar coordinate system). |
crs_wkt | The geographic coordinate system represented by wkt. (wkt: A text markup language developed by OGC. For details, please refer to http://docs.geotools.org/stable/javadocs/org/opengis/referencing/doc-files/WKT.html) |
tile_height | The tile height, generally 256. |
tile_width | The tile width, generally 256. |
scales | Collection of scales corresponding to different levels resolutions. |
resolutions | Scales set corresponding to each-level resolution. |
geometry_storage_type | The storage formats of geometric objects. Optional values can be SuperMapJson, WKT, GeoJson, GML. |
attribute_storage_type | The storage formats of attribute data. Optional values can be Json and Xml. |
layer_infos | The metadata information used to describe each layer. |
All vector tile data and values for locating tiles are included, as illustrated in the figure:
Table 3 shows the fields' description of tile data table.
Table 3 Description of fields in SVTiles tile table
Field name | Data type | Description |
resolution | varchar | Resolution corresponding to the tile. |
tile_colum | integer | The column number of the tile. |
tile_row |
integer |
The row number of the tile. |
tile_id | String | Tile ID. |
create_time | Text | The creation time. |
Example of tile dataset content is shown in the figure below.
Records the geometry information of the geographic features in tiles, as illustrated in the figure below:
Table 4 shows the fields' description of geometric object table.
Table 4 Description of fields in geometric object table
Field name | Data type | Description |
layer |
Text |
Layer name. |
fid |
Long | Geometry feature ID. |
tile_id |
Text |
Tile ID. |
geometry_data | Text | The geometry object. |
Each record corresponds to a clipped geometric object. geometry_data stores pixel coordinates. At different levels, pixel coordinates of a same geometric object are different; at the same level, one geometric object can cover multiple tiles, as shown in figure 1. The tile stores geometric object after clipping, as shown in figure 2.
Figure 1 Geometric object covering 2 tiles
Figure 2 Geometric object after clipping
The default storage format is SuperMapJSON. It can also be WKT, GeoJSON, GML. SuperMapJSON format is as follows:
{
“type”:”REGION”,
“points”:[0,0,256,0,256,256,0,256,0,0,1,1,3,3,2,2,1,1],
“parts”:[5,4]
}
Records the attribute information of the geometric objects, as shown in the figure below.
Table 5 shows the fields' description of attribute information table.
Table 5 Description of fields in attribute information table
Field name | Data type | Description |
layer |
Text |
Layer name. |
fid |
Long | Geometry feature ID. |
attr_data |
Text |
The attribute data. |
search_values |
Text | Query content. |
The attribute and geometric objects are corresponding to each other. The geometric object of each geographic feature spread in different tiles (2.3), therefore, attributes and geometry has 1:many relationship. The Json format of attr_data is as follows:
{
“NAME”:”Beijing”,
“PostCode”:100000,
“POP”:11510000,
“Country”:”China”
}
search_values are strings separated by comma and it is used for fast query. For instance, search_values for Beijing is “Beijing,100000”. Query statement according to search_values is as follows:
where search_values like ‘%Beijing%’
The tilesfeatures view generated based on tiles, attributes, geometies.
Table 6 shows the fields' description of tilefeatures view.
Table 6 Description of values of tilefeatures view
Field name | Data type | Description |
resolution |
Double |
The resolution. |
tile_column |
Long | The column number of the tile. |
tile_row |
Long | The row number of the tile. |
tile_id |
String | Tile ID. |
create_time |
Text | The creation time. |
layer |
Text | Layer name. |
fid |
Integer | Geometry feature ID. |
geometry_data |
Text | The geometry object. |
search_values |
Text | Query content. |
attr_data |
Text | The attribute data. |
The tilesgeometries view generated based on tiles, attributes, geometries is used to completely represent the geometric information of tile and geographic features in tile. If attribute information is not required, the query based on tilegeometries will be faster, as shown in the figure below:
Table 6 shows the fields' description of tilegeometries view.
Table 7 Description of fields in tilegeometries view
Field name | Data type | Description |
resolution |
Double |
The resolution. |
tile_column |
Long | The column number of the tile. |
tile_row |
Long | The row number of the tile. |
tile_id |
String | Tile ID. |
create_time |
Text | The creation time. |
layer |
Text | Layer name. |
fid |
Integer | Geometry feature ID. |
geometry_data |
Text | The geometry object. |
metadata
CREATE TABLE metadata (name text, value text);
CREATE UNIQUE INDEX metadata_idx ON metadata (name);
tiles
CREATE TABLE tiles (resolution double, tile_column integer, tile_row integer,tile_id text, create_time
text);
CREATE UNIQUE INDEX tiles_index on tiles(resolution,tile_column,tile_row);
Create index tiles_id_index ON tiles(tile_id);
geometries
CREATE TABLE geometries(layer text,fid long,tile_id text,geometry_data text );
CREATE UNIQUE INDEXgeometries_index ON geometries(layer ,fid,tile_id);
attributes
CREATE TABLE attributes( layer text, fid long, attr_datatext,search_values text);
CREATE UNIQUE INDEX attrbutes_index ON attributes (layer, fid);
tilefeatures
CREATE VIEW tilefeatures as
SELECT A.*,B.layer,B.fid,B.geometry_data,C.search_values,C.attr_data
FROM tiles as A,geometries as B,attributes as C
WHERE A.tile_id=B.tile_id and B.layer=C.layer and B.fid=C.fid
tilegeometries
CREATEVIEW tilegeometries as
SELECT A.*,B.layer,B.fid,B.geometry_data
FROM tiles as A,geometries as B
WHERE A.tile_id=B.tile_id
Functionality comparison is shown in table 8:
Table 8 SVTile functionality comparison between SVTiles V201401 SVtiles V201310
Function |
V201310 | V201401 |
Geometric object storage | SuperMapJson | Extended regulation supports multiple formats: SuperMapJson, WKT, GeoJson, GML |
Feature attribute storage | Not supported | XML, Json |
Data table comparison is shown in table 9:
Table 9 Table comparison between SVTiles V201401 SVtiles V201310
Version |
Table description |
V201310 | metadata metadata table. |
tiles tile table. | |
tiles_data field stores all geometric object collection. | |
V201401 | metadata metadata table. |
tiles tile table, which only stores tile index. | |
geometries geometry object table. | |
attributes attribute information table. | |
tilefeatures tile and feature view. | |
tilegeometries tile and geometric object view. |
SuperMapJson is a type of Json format defined by SuperMap iServer. This format is composed of 3 parts:
type: Geometric shape type.
Optional values are POINT, LINE, REGION, which corresponds to MultiPoint, MultLineString, MultiPolygon in WKT separately.
points: Represents a group of pixel coordinate sequence, each neighboring items representing a pair of coordinates.
parts: Represents the segmentation information of the current geometric object. Each segment represents a child object and the value of segment represents the number of child object points.
Example:
{
“type”:”REGION”,
“points”:[0,0,256,0,256,256,0,256,0,0,1,1,3,3,2,2,1,1],
“parts”:[5,4]
}
In the example above, “parts”:[5,4] represents that the object has two segments, and the coordinates of the two segments are [0,0 ,256,0,256,256,0,256,0,0], [1,1,3,3,2,2,1,1] respectively.
Note: For geometric object with type being POINT, json can contain no parts items. Each coordinate in points of this type of geometric object represents a child POINT.
The style table is used to record each layer's style type and its style description. The fields in the table are shown below:
The meanings of the above fields show below.
Table 10 The fields of style table
Field name | Data type | Description |
layer name |
Text |
The name of map layer. |
type |
Text |
The style type. Currently, it supports CartoCSS. |
style |
Text |
The style information of layer. |
Example:
#District@Changchun[zoom<=9.80459446371E-5][zoom>=1.05263157895E-5]{text-placement-type:simple;text-placements:"E,NE,SE,W,NW,SW";line-pattern-file:url(SYMBOLLINE__District@Changchun__64__64__true__-1483079698.png);polygon-pattern-file:url(SYMBOLFILL__District@Changchun__64__64__true__-1483079698.png);point-file:url(SYMBOLMARKER__District@Changchun__64__64__true__-1483079698.png);polygon-opacity:1;polygon-pattern-opacity:1;}
The symbol table records the symbol image in tile.
The fields in the table are shown below:
Table 12 The fields of symbol table
Field name | Data type | Description |
id |
Text |
The identifier of the symbol. id consists of symbol type, the layer where the symbol locates, image width and height, transparent or not, and hashcode. |
format |
Text |
Image format, such as PNG. |
symboldata |
blob |
The image of symbol. |
The symbol contents in database are shown below.