Cross-border trade planning method and device and electronic equipment

Abstract

The invention relates to a cross-border trade planning method, which comprises the following steps: acquiring space coordinate data of a trade position so as to establish a regular gridding route map and determine a unified coordinate system; on the basis of a unified coordinate system, generating a Morton space code which is completely adaptive to the regular gridding route map; building a multi-path lookup tree storage system, converting the retrieval center coordinate into a corresponding Morton code based on the multi-path lookup tree storage system, and intercepting to obtain a target coding prefix; in the retrieval process, a trade position with high-frequency updating of a space coordinate is preferentially matched, the retrieval precision is optimized by dynamically adjusting the length of a Morton code coding prefix, and full coverage of the trade position of a cross-regional target and precise capture of a missing target at a coding boundary are respectively completed by combining two core mechanisms of effective direction expansion and coding boundary completion. The invention further relates to a cross-border trade planning device and electronic equipment. Through the arrangement, the trade position positioning accuracy can be improved.

Description

A cross-border trade planning method, apparatus and electronic equipment Technical Field

[0001] This invention relates to the field of cross-border e-commerce logistics planning technology, and in particular to a cross-border trade planning method, apparatus and electronic equipment. Background Technology

[0002] Current trade location positioning technologies suffer from numerous pain points that urgently need to be addressed. Mainstream positioning methods include image template matching, traditional spatial coding, and simple grid storage, each with significant drawbacks: image template matching is susceptible to occlusion of trade locations, and scaled-down maps lose location details, resulting in low positioning accuracy; traditional spatial coding is prone to coordinate mapping conflicts, failing to meet the retrieval needs of different scenarios and exhibiting poor adaptability; simple grid storage mixes dynamic relay locations with static endpoint locations, generating significant retrieval redundancy and causing slow request response times.

[0003] Meanwhile, existing search strategies have obvious coverage blind spots, making it difficult to flexibly adapt to search needs with different search radii and insufficient adaptability to maps of different shapes; the filtering mechanism has low flexibility, cannot support users to customize filtering dimensions and priorities, and is difficult to meet diverse positioning and trade planning needs.

[0004] To address the core pain points of existing technologies in adapting to multiple scenarios and handling high-concurrency retrieval, there is an urgent need to develop a new cross-border trade planning method to solve problems such as low positioning accuracy, slow retrieval efficiency, blind spots in coverage, and inflexible filtering, and to adapt to cross-border trade scenarios of different scales and diverse retrieval needs. Summary of the Invention

[0005] This invention relates to a cross-border trade planning method, apparatus, and electronic device, which can improve the accuracy of trade location positioning during cross-border trade planning.

[0006] The technical solution proposed in this invention is as follows: a cross-border trade planning method, comprising: acquiring spatial coordinate data of trade locations to build a regular gridded route map and determine a unified coordinate system; based on the unified coordinate system, performing binary cross-combination operations on the two-dimensional coordinates of the regular gridded route map, and then converting them to decimal format to generate a Morton spatial code that is fully adapted to the regular gridded route map; using the generated Morton code as the core index, building a multi-way search tree storage system; all trade location data are aggregated and classified according to the association relationship of the Morton code encoding prefix, and stored in the corresponding nodes of the multi-way search tree storage system, while dividing each tree node into hot storage area and cold storage area according to the update frequency of each trade location data to achieve hierarchical storage management of data; after obtaining a search request containing the search center coordinates and the corresponding search radius, based on the multi-way search tree storage system, converting the search center coordinates into the corresponding Morton code and extracting the target encoding prefix; during the search process, prioritizing the matching of trade locations with high-frequency spatial coordinate updates, and dynamically adjusting the Morton code... The length of the code prefix optimizes retrieval accuracy. Combined with two core mechanisms, effective directional expansion and code boundary completion, it achieves full coverage of cross-regional target trade locations and accurate capture of targets missed at code boundaries. Finally, through multi-dimensional filtering, it accurately locates the spatial position of all target trade locations within the search radius.

[0007] Furthermore, the specific construction process of the coordinate system is as follows: Spatial coordinates are collected for trade locations that require spatial positioning in cross-border trade planning to obtain initial coordinate data. Trade locations include relay locations and endpoint locations. A regular gridded route map is constructed based on preset size parameters, which are adapted to the needs of the trade scenario. A unified two-dimensional rectangular coordinate system is established, with preset vertices of the regular gridded route map set as the origin of the coordinate system, and the horizontal and vertical directions set as the positive directions of the coordinate axes. This maps the initial coordinate data of the trade locations to the coordinate system, resulting in standardized coordinate data, where the coordinate values ​​are integers that conform to the map grid range. The standardized coordinate data is then associated and bound with the unique identifier of the corresponding trade location to form a coordinate-trade location association dataset, thus completing the establishment of the unified coordinate system.

[0008] Furthermore, the process of obtaining the Morton code is as follows: Standardized coordinate data of the trade location is extracted from the coordinate-trade location association dataset. The x and y coordinates are converted into binary numbers of a preset number of bits, with high-order bits padded with 0s if necessary. The binary bits corresponding to the x and y coordinates are alternately extracted from the high-order bits to the low-order bits to form an intermediate binary code. The intermediate binary code is split into multiple binary units according to a preset unit length. Each binary unit is converted into a decimal number within a corresponding range. All decimal numbers are concatenated sequentially to generate a Morton code adapted to the trade scenario. The Morton code is stored in association with a unique identifier of the trade location.

[0009] Furthermore, the specific process of dividing the hot storage area and cold storage area through the multi-way search tree storage system is as follows: A multi-way search tree storage structure is constructed based on the prefix length of the Morton code, with each node of the multi-way search tree corresponding to a set of Morton codes with the same prefix; the Morton codes associated with trade locations are extracted, and the encoded prefix is ​​truncated according to a preset prefix length; trade locations with the same encoded prefix are aggregated and stored in the corresponding node of the multi-way search tree; a location update frequency statistical period is set, and the number of spatial coordinate updates for each trade location within the statistical period is counted in real time; a hot storage area and a cold storage area are divided within each node of the multi-way search tree, with the hot storage area using a memory-first storage method and the cold storage area using a disk cache storage method; trade locations whose spatial coordinate updates reach a preset update threshold within the statistical period are assigned to the hot storage area of ​​the corresponding node, and trade locations whose spatial coordinates are not updated within the statistical period are assigned to the cold storage area of ​​the corresponding node, establishing an association index between the storage area and the trade location.

[0010] Furthermore, the specific process for optimizing retrieval accuracy is as follows: Obtain the search radius parameter from the location request; use an exponential index optimization algorithm to establish a mapping relationship between the search radius and the Morton code prefix length; calculate the target prefix length corresponding to the current search radius based on the mapping relationship, as the search radius and prefix length are negatively correlated; based on the calculated target prefix length, extract the prefix portion of the Morton code corresponding to the center coordinates to form the target encoded prefix; if the number of matching nodes deviates from the suitable range during the retrieval process, dynamically fine-tune the target prefix length and re-match the nodes until the number of matching nodes is within the preset optimal retrieval range, thereby achieving dynamic optimization of retrieval accuracy.

[0011] Furthermore, the specific process of effective direction expansion is as follows: Determine the basic directions for effective direction expansion, which are up and down, left and right, and the four diagonal directions; obtain the position of the center coordinates in a unified coordinate system, and calculate the vertical distance from the center coordinates to the four boundaries of the route map; compare each vertical distance with a preset boundary threshold, and automatically trim expansion directions that exceed the range of the route map; for the remaining effective expansion directions, sequentially search the multi-way search tree nodes associated with the target coding prefix in each direction to expand the search coverage and ensure the comprehensiveness of the search for nearby trade locations.

[0012] Furthermore, the specific process of code boundary completion is as follows: Identify the neighboring nodes of the multi-way search tree node corresponding to the target code prefix. The neighboring nodes are nodes whose code prefixes differ only in the last bit. Perform supplementary retrieval on the neighboring nodes and extract the spatial coordinate data of the trade location stored in the neighboring nodes. Calculate the actual straight-line distance between the trade location obtained from the supplementary retrieval and the center coordinates. Include the trade locations whose actual straight-line distance is less than or equal to the search radius into the candidate trade location set to eliminate the retrieval blind spot across the code prefix boundary and ensure the integrity of the positioning coverage.

[0013] Furthermore, the specific process of multi-dimensional filtering is as follows: Preset multi-dimensional filtering dimensions, including trade location type, level range, faction affiliation, and interaction status; sort each filtering dimension according to preset priority; receive user-defined filtering instructions, including dynamically adding or removing filtering dimensions, and adjusting the priority order of each dimension; based on the sorted filtering dimensions, filter the trade locations in the candidate trade location set layer by layer, filtering out target type trade locations by trade location type, filtering out trade locations that meet level requirements by level range, and so on, completing the full-dimensional filtering; perform a secondary distance verification on the filtered trade locations to exclude trade locations that actually exceed the search radius, obtaining the final candidate trade locations.

[0014] To achieve the above technical solution, this application also includes a cross-border trade planning device, comprising: a central control section and a planning section, wherein the planning section is used for cross-border trade route planning, the central control section is electrically connected to the planning section, and the central control section executes the cross-border trade planning method when receiving the route signal output by the planning section.

[0015] To achieve the above technical solution, this application also includes an electronic device, comprising: a memory, a processor, and a computer program stored on the memory, wherein the processor is configured to run the computer program to execute a cross-border trade planning method.

[0016] The beneficial effects of this invention are as follows: The cross-border trade planning method constructs a full-process retrieval system using spatial coordinates and Morton codes. It establishes a unified coordinate system and generates adapted Morton codes, converting two-dimensional coordinates into one-dimensional codes. This enables efficient compressed storage of spatial data and allows for rapid determination of spatial proximity through code prefixes, laying a precise foundation for retrieval. Secondly, it uses an exponential algorithm to dynamically adapt the prefix length to the search radius. Combined with 8-directional effective expansion and code boundary completion, it eliminates retrieval blind spots, ensuring no trade locations across regions or code boundaries are missed. This improves the accuracy of cross-border trade location positioning, significantly enhancing the precision of cross-border trade location locating. Attached Figure Description

[0017] Figure 1 is a structural block diagram of an electronic device.

[0018] Figure 2 is a flowchart of a cross-border trade planning method.

[0019] Figure 3 is a structural block diagram of a cross-border trade planning device. Detailed Implementation

[0020] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in specific embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0022] It should be noted that the terms "first," "second," and similar terms used in this application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, "a" or "one," and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. "A plurality of" or "multiple" indicates at least two. Unless otherwise stated, terms such as "front," "back," "left," "right," "lower," and / or "upper" are for illustrative purposes only and are not limited to a location or spatial orientation. Terms such as "comprising" or "including" indicate that the elements or objects preceding "comprising" or "including" encompass the elements or objects listed following "comprising" or "including" and their equivalents, and do not exclude other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0023] The singular forms “a,” “the,” and “the” used in this application specification and appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0024] The multimodal fusion-based flaw detection method provided in this embodiment can be executed in an electronic device 100 or a similar device. Figure 1 is a hardware structure block diagram of an electronic device 100 executing an embodiment of this application. As shown in Figure 1, the electronic device 100 may include one or more (only one is shown in Figure 1) memories 12 and processors 11. The electronic device 100 is a cross-border control terminal used to establish a rule-based gridded route map that can adapt to cross-border trade planning of different distances, thereby improving the accuracy of cross-border trade route planning.

[0025] The memory 12 stores program instructions, such as software programs and modules for application software, as in the cross-border trade planning method of this embodiment. The processor 11 executes the program instructions stored in the memory 12. By running the computer program stored in the memory 12, it can perform various functional applications and data processing, thereby realizing cross-border trade planning.

[0026] The processor 11 may include, but is not limited to, a microprocessor 11 (Microcontroller Unit, abbreviated as MCU) or a programmable gate array (FPGA).

[0027] Those skilled in the art will understand that the structure shown in FIG1 is merely illustrative and does not limit the structure of the electronic device 100 described above. For example, the electronic device 100 may include more or fewer components than shown in FIG1, or have a different configuration than that shown in FIG1.

[0028] As shown in Figure 1, this invention discloses a cross-border trade planning method. The method includes: collecting spatial coordinate data of trade locations, constructing a regular gridded route map, and establishing a unified coordinate system; based on the coordinate system, generating Morton codes adapted to the regular gridded route map by combining binary coordinates and converting them to decimal; based on the Morton codes, constructing a multi-way search tree storage system, aggregating and storing trade locations in corresponding nodes according to the association relationship of the coding prefix, and dividing the nodes into hot storage areas and cold storage areas according to the update frequency of the trade locations; receiving retrieval requests containing center coordinates and search radius, using the multi-way search tree storage system to convert the center coordinates into Morton codes and extract the target prefix, prioritizing the matching of trade locations with high-frequency spatial coordinate updates, optimizing retrieval accuracy by dynamically adjusting the length of the coding prefix, capturing target trade locations that are missed across regions and boundaries by combining effective directional expansion and coding boundary completion, and accurately locating the spatial position of the target trade location within the search radius through multi-dimensional filtering.

[0029] Specifically, the construction process of the coordinate system is as follows: Spatial coordinates are collected for trade locations requiring spatial positioning in cross-border trade planning to obtain initial coordinate data. Trade locations include relay and endpoint locations. A regular gridded route map is constructed based on preset size parameters, which are adapted to the needs of the trade scenario. A unified two-dimensional Cartesian coordinate system is established, with preset vertices of the regular gridded route map set as the origin, and the horizontal and vertical directions set as the positive directions of the coordinate axes. This maps the initial coordinate data of the trade locations to the coordinate system, obtaining standardized coordinate data where the coordinate values ​​are integers conforming to the map grid range. The standardized coordinate data is then associated with the unique identifier of the corresponding trade location, forming a coordinate-trade location association dataset, thus completing the establishment of the unified coordinate system.

[0030] Specifically, the detailed process of constructing the coordinate system is as follows: Trade location is the core target entity in the positioning process, and it is divided into two categories according to its dynamic location characteristics, adapting to differentiated storage and retrieval strategies: Relay locations: These include the locations traversed from the initial location to the final location in the trade planning route. Trade location classification is automatically labeled by the trade location management system, and users can manually adjust the classification labels. The classification results are synchronized to the subsequent storage and retrieval modules.

[0031] Preset size parameters are a core configuration item for regular gridded maps. They dynamically adapt to the scale of trade scenarios and positioning needs, specifically divided into three scenario templates: Small-scale cross-border trade map: Preset size parameters are adapted to trade between neighboring countries, with a high grid density to ensure near-range positioning accuracy; Medium-scale cross-border trade map: Preset size parameters are adapted to trade between adjacent continents, balancing positioning accuracy and server load; Large-scale cross-border trade map: Preset size parameters are adapted to trade spanning hemispheres, with a moderately reduced grid density, and optimized coding to ensure large-scale retrieval efficiency. Parameter configuration is achieved through the "Map Grid Configuration Interface," which offers two configuration methods: one is to directly select a preset scenario template, and the system automatically fills in the size parameters; the other is to manually enter the number of grid rows, columns, and unit grid size, and preview the map coverage and grid distribution in real time after input. Configuration requires verification of server hardware performance. If the parameters exceed the hardware capacity threshold, the system will display a warning and recommend the optimal parameter combination to ensure smooth map operation.

[0032] Spatial coordinate acquisition is performed through the coordinate picking module built into the trade engine, with the acquisition logic strongly correlated with the trade location type. A unified two-dimensional Cartesian coordinate system adopts an architecture combining a "vertex origin" and "fixed axis direction," with the following design details: Origin selection: Three origin modes are available: top-left corner, bottom-left corner, and center point. Users select through the "Coordinate System Configuration Interface," with the top-left corner as the default, adapting to the rendering logic of mainstream trade engines; Coordinate axis direction: Fixed settings of "horizontal to the right as the positive x-axis and vertical downward as the positive y-axis," consistent with screen display logic, reducing coordinate transformation errors; Coordinate value constraints: Coordinate values ​​are limited to non-negative integers, with a value range consistent with the map grid range, ensuring that each trade location coordinate is accurately mapped to a unique grid cell, providing a regularized input for Morton codes. After the coordinate system configuration is complete, the system automatically generates a "Coordinate Mapping Lookup Table," recording the conversion relationship between native and standardized coordinates, facilitating user export and viewing for troubleshooting.

[0033] The association binding is achieved through a two-way mapping table of "coordinates-trade locations". The core logic is as follows: Binding basis: The unique identifier of the trade location (including trade location ID and globally unique number) corresponds one-to-one with the standardized coordinates, ensuring that trade location information can be quickly queried through coordinates and coordinate data can be quickly obtained through trade location identifiers; Storage method: The mapping table is stored in an in-memory database (such as Redis), which can achieve millisecond-level query response to meet the needs of high-frequency location requests; Maintenance mechanism: When the trade location coordinates are updated, the mapping table is updated in real time; when a trade location is deleted, the corresponding record is automatically removed from the mapping table; Users can manually maintain the binding relationship through the "Association Management Interface", including adding bindings, unbinding, and modifying bindings, which is convenient for traceability.

[0034] By constructing a unified coordinate system, we can: 1) solve the positioning deviation problem caused by inconsistent native coordinate benchmarks, with the coordinate error not exceeding one grid cell after standardization; 2) establish a strong correlation between "trade location and coordinates," providing a unified data foundation for subsequent coding, storage, and retrieval; and 3) lay the foundation for differentiated positioning strategies through trade location classification and parameter adaptation, thereby improving positioning efficiency and accuracy.

[0035] In this embodiment, the specific process of standardized calibration using a unified coordinate system is as follows: Addressing the differences in the baselines of the original coordinate systems for different trade locations (different origin positions and axial directions), the coordinate units are first unified, and then a precise mapping is achieved through a "three-step mathematical transformation." The specific transformation logic is as follows: First, a far-point translation transformation is performed. Step 1: Obtain the corresponding coordinates of the origin of the original coordinate system in the unified coordinate system (referred to as the "origin offset"). The calculation method is: subtract the horizontal component of the origin of the original coordinate system from the horizontal component of the target origin of the unified coordinate system to obtain the horizontal offset; subtract the vertical component of the origin of the original coordinate system from the vertical component of the target origin of the unified coordinate system to obtain the vertical component offset. Step 2: Subtract the horizontal component of the original origin from the horizontal component of the original coordinate system, and add the horizontal offset to obtain the translated horizontal median value; subtract the vertical component of the original origin from the vertical component of the original coordinate system, and add the vertical offset to obtain the translated vertical median value, thus achieving origin alignment.

[0036] Next, perform axial adaptation transformation. If the vertical axis of the original coordinate system is opposite to that of the unified coordinate system (e.g., the original vertical upward is the positive direction, and the unified coordinate system vertical downward is the positive direction), then the vertical intermediate value is flipped: the vertical intermediate value is subtracted from the total vertical length of the map in the unified coordinate system to obtain the adapted vertical component; if the horizontal axis is opposite (e.g., the original horizontal leftward is the positive direction), then the horizontal intermediate value is subtracted from the total horizontal length of the map to obtain the adapted horizontal component; if the axes are the same, then the translated intermediate value is directly retained.

[0037] Finally, numerical mapping and range verification are performed. The first step is to calculate the scaling ratio: divide the total horizontal length of the map in the unified coordinate system by the effective horizontal range length of the native coordinate system to obtain the horizontal scaling ratio; the vertical scaling ratio is obtained similarly (if the units of the native and unified coordinate systems are the same, the scaling ratio is 1). The second step is to multiply the adapted horizontal component by the horizontal scaling ratio, and the vertical component by the vertical scaling ratio, then round to the nearest integer to obtain the integer coordinate value. The third step is range verification: if the integer coordinate value is less than 0, it is corrected to 0; if it is greater than the total length of the corresponding dimension of the map in the unified coordinate system minus 1, it is corrected to that maximum value, ensuring that the coordinate value meets the non-negative integer requirement of the map grid range.

[0038] To address coordinate jumps caused by network latency during relay location movement, a compensation mechanism combining "jump judgment" and "sliding window weighted averaging" is adopted to ensure smooth coordinate transitions. The specific implementation is as follows: The jump judgment rules are: First, set a jump threshold: using map grid cells as the unit, the jump threshold is set to 3 grid cells (derived from the document that "the standardized coordinate error should not exceed 1 grid cell," a 3x error can effectively distinguish between normal movement and abnormal jumps); Second, real-time comparison: after the mathematical transformation in the first step, the currently collected native coordinates are compared with the previously calibrated coordinates, with the horizontal and vertical differences calculated separately; Third, judgment result: if the difference in either direction exceeds the jump threshold, it is judged as a coordinate jump, triggering the compensation mechanism; if the difference in neither direction exceeds the threshold, the current transformed coordinates are directly used as the calibrated coordinates, without compensation.

[0039] The specific steps of the sliding window weighted average compensation are as follows: First, window data selection: Select the five most recent valid coordinate data (including the current jump coordinates) from newest to oldest, ensuring coverage of the document's relay positions with a collection frequency of up to 30 times / second, balancing real-time performance and smoothness. Second, weight allocation rules: Assign decreasing weights from newest to oldest, specifically: the latest data accounts for 40%, the second newest for 30%, the third for 15%, the fourth for 10%, and the earliest for 5%, with a total weight sum of 100%. Third, weighted average calculation: Horizontal direction: Multiply the horizontal component of each data point by its corresponding weight and sum them to obtain the horizontal weighted sum. Vertical direction: Calculate the vertical weighted sum similarly. Integer conversion: Round the horizontal and vertical weighted sums to the nearest integer to obtain the smoothed calibration coordinates. Fourth, boundary verification: If the smoothed coordinates exceed the map range of the unified coordinate system, correct them according to the rule of "taking the upper limit value if exceeding the upper limit, and taking the lower limit value if exceeding the lower limit," ensuring compliance with non-negative integer requirements.

[0040] The compensation mechanism is linked in real time with the "coordinate-trade location" bidirectional mapping table: the coordinates after each calibration are synchronously updated to the mapping table, overwriting the original collected coordinates; if no jump occurs in 3 consecutive collections, the compensation mechanism is automatically exited and the calibration method of directly using the transformed coordinates is restored to ensure the positioning response speed when the relay position moves normally.

[0041] Specifically, the process of obtaining the Morton code is as follows: Standardized coordinate data of the trade location is extracted from the coordinate-trade location association dataset. The x and y coordinates are converted into binary numbers of a preset number of bits, with leading zeros padded if the number of bits is insufficient. The binary bits corresponding to the x and y coordinates are alternately extracted from the highest to the lowest bit, and these bits are cyclically combined to form an intermediate binary code. The intermediate binary code is split into multiple binary units according to a preset unit length. Each binary unit is converted into a decimal number within a corresponding range, and all decimal numbers are concatenated sequentially to generate a Morton code adapted to the trade scenario. The Morton code is stored in association with a unique identifier of the trade location.

[0042] The detailed process of Morton code generation is as follows: The preset number of bits is a key parameter determining the accuracy of the Morton code, and it is strongly correlated with map size and positioning accuracy requirements. Specific configuration standards are as follows: Small-scale cross-border trade maps: High positioning accuracy is required, so the preset number of bits is configured to 14-16. The spatial range corresponding to the code is relatively small, ensuring accurate differentiation of nearby trade locations. Medium-scale cross-border trade maps: Positioning accuracy and retrieval efficiency need to be balanced, so the preset number of bits is configured to 12-14. Large-scale cross-border trade maps: The retrieval range is wide, requiring reduced coding complexity, so the preset number of bits is configured to 10-12. The preset number of bits is set through the "Morton Code Configuration Interface." After setting, the system displays the spatial range and positioning accuracy corresponding to the code in real time. Users can fine-tune the settings based on actual test results, with a fine-tuning step of 1 bit to ensure configuration flexibility.

[0043] After generating the Morton code for the center coordinates according to a preset number of bits, the 8-neighborhood code pre-generation process is executed simultaneously to construct a "center code - 8-neighborhood code" mapping relationship to eliminate boundary blind spots caused by coding mutations. The specific steps are as follows: Inverse decoding: Using the Morton inverse decoding algorithm, the center code is restored to the corresponding rectangular region boundary coordinates (including minimum / maximum longitude and minimum / maximum latitude), ensuring the accuracy of the spatial reference for neighborhood calculation; Neighborhood center coordinate calculation: Based on the boundary coordinates, the center coordinates of the 8 neighboring regions (up, down, left, right, upper left, upper right, lower left, lower right) are calculated respectively, with each neighboring region having a completely consistent spatial range with the region corresponding to the center code; Neighborhood code generation: The Morton code with the same preset number of bits as the center code is generated for the 8 neighboring center coordinates. The system employs several techniques: First, it ensures that the precision of the neighboring codes perfectly matches the central code, preventing spatial misalignment due to precision differences. Second, it stores the mapping relationship between the central code and its eight neighboring codes as metadata in the multi-way search tree node to which the code belongs. This metadata can be directly accessed during retrieval without real-time calculation of the neighboring codes, reducing retrieval overhead. Third, it dynamically updates the system when the user adjusts the preset number of bits via the configuration interface. This automatically regenerates the central code and its eight corresponding neighboring codes, synchronously updating the mapping relationship metadata in the multi-way search tree node. This ensures that even after the preset number of bits is adjusted, the neighboring codes maintain consistent precision and spatial proximity with the central code.

[0044] The binary conversion of x and y coordinates uses a general integer-to-binary algorithm with the following core rules: Conversion logic: The integer value of the standardized coordinate is successively divided by 2, and the remainders are recorded until the quotient is 0. The remainders are then arranged in reverse order to obtain the binary number. Padding rule: If the length of the converted binary number is less than the preset number of bits, 0s are added to the high bits to ensure that the binary number lengths of the x and y coordinates are consistent, providing a unified basis for subsequent alternating truncation. For example, if the standardized x coordinate is 123 (decimal) and the preset number of bits is 12, the converted binary number is 000001111011. After padding with zeros, the length is strictly equal to the preset number of bits, avoiding encoding errors due to inconsistent lengths. The conversion results are recorded in the "Encoding Preprocessing Log," allowing users to view the binary conversion process for each coordinate and easily troubleshoot encoding anomalies.

[0045] Alternating truncation and combination is the core step in converting two-dimensional coordinates to one-dimensional encoding. The specific process is as follows: Truncation order: Truncate the first bit of the x-coordinate binary number from the highest bit to the lowest bit, then truncate the first bit of the y-coordinate binary number, and so on, until all binary bits are truncated. Combination rule: The truncated binary bits are concatenated sequentially in the truncation order to form a continuous intermediate binary code. The code length is equal to twice the preset number of bits (x and y coordinates each occupy a preset number of bits). To avoid different coordinates generating the same intermediate binary code, after combining to form the intermediate binary code, the horizontal and vertical components of the standardized coordinates are added together, and the last 3 bits of the sum are taken as check bits and concatenated to the end of the intermediate binary code to form an intermediate code with check bits, improving the uniqueness of the code by 8 times. This process is automatically executed by the encoding algorithm module, with an execution efficiency of no less than 1000 times / second, ensuring the real-time generation of batch trade location codes.

[0046] The preset unit length is a fixed rule for splitting the intermediate binary code, with two splitting modes available through the "Code Splitting Configuration Interface": 2-bit splitting mode: Splits the intermediate binary code into 2-bit segments, each binary unit corresponding to a decimal digit from 0 to 3. The encoded string consists of 0, 1, 2, and 3, resulting in a shorter code length suitable for large-scale trade maps. 4-bit splitting mode: Splits the intermediate binary code into 4-bit segments, each binary unit corresponding to a decimal digit from 0 to 15. The encoded string consists of 0 to 9 and AF, offering higher encoding precision suitable for smaller-scale trade maps. Decimal conversion uses the general logic of binary to decimal conversion. Each binary unit is converted independently and then concatenated sequentially according to the splitting order to form the final Morton code. If invalid binary units appear during the conversion process (e.g., the split length is less than the preset unit length), the system automatically pads the end with 0s to ensure code integrity.

[0047] Conflict Detection: After the initial Morton code is generated, the system automatically queries the distributed cache for stored codes. If a code is found to be duplicated (i.e., different coordinates correspond to the same code), conflict resolution is immediately triggered. Resolution Logic: A differentiating identifier (value range 0-7) is added to the end of the duplicate code. The identifier is allocated according to the "first-come, first-served" principle. The first trade location to use the code has an identifier of 0, and subsequent conflicting trade locations increment the identifier sequentially to ensure that the Morton code for each trade location is unique. Identifier Maintenance: The differentiating identifier is stored in association with the unique identifier of the trade location. When a trade location is deleted or the coordinates are updated, causing a code change, the corresponding identifier is released for subsequent use to avoid exhausting the identifier.

[0048] The association between Morton codes and unique trade location identifiers is stored in key-value pairs, with the following storage architecture: Storage medium: A distributed caching system (such as a Redis cluster) is used, supporting high-concurrency read and write operations with a response time of no more than 10 milliseconds; Storage structure: The key is the Morton code, and the value is a list of unique trade location identifiers (when the same code corresponds to multiple trade locations, they are sorted by trade location type, with relay locations first and destination locations last); Index construction: An index is built based on Morton code prefixes, allowing for fast queries by prefix. Queries only need to traverse nodes matching the prefix, eliminating the need for a full scan, significantly improving retrieval efficiency; Update mechanism: When trade location coordinates are updated, Morton codes are synchronously regenerated, the association between the original code and the trade location identifier is deleted, and a new association is established, ensuring real-time matching between codes and locations. The associated storage status is visualized through the "Code Storage Monitoring Interface," including indicators such as code distribution, the number of associated trade locations, and storage space usage. Users can manually clean up invalid codes (such as records where the trade location has been deleted but the code has not).

[0049] When the search radius is large and crosses multiple Morton code boundaries, relying solely on adjacent nodes for completion may result in insufficient coverage. Optimization through correction parameters is necessary: ​​Correction parameter calculation: Correction parameter = Search radius ÷ Spatial side length of a single coding unit (the spatial side length of a single coding unit is the side length of the spatial range corresponding to the current prefix length). The larger the ratio, the stronger the correction. Expanding the search range: When the correction parameter > 2, in addition to searching directly adjacent nodes (with a difference of 1 bit at the end of the coding prefix), secondary adjacent nodes (with a difference of 2 bits at the end of the coding prefix) are also searched to ensure coverage of all target trade locations crossing boundaries. Efficiency optimization: Trade locations retrieved from secondary adjacent nodes are weighted according to their distance from the center coordinates; the farther the distance, the lower the weight. Trade locations with a weight below 0.2 are automatically removed to avoid over-expansion leading to decreased search efficiency. Parameter adaptation: The correction parameter can be manually adjusted through the "Ccoding Boundary Configuration Interface." Users can preset adaptation values ​​based on map coding density and common search radii to balance coverage integrity and search efficiency.

[0050] The core value of Morton code generation lies in three aspects: First, it compresses two-dimensional spatial coordinates into one-dimensional strings, significantly reducing storage overhead. Compared to the original coordinate storage, the storage space occupied is reduced by more than 60%. Second, by matching the encoding prefixes, the spatial proximity of trade locations can be quickly determined. Trade locations with the same prefix are in the same spatial area, providing a core basis for multi-way search tree aggregation storage. Third, the encoding structure is simple, facilitating rapid comparison and retrieval, and improving the response speed of location requests.

[0051] Specifically, the construction process of the multi-way search tree storage system and the hot and cold partitioning is as follows: A multi-way search tree storage structure is constructed based on the prefix length of the Morton code, with each node of the multi-way search tree corresponding to a set of Morton codes with the same prefix; the Morton codes associated with trade locations are extracted, and the encoded prefix is ​​truncated according to a preset prefix length. Trade locations with the same encoded prefix are aggregated and stored in the corresponding node of the multi-way search tree; a location update frequency statistical period is set, and the number of spatial coordinate updates for each trade location within the statistical period is counted in real time; each node of the multi-way search tree is divided into a hot storage area and a cold storage area. The hot storage area uses a memory-first storage method, and the cold storage area uses a disk cache storage method; trade locations whose spatial coordinate updates reach a preset update threshold within the statistical period are assigned to the hot storage area of ​​the corresponding node, and trade locations whose spatial coordinates are not updated within the statistical period are assigned to the cold storage area of ​​the corresponding node, establishing an association index between the storage areas and the trade locations.

[0052] The detailed description of the construction and hot / cold partitioning of the multi-way search tree storage system is as follows: The multi-way search tree storage structure is based on the number of Morton code prefix bits as the hierarchical basis, and the construction process is executed automatically. Multi-way search trees include binary trees, quadtrees, and octrees. In this application, a quadtree is used as an example. The specific details of the quadtree storage system construction and hot / cold partitioning are as follows: Hierarchical rules: The levels of the quadtree correspond one-to-one with the number of Morton code prefix bits. The root node (level 0) corresponds to an empty prefix, covering the entire map range; level 1 corresponds to a 1-bit encoding prefix, with a total of 4 nodes (corresponding to prefixes 0, 1, 2, and 3 respectively); level 2 corresponds to a 2-bit encoding prefix, with a total of 16 nodes; and so on. The deeper the level, the smaller the spatial range corresponding to the node, and the fewer the number of aggregated trade locations; Node capacity: Each node has a preset maximum threshold for storing the number of trade locations. If the number of trade locations exceeds the threshold, the node is automatically split into four child nodes by adding 1 bit extension (value 0-3) to the end of the Morton code prefix. The trade locations in the original node are automatically allocated to the corresponding child nodes according to their own encoding prefix. The splitting process does not interrupt the retrieval service, only pausing the write operation of the node; the use of the four-way splitting method is based on Morton code... The quadtree adaptation feature of the code ensures that each bit extension of the encoding prefix corresponds to exactly four possible values ​​(0-3), which perfectly matches the four-branch structure of the quadtree. This ensures that the spatial range of child nodes after splitting is non-overlapping and non-omitted, and the trade location allocation logic is consistent with the encoding prefix rules, requiring no additional adaptation calculations. Construction efficiency: The construction time of the quadtree for small-scale trade maps is no more than 1 second, for medium-scale maps no more than 3 seconds, and for large-scale trade maps no more than 5 seconds. After construction, the tree structure is displayed through the "Storage Structure Monitoring Interface", and users can expand to view the trade location storage status of each node.

[0053] Delay control mechanism: A maximum delay threshold of 50 milliseconds is set for priority retrieval of the hot storage area. This threshold can be adjusted according to the trade scenario through the "Retrieval Configuration Interface". If the retrieval time of the hot storage area exceeds the threshold, parallel retrieval of the cold storage area is immediately started to avoid timeout in the retrieval response of low-frequency trade locations. Synchronous verification mechanism: After the hot storage area retrieval is completed, the cold storage area fast verification is automatically triggered. Only the cold storage area of ​​the quadtree node corresponding to the target encoding prefix is ​​retrieved. There is no need for full traversal. The verification process only extracts the trade location coordinates and unique identifier, calculates the actual straight-line distance between it and the center coordinates, and includes trade locations that meet the search radius requirements into the candidate set to ensure that geographically proximate low-frequency trade locations are not missed. Dynamic adjustment mechanism: Real-time correlation with server load (CPU utilization, memory usage). When CPU utilization > 80% or memory usage > 85%, the priority of hot storage area retrieval is temporarily reduced, and hot and cold storage areas are retrieved synchronously. When the load < 50%, the priority of hot storage area is maintained, but synchronous verification is retained to balance retrieval efficiency and coverage integrity.

[0054] The preset prefix length is a key parameter for aggregated storage of trade locations, strongly correlated with the quadtree level and node capacity. Its value ranges from 4 to 8 bits, with the following configuration rules: A longer prefix length results in a smaller spatial range corresponding to the node, fewer aggregated trade locations, and higher retrieval efficiency, but also more quadtree levels and slightly increased storage overhead. A shorter prefix length results in a larger spatial range corresponding to the node, more aggregated trade locations, and slightly lower retrieval efficiency, but fewer quadtree levels and lower storage overhead. Parameter configuration is achieved through the "Quadtree Configuration Interface." Users can dynamically adjust the parameter based on the trade location density. The system will calculate the adjusted node load and retrieval efficiency in real time and provide adjustment suggestions. For example, when the trade location density is high, it is recommended to increase the prefix length to reduce the load on individual nodes; when the trade location density is low, it is recommended to decrease the prefix length to simplify the quadtree structure.

[0055] The location update frequency statistics period is a core parameter for distinguishing the dynamic characteristics of trade locations. The default value is 2-5 seconds, which users can manually adjust through the "Frequency Statistics Configuration Interface," and the adjustment takes effect immediately. Statistics range: Only coordinate updates of trade locations within the map boundary are counted; updates outside the boundary are not included. Statistics precision: Coordinate update timestamps are recorded at the millisecond level to ensure accurate results and avoid omissions or duplicates. Result storage: Statistical results are stored in the trade location status table, associated with a unique trade location identifier. The storage period is 24 hours; expired results are automatically cleared, releasing storage resources. The choice of statistics period needs to balance accuracy and performance overhead. A period that is too short can easily lead to misjudgments of relay locations, while a period that is too long cannot respond promptly to changes in trade location status.

[0056] The preset update frequency threshold is the criterion for determining hot and cold zones, with a value range of 2-5 times. It is configured differently according to the trade location type: For relay locations: the threshold is set to 2-3 times. The coordinate update frequency of relay locations in cross-border trade planning follows a Poisson distribution with λ=2, and the probability of P(X≥2) (≥2 updates within 3 seconds) reaches 73.5%, effectively distinguishing relay locations after route changes from trade locations before route changes. For destination locations: the threshold is set to 4-5 times. The coordinate update frequency of destination locations follows a Poisson distribution with λ=0.5, and the probability of P(X≥4) is only 0.2%, minimizing the risk of destination locations being mistakenly assigned to the hot storage area and avoiding partitioning errors caused by accidental updates. Threshold configuration is achieved through the "Partition Threshold Configuration Interface." After configuration, the system automatically generates a partitioning rule table, recording the threshold standards for different trade location types. For example, with a statistical period of 3 seconds, when the relay location threshold is set to 2 times, relay locations with at least 2 coordinate updates within 3 seconds are assigned to the hot storage area, while those without updates are assigned to the cold storage area.

[0057] The hot and cold storage areas employ differentiated storage strategies to ensure efficient utilization of storage resources: Hot storage area: uses an in-memory database (such as Redis) to store trade locations as frequently updated relay locations, allowing for random read / write operations to ensure fast retrieval of trade location data during searches; Cold storage area: uses a hybrid storage of disk cache and SSDs to store trade locations as endpoint locations, primarily using sequential read / write operations to reduce storage costs; Partition switching: Dynamic switching between hot and cold storage areas allows for automatic migration to the hot storage area when the number of trade location coordinate updates in the cold storage area reaches a threshold; when a trade location in the hot storage area has no updates for two consecutive statistical periods, it automatically migrates to the cold storage area. The switching process does not affect the response to location requests.

[0058] The associated index is a mapping table that records the relationship between "code prefix - node - storage area - trade location identifier". Its core design is as follows: Index structure: A B+ tree index is used for fast queries by code prefix, with a query efficiency of no more than 8 milliseconds; Index updates: Executed synchronously with the trade location storage. When the trade location storage location changes (e.g., migrated to another node, switched storage areas), the index is updated in real time to ensure consistency between the index and the storage state; Index maintenance: The system automatically performs index optimization (e.g., defragmentation, redundant deletion) every morning to improve query efficiency; Users can manually rebuild the index through the "index management interface". When the index query efficiency is lower than a preset threshold (e.g., exceeding 10 milliseconds), the system will display an optimization prompt.

[0059] This step utilizes spatial aggregation and differentiated storage. First, it aggregates trade locations by spatial location using a multi-way search tree structure, avoiding a full traversal of all trade locations and thus improving retrieval efficiency. Second, it allocates storage resources based on the characteristics of trade locations using hot and cold partitioning, prioritizing memory for frequently updated trade locations and using disk cache to carry the final location, balancing retrieval speed and storage costs, and providing efficient storage support for subsequent accurate positioning.

[0060] Specifically, the process for optimizing retrieval accuracy is as follows: Obtain the search radius parameter from the location request; use an exponential index optimization algorithm to establish a mapping relationship between the search radius and the Morton code prefix length; calculate the target prefix length corresponding to the current search radius based on the mapping relationship, as the search radius and prefix length are negatively correlated; based on the calculated target prefix length, extract the prefix portion of the Morton code corresponding to the center coordinates to form the target encoding prefix; if the number of matching nodes deviates from the suitable range during the retrieval process, dynamically fine-tune the target prefix length and re-match the nodes until the number of matching nodes is within the preset optimal retrieval range, thus achieving dynamic optimization of retrieval accuracy.

[0061] The exponential index optimization algorithm is the core of constructing the mapping relationship between the search radius and the prefix length. The algorithm logic is based on the correlation between the prefix length and spatial range of Morton codes: for every 1-bit increase in the prefix length, the corresponding spatial range shrinks to one-quarter of its original size, thus adapting to a quadtree. The specific mapping logic is as follows: Baseline setting: A preset base prefix length (e.g., 6 bits) and corresponding base spatial range (e.g., a 6-bit prefix corresponds to 100 trade units) serve as the base for the mapping relationship; Dynamic generation logic of the mapping table: The mapping table is automatically generated based on a geometric progression. The core generation rule is "for every 1-bit increase in prefix length, the corresponding spatial range shrinks to one-quarter of the previous bit; for every 1-bit decrease in prefix length, the corresponding spatial range expands to four times the previous bit." The specific generation steps are: starting from the base prefix length and base spatial range, proceed forward (prefix length decreases): for every 1-bit decrease in prefix length, the spatial range is multiplied by 4, until the maximum search radius is covered; proceed backward (…). Prefix length increase: For each additional prefix bit, the spatial range is divided by 4 until the spatial range is less than the minimum search radius; Generate mapping table entries: Each entry contains "search radius range - corresponding prefix length", and so on; Non-square map correction method: For non-square maps (different number of grids on the x-axis and y-axis), the spatial range coefficients in the x and y directions need to be calculated separately. The correction logic is: calculate the spatial range coefficient in the x-direction = total number of grids on the x-axis of the map ÷ total number of grids on the y-axis of the map; The candidate prefix length is initially calculated according to the square map rules; If the spatial range coefficient in the x-direction is >1 (the x-axis is longer), the candidate prefix length is increased by 1 bit; If the spatial range coefficient in the x-direction is <1 (the y-axis is longer), the candidate prefix length remains unchanged, while the retrieval range of adjacent nodes in the x-direction is expanded to ensure the complete coverage of the search radius in the long axis direction. Mapping Derivation: When the search radius is greater than the basic spatial range, the prefix length is less than the basic length; the larger the radius, the shorter the prefix length. When the search radius is less than the basic spatial range, the prefix length is greater than the basic length; the smaller the radius, the longer the prefix length. Dynamic Mapping Table Update Mechanism: The mapping table is strongly correlated with the route map size. When users modify map dimensions, grid density, and other parameters through the "Map Grid Configuration Interface," the system automatically recalculates the basic spatial range and geometric progression derivation results, updating the mapping table entries without manual intervention, ensuring the mapping relationship always accurately adapts to the current map. Algorithm Execution: The algorithm execution efficiency does not exceed 2 milliseconds per request, allowing for batch retrieval requests to be processed in parallel, ensuring fast response times in high-frequency retrieval scenarios. The algorithm prioritizes fast matching through the preset mapping table; when the range exceeds the mapping table's limit, it dynamically calculates based on geometric progression rules.

[0062] Setting an optimal search interval is a key parameter for balancing search efficiency and coverage. The value should range from 5 to 15 nodes, with the following configuration rules: High-performance servers: set the interval to 5-10 nodes to prioritize search speed; Low-performance servers: set the interval to 10-15 nodes to prioritize coverage. Interval configuration is achieved through the "Search Interval Configuration Interface." After configuration, the system automatically monitors the number of matching nodes during the search process. If the number of nodes in 10 consecutive searches exceeds the interval, a warning will pop up, prompting adjustments to the interval parameters or server configuration. Setting the optimal search interval should avoid two extremes: too many nodes will increase traversal overhead (e.g., traversing 20 nodes one by one), leading to search delays; too few nodes may miss target trading locations (e.g., matching only 3 nodes, failing to cover parts of the search radius).

[0063] Dynamic fine-tuning is a supplementary mechanism for optimizing retrieval accuracy. The fine-tuning rules are clear and configurable: Fine-tuning trigger condition: The number of matching nodes exceeds the upper limit of the interval or falls below the lower limit of the interval during retrieval; Fine-tuning step size: The prefix length is increased or decreased by 1 bit each time, avoiding excessive adjustment that could cause significant changes in the retrieval range; For non-square maps, the prefix length correction corresponding to the long axis is adjusted first during fine-tuning. For example, for maps with a longer x-axis, the prefix length is increased or decreased first during fine-tuning to adapt to the x-axis coverage requirements, ensuring that target trade locations are not missed in the long axis direction; Fine-tuning limit: A maximum of 3 fine-tuning operations can be performed. If the optimal interval is not reached after 3 fine-tuning operations, the default prefix length is used to ensure that the retrieval does not fall into an infinite loop; Fine-tuning record: The fine-tuning process is recorded through the "retrieval log interface," including information such as the prefix length before adjustment, the number of matching nodes, and the prefix length after adjustment. For example, if the preset optimal retrieval range is 5-10 nodes, and the number of matched nodes during retrieval is 16 (exceeding the upper limit), then the prefix length is increased by 1 bit, and nodes are rematched; if the number of matched nodes is 3 (below the lower limit), then the prefix length is decreased by 1 bit, and nodes are rematched, until the number of nodes is within the range.

[0064] To avoid the limitations of the preset mapping table, the algorithm supports dynamically calculating the prefix length corresponding to the search radius that exceeds the range of the mapping table: when the search radius is greater than the maximum coverage range of the mapping table, iterative derivation is performed according to the rule that "for every 1 bit decrease in prefix length, the spatial range expands by 4 times"; when the search radius is less than the minimum coverage range of the mapping table, iterative derivation is performed according to the rule that "for every 1 bit increase in prefix length, the spatial range shrinks by 4 times". There is no need to manually expand the mapping table, which can adapt to the positioning requirements of any reasonable search radius.

[0065] This step addresses the issue of a fixed prefix length failing to accommodate different search ranges by dynamically adapting the search radius and prefix length: a longer prefix length is used for small-range searches to accurately match a small number of nodes and improve search accuracy; a shorter prefix length is used for large-range searches to match multiple nodes and ensure coverage. Simultaneously, the optimal search interval and dynamic fine-tuning mechanism further balance search efficiency and accuracy, ensuring that location requests in different scenarios can be responded to quickly and accurately.

[0066] Specifically, the process of expanding the effective direction is as follows: Determine the basic directions for expanding the effective direction, which are up and down, left and right, and the four diagonal directions; obtain the position of the center coordinates in a unified coordinate system, and calculate the vertical distance from the center coordinates to the four boundaries of the route map; compare each vertical distance with the preset boundary thresholds, and automatically prune the expansion directions that exceed the range of the route map; for the remaining effective expansion directions, sequentially search the multi-way search tree nodes associated with the target coding prefix in each direction to expand the search coverage and ensure the comprehensiveness of the search for nearby trade locations.

[0067] The detailed specifications for effective directional expansion are as follows: The basic directions are eight fixed spatial directions: up, down, left, right, upper left, upper right, lower left, and lower right, covering all spatial areas surrounding the central coordinates to ensure no direction is missed. Directional Identifiers: Each direction is assigned a unique identifier code (e.g., "up" corresponds to code 01, "down" to code 02) for easy system identification and retrieval. Directional Angles: Preset angle ranges for each direction, such as "up" corresponding to 90°±22.5° and "upper right" corresponding to 45°±22.5°, ensuring accurate determination of trade location directions. Customization Support: Users can adjust the direction angle range through the "Directional Configuration Interface" to adapt to special map shapes (e.g., circular maps, diamond-shaped maps). After adjustment, the system automatically updates the directional identifiers and retrieval logic.

[0068] Vertical distance calculation uses a coordinate difference algorithm, with the core logic as follows: Boundary parameter acquisition: The extreme coordinate values ​​of the four boundaries (minimum x-value of the left boundary, maximum x-value of the right boundary, minimum y-value of the upper boundary, and maximum y-value of the lower boundary) are read from the map configuration file. For non-rectangular maps, the core boundary parameters are read (the center coordinates and radius of the circular map are read, and the coordinates of the diagonal endpoints are read for the rhombus map) to ensure accurate calculation. Calculation process: Rectangular map: When the center coordinates are (x0, y0), the distance to the left boundary is the difference between x0 and the minimum x-value of the left boundary; the distance to the right boundary is the difference between the maximum x-value of the right boundary and x0; the distance to the upper boundary is the difference between y0 and the minimum y-value of the upper boundary; and the distance to the lower boundary is the difference between the maximum y-value of the lower boundary and y0. Circular map: When the center coordinates are (x0, y0), the map center is (cx, cy), and the radius is r, the distance calculation steps to the map boundary are: Step 1... The calculation process involves six steps: First, calculate the difference between the center coordinates and the map center in the horizontal direction. Second, calculate the difference in the vertical direction. Third, square both differences. Fourth, sum the squared results. Fifth, take the square root of this sum to obtain the straight-line distance between the two points. Sixth, subtract this straight-line distance from the map radius. A final result greater than or equal to 0 indicates the point is inside the map, and less than 0 indicates it is outside the map. For a rhombus-shaped map: with center coordinates (x0, y0), the intersection of the map diagonals (dx, dy), a long diagonal length of 2a, and a short diagonal length of 2b, the distance to the boundary is the smaller of "half the length of the long diagonal minus the horizontal distance between the center coordinates and the intersection" and "half the length of the short diagonal minus the vertical distance between the center coordinates and the intersection." Calculation precision: The results are rounded to integers and are in trading units. The calculation efficiency is no more than 1 millisecond per calculation to ensure fast distance calculation and avoid affecting search response speed. The calculation results are stored in a temporary cache, used only for this direction expansion judgment, and automatically cleared after the search is completed to avoid consuming storage resources.

[0069] The preset boundary threshold is the criterion for directional clipping, and its value is 1.2-1.5 times the search radius. Users can manually adjust it through the "Boundary Threshold Configuration Interface," and the adjustment takes effect immediately. Threshold Adaptation: When the search radius changes dynamically, the boundary threshold is adjusted proportionally to ensure that the threshold and search radius always maintain an adaptive relationship. Clipping Logic: When the vertical distance from the center coordinate to a boundary is less than the boundary threshold, it is determined that the expansion in that direction may exceed the map range, and the direction and its two adjacent diagonal directions are automatically clipped. When the vertical distance is greater than or equal to the boundary threshold, the expansion permission for that direction is retained. For example, if the search radius is 50 trade units and the boundary threshold is set to 1.2 times (i.e., 60 trade units), if the distance from the center coordinate to the left boundary is 50 trade units (less than 60), the left, upper left, and lower left directions are clipped to avoid searching invalid nodes outside the map; if the distance to the right boundary is 70 trade units (greater than 60), the expansion permission for the right, upper right, and lower right directions is retained.

[0070] The valid direction retrieval adopts a "direction-node" association query mechanism, with the following specific process: Association Node Matching: For each valid direction, the system automatically queries the multi-way search tree nodes associated with the target encoding prefix. The association rule is "the spatial range corresponding to the direction overlaps with the spatial range of the node"; Retrieval Order: Retrieval is performed in the order of "up → down → left → right → upper left → upper right → lower left → lower right" to ensure that each valid direction can be traversed; Parallel Processing: Multi-directional parallel retrieval is adopted, with a retrieval speed of no less than 20 nodes / second. The retrieval results are summarized in real time to the candidate trade location set, sorted by trade location type (relay locations first, destination locations last). If a direction has no associated nodes during the retrieval process, the system automatically skips that direction and continues to search the next valid direction, avoiding unnecessary waiting and improving retrieval efficiency.

[0071] This process combines 8-way full coverage expansion with intelligent boundary trimming to achieve two main goals: first, to solve the problem of limited coverage of a single node by expanding the search scope from the central node to surrounding related nodes, ensuring that no cross-regional trade locations are missed; and second, to reduce unnecessary node traversal by eliminating invalid directions through boundary trimming, thereby reducing search overhead and balancing coverage integrity and search efficiency.

[0072] Specifically, the process of code boundary completion is as follows: Identify the neighboring nodes of the multi-way search tree node corresponding to the target code prefix. The neighboring nodes are nodes whose code prefixes differ only in the last bit. Perform supplementary retrieval on the neighboring nodes and extract the spatial coordinate data of the trade location stored in the neighboring nodes. Calculate the actual straight-line distance between the trade location obtained from the supplementary retrieval and the center coordinates. Include the trade locations whose actual straight-line distance is less than or equal to the search radius into the candidate trade location set to eliminate the retrieval blind spot across the code prefix boundary and ensure the integrity of the positioning coverage.

[0073] The detailed content of the encoding boundary completion is as follows: Adjacent node identification uses a prefix difference matching algorithm. The core logic focuses on the difference in the last bit of the encoding prefix. The specific rules are as follows: Identification condition: Two nodes are considered adjacent nodes only if their Morton code prefixes are completely identical except for the last bit. For example, if the target node's prefix is ​​"1234", then nodes with prefixes "1230", "1231", "1232", "1233", "1235", etc., differing only in the last bit, are all adjacent nodes. Identification scope: Limited to nodes at the same level as the target node in the multi-way search tree. Nodes at different levels are not considered adjacent nodes even if their prefixes differ in the last bit. Identification efficiency: The identification speed is no less than 3 milliseconds per node. Multiple adjacent nodes are identified in batches, and the identification results are stored in a temporary list for subsequent supplementary retrieval. During the identification process, if the target node is an edge node of the multi-way search tree (e.g., the prefix last bit is 0, and there are no nodes with smaller last bits), non-existent adjacent nodes are automatically skipped to avoid invalid identification.

[0074] Supplementary retrieval is the core step in code boundary completion. The retrieval strategy is consistent with the retrieval logic of effective direction expansion, and the specific details are as follows: Retrieval priority: Prioritize the hot storage area of ​​adjacent nodes, then retrieve the cold storage area to ensure that frequently updated relay positions can be captured first; Retrieval content: Only extract the spatial coordinate data and unique identifier of the trade position in adjacent nodes, without extracting other redundant information (such as trade position attributes and status) to reduce data transmission overhead; Retrieval restrictions: The number of adjacent nodes for supplementary retrieval shall not exceed 8. If the number of adjacent nodes exceeds the limit, they shall be sorted according to their spatial distance from the target node, and the closest node shall be retrieved first; Retrieval speed: The retrieval speed shall not be less than 15 nodes / second, and the retrieval results shall be transmitted to the distance calculation module in real time to avoid data backlog.

[0075] The actual straight-line distance is calculated using Euclidean distance, with the following steps: First, obtain the spatial coordinates (x1, y1) of the supplementary search trade location and the coordinates (x0, y0) of the search center. Second, calculate the horizontal difference (the difference between x1 and x0) and the vertical difference (the difference between y1 and y0). Third, square both differences. Fourth, sum the squared results. Fifth, take the square root of the sum, which is the actual straight-line distance between the two coordinates. The calculation precision is maintained to one decimal place, and the unit is trade unit. The calculation efficiency is no more than 0.5 milliseconds per trade location, and batch parallel calculation of trade locations is supported to ensure rapid distance filtering.

[0076] Supplementary search for trade locations must meet distance criteria to be included in the candidate trade location set. The specific rules are as follows: Distance determination: Trade locations with an actual straight-line distance less than or equal to the search radius are directly included in the candidate set; trade locations with a distance greater than the search radius are automatically removed; Deduplication: If the supplementary search for trade locations has already been included in the candidate set through effective directional expansion, the system automatically deduplicates them to avoid duplicate statistics; Sorting rules: Trade locations included in the candidate set are sorted according to their distance from the center coordinates. The closer the distance, the higher the ranking, providing a priority basis for subsequent multi-dimensional filtering.

[0077] The core objective of code boundary completion is to eliminate retrieval blind spots caused by Morton code prefix division: Since code prefixes are divided according to spatial range, some trade locations may be within the search radius, but their actual locations may differ from the target prefix only in the last bit, making them undetectable through effective directional expansion. By supplementing retrieval with adjacent nodes and filtering by distance, these cross-border trade locations can be accurately captured. This step complements effective directional expansion, which addresses the coverage problem of "cross-regional nodes," while code boundary completion addresses the omission problem of "cross-code boundaries." Together, they ensure that no target trade locations within the search radius are missed.

[0078] Preset filtering dimensions are the core conditions for accurate trade location positioning, covering the core attributes of trade locations and providing precise filtering basis for cross-border trade planning. Specific details are as follows: Trade Location Type: Includes relay locations and destination locations. Each type is assigned a unique classification code. Developers can add new types (such as "temporary trade point" or "transit warehouse point") through the "Filtering Dimension Configuration Interface"; Level Range: Supports customizable level ranges for trade locations (such as levels 1-5, level 10 and above). Range settings are implemented through the "Level Range Configuration Interface," supporting input of a start and end level. The system automatically verifies the validity of the range (start level ≤ end level). Trade location levels are divided based on indicators such as traffic, scale, and service capacity; Interactive Status: Includes tradable, non-tradable, under maintenance, and high traffic congestion. Status labels are updated in real time by the trade location management system to ensure that the filtering results are consistent with the actual operational status of the trade location. Default configurations for each filtering dimension can be saved through the "Filter Template Management Interface" for quick recall, significantly improving filtering configuration efficiency.

[0079] The preset priority determines the execution order of the filtering dimensions. The default order is Trade Location Type → Level Range → Interaction Status, ensuring that core dimensions are filtered first, reducing the amount of data processing required for subsequent filtering and improving overall filtering efficiency. Sorting Logic: Dimensions with higher priority are filtered earlier. For example, "Relay Location" type trade locations are filtered first, then objects matching the level range are filtered within relay locations, and so on, completing the full-dimensional filtering sequentially. Configuration Method: Users can drag and drop to adjust the sorting order through the "Priority Configuration Interface." Adjustments take effect immediately, and the sorting results are permanently stored in the filtering rule table for subsequent retrieval requests. Priority Basis: Priority settings are based on the filtering efficiency of dimensions and trade planning needs. Filtering Trade Location Type and Level Range has the highest efficiency, quickly eliminating a large number of irrelevant trade locations. Filtering Interaction Status is the next most efficient. This sorting ensures both filtering speed and aligns with the core logic of "determine type first, then select level" in cross-border trade planning.

[0080] The system allows users to flexibly adjust filtering rules through a "custom filtering interface" to meet the diverse positioning and planning needs of cross-border trade. Specific functions include: Dimension Operations: Dynamically adding filtering dimensions (e.g., adding dimensions like "trade category," "transportation cost range," and "opening hours") and removing irrelevant dimensions (e.g., removing the "transit capacity" dimension when searching for destination locations); Priority Adjustment: Adjusting the priority order of dimensions via drag-and-drop; Rule Saving: Custom filtering rules can be named and saved as filtering templates in a template library, supporting subsequent direct calling, modification, and sharing to adapt to high-frequency, similar search needs; Access Control: The custom filtering function differentiates between multiple levels of permissions. Developers have full operation permissions such as adding, deleting, and adjusting priorities of dimensions; trade planning administrators can only adjust basic dimensions such as level ranges and interaction states; ordinary operators do not have custom permissions, ensuring the standardization of filtering rules.

[0081] The layered filtering adopts a pipelined processing logic, with a clear process and high efficiency, adapting to the high-concurrency retrieval needs of cross-border trade: Filtering process: Strictly following preset or custom priorities, it executes the first layer of filtering (trade location type) → the second layer of filtering (level range) → the third layer of filtering (interactive state). Each layer of filtering yields a subset of trade locations, and the data size gradually decreases with each filtering level, reducing subsequent processing overhead; Execution efficiency: Filtering efficiency is positively correlated with the number of candidate trade locations, supporting parallel filtering of large batches of trade locations, fully meeting the high-frequency location requests of cross-border trade; Filtering log: The entire filtering process is automatically recorded through the "Filtering Log Interface," including information such as filtering dimensions, filtering conditions, the number of filtering results at each level, and total time consumption. Developers can analyze filtering bottlenecks through log analysis and optimize filtering rules and dimension priorities.

[0082] Distance secondary verification is the ultimate guarantee of accurate positioning of trade locations, avoiding situations where some trade locations actually exceed the search radius due to cross-regional searches involving effective direction expansion and code boundary completion. The specific logic is as follows: Verification object: Distance verification is only performed on trade locations after multi-dimensional layer-by-layer filtering, significantly reducing the amount of verification data and improving verification efficiency; Verification method: The Euclidean distance calculation logic, which is completely consistent with code boundary completion, is adopted to unify the spatial distance judgment standard, ensuring the accuracy of verification results and avoiding positioning deviations caused by differences in calculation rules; Verification results: Trade locations with actual straight-line distances less than or equal to the search radius are retained and included in the final candidate trade location set, providing a valid basis for cross-border trade planning; Trade locations with distances greater than the search radius are directly eliminated, and information such as the reason for elimination, trade location identification, and actual distance exceeding the radius is recorded synchronously in the verification log for easy problem tracing; Verification warning: Under normal cross-border trade scenarios, the pass rate of distance secondary verification is no less than 95%. If the system detects that the pass rate is continuously lower than 90%, an warning will be automatically triggered, prompting relevant personnel to check the boundary threshold of effective direction expansion, the retrieval range of adjacent nodes for code boundary completion, and other parameter configurations to correct positioning deviations in a timely manner.

[0083] This step achieves a core transformation in trade location selection, moving from "full spatial coverage" to "precise attribute filtering." It provides high-quality candidate trade location data for cross-border trade planning, with three key values: First, by filtering irrelevant trade locations through multi-dimensional attributes, it eliminates issues such as mixed trade location types and inconsistent attributes caused by relying solely on spatial location, significantly improving the accuracy of trade location positioning and providing a valid basis for route planning and resource allocation. Second, it supports fully customizable filtering rules throughout the process, flexibly adapting to diverse cross-border trade planning scenarios (such as finding high-level relay stations within the search radius of allied factions, retrieving tradable endpoints of specific levels, and locating temporary trade points of neutral factions), meeting different trade planning needs. Third, through secondary distance verification, it ensures that the final candidate trade locations fully comply with spatial requirements, avoiding invalid trade locations from occupying planning resources and guaranteeing the rationality and scientific nature of cross-border trade route planning and trade node selection from a data perspective.

[0084] In the above setup, this application, by establishing a rule-based gridded route map, can completely eliminate boundary omissions in trade location retrieval during cross-border trade planning, thereby improving the accuracy of cross-border trade route planning. The core premise of trade planning is covering all valid trade locations within the search radius. However, the Morton code's prefix-based spatial division can lead to the omission of trade points whose physical locations are within the range but whose coded prefixes cross boundaries (e.g., a trade point with a matching distance in adjacent nodes 1235 of the target node prefix 1234). By matching the difference between the last two bits of the prefix to lock adjacent nodes at the same level, and then combining this with Euclidean distance filtering, these trade locations crossing coded boundaries can be accurately captured, thus achieving high-precision cross-border trade route planning. Simultaneously, it can avoid missing key trade points (such as core relay stations and high-traffic trade locations) due to search blind spots, ensuring that the basic data (i.e., trade location positioning) for trade route planning, resource allocation, and cost accounting is complete, thus eliminating inaccurate trade location positioning during cross-border trade planning from the source.

[0085] As shown in Figure 3, this application embodiment provides a cross-border trade planning device 200, including a control part 21 and a planning part 22. The cross-border trade planning device 200 can realize the planning of cross-border trade routes.

[0086] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0087] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A cross-border trade planning method, characterized in that, The method includes: acquiring spatial coordinate data of trade locations to build a regular gridded route map and determine a unified coordinate system; based on the unified coordinate system, performing binary cross-combination operations on the two-dimensional coordinates of the regular gridded route map, and then converting them to decimal format to generate a Morton spatial code that is fully compatible with the regular gridded route map; using the generated Morton code as the core index, building a multi-way search tree storage system; the trade location data are all aggregated and classified according to the association relationship of the Morton code encoding prefix, and stored in the corresponding nodes of the multi-way search tree storage system; at the same time, according to the update frequency of each trade location data, hot storage area and cold storage area are divided in each tree node to realize hierarchical storage management of data; after obtaining a search request containing the search center coordinates and the corresponding search radius, based on the multi-way search tree storage system, the search center coordinates are converted into the corresponding Morton code and the target encoding prefix is ​​extracted; during the search process, priority is given to matching trade locations with high-frequency spatial coordinate updates, and the Morton code is dynamically adjusted. The length of the code prefix optimizes retrieval accuracy. Combined with two core mechanisms, effective directional expansion and code boundary completion, it achieves full coverage of cross-regional target trade locations and accurate capture of targets missed at code boundaries. Finally, through multi-dimensional filtering, it accurately locates the spatial position of all target trade locations within the search radius.

2. The cross-border trade planning method according to claim 1, characterized in that, The specific construction process of the coordinate system is as follows: Spatial coordinates are collected for trade locations that require spatial positioning in cross-border trade planning to obtain initial coordinate data. Trade locations include relay locations and endpoint locations. A regular gridded route map is constructed based on preset size parameters, which are adapted to the needs of the trade scenario. A unified two-dimensional rectangular coordinate system is established, with preset vertices of the regular gridded route map set as the origin, and the horizontal and vertical directions set as the positive directions of the coordinate axes. This maps the initial coordinate data of the trade locations to the coordinate system, resulting in standardized coordinate data, where the coordinate values ​​are integers that conform to the map grid range. The standardized coordinate data is then associated and bound with the unique identifier of the corresponding trade location to form a coordinate-trade location association dataset, thus completing the establishment of the unified coordinate system.

3. The cross-border trade planning method according to claim 2, characterized in that, The process of obtaining the Morton code is as follows: Standardized coordinate data of the trade location is extracted from the coordinate-trade location association dataset. The x and y coordinates are converted into binary numbers of a preset number of bits, with high-order bits padded with 0s if necessary. The binary bits corresponding to the x and y coordinates are alternately extracted from the high-order bits to the low-order bits to form an intermediate binary code. The intermediate binary code is split into multiple binary units according to a preset unit length. Each binary unit is converted into a decimal number within a corresponding range. All decimal numbers are concatenated sequentially to generate a Morton code adapted to the trade scenario. The Morton code is associated with and stored as a unique identifier for the trade location.

4. The cross-border trade planning method according to claim 3, characterized in that, The specific process of dividing the hot storage area and the cold storage area through the multi-way search tree storage system is as follows: The multi-way search tree storage structure is constructed based on the prefix number of the Morton code as the hierarchical basis. Each node of the multi-way search tree corresponds to a set of Morton codes with the same prefix. Extract the Morton code associated with the trade location, truncate the encoded prefix according to the preset prefix length, and aggregate and store trade locations with the same encoded prefix to the corresponding node of the multi-way search tree; Set the location update frequency statistics period to count the number of times the spatial coordinates of each trade location are updated within the statistics period in real time; Within each node of the multi-way search tree, a hot storage area and a cold storage area are divided. The hot storage area uses a memory-first storage method, while the cold storage area uses a disk cache storage method. Trade locations whose spatial coordinates are updated a preset number of times within the statistical period are assigned to the hot storage area of ​​the corresponding node, while trade locations whose spatial coordinates are not updated within the statistical period are assigned to the cold storage area of ​​the corresponding node. An association index between the storage areas and the trade locations is established.

5. The cross-border trade planning method according to claim 4, characterized in that, The specific process for optimizing the retrieval accuracy is as follows: obtain the search radius parameter in the positioning request, and use the exponential index optimization algorithm to establish a mapping relationship between the search radius and the Morton code prefix length; calculate the target prefix length corresponding to the current search radius according to the mapping relationship, since the search radius and the prefix length are negatively correlated; based on the calculated target prefix length, extract the prefix part of the Morton code corresponding to the center coordinates to form the target encoding prefix; If the number of matching nodes deviates from the suitable range during the retrieval process, the target prefix length is dynamically adjusted and node matching is performed again until the number of matching nodes is within the preset optimal retrieval range, thereby achieving dynamic optimization of retrieval accuracy.

6. The cross-border trade planning method according to claim 5, characterized in that, The specific process of expanding the effective direction is as follows: Determine the basic direction for expanding the effective direction, which includes the up and down, left and right, and four diagonal directions; obtain the position of the center coordinates in a unified coordinate system, and calculate the vertical distance from the center coordinates to the four boundaries of the route map; compare each vertical distance with a preset boundary threshold, and automatically trim the expansion directions that exceed the range of the route map; for the remaining effective expansion directions, sequentially search the multi-way search tree nodes associated with the target encoding prefix in each direction to expand the search coverage and ensure the comprehensiveness of the search for nearby trade locations.

7. A cross-border trade planning method according to claim 6, characterized in that, The specific process of code boundary completion is as follows: Identify the neighboring nodes of the multi-way search tree node corresponding to the target code prefix. The neighboring nodes are nodes whose code prefixes differ only in the last bit. Perform supplementary retrieval on the neighboring nodes and extract the spatial coordinate data of the trade positions stored in the neighboring nodes. Calculate the actual straight-line distance between the trade positions obtained from the supplementary retrieval and the center coordinates. Include the trade positions whose actual straight-line distance is less than or equal to the search radius into the candidate trade position set to eliminate the retrieval blind spot across the code prefix boundary and ensure the integrity of the positioning coverage.

8. A cross-border trade planning method according to claim 7, characterized in that, The specific process of the multi-dimensional filtering is as follows: Preset multi-dimensional filtering dimensions, including trade location type, level range, faction affiliation, and interaction status; sort each filtering dimension according to preset priority; receive user-defined filtering instructions, including dynamically adding or removing filtering dimensions, and adjusting the priority order of each dimension; based on the sorted filtering dimensions, perform layer-by-layer filtering on the trade locations in the candidate trade location set, filtering out target type trade locations by trade location type, filtering out trade locations that meet level requirements by level range, and so on, completing the full-dimensional filtering; perform a secondary distance verification on the filtered trade locations, excluding trade locations that actually exceed the search radius, to obtain the final candidate trade locations.

9. A cross-border trade planning device, characterized in that, include: The system comprises a central control section and a planning section, wherein the planning section is used for cross-border trade route planning, the central control section is electrically connected to the planning section, and the central control section executes the cross-border trade planning method according to any one of claims 1 to 8 when receiving the route signal output by the planning section.

10. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored on the memory, the processor being configured to run the computer program to perform the cross-border trade planning method according to any one of claims 1 to 8.

Images