A distributed ocean satellite space-time asset real-time online processing method and device

Abstract

The application provides a kind of distributed ocean satellite space-time asset real-time online processing method, comprising: using general specification to carry out unified metadata description to ocean satellite multi-load data;Unified metadata and original satellite remote sensing image are stored in object storage bucket, support cross-regional multiple copies and version control;Unified open application program interface, provide RESTful endpoint in line with specification, realize the attribute, time and space composite search of stored metadata;Call API to obtain data in storage bucket, based on metadata description, utilize image pyramid and GDAL virtual file system to generate tiles on demand by cutting;Based on the situation of generated tiles, automatically expand, and store hotspot tiles through distributed cache.The application also provides a device and a computer readable storage medium that can execute the above method.The method of the application has higher standardization and QPS peak expansion capacity, lower redundant storage and tile request delay time than cloud data management scheme.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of satellite remote sensing data management, cloud native microservices and geographic information system (GIS), in particular to a distributed spatio-temporal asset real-time online processing method, device and computer readable storage medium for ocean satellite multi-load and multi-resolution remote sensing data. BACKGROUND

[0002] Satellite spatio-temporal assets are data and information with spatio-temporal attributes acquired by satellites, including multiple data types such as satellite remote sensing images, hyperspectral optical data, synthetic aperture radar (SAR) data, etc. Satellite spatio-temporal assets have wide application value in many fields. Through analysis and processing of satellite spatio-temporal assets, decision support can be provided for resource investigation and monitoring, environmental monitoring and protection, urban planning and management, agricultural yield estimation and disaster assessment, etc.

[0003] The spatio-temporal assets of ocean satellites contain a large amount of remote sensing images, with high temporal and spatial resolution, long time series, large spatial coverage, etc., and have multi-dimensional spatial information. With the successful launch and on-orbit operation of China's new generation of ocean color observation satellites such as HY-1D and HY-1E, massive remote sensing images are transmitted back to the ground at a rate of minutes. For the data processing of the massive satellite remote sensing images, the existing cloud data management scheme is mainly based on offline pre-slicing, static publishing or private interface, which has the following shortcomings:

[0004] (1) Lack of unified metadata standard: Different satellites and different loads have inconsistent metadata formats, affecting data sharing and secondary development;

[0005] (2) Lack of real-time performance: offline slicing needs to be generated in advance, causing 20-40% of redundant storage, and it is difficult to meet the near real-time (NRT) business scenario;

[0006] (3) Poor scalability: traditional monolithic or fixed node deployment mode is difficult to scale in high concurrency scenarios;

[0007] (4) Interface is closed: lack of open API based on international standards, limiting the access efficiency of ecological partners and scientific research users.

[0008] Therefore, it is necessary to propose a real-time online processing method suitable for distributed ocean satellite data to solve the above problems in industrial applications. SUMMARY

[0009] In view of the above problems existing in the prior art, a primary purpose of the present application is to provide a distributed marine satellite data management and online processing method conforming to a space-time asset catalog (STAC) standard, which realizes unified description, elastic storage, real-time retrieval and millisecond-level visual access of massive marine satellite remote sensing images through a cloud-native architecture and a dynamic slicing technology.

[0010] Another purpose of the present application is to provide a device, an electronic equipment and a computer readable storage medium that can execute the above method.

[0011] The above purpose of the present application is realized by the following technical solutions.

[0012] In a first aspect, the present application provides a distributed marine satellite space-time asset real-time online processing method, comprising:

[0013] Step S1. Metadata standardization

[0014] The metadata of the unified data exchange format of the marine satellite multi-load data is described by using the existing general specification.

[0015] Step S2: Distributed cloud object storage

[0016] The metadata of the unified data exchange format obtained in step S1 and the original satellite remote sensing image are stored in an object storage bucket (Bucket) at the same time, supporting cross-regional multiple copies and version control.

[0017] Step S3: Unified open application programming interface (Application Programming Interface, API)

[0018] RESTful endpoints conforming to the general specification of geospatial data are provided to realize the attribute, time and space composite retrieval of the metadata stored in step S2.

[0019] Step S4: Dynamic web map tile service (Web Map Tile Service, WMTS)

[0020] The data in the storage bucket in step S2 is obtained by calling the API provided in step S3, based on the containerized micro-service architecture, based on the metadata description in step S1, and 256x256 PNG / JPEG tiles are generated by image pyramid and GDAL virtual file system (VSI) on demand.

[0021] Step S5: Elastic expansion and high-frequency caching

[0022] Automatic expansion is performed based on the generation of tiles in step S4, and hot tiles in step S4 are stored through distributed caching (Redis / Memcached).

[0023] In the method, the existing general specification in step S1 includes STAC 1.0.0 and EO, Projection, Sat extensions.

[0024] In the method, the uniform data exchange format in step S1 is specifically a JSON format.

[0025] In the method, the metadata in step S1 includes basic attributes, time attributes, spatial ranges, projection information, payload information and asset information.

[0026] In the method, the original satellite remote sensing image in step S2 is an original HDF5 image.

[0027] In the method, the support for cross-region multi-copy and version control in step S2 is specifically object storage support for cross-available zone three-copy redundancy, life cycle management and version control.

[0028] In the method, the geospatial data general specification in step S3 includes OGC STA (OpenGeospatial Consortium Spatio-Temporal API) and STAC.

[0029] In the method, the STAC API in step S3 includes at least / stac, / collections, / items, / stac / search endpoints.

[0030] In the method, the dynamic network map tile service in step S4 generates tiles using image pyramids and GDALVRT technology.

[0031] In the method, the automatic expansion in step S5 is specifically based on Kubernetes HPA, and the number of instances is automatically adjusted according to CPU usage or request rate.

[0032] In the method, the hot tile storage through the distributed cache (Redis / Memcached) in step S5 is specifically using Redis distributed cache to store tile data with the highest access frequency in the last 24 hours.

[0033] Further, in order to improve the security and compliance of data, the method further includes any one or a combination of more than two of the following: encrypting the object storage process in step S2, token authentication for the API in step S3 and / or tile transmission encryption for the tile service in step S4.

[0034] In a second aspect, the present application also provides a distributed online processing device capable of executing the method of the first aspect of the present application, comprising a metadata service module, an object storage module, a slicing service module, an authentication module and a monitoring module.

[0035] The metadata service module is deployed in a PostgreSQL + PostGIS cluster and is used for unified format metadata description of marine satellite multi-load data.

[0036] The object storage module is used for storing original HDF5 images in an object storage bucket (Bucket).

[0037] The slicing service module is run in a Kubernetes cluster by using a FastAPI framework and encapsulating a container image, and is used for generating 256x256 PNG / JPEG tiles by using an image pyramid and a GDAL virtual file system (VSI) on demand.

[0038] The authentication module realizes token-level access control based on an OAuth2 protocol.

[0039] The monitoring module is used for monitoring distributed cache, cluster server resources and storage resources, prompting possible overload conditions, so as to dynamically increase resources before the resources are exhausted.

[0040] In a third aspect, the present application also provides a computer readable storage medium having a computer program stored thereon, wherein the program is executed by a processor to realize the steps of the method of the first aspect of the present application.

[0041] The present application discloses a marine satellite space-time asset real-time processing method and device based on STAC metadata and a cloud native architecture and a computer readable storage medium.

[0042] Compared with existing cloud data management solutions, the method of the present application has the following beneficial effects:

[0043] 1. Standardization: STAC metadata and open API improve cross-platform interoperability and reduce 30% of integration costs;

[0044] 2. Reduce storage: dynamic slicing cancels offline pre-slicing, and greatly reduces redundant storage by more than 60%;

[0045] 3. High concurrency: Kubernetes elastic expansion makes the QPS peak expansion ability increase by more than 3 times the original scheme;

[0046] 4. Fast response: Pyramid + cache strategy makes 95% of tile request delay controlled within 150ms;

[0047] 5. Safe and reliable: conforms to the requirements of "Information Security Level Protection 2.0" and "Data Outbound Security Assessment Method". BRIEF DESCRIPTION OF DRAWINGS

[0048] Figure 1 The system overall architecture diagram (composed of metadata service, storage service, slice service, authentication service and monitoring service) described in the embodiment of the application is shown.

[0049] Figure 2 The dynamic WMTS slice generation process in the embodiment of the application is embodied.

[0050] Figure 3 It is an example structure of STAC metadata.

[0051] Figure 4 It is a load balancing and automatic expansion logic diagram in the system described in the embodiment of the application. DETAILED DESCRIPTION

[0052] The technical solutions of the present application are further described in detail through the description of the specific embodiments. The examples of the embodiments are shown in the drawings, wherein the same or similar reference numbers represent the same or similar elements, modules or steps, or elements, modules or steps with the same or similar functions throughout. The specific embodiments described below with reference to the drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0053] The present application provides a kind of distributed ocean satellite space-time assets real-time online processing system, its overall structure as shown in Figure 1 Including browsing layer, gateway layer and service layer.

[0054] The browsing layer is provided with user browser, for real-time in user front end acquisition and with the way of map slice to data display;

[0055] The gateway layer is provided with API gateway, for providing uniform access URL to outside, and the access request is transferred to different cluster processing unit (PODS of K8S) by gateway;

[0056] The service layer is provided with a slice service module, a metadata service module and an object storage module; the slice service provides real-time data slicing service, directly returns data to the front end in the form of memory bytes, avoids occupying a large amount of storage space by traditional slicing, the metadata service quickly locates data files and access positions according to the slice request of the user front end, and the object storage module provides data transmission interaction based on the HTTPS protocol, so that the conversion of data on different transmission protocols is avoided.

[0057] The application also provides a distributed real-time online processing method for marine satellite space-time assets, which can be specifically implemented in the following manner:

[0058] S1. Generating metadata containing 64-bit Z-Key for each satellite remote sensing image based on STAC 1.0.0;

[0059] S2. Storing satellite remote sensing images and metadata produced in S1 in the order of Z-Key with HDF5 Chunk=256px*256px*Bands, and generating an index tpi.idx;

[0060] S3. Calculating Z-Key when a WMTS request arrives, directly reaching offset by using tpi.idx, calling pread() to read Chunk and encoding by PNG Deflate, and generating a tile (Tile);

[0061] S4. Writing the Tile generated in S3 into a Redis distributed cluster (Redis Cluster) and returning;

[0062] S5. Automatically expanding instances of a tile server (Tile Server) when the index rate (tile_server_request_duration_seconds_count[2m])>200QPS by using Prometheus and Kubernetes HPA.

[0063] In the preferred embodiment of the application, S3 is implemented in the following manner:

[0064] HDF5 pyramid-block index (TPI), using TIP algorithm, interlacing Tile rows and columns by Z-Curve into 64-bit keys and storing into tpi.idx mapping <offset,size>, directly pread jumping to read target Chunk during runtime, and single-slice IO delay is lower than 5 ms. The specific implementation requires that, for the load COCTS, the following table 1.

[0065] Table 1

[0066] Resolution (m) Map size (px) Chunk size Offset overhead 1100 8640×4320 2048 x 2048 x Bands 11µs 2200 4320×2160 1024 x 1024 x Bands 9µs 4400 2160×1080 512 x 512 x Bands 6µs 8800 1080×540 256 x 256 x Bands 4µs

[0067] In a preferred embodiment of the present invention, S4 adopts a multi-level caching strategy: Redis Cluster + object storage bucket caching, requiring a hit rate of 93% / 20%.

[0068] In a preferred embodiment of the present invention, S5 employs as follows: Figure 4 The HPA scaling strategy shown is as follows: The `tile_server_request_duration_seconds_count` metric is captured using Prometheus, and the two-minute sliding window rate is calculated in PromQL. When the custom metric `QPS > 200`, HPA triggers a scaling strategy (increasing the number of Pod replicas). When `QPS < 80` and the current number of replicas exceeds the minimum threshold, HPA performs scaling down to reclaim computing resources. The performance of this algorithm is shown in Table 2 below.

[0069] Table 2

[0070] Indicator Invention Conventional approach Improvement Peak QPS 8200 2630 ↑212% Average latency (ms) 95 210 ↓54% Storage footprint (TB, 2y) 78 212 ↓63%

[0071] Furthermore, Figure 2 The process shown employs the following proprietary algorithm:

[0072] 1. Tile-Pyramid Index (TPI) Construction Process TPI aims to enable any WMTS tile request to locate the data block inside the HDF5 file in O(1) time. Its core idea is: first, construct a multi-level pyramid according to resolution; then, interleave the two-dimensional tile numbers into a 64-bit integer Z-Key; finally, associate the Z-Key with...<offset,size> Key-value pairs are written to the index file tpi.idx.

[0073] Step 1: Execute gdaladdo on the original image to generate a L0-L3 pyramid file (MAX is used for no resampling).

[0074] Step 2: Repackage each layer into an HDF5 Chunk according to a fixed block size of 256×256×Bands;

[0075] Step 3: Traverse all chunks in each level and calculate:

[0076] ZKey = bit_interleave(TileRow, TileCol) / / Z-curve

[0077] Step4: Record entry <ZKey, offset64, size32, crc32> to memory buffer;

[0078] Step5: Write binary index file tpi.idx in ascending ZKey order and append 8 bytes Magic (0xA1B2C3D4E5F60708) at the end.

[0079] 2. Execution phase Chunk locating and cropping algorithm

[0080] Input: WMTS request (z, x, y), index file tpi.idx, HDF5 image file.

[0081] R1. Calculate TileRow = y, TileCol = x in z level;

[0082] R2. Call z_encode(TileRow, TileCol) to get ZKey;

[0083] R3. Locate entry using memory mapped tpi.idx (mmap) + binary search ≤ 18 comparisons;

[0084] R4. Read Chunk into shared memory using pread(fd, buf, size, offset);

[0085] R5. Perform 256x256 ROI cropping under GPU or SIMD acceleration;

[0086] R6. Compress using libpng 1.6 Deflate-fast, average 3.1ms;

[0087] R7. Write to Redis Cluster and return to client.

[0088] 3. Hybrid-LFU / LRU cache eviction algorithm

[0089] High resolution Tiles access show hot set characteristics, use LFU; low resolution Tiles access show temporal locality characteristics, use LRU. Weight function: w = 0.6*hit_count_norm + 0.4*recency_norm. When cache_size is set to a certain value, the object with the minimum weight is obtained, and it is deleted from Redis.

[0090] 4. Prometheus-HPA metrics bridging algorithm

[0091] B1. Prometheus fetch tile_server_request_duration_seconds_count every 15s;

[0092] B2. Prometheus-adapter execute PromQL: rate(...[2m]);

[0093] B3. Write result to Kubernetes CustomMetrics API (metric: ts_qps);

[0094] B4. HPA metric rule: ts_qps > 200 automatically add replicas += 2; ts_qps < 80 and replicas > 2 halve;

[0095] B5. After scaling up, Prometheus re-fetch new Pod metrics to form a closed loop.

[0096] The STAC example for HY1D satellite COCTS (whose structure is shown in Figure 3 Figure 1) is as follows:

[0097] {

[0098] "type": "Feature",

[0099] "hy_version": "1.0.0",

[0100] "id": "HY-1D_COCTS_20250318T023456Z_0123",

[0101] "collection": "hy-1d_cocts",

[0102] "bbox": [120.0, 30.0, 131.0, 42.0],

[0103] "geometry": {

[0104] "type": "Polygon",

[0105] "coordinates": [ [

[0107] [120.0, 30.0],

[0108] [131.0, 30.0],

[0109] [131.0, 42.0],

[0110] [120.0, 42.0],

[0111] [120.0, 30.0] ] ]

[0114] },

[0115] "properties": {

[0116] "datetime": "2025-03-18T02:34:56Z",

[0117] "platform": "HY-1D",

[0118] "instruments": ["COCTS"],

[0119] "constellation": "HY",

[0120] "mission": "HY-1D",

[0121] "gsd": 1100, / / Ground resolution approximately 1.1 km

[0122] "cloud_cover": null, / / Ocean color products typically do not calculate cloud cover, so it can be set to null.

[0123] "absolute_orbit": 1456,

[0124] "relative_orbit": 37,

[0125] "orbit_state": "ascending"

[0126] },

[0127] "proj:epsg": 4326,

[0128] "assets": {

[0129] "B01": {

[0130] "href": "https: / / nsoas.org / hy-1d / B01.hdf",

[0131] "type": "application / x-hdf",

[0132] "roles": ["data"],

[0133] "title": "Coastal aerosol (B01)",

[0134] "eo:bands": [

[0135] { "name": "B01", "common_name": "coastal", "center_wavelength": 0.412, "full_width_half_max": 0.020} ]

[0137] },

[0138] "B02": {

[0139] "href": "https: / / nsoas.org / hy-1d / B02.hdf",

[0140] "type": "application / x-hdf",

[0141] "roles": ["data"],

[0142] "title": "Blue-1 (B02)",

[0143] "eo:bands": [

[0144] { "name": "B02", "common_name": "blue", "center_wavelength":0.443, "full_width_half_max": 0.020} ]

[0146] },

[0147] "B03": {

[0148] "href": "https: / / nsoas.org / hy-1d / B03.hdf",

[0149] "type": "application / x-hdf",

[0150] "roles": ["data"],

[0151] "title": "Blue-2 (B03)",

[0152] "eo:bands": [

[0153] { "name": "B03", "common_name": "blue", "center_wavelength":0.490, "full_width_half_max": 0.020} ]

[0155] },

[0156] "B04": {

[0157] "href": "https: / / nsoas.org / hy-1d / B04.hdf",

[0158] "type": "application / x-hdf",

[0159] "roles": ["data"],

[0160] "title": "Green (B04)",

[0161] "eo:bands": [

[0162] { "name": "B04", "common_name": "green", "center_wavelength":0.555, "full_width_half_max": 0.020} ]

[0164] },

[0165] "B05": {

[0166] "href": "https: / / nsoas.org / hy-1d / B05.hdf",

[0167] "type": "application / x-hdf",

[0168] "roles": ["data"],

[0169] "title": "Red (B05)",

[0170] "eo:bands": [

[0171] { "name": "B05", "common_name": "red", "center_wavelength": 0.670, "full_width_half_max": 0.020} ]

[0173] },

[0174] "B06": {

[0175] "href": "https: / / nsoas.org / hy-1d / B06.hdf",

[0176] "type": "application / x-hdf",

[0177] "roles": ["data"],

[0178] "title": "Narrow NIR (B06)",

[0179] "eo:bands": [

[0180] { "name": "B06", "common_name": "nir08", "center_wavelength": 0.753, "full_width_half_max": 0.010} ]

[0182] },

[0183] "B07": {

[0184] "href": "https: / / nsoas.org / hy-1d / B07.hdf",

[0185] "type": "application / x-hdf",

[0186] "roles": ["data"],

[0187] "title": "Broad NIR (B07)",

[0188] "eo:bands": [

[0189] { "name": "B07", "common_name": "nir09", "center_wavelength": 0.865, "full_width_half_max": 0.040} ]

[0191] },

[0192] "B08": {

[0193] "href": "https: / / nsoas.org / hy-1d / B08.hdf",

[0194] "type": "application / x-hdf",

[0195] "roles": ["data"],

[0196] "title": "Shortwave Infrared (SWIR 1) (B08)",

[0197] "eo:bands": [

[0198] { "name": "B08", "common_name": "swir12", "center_wavelength": 1.250, "full_width_half_max": 0.020} ]

[0200] },

[0201] "B09": {

[0202] "href": "https: / / nsoas.org / hy-1d / B09.hdf",

[0203] "type": "application / x-hdf",

[0204] "roles": ["data"],

[0205] "title": "Shortwave Infrared (SWIR 2) (B09)",

[0206] "eo:bands": [

[0207] { "name": "B09", "common_name": "swir16", "center_wavelength": 1.640, "full_width_half_max": 0.060} ]

[0209] },

[0210] "B10": {

[0211] "href": "https: / / nsoas.org / hy-1d / B10.hdf",

[0212] "type": "application / x-hdf",

[0213] "roles": ["data"],

[0214] "title": "Shortwave Infrared (SWIR 3) (B10)",

[0215] "eo:bands": [

[0216] { "name": "B10", "common_name": "swir22", "center_wavelength": 2.170, "full_width_half_max": 0.080} ]

[0218] }

[0219] } ]

[0221] }

[0222] Embodiments of the application also provide an electronic device, which includes an apparatus implementing the foregoing method. The electronic device exists in various forms, including but not limited to:

[0223] (1) Ultra-mobile personal computer device: This type of device belongs to the category of personal computers, has computing and processing functions, and generally also has network connection features. This type of terminal is generally a computer that processes computing data.

[0224] (2) Server: A device that provides computing services. The components of a server include a processor, a hard disk, a memory, a system bus, etc. The server is similar in architecture to a general-purpose computer, but because it needs to provide high-reliability services, it has higher requirements in terms of processing capability, stability, reliability, security, scalability, manageability, etc.

[0225] (3) Other electronic devices with data computation and processing.

[0226] In addition, the terms "first", "second", etc. are used herein only to describe various features, and are not to be construed as indicating or implying relative importance or a specific order of limiting the features indicated. Thus, features limited by "first", "second", etc. can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is at least two, for example, two, three, etc., unless otherwise specifically limited.

[0227] In the description of the present application, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present application, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the skilled person in the art can combine and combine the different embodiments or examples described in the present application and the features of the different embodiments or examples, without contradiction.

[0228] Although the embodiments of the present application have been shown and described above, it is understood that the above-described embodiments are exemplary and cannot be construed as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-described embodiments within the scope of the present application.

Claims

1. A method for real-time online processing of distributed marine satellite spatiotemporal assets, characterized in that, include: S1. Generate metadata containing a 64-bit Z-key for each satellite remote sensing image based on STAC 1.0.0; S2. Store the satellite remote sensing imagery and metadata generated by S1 in Z-key order as data blocks of size 256 pixels × 256 pixels × number of bands in the HDF5 file, and generate an index file tpi.idx; S3. When a WMTS request arrives, the Z-Key is calculated. The offset is directly accessed using the index file tpi.idx. Data chunks are read and encoded using PNG Deflate, then tiles are generated. The HDF5 file uses the Pyramid-Block Indexing (TPI) algorithm, which interleaves the tile rows and columns using Z-Curve encoding to create 64-bit keys, which are then stored in the index file tpi.idx for mapping.<offset,size> At runtime, it can directly and accurately jump to read the target data block chunk, with a single slice IO latency of less than 5 ms; S4. Write the Tile generated in S3 to the Redis distributed cluster and return; A multi-level caching strategy is adopted: Redis Cluster + object bucket caching, requiring a hit rate of 93%; high-resolution tiles obtained by the S3 TPI algorithm are accessed using LFU; low-resolution tiles obtained by the S3 TPI algorithm are accessed using LRU for multiple roaming; the weight function is calculated according to the following formula: The weight function is w = 0.6 * hit_count_norm + 0.4 * recency_norm; When cache_size is greater than the set value, the object with the lowest weight will be deleted from Redis; S5. Using Prometheus and Kubernetes HPA, when the metric calculation result is >200 QPS, automatically scale up the Tile Server instances; HPA's scaling strategy specifically involves using Prometheus to capture the metric `Tile_server_request_duration_seconds_count` and calculating the two-minute sliding window rate in PromQL. When the custom metric `QPS > 200`, HPA triggers the scaling strategy, which increases the number of Pod replicas. When `QPS < 80` and the current number of replicas exceeds the minimum threshold, HPA performs scaling down to reclaim computing resources.

2. A distributed online processing apparatus for performing the method of claim 1, characterized in that, include: The metadata service module, deployed using a PostgreSQL + PostGIS cluster, is used to provide a unified format for metadata description of multi-payload data from marine satellites. The object storage module is used to store the original HDF5 images in an object storage bucket; The slicing service module uses the FastAPI framework and is packaged as a container image to run on a Kubernetes cluster. It is used to generate 256×256 PNG / JPEG tiles on demand by utilizing the image pyramid and GDAL virtual file system. The authentication module implements token-level access control based on the OAuth2 protocol; The monitoring module is used to monitor distributed cache, cluster server resources, and storage resources, and to alert users to potential overload situations.

3. A computer-readable storage medium, characterized in that: It stores a computer program that, when executed by a processor, implements the steps of the method of claim 1.

Images