Position supplementary transmission method based on driving positioning

Abstract

The invention provides a position supplementary transmission method based on driving positioning. The position supplementary transmission method comprises the following steps: S1, through a network amp authorized by a user; the GPS service capability is used for respectively acquiring network point location information and GPS point location information in real time; s2, monitoring point location short chain uploading service; s3, monitoring point position supplementary transmission; s4, accessing a configuration platform, and obtaining required information; according to the invention, based on the short chain compensation service and the point location caching strategy, the position supplementary transmission bottom layer core capability in the driving process is realized, point location acquisition compensation is carried out based on the network point location and GPS point location dual compensation strategy, and the problem of scene point location abnormity such as unstable network or weak network environment or weak GPS signal is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a position supplement transmission method based on driving positioning. Background Art

[0002] When the driver's network is unstable or weak, or the GPS signal is weak, the location reported by the driver will be missing, resulting in lost mileage during the trip, causing errors and interference in subsequent pricing settlement, trip risk control and accountability, and affecting the user's real experience;

[0003] Lack of location retransmission affects the driver's pricing settlement, trip risk control and accountability, etc.

[0004] The point information is acquired in a single way and is not comprehensive;

[0005] Lack of inspection and verification, poor robustness, and affecting the effect of re-transmission;

[0006] There is a lack of configuration for frequency and upload timing, and the flexibility is poor. Therefore, a position supplement transmission method based on driving positioning is proposed. Summary of the invention

[0007] In view of this, the embodiments of the present invention hope to provide a method for position supplementation based on driving positioning to solve or alleviate the technical problems existing in the prior art and at least provide a beneficial option.

[0008] The technical solution of the embodiment of the present invention is implemented as follows: a method for position supplementation based on driving positioning, comprising the following steps:

[0009] S1. Obtain network point information and GPS point information in real time through the network & GPS service capabilities authorized by the user;

[0010] S2, monitoring point short link upload service;

[0011] S3, monitoring point supplementary transmission;

[0012] S4. Access the configuration platform to obtain the required information.

[0013] In some embodiments, in said S1, GPS point information is mainly used, and if GPS point information is missing, network point information is used;

[0014] Get the location information through location.getOriental Location. If the GPS point has a value, use this point. If the GPS point has no value, use this point if it is empty.

[0015] In some embodiments, in S2, the code logically monitors the correctness of the point short link upload service through interface result verification (try / catch monitoring non-200 status, illegal return result). If the verification fails, the point information currently obtained by the driver side is cached in the container cache (local Storage.set ItemSync) for use in the next upload.

[0016] In some embodiments, in S3, the step of point supplement transmission is as follows:

[0017] S31, monitoring point short link upload service, which will retry uploading when it is restored and delete the cache after success;

[0018] S32. Retry when upload fails through exception capture (try / catch), in-line status flow monitoring and heartbeat check. When the order status changes, query whether there are unuploaded monitoring points in the cache through the long link (websoket), and then retry the upload. Monitor the short link API through set Interval, and retry the upload when normal operation is restored.

[0019] In some embodiments, in S31, when uploading the monitoring point information next time, it is detected that there is point information in the cache, and the new (current point obtained in real time) / old (in the cache) monitoring point information is merged and uploaded. After success, the cache is cleared (local Storage.remove ItemSync).

[0020] In some embodiments, in S32, the in-trip state flow states include the driver accepting the order, the driver arriving, and starting the trip.

[0021] In some embodiments, in S32, the heartbeat check is a three-minute self-check.

[0022] In some embodiments, in said S4, accessing the configuration platform is to write dynamic information of upload frequency (uploadRate), upload timing (orderState) and retry count (retryCount) into the configuration platform;

[0023] The required information is obtained by the driver side from the API of the configuration platform at one time during initialization. At the same time, in order to ensure that the configuration information is not missing, a default data will be set, which will be updated only when the API information is successfully obtained.

[0024] The embodiment of the present invention has the following advantages due to the adoption of the above technical solution:

[0025] 1. The present invention is based on short-link compensation services and point caching strategies to achieve the underlying core capabilities of position retransmission during driving, and performs point acquisition compensation based on a dual compensation strategy of network points and GPS points to solve point abnormality problems in scenarios such as unstable network or weak network environment or weak GPS signal.

[0026] 2. The present invention ensures the robustness of the supplementary transmission capability in multiple dimensions based on exception capture, state flow monitoring, and fixed frequency heartbeat self-check strategies, and accesses a configurable platform for flexible configuration in dimensions such as upload frequency and upload timing.

[0027] The above summary is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present invention will be readily apparent by reference to the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0029] Figure 1 is a flow chart of the present invention;

[0030] Figure 2 A block diagram of the present invention. DETAILED DESCRIPTION

[0031] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the spirit or scope of the present invention. Therefore, the drawings and descriptions are considered to be exemplary and non-restrictive in nature.

[0032] It should be noted that the terms "first", "second", "symmetrical", "array", etc. are only used to distinguish between description and position description purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the definition of "first", "symmetrical", etc. can explicitly or implicitly include one or more of these features; similarly, when the quantity of certain features is not limited in the form of words such as "two" or "three", it should be noted that this feature also explicitly or implicitly includes one or more feature quantities;

[0033] In the present invention, unless otherwise clearly specified and limited, the terms such as "installation", "connection", "fixation" and the like should be understood in a broad sense; for example, it can be a fixed connection, a detachable connection, or an integral molding; it can be a mechanical connection, a direct connection, welding, or an indirect connection through an intermediate medium, or it can be the internal connection of two elements or the interaction relationship between two elements. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood based on the description and drawings combined with specific circumstances.

[0034] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0035] like Figure 1-Figure 2 As shown, an embodiment of the present invention provides a method for position supplementation based on driving positioning, comprising the following steps:

[0036] S1. Obtain network point information and GPS point information in real time through the network & GPS service capabilities authorized by the user;

[0037] S2, monitoring point short link upload service;

[0038] S3, monitoring point supplementary transmission;

[0039] S4. Access the configuration platform to obtain the required information.

[0040] In this embodiment, specifically, in S1, GPS point information is mainly used, and if GPS point information is missing, network point information is used;

[0041] Get the location information through location.getOriental Location. If the GPS point has a value, use this point. If the GPS point has no value, use this point if it is empty.

[0042] In this embodiment, specifically, in S2, the code logic monitors the correctness of the point short link upload service through the interface result verification (try / catch monitoring non-200 status, illegal return result). If the verification fails, the point information currently obtained by the driver is cached in the container cache (local Storage.set ItemSync) for use in the next upload. The above setting of container cache (Conta i ner Cache ng) means that when using container technology, the file system resources that the application in the container depends on are cached to increase the container startup speed and reduce the access to the basic storage system. The purpose of container cache is to speed up the creation and operation of containers, especially in container orchestration systems (such as Docker).

[0043] The implementation of container cache usually involves the following key points:

[0044] Images: Before a container runs, it needs to download a base image from the container image repository. The base image contains all the files and resources required for the container to run. Once the image is downloaded locally, it can be cached so that it can be used directly the next time a container with the same dependencies is created without having to download it again.

[0045] Cache Layers: A container image consists of multiple layers, each of which represents a change to a file system. When the container is running, only the changed part (the last layer) is loaded into memory. In this way, if multiple containers use the same image layers, these layers only need to be cached once on disk, rather than copying them for each container.

[0046] Container Layers: In addition to the image layer, a writable layer, the container layer, is added to the container at runtime. This layer allows the container to perform write operations without affecting the base image. When the container is deleted, its container layer is also deleted, so that the latest image layer can be pulled again.

[0047] Volumes: Container volumes are a mechanism for persisting data within a container. A volume can be a local file system path or a network storage resource. The contents of volumes are not cached because they are designed for persistent and shared data.

[0048] Caching Strategies: Container engines (such as Docker) provide different caching strategies, such as local caching, remote caching, and distributed caching. These strategies can help optimize the cache usage of containers in different environments.

[0049] Container caching is very important for increasing the deployment speed of containerized applications and reducing bandwidth usage. It enables rapid iteration and deployment of containerized applications while also reducing the load on the underlying storage system.

[0050] In this embodiment, specifically, in S3, the steps of point supplement transmission are as follows:

[0051] S31, monitoring point short link upload service, which will retry uploading when it is restored and delete the cache after success;

[0052] S32. Through exception capture (try / catch), in-line status flow monitoring and heartbeat check, retry when upload fails. Through long link (websoket), query whether there are unuploaded monitoring points in the cache when the order status changes, and then retry uploading. Through setInterval, monitor the short link API, and retry uploading when it returns to normal. Through the above settings, exception capture (Exception Handling) refers to the mechanism of identifying, handling and responding to abnormal situations that may occur during program operation in software development. When errors or abnormal situations (i.e. "exceptions") are encountered during program execution, the exception capture mechanism allows the program to handle these problems in a controllable way instead of directly crashing or producing unpredictable behavior.

[0053] Exception capture usually includes the following steps:

[0054] Detect anomalies: The program monitors runtime events and states to detect anomalies as soon as they occur.

[0055] Throwing an exception: When an abnormal event is detected, the program throws an exception object, which usually contains information about the exception, such as the exception type and the cause of the occurrence.

[0056] Catching exceptions: Specific parts of the program (usually exception handling blocks or exception handling functions) will catch the thrown exceptions. These handling blocks are code segments that are specifically designed to handle specific types of exceptions.

[0057] Handling exceptions: After catching an exception, the program executes the corresponding processing code to deal with the exception. This may include displaying an error message, logging, attempting to recover, converting the exception, or rethrowing the exception.

[0058] Clean up resources: After handling the exception, the program may perform some cleanup work, such as closing files, releasing memory, etc., to ensure that the program ends in a clean state.

[0059] The purpose of exception handling is to ensure the stability and reliability of the program, so that it can run normally even in the face of errors and unexpected situations. By effectively handling exceptions, the program can provide a better user experience and reduce the risk of system crashes and data loss;

[0060] A long connection is a valid connection between a client and a server that can last for a long time in network communication. This connection is in contrast to a short connection, which usually refers to a connection that is disconnected immediately after each request.

[0061] The characteristics of long links include:

[0062] Duration: A long link can remain active for a period of time without having to be disconnected and re-established after each data transmission.

[0063] Efficiency: For scenarios with frequent data transmission, long links can reduce the overhead of establishing and disconnecting connections and improve communication efficiency.

[0064] Applicable scenarios: Long links are often used in scenarios where data needs to be transmitted multiple times continuously, such as real-time communication (such as VoIP, online games), streaming media transmission, etc.

[0065] Resource usage: Long connections may consume more network and server resources because they need to maintain the connection state.

[0066] Maintenance cost: Long links may require more complex maintenance, such as handling connection reconnection, heartbeat checks, connection leaks, and other issues.

[0067] In Web applications, long connections are usually implemented through HTTP long connections (such as Keep-Alive in HTTP / 1.1) or WebSocket and other technologies. These technologies allow a persistent connection to be maintained between the server and the client, so that multiple requests and responses can be sent continuously without establishing a new connection each time.

[0068] In this embodiment, specifically, in S31, when uploading the monitoring point location next time, it is detected that there is point information in the cache, and the new (current point location acquired in real time) / old (in the cache) monitoring point information is merged and uploaded, and the cache is cleared after success (local Storage.remove ItemSync).

[0069] In this embodiment, specifically, in S32, the in-trip state flow states include the driver accepting the order, the driver arriving and starting the trip.

[0070] In this embodiment, specifically, in S32, the heartbeat check is a three-minute self-check.

[0071] In this embodiment, specifically, in S4, the access configuration platform writes dynamic information of the upload frequency (uploadRate), upload timing (orderState) and retry count (retryCount) into the configuration platform;

[0072] The required information is obtained by the driver side from the API of the configuration platform at one time during initialization. At the same time, in order to ensure that the configuration information is not missing, a default data will be set, which will be updated only when the API information is successfully obtained.

[0073] In this embodiment, specifically, upload frequency refers to the number and speed of upload operations during data transmission. This concept is usually used to describe the process of data transmission from one device to another device or server within a certain period of time.

[0074] The meaning of upload frequency includes the following aspects:

[0075] Interval: The upload frequency can refer to the number of times data is uploaded per hour, per day, or per week. For example, a monitoring system may upload data once a day, while a real-time data analysis system may need to upload data every second.

[0076] Data volume: The upload frequency can also refer to the amount of data transferred in each upload operation. For example, the system may upload a small amount of data (such as a few KB) or a large amount of data (such as a few GB) each time.

[0077] Activity duration: Upload frequency can also describe the duration of the device's upload activity. For example, the device may upload data frequently when the user is active, and upload less frequently when the user is inactive.

[0078] Network bandwidth: The upload frequency is limited by the network bandwidth. If the network bandwidth is low, the upload frequency may need to be reduced to avoid network congestion and slow data transfer.

[0079] System performance: The processing power and resources of your system will also affect the frequency of uploads. If your system has limited resources, you may need to adjust the frequency of uploads to avoid negatively affecting system performance.

[0080] In this embodiment, specifically, upload timing refers to the process of deciding when to upload data to a server or other storage system during data collection, processing, or application execution. This concept is very important in the fields of data synchronization, logging, telemetry data, backup operations, etc.

[0081] The meaning of upload timing includes the following aspects:

[0082] Data integrity: Upload data after ensuring data integrity and consistency, and avoid uploading partial or incomplete data.

[0083] System load: Consider the current load of the system and avoid uploading data during system peak hours to reduce the impact on system performance.

[0084] Network conditions: Choose the right time to upload data based on the network availability and bandwidth to improve the efficiency and success rate of data transmission.

[0085] Data value: The upload timing is determined based on the value and timeliness of the data. For example, for real-time analysis, real-time data needs to be uploaded quickly; for non-real-time analysis, data upload can be delayed.

[0086] Event triggering: In some cases, data upload is triggered by specific events, such as user behavior, system errors, scheduled tasks, etc.

[0087] Frequency and strategy: Determine the timing of uploading data based on preset frequencies and strategies, such as periodic uploading, on-demand uploading, or uploading triggered by data volume.

[0088] In this embodiment, specifically, the retry count refers to the number of times the system attempts to re-execute an operation after an operation fails in a computer program or network communication. When a request or operation fails to complete successfully due to some errors (such as network problems, server failures, permission restrictions, system busy, etc.), the system will make multiple attempts according to the set retry strategy in the hope of eventually being able to successfully execute.

[0089] The meaning of the number of retries includes the following aspects:

[0090] Retry strategy: The system can have multiple retry strategies, such as fixed retry times, exponential backoff retry, etc. Fixed retry times means that the system pre-sets a maximum number of retries, and will not retry after exceeding this number. Exponential backoff retry means that the time interval between each retry will increase as the number of retries increases, thereby reducing the impact on the system.

[0091] Retry conditions: Not all failures will trigger a retry. Usually, the system will decide whether to retry based on specific conditions. For example, if it is a temporary network problem, the system may try to reconnect; if it is a permanent error, it may not retry.

[0092] Resource consumption: Too many retries may lead to resource waste, because each retry consumes a certain amount of system resources. Therefore, it is important to set the number of retries and retry strategy reasonably.

[0093] Timeout processing: After the number of retries reaches the set value, if the operation still fails to complete successfully, the system will handle it according to the timeout policy, which may include logging the error, notifying the user or administrator, entering maintenance mode, etc.

[0094] Application scenarios: Retry times are very common in many application scenarios, such as Web service requests, database operations, file transfers, network connections, API calls, etc., where retries may be required.

[0095] When setting the number of retries and policies, you need to balance the robustness and efficiency of the system to ensure that while ensuring the success of the operation, there is no waste of resources or unnecessary service delays due to excessive retries.

[0096] In this embodiment, specifically, API is the abbreviation of "Application Programming Interface", which is a set of predefined rules and protocols for building and interacting with interfaces between software applications. API defines how requests are made, how to send requests, the expected response format, and the functions and data that can be accessed.

[0097] The main role of API is to allow different software applications to interact with each other without the need for direct user involvement. It hides the complexity of the underlying system and exposes only a portion of the available functions, allowing developers to create applications more simply and quickly.

[0098] APIs can be divided into several types:

[0099] Built-in API: A set of built-in functions and libraries provided by a programming language or framework.

[0100] Libraries: Contains pre-written code to perform specific tasks.

[0101] Framework: Provides building blocks with specific functionality to help developers quickly create applications.

[0102] Operating system API: Allows applications to interact with the operating system.

[0103] Library API: A library developed by a third party that provides specific functionality.

[0104] Service API: A remote server that provides data and functions over a network.

[0105] Using the API typically involves the following steps:

[0106] Request: The client (usually an application written by a developer) sends a request to the server.

[0107] Response: The server processes the request and returns a response, which may include data, a status code, and / or an error message.

[0108] In this embodiment, specifically, Figure 2As shown, starting from the "driver", he can obtain the "GPS point", and then the system will save the data to the "cache server" according to the "cache service". If the "short link upload service" is required, a "failure" result will be generated. In the case of "success", the data in the cache will be cleared and an attempt will be made to execute the "retry service". If the "retry service" is successful, the data will be uploaded to the "monitoring server". In addition, there is an "exception capture" link to capture and record the "state flow" and "heartbeat check". Finally, all data will be sent to the "center" for processing.

[0109] In the present embodiment, specifically, for those skilled in the art, it can be further realized that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to the function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0110] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0111] In this embodiment, specifically, it can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented by software, the above embodiments can be implemented in whole or in part in the form of computer program goods;

[0112] When the computer instruction or computer program is loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instruction can be stored in a computer-readable storage medium, or transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instruction can be transmitted from a website site, a computer, a server, or a data center to another website site, a computer, a server, or a data center by wired or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that contains one or more available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state hard disk.

[0113] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0114] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0115] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0116] If the functions are implemented in the form of software functional units and sold or used as independent goods, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of software goods, or the part that contributes to the prior art or the part of the technical solution. The computer software goods are stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0117] The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of various changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A method for position supplement based on driving positioning, characterized in that: The following steps are involved: S1. Obtain network point information and GPS point information in real time through the network & GPS service capabilities authorized by the user; S2, monitoring point short link upload service; S3, monitoring point supplementary transmission; S4. Access the configuration platform to obtain the required information.

2. The position supplement transmission method based on driving positioning according to claim 1 is characterized in that: In S1, GPS point information is mainly used. If GPS point information is missing, network point information is used; Get the point information through location.getOriginalLocation. If the GPS point has a value, use this point. If the GPS point has no value or is empty, use this point.

3. The position supplement transmission method based on driving positioning according to claim 1 is characterized in that: In S2, the code logically monitors the correctness of the point short link upload service through the interface result verification (try / catch monitoring non-200 status, illegal return result). If the verification fails, the point information currently obtained by the driver side is cached in the container cache (localStorage.setItemSync) for use in the next upload.

4. The position supplement transmission method based on driving positioning according to claim 1 is characterized in that: In S3, the steps of point supplement transmission are as follows: S31, monitoring point short link upload service, which will retry uploading when it is restored and delete the cache after success; S32. Retry when upload fails through exception capture (try / catch), in-line status flow monitoring and heartbeat check. When the order status changes, query whether there are unuploaded monitoring points in the cache through the long link (websoket), and then retry the upload. Monitor the short link API through setInterval and retry the upload when normal operation is restored.

5. The position supplement transmission method based on driving positioning according to claim 4 is characterized in that: In S31, when uploading the monitoring point information next time, it is detected that there is point information in the cache, and the new (current point obtained in real time) / old (in the cache) monitoring point information is merged and uploaded. After success, the cache is cleared (localStorage.removeItemSync).

6. The position supplement transmission method based on driving positioning according to claim 4 is characterized in that: In the S32, the in-trip state flow states include the driver accepting the order, the driver arriving and starting the trip.

7. The position supplement transmission method based on driving positioning according to claim 4 is characterized in that: In the step S32, the heartbeat check is a three-minute self-check.

8. The position supplement transmission method based on driving positioning according to claim 1 is characterized in that: In said S4, accessing the configuration platform is to write dynamic information of upload frequency (uploadRate), upload timing (orderState) and retry count (retryCount) into the configuration platform; The required information is obtained by the driver side from the API of the configuration platform at one time during initialization. At the same time, in order to ensure that the configuration information is not missing, a default data will be set, which will be updated only when the API information is successfully obtained.

Images