Introduction to Web Datasource

The Web engine can directly access services provided by WFS, WMS, WCS, REST, and other map service providers. This type of engine treats web servers that comply with industry standards as SuperMap's datasources for processing. Through it, maps and data published on the network can be fully integrated with SuperMap's maps and data, integrating applications into the SuperMap technology system and expanding the application field of the SuperMap data engine. The Web datasource is a read-only engine.

desktop products support the following types of Web datasources:

    1. OGC Standard Services (W*S)

    2. REST Services

    3. Google Map Service (GoogleMaps)

    4. MapWorld Service (MapWorld)

    5. Geovis Earth

    6. Siwei Earth

    7. CareLand

    8. Century Space Images

    9. Jilin No.1

    10. Global Terrain Map Services

    11. Service Examples

OGC Standard Services (W*S)

Understanding OGC Concepts

  • GML: Geography Markup Language, OGC's geographic markup language. Its model uses OGC's simple feature model and organizes files based on XML syntax and file format.
  • URI: Locates using a resource identifier. To open an OGC service with the desktop client, you need to enter the address of the request body, i.e., the URI. It generally consists of three parts: the naming mechanism for accessing the resource, the hostname storing the resource, and the name of the resource itself, represented by a path. The path structure is: http://<server>:<port>/iserver/services. Where:
    • server: The server address publishing the service.
    • port: The port number for publishing the service.
    • servicecomponent: The name of a configured service component or service component set. For example, SuperMap iServer by default configures the map service component map-world.
    • serviceinterface: The name of a configured service interface bound to the service component. For example, SuperMap iServer by default configures the WMS 1.1.1 version service interface, with the service interface name wms111.
  • Version Negotiation: Version Number Negotiation, OGC web service standards have different versions, identified by numbers. Generally, the versions implemented or supported by the client and server are often different. Version negotiation sets the rules for achieving version synchronization between the client and server. The rules are as follows:
    1. If the server implements the version number requested by the client, the server must send data for that version.
    2. If the client sends a request for a higher version not recognized by the server, the server must send the highest version lower than the requested version.
    3. If the client requests a version lower than all versions supported by the server, the server must send the lowest version it supports.
    4. If the client does not recognize the version returned by the server, it will stop communication with the server and request a version lower than the server's returned version that the client can recognize.
    5. If the client requests a version lower than all versions supported by the server, according to rule 3, the server responds with its lowest version, but the client still does not recognize this higher version. Then the client will send a request for a version higher than the server's response version.
    6. The version negotiation process repeats continuously until a mutually agreed version is reached, or the client determines that it can no longer interact with that specific server.

OGC Service Introduction

WMS (Web Map Service) is a web map service that complies with the WMS implementation specification established by OGC (Open Geospatial Consortium). This standard mainly defines three operations for creating and displaying maps: GetCapabilities (Get Service Capabilities), GetMap (Get Map), and GetFeatureInfo (Get Object). The standard primarily defines three major operations for creating and displaying maps, including:

Currently desktop supports opening the following WMS versions:

WCS (Web Coverage Service) is a service that complies with the WCS implementation specification established by OGC (Open Geospatial Consortium).

WCS is an OGC-defined specification for sharing geographic spatial data in the form of "Coverage" on the Web. "Coverage" refers to data capable of returning values for any specified point, in a form easily used as input to models. The WCS service implements the sharing of raster image datasets in the form of "Coverage".

Currently desktop supports opening data from WCS version 1.0.0.

  • WMS Service
    1. GetCapabilities: This operation is used to obtain service-level metadata. This operation is required.
    2. GetMap: The core operation. This operation is used to obtain a map image with clearly defined geographic spatial parameters and size. This operation is required.
    3. GetFeatureInfo: This operation is used to obtain information about certain special features displayed on the map. This operation is optional.
    • WMS 1.1.1
    • WMS 1.3.0
  • WFS Service

    WFS (Web Feature Service): A web feature service that complies with the WFS implementation specification established by OGC (Open Geospatial Consortium). This standard is primarily used to return GML-encoded features at the feature level. WFS allows clients to obtain geographic spatial data encoded in GML from multiple web feature services. Different WFS clients support different character sets, so the encoding type of the request body is not consistent when sending requests.

    Notes

    Currently, the WFS datasource only supports data browsing functionality.

  • WCS
  • WMTS

    WMS map services can flexibly respond to various requests. For each request from the client, the server visualizes the data in real-time and returns the result as an image. However, with high access volumes, frequent requests consume significant resources for calculation, leading to reduced responsiveness. To improve the responsiveness of map services, it is necessary to reduce the time spent on server-side visualization processing. Therefore, services that use caching to improve responsiveness have emerged, and WMTS is one such service.

    WMTS, Web Map Tile Service, is a service that complies with the WMTS specification specified by OGC. The WMTS standard defines operations that allow users to access tiled maps. It is OGC's first service standard supporting REST access.

    WMTS is a caching technology standard proposed by OGC, providing a standardized solution for publishing map services using predefined tiles. On the server side, maps cached as tiles of a certain size are provided, and the service only offers these predefined individual tiles to the client, placing more data processing operations such as layer overlaying on the client side, thereby alleviating the pressure on the GIS server for data processing and improving the user experience.

    WMTS uses a tile matrix set (Tile matrix set) to represent the cut map, as shown in Figure 1. A tile is a matrix unit containing geographic data. A map is cut into multiple tiles according to a certain tile size, forming a tile matrix. One or more tile matrices constitute a tile matrix set. Different tile matrices have different scales. Each tile matrix is identified by a tile matrix identifier (generally the sequence number of the tile matrix, with the lowest resolution layer as layer 0, and increasing upwards). WMTS stipulates that each layer can specify multiple tile matrix sets. Each tile matrix set has its own coordinate reference system, and the tile matrices within the set correspond to various scales.

    Figure 1: Tile Matrix Set

    Each tile matrix has the following characteristics:

    Each tile in a tile matrix is identified by the tile row number (TileRow) and column number (TileCol). The row and column values are counted starting from the tile where the upper-left corner point of the tile matrix is located, with the starting row and column values being (0, 0), increasing downwards and to the right, as shown in Figure 2.

    Figure 2: Tile Matrix

    WMTS 1.0.0 supports three implementation models:

    currently provides implementations for KVP and REST methods.

    The resources requested by WMTS from the server can adopt either a procedure-oriented architectural style or a resource-oriented architectural style. From a procedure-oriented concept, WMTS 1.0.0 defines three operations: GetCapabilities, GetTile, GetFeatureInfo, where GetFeatureInfo is an optional operation. From a resource-oriented concept, WMTS 1.0.0 defines three types of resources: ServiceMetadata (service metadata), Tile (tile data), FeatureInfo (feature information), corresponding to the GetCapabilities, GetTile, and GetFeatureInfo operations, respectively.

    1. If the WMTS service uses username and password authentication in Basic mode, you need to add the parameter AUTHORIZATION=Basic to the URL.

    1. Proposal of WMTS
    2. Concepts of WMTS
      • Using its own tile size as the scale.
      • The width (TileWidth) and height (TileHeight) of each tile defined by pixels, i.e., the tile size.
      • The upper left coordinates (TileMatrixminX, TileMatrixmaxY) of the matrix bounding box.
      • The width (MatrixWidth) and height (MatrixHeight) of the matrix defined in tile units, such as the number of tiles.
    3. Implementation Models of WMTS
      • HTTP KVP (Key-Value Pair) method
      • SOAP method
      • REST method
      1. GetCapabilities, returns service metadata (ServiceMetadata), i.e., service capabilities and information content.
      2. GetTile, returns tile maps (Tile).
      3. GetFeatureInfo, returns feature information (FeatureInfo) displayed on the tile map, which is an optional operation.
    4. Special Notes for WMTS
  • TMS

    TMS (Tile Map Service): A tiled map service that complies with the TMS specification specified by OGC, allowing on-demand access to map tiles and supporting modification.

    TMS stores pre-cut tiles on the server, offering higher service performance and faster access. However, it is not possible to perform operations on the pre-cut tiles.

For more information about OGC services, please refer to: OGC (Open Geospatial Consortium) related specifications, http://www.opengeospatial.org.

REST Services

REST (Representational State Transfer) is a software architectural style proposed by Dr. Roy Fielding in 2000. Web services adopting the REST architectural style are more concise and easier to use compared to complex SOAP services. SuperMap's REST services specifically provide GIS services with a REST style for GIS users.

REST emphasizes viewing the entire network from the perspective of resources. An architecture based on REST is a Resource-Oriented Architecture (ROA). Resources can be specific data or services that can implement certain functionalities. Client applications use a URI (Uniform Resource Identifier) for unique identification. Client applications obtain representations of resources through URIs. Obtaining these representations causes the state of the client application system to change, i.e., a representational state transfer.

REST typically uses existing widely popular protocols and standards such as HTTP, URI, XML, and HTML. SuperMap UGC REST services have the following characteristics:

  1. Each resource provided by the server is uniquely identified by a URI, but a resource can be identified by multiple URIs.
  2. REST services use standard HTTP protocol methods, including: GET, POST, PUT, DELETE, etc., corresponding to four operations on resources: retrieve, create, modify, and delete, etc.
  3. Provides multiple format representations of resources, such as xml, json, html, etc.
  4. All information required by the REST service to process resource requests is contained within the request.

SuperMap iServer REST Map Service Address Filling Instructions

The template for filling in the SuperMap iServer REST Map Service address in SuperMap iDesktopX is: http://{server address}:{port}/iserver/services/{map service name}/rest/maps/{map name}. The parameter description is as follows:

Parameter Whether it is Required Description Example
{server address}:{port} Yes Specifies the iServer server IP address or domain name, and the corresponding port. 172.16.120.35
{map service name} Yes Specifies the name set when publishing the service. map-China100
{map name} Yes Specifies the specific map name within the service. China

Example: http://172.16.120.35:8090/iserver/services/map-China100/rest/maps/China.

SuperMap iServer REST Image Service Address Filling Instructions

(I) Server Address and Parameter Description

SuperMap iDesktopX only supports the iServer image service tile resource request URL. For details, see the /collections/{collectionId}/tile interface definition in the Image Service Resource OpenAPI.

The basic structure is: http://{server address}:{port}/iserver/services/{image service name}/restjsr/collections/{Image collection ID}/tile.{format}?z={z}&y={y}&x={x}&width={width}&height={height}&renderingRule={renderingRule}&ids={ids}&names={names}&sqlFilter={sqlFilter}&transparent={transparent}. The parts of the URL are explained as follows:

Parameter Parameter Group Whether it is Required Description Example
{server address}:{port} Basic Yes Specifies the iServer server IP address or domain name, and the corresponding port.  
{image service name} Yes Specifies the name set when publishing the service. imageservice-imageservicetest
{Image collection ID} Yes Unique resource identifier for the image collection. imagedata
{format} tile format No

Specifies the returned tile image format. Supports *.png, *.jpg, *.webp.

If not specified, the tile format returned by the image service tileinfo interface (server-side configuration) is used.

 png
{z}, {y}, {x} Query No Tile level, row number, column number. Parameters in the URL are invalid. The system returns all tiles meeting the conditions based on the browsing extent and scale. z=13, y=1628, x=6571
{width}, {height} No Specifies the width and height of the tile. The two values must be equal and be 256; otherwise, a blank tile will be returned. If not specified, the server-side configuration is used. width=256, height=256
{renderingRule} No Specifies the tile rendering style. If not specified, the server-side default style is used. {"displayMode":"STRETCHED", ...}
{ids} No Specifies the Image ID, i.e., the SmID of the image in the mosaic dataset. 26
{names} No Specifies the image file name, including the suffix. S-60-45.tiff
{sqlFilter} No Uses image collection mosaic dataset property fields to build an SQL filter expression. SmID > 100
{transparent} No Specifies whether the tile background is transparent. true means transparent display, false means non-transparent display. If not specified, the server-side configuration is used. true

(II) Handling Special Characters

  • Special characters such as spaces: When they appear in query parameters (e.g., sqlFilter), they must be converted to URL encoding; otherwise, it will cause connection failure. For example, the URL encoding for a space is %20. Therefore, the original URL sqlFilter=smfilename like 'TRIPLESAT_2%' should be converted to sqlFilter=smfilename%20like%20'TRIPLESAT_2%'.
  • Chinese characters in query conditions: Should not be URL encoded; otherwise, matching will fail.
  • Chinese characters in image collection ID: URL encoding is not recommended. If encoded, the cache directory name will also become encoded.

(III) Local Cache Mechanism

After connecting to the image service, the browsed tiles will be cached in different folders based on different URL requests, facilitating subsequent fast loading.

The tile cache path is: iDesktopX installation directory\bin\Cache\WebCache\Rest\{server address}_{port}\imageservice-image service name\Image collection ID\folders for different request URL tile files.

For cached tiles, please note the following:

  • Same URL but tileFormat not specified: If the server-side tile format changes, it is considered a different request and a new cache will be generated.
  • Token parameter: Only different token values are considered the same request, reusing the cache.
  • Cache update: Does not update automatically. You need to manually delete the corresponding cache directory to reload. For example, after modifying the image collection style configuration on the server side, you need to delete the original cache directory first, and then the system will re-cache the tiles.
  • Cache example with Chinese collection name: If Chinese characters in the Image collection ID are URL encoded, the folder name for "Image collection ID" under the cache directory will use the transcoded result.
    • Original URL: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/satellite image.
    • Cache Directory: Cache\WebCache\Rest\server address_port\imageservice-imageservicetest\satellite image\.
    • After URL encoding: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/%E5%8D%AB%E6%98%9F%E5%BD%B1%E5%83%8F.
    • Cache directory becomes: Cache\WebCache\Rest\server address_port\imageservice-imageservicetest\%e5%8d%ab%e6%98%9f%e5%bd%b1%e5%83%8f\.

(IV) Common Examples

  • No Query Parameters:
    • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata.
    • Description: Requests tile resources for the image collection imagedata. During browsing, loads all tiles according to map bounds and scale. Tile format, size, and style adopt server-side configuration.
  • Specify Tile Format:
    • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata/tile.webp.
    • Description: Requests tile resources for the image collection imagedata, specifying the tile format as WEBP. Tile size and style adopt server-side configuration.
  • Specify Tile Format and Size:
    • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata/tile.webp?width=256&height=256.
    • Description: Requests tile resources for the image collection imagedata, specifying the tile format as WEBP and the size as 256×256 pixels. Tile style adopts server-side configuration.
  • Filter by Filename (names):
    • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata?names=E49C002001.tif.
    • Description: Requests tile resources for the image with filename E49C002001.tif within the image collection imagedata. Tile format, size, and style adopt server-side configuration.
  • Filter by ID (ids):
    • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata?ids=1.
    • Description: Requests tile resources for the image with ID (smID) 1 within the image collection imagedata. Tile format, size, and style adopt server-side configuration.
  • Filter by SQL (sqlFilter):
    • Example:

      The request URL uses the sqlFilter query parameter to construct an SQL statement using image collection mosaic dataset property fields to filter tiles. The URL is: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata?sqlFilter=smfilename like 'TRIPLESAT_2%'.

      However, the above URL contains the special character space, which must be converted to the corresponding URL encoding (%20). The URL after conversion is: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata?sqlFilter=smfilename%20like%20'TRIPLESAT_2%'.

    • Description: Requests tile resources for images whose filenames contain "TRIPLESAT_2" within the image collection imagedata. Tile format, size, and style adopt server-side configuration.
  • Spatial Filtering:

    The request URL uses the sqlFilter query parameter to implement spatial query filtering using the st_geometry spatial function.

    • Polygon Intersection:
      • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata?sqlFilter=st_intersects(smgeometry, st_geomfromtext('polygon((107.23237354532517 33.81726420547909,107.30852651319088 33.81726420547909,107.30852651319088 33.760425396130046,107.23237354532517 33.760425396130046,107.23237354532517 33.81726420547909))',4326)).
      • Description: The coordinate system (EPSG code) specified in the query conditions needs to be consistent with the coordinate system of the queried image collection.
    • Rectangle Extent Intersection:
      • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata?sqlFilter=st_intersects(smgeometry,st_makeenvelope(107.23237354532517,33.760425396130046,107.30852651319088,33.81726420547909,4326)).
      • Description: Only applicable to image services where the image collection is stored using a PostGIS database datasource.
  • Specify Rendering Style:
    • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata?renderingRule={"displayMode":"COMPOSITE","displayBands":"0,1,2"}.
    • Description: Requests tile resources for the image collection imagedata, and uses the specified band combination to display the image. Tile format and size adopt server-side configuration.
  • Combination of Multiple Query Parameters:
    • Example: http://{server address}:{port}/iserver/services/imageservice-imageservicetest/restjsr/collections/imagedata/tile.png?names=TRIPLESAT_2_PAN_L1_20190707031410_001D99VI_006_0120190829004001_013_ortho_fuse_color1.img,TRIPLESAT_3_PAN_L1_20190921031507_0024BDVI_016_0120191014007001_002_ortho_fuse_color1.img&sqlFilter=producetime>'2024-09-25'&renderingRule={"displayMode":"COMPOSITE","displayBands":"0,1,2","stretchOption":{"stretchType":"GAUSSIAN","+""gaussianCoefficient":2,"useMedianValue":true}}.
    • Description: Requests tile resources for images within the image collection imagedata that satisfy both filename and image production time filters, and uses the specified band combination and stretch method to display the image. Tile format PNG, tile size adopts server-side configuration.

Google Map Service (GoogleMaps)

For Google electronic map services, it is read-only and cannot be created.

Google Maps (GoogleMaps) is an electronic map service provided by Google Inc., including vector maps, remote sensing imagery at different resolutions, and some terrain data. desktop integrates the GoogleMaps engine. When connected to the network, you can directly access Google map services within the desktop product. Currently supports accessing the following map types:

  • roadmap: Standard roadmap, such as the ordinary map shown on the Google Maps website.
  • satellite: Satellite image layer.
  • terrain: Terrain map, used to display terrain and vegetation.
  • hybrid: Hybrid layer containing satellite imagery and roadmaps. A transparent layer showing major streets and address names over satellite images.

Google Maps website: http://maps.google.com

Note: Currently, the default server address http://maps.google.com may not display maps normally within China, appearing blank after opening, but users outside China can use this feature normally.

      For users within China, you can try accessing the map again by switching the server address to http://www.google.cn/maps.

MapWorld Service (MapWorld)

For map services published by MapWorld. Read-only, cannot be created.

The MapWorld service is a geographic information service provided to the public by the National Bureau of Surveying and Mapping, offering authoritative, reliable, and unified geographic information. It is currently the geographic information service website with the most comprehensive data resources within China. The MapWorld website provides massive basic geographic information resources, including global vector terrain services and remote sensing imagery, nationwide map data, navigation digital map data, and 3D street view data for some cities. desktop integrates the MapWorld engine. When connected to the network, you can directly access MapWorld services within the desktop product. Currently supported layer types include:

  • BackgroundMap: Background layer, can be used as a base map.
  • AnnoMap: Chinese annotation layer.
  • AnnoMapE: English annotation layer.
  • Terrain: Terrain layer, coordinate system is WGS_1984, can be directly loaded into the scene for use.

MapWorld website: www.tianditu.cn

Geovis Earth

Geovis Earth