A cross-border trade planning method, device and electronic equipment

Abstract

This invention relates to a cross-border trade planning method, comprising: acquiring spatial coordinate data of trade locations to construct a regular gridded route map and determine a unified coordinate system; generating Morton spatial codes that are fully adapted to the regular gridded route map based on the unified coordinate system; constructing a multi-way search tree storage system, and based on the multi-way search tree storage system, converting the search center coordinates into corresponding Morton codes and extracting the target code prefix; prioritizing the matching of trade locations with frequently updated spatial coordinates during the search process, optimizing the search accuracy by dynamically adjusting the length of the Morton code prefix, and combining two core mechanisms—effective direction expansion and code boundary completion—to achieve full coverage of cross-regional target trade locations and accurate capture of targets missed at code boundaries, respectively. This invention also relates to a cross-border trade planning device and electronic device. Through the above settings, the accuracy of trade location positioning can be improved.

Description

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: a cross-border trade planning method, the method comprising: Acquire spatial coordinate data of trade locations to build a regular gridded route map and determine a unified coordinate system; Based on a unified coordinate system, binary cross-combination operations are performed on the two-dimensional coordinates of the regular gridded route map, and then converted to decimal format to generate Morton spatial encoding that is fully compatible with the regular gridded route map. Based on the generated Morton code as the core index, a multi-way search tree storage system is built. Trade location data are aggregated and classified according to the correlation of Morton code encoding prefixes and stored in the corresponding nodes of the multi-way search tree storage system. At the same time, based on 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 the retrieval request containing the coordinates of the retrieval center and the corresponding search radius, the retrieval center coordinates are converted into the corresponding Morton code and the target encoding prefix is ​​extracted based on the multi-way search tree storage system. During the retrieval process, trade locations with frequently updated spatial coordinates are prioritized for matching. At the same time, the retrieval accuracy is optimized by dynamically adjusting the length of the Morton code encoding prefix. Combined with two core mechanisms, effective direction expansion and encoding boundary completion, full coverage of cross-regional target trade locations and accurate capture of targets missed at encoding boundaries are achieved, respectively. Finally, after multi-dimensional filtering and screening, the spatial location of all target trade locations within the search radius is accurately locked.

[0007] Furthermore, the specific process of constructing 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 destination locations. A rule-based gridded route map is constructed based on preset size parameters, which are adapted to the needs of trade scenarios. A unified two-dimensional rectangular coordinate system is established, and the preset vertices of the regular gridded route map are set as the coordinate origin. The horizontal and vertical directions are set as the positive directions of the coordinate axes, so that the initial coordinate data of the trade location is mapped to the coordinate system to obtain standardized coordinate data, where the coordinate values ​​are integers that conform to the map grid range. By associating standardized coordinate data with unique identifiers corresponding to trade locations, a coordinate-trade location association dataset is formed, thus establishing a unified coordinate system.

[0008] Furthermore, the process of obtaining the Morton code is as follows: Extract standardized coordinate data of trade locations from the coordinate and trade location association dataset, and convert the x and y coordinates into binary numbers of a preset number of bits, padding the higher bits with 0 if the number of bits is less than the preset number of bits. The binary bits corresponding to the x and y coordinates are alternately extracted and combined in order from the most significant bit to the least significant bit to form the 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 corresponding range of decimal numbers. All decimal numbers are then 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 using a multi-way search tree storage system is as follows: A multi-way search tree storage structure is constructed based on the prefix number of Morton codes. 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 have been updated up to a preset threshold within the statistical period are assigned to the hot storage area of ​​the corresponding node, while trade locations whose spatial coordinates have not been 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.

[0010] Furthermore, the specific process for optimizing retrieval accuracy is as follows: Obtain the search radius parameter from the location request, and use the exponential index optimization algorithm to establish a mapping relationship between the search radius and the Morton code prefix length; The target prefix length corresponding to the current search radius is calculated based on the mapping relationship. The search radius and the prefix length are negatively correlated. Based on the calculated target prefix length, the prefix portion of the Morton code corresponding to the center coordinates is extracted 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.

[0011] Furthermore, the specific process of effective directional expansion is as follows: Determine the basic directions for effective directional expansion. The basic directions 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; Each vertical distance is compared with a preset boundary threshold, and the extended direction that exceeds the range of the route map is automatically cropped. For the remaining valid expansion directions, the multi-way search tree nodes associated with the target coding prefix in each direction are retrieved sequentially to expand the search coverage and ensure the comprehensiveness of the search for nearby trade locations.

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

[0013] Furthermore, the specific process of multi-dimensional filtering is as follows: The system allows for multi-dimensional filtering, including trade location type, level range, faction affiliation, and interaction status. Sort the filtering dimensions 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, the trade locations in the candidate trade location set are filtered layer by layer. The target type of trade location is filtered out by trade location type, and the trade locations that meet the level requirements are filtered out by level range. The full-dimensional filtering is completed in sequence. The selected trade locations are then subjected to a second distance check to exclude those that are actually outside the search radius, thus 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 This is a structural block diagram of an electronic device.

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

[0019] Figure 3 This 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 electronic device 100 or similar device. Figure 1 This is a hardware structure block diagram of an electronic device 100 that implements an embodiment of this application. For example... Figure 1 As shown, the electronic device 100 may include one or more ( Figure 1 (Only one is shown) memory 12 and processor 11. The electronic device 100 is a cross-border control terminal used to create a rule-based gridded route map that can be adapted 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 Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100 described above. For example, the electronic device 100 may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0028] like Figure 1 As shown, this invention discloses a cross-border trade planning method, which 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, dividing the land... Figure 2 The coordinates are combined using binary cross-combination and decimal conversion to generate Morton codes adapted to the rule-based gridded route map. Based on the Morton codes, a multi-way search tree storage system is constructed to aggregate and store trade locations in corresponding nodes according to the association relationship of the coded prefixes. The nodes are divided into hot storage areas and cold storage areas according to the update frequency of the trade locations. The system receives retrieval requests containing center coordinates and search radius, converts the center coordinates into Morton codes using the multi-way search tree storage system, extracts the target prefix, prioritizes matching trade locations with high-frequency spatial coordinate updates, optimizes retrieval accuracy by dynamically adjusting the length of the coded prefix, and captures target trade locations that are missed across regions and boundaries by combining effective directional expansion and coded boundary completion. After multi-dimensional filtering, the spatial location of the target trade location within the search radius is accurately located.

[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 destination locations. A regular gridded route map is constructed based on preset size parameters 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 conforming 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.

[0030] Specifically, the detailed process of constructing the coordinate system is as follows: Trade location is the core target entity in the location process, and it is divided into two categories based on its dynamic location characteristics, adapting to differentiated storage and retrieval strategies: Intermediate locations: These include the locations traversed from the initial location to the final location in a trade planning route. Trade location classification is automatically assigned 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 the core configuration items for regular gridded maps, dynamically adapting to the scale of the trade scenario and positioning requirements, and are specifically divided into three types of scenario templates: Small-scale cross-border trade maps: Preset size parameters adapt to trade between neighboring countries, with a high grid density to ensure near-field positioning accuracy; Medium-scale cross-border trade maps: Preset size parameters adapt to trade between neighboring continents, balancing positioning accuracy and server load; Large-scale cross-border trade maps: Preset size parameters adapt to trade spanning hemispheres, with a moderately reduced grid density, and optimized coding to ensure efficient large-scale retrieval. Parameter configuration is achieved through the "Map Grid Configuration Interface," which offers two configuration methods: one is to directly select a preset scene template, and the system automatically fills in the size parameters; the other is to manually input the number of grid rows, columns, and unit grid size, and then preview the map coverage and grid distribution in real time. Configuration requires verification of server hardware performance. If the parameters exceed the hardware's 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, and the acquisition logic is strongly correlated with the trade location type. The unified two-dimensional Cartesian coordinate system adopts an architecture combining a "vertex origin" and a "fixed axis direction," with design details as follows: Origin Selection: Three origin modes are available: top-left corner, bottom-left corner, and center point. Users select the origin through the "Coordinate System Configuration Interface." The top-left corner is used by default, aligning with the rendering logic of mainstream trade engines. Coordinate Axis Direction: A fixed setting of "horizontal to the right as the positive x-axis and vertical downward as the positive y-axis" ensures consistency with screen display logic and reduces coordinate transformation errors. Coordinate Value Constraints: Coordinate values ​​are limited to non-negative integers, with a value range consistent with the map grid range. This ensures that the coordinates of each trade location are accurately mapped to a unique grid cell, providing a standardized input for Morton codes. After coordinate system configuration, the system automatically generates a "Coordinate Mapping Reference Table," recording the conversion relationship between native and standardized coordinates. This allows users to easily export and view the table for troubleshooting.

[0033] The association and binding are achieved through a two-way mapping table of "coordinates-trade location", and the core logic is as follows: Binding Basis: A unique identifier for a trade location (including trade location ID and globally unique number) corresponds one-to-one with standardized coordinates, ensuring that trade location information can be quickly queried via coordinates and coordinate data can be quickly obtained via trade location identifiers; Storage Method: The mapping table is stored in an in-memory database (such as Redis), enabling millisecond-level query responses to meet the needs of high-frequency location requests; Maintenance Mechanism: When 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 binding relationships through the "Relationship Management Interface," including adding, unbinding, and modifying bindings, for easy 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: To address the differences in the baselines of the native coordinate systems at different trade locations (different origin positions and axial directions), the coordinate system units are first standardized, and then a precise mapping is achieved through a "three-step mathematical transformation." The specific transformation logic is as follows: First, perform a translation transformation. The first step is to obtain the corresponding coordinates of the origin of the original coordinate system in the unified coordinate system (called the "origin offset"). This is calculated as follows: subtract the horizontal component of the origin of the original coordinate system from the horizontal component of the target origin in 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 in the unified coordinate system to obtain the vertical offset. The second step is to subtract the horizontal component of the original origin from the horizontal component of the original coordinate system, and then 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 then add the vertical offset to obtain the translated vertical median value, thus aligning the origins.

[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 determination" and "sliding window weighted averaging" is adopted to ensure smooth coordinate transitions. The specific implementation is as follows: The jump judgment rules are as follows: First, set the jump threshold: using map grid cells as the unit, the jump threshold is set to 3 grid cells (derived from the document that "the coordinate error after standardization does 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 difference between the currently collected native coordinates and the previously calibrated coordinates is calculated, and the differences in the horizontal and vertical directions are counted 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 both directions does not exceed the threshold, the current transformed coordinates are directly used as the calibrated coordinates, and no compensation is required.

[0039] The specific details of the sliding window weighted average compensation are as follows: First, window data selection: Select the 5 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 collection time, 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 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 in the same way; Integer conversion: Round the horizontal and vertical weighted sums to the nearest integer to obtain the smoothed calibration coordinates; Fourth step, boundary verification: If the smoothed coordinates exceed the map range of the unified coordinate system, they are corrected according to the rule of "taking the upper limit value if it exceeds the upper limit, and taking the lower limit value if it exceeds the lower limit" to ensure that they meet the 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 Morton codes is as follows: Standardized coordinate data of trade locations are extracted from the coordinate and 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 less than the preset number. The binary bits corresponding to the x and y coordinates are alternately extracted in order from the highest bit to the lowest bit, and combined in a cyclical manner 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 in sequence to generate a Morton code adapted to the trade scenario. The Morton code is associated with and stored as 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 that determines the accuracy of Morton codes, and it is strongly correlated with map size and positioning accuracy requirements. The specific configuration standards are as follows: Small-scale cross-border trade maps: High positioning accuracy is required, with a preset bit depth of 14-16 digits. The spatial range corresponding to the code is relatively small, ensuring accurate differentiation of nearby trade locations. Medium-scale cross-border trade maps: A balance needs to be struck between positioning accuracy and retrieval efficiency, with a preset bit depth of 12-14 digits. Large-scale cross-border trade maps: A wide retrieval range requires reduced coding complexity, with a preset bit depth of 10-12 digits. The preset bit depth 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 an adjustment step of 1 bit to ensure configuration flexibility.

[0043] After generating the Morton code for the center coordinates according to the preset number of bits, the 8-neighbor code pre-generation process is executed simultaneously to construct a "center code - 8-neighbor code" mapping relationship to eliminate boundary blind spots caused by coding mutations. The specific steps are as follows: Encoding and 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 neighborhood regions in eight directions (up, down, left, right, upper left, upper right, lower left, and lower right) are calculated respectively, and the spatial range of each neighborhood region is completely consistent with the region corresponding to the center code; Neighborhood Code Generation: The Morton algorithm with the same preset number of bits is applied to the eight neighborhood 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 algorithm for integer to binary conversion, 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. Zero-padding rule: If the length of the converted binary number is less than the preset number of bits, 0s are padded 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), the preset number of bits is 12, and the converted binary number is 000001111011, the length after zero-padding 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, facilitating the troubleshooting of encoding anomalies.

[0045] Alternating cropping and combining is the core step in converting two-dimensional coordinates to one-dimensional encoding. The specific process is as follows: Extraction Order: Extracting the first bit of the x-coordinate binary number from the highest bit to the lowest bit, then the first bit of the y-coordinate binary number, and so on, until all binary bits are extracted. Combination Rules: The extracted binary bits are concatenated sequentially to form a continuous intermediate binary code. The code length is 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 forming 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 used as check bits. These check bits are then concatenated to the end of the intermediate binary code, forming an intermediate code with check bits, increasing the code's uniqueness 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 real-time generation of batch trade location codes.

[0046] The preset unit length is a fixed rule for splitting intermediate binary codes, and it has two splitting modes, which users can select through the "Encoding Split Configuration Interface": 2-bit splitting mode: The middle binary code is split into 2 bits, with each binary unit corresponding to a decimal digit from 0 to 3. The encoded string consists of 0, 1, 2, and 3. This mode has a shorter code length and is suitable for large-scale trade maps. 4-bit splitting mode: The middle binary code is split into 4 bits, with each binary unit corresponding to a decimal digit from 0 to 15. The encoded string consists of 0 to 9 and AF. This mode offers higher encoding precision and is suitable for small-scale trade maps. Decimal conversion uses the general logic of binary to decimal conversion. Each binary unit is converted independently and then concatenated in the order of splitting to form the final Morton code. If an invalid binary unit appears during the conversion process (e.g., the length after splitting is less than the preset unit length), the system automatically pads it with 0s at the end 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: Employs a distributed caching system (such as a Redis cluster), supporting high-concurrency read and write operations with a response time of no more than 10 milliseconds; Storage structure: Keys are Morton codes, and values ​​are a list of unique identifiers for trade locations (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: The 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 spans multiple Morton code boundaries, relying solely on adjacent nodes for completion can easily result in insufficient coverage, requiring optimization through correction parameters: 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 (difference of 1 bit at the end of the coding prefix), secondary adjacent nodes (difference of 2 bits at the end of the coding prefix) are searched to ensure coverage of all cross-boundary target trade locations. 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 lower than 0.2 are automatically removed to avoid excessive expansion that leads to a decrease in search efficiency. Parameter adaptation: The correction parameter can be manually adjusted through the "coding boundary configuration interface". Users can preset adaptation values ​​according to 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 / cold partitioning are 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 to count the number of spatial coordinate updates for each trade location within the statistical period 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, while 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, 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.

[0052] The detailed specifications of the multi-way search tree storage system construction and hot / cold partitioning are as follows: The multi-way search tree storage structure is hierarchically based on the number of Morton code prefix bits, and the construction process is automated. Multi-way search trees include binary trees, quadtrees, and octrees. In this embodiment, a quadtree is used as an example. The specific details of the quadtree storage system construction and hot / cold partitioning are as follows: Layering 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 area; level 1 corresponds to a 1-bit prefix, with a total of 4 nodes (corresponding to prefixes 0, 1, 2, and 3 respectively); level 2 corresponds to a 2-bit 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 trade locations. If the number of trade locations exceeds the threshold, a four-part split is automatically triggered. The original node is expanded by adding 1 bit (value 0-3) to the end of the Morton code prefix, splitting into 4 child nodes. The trade locations in the original node are automatically allocated to the corresponding child nodes according to their own prefixes. The splitting process does not interrupt the retrieval service, only pausing the write operation of that node. The four-part splitting method is based on Morton code prefixes. 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 trade location aggregation storage, and it is strongly related to the quadtree level and node capacity. The value range is 4-8 bits, and the specific configuration rules are as follows: A longer prefix length results in a smaller spatial range for the node, fewer aggregated trade locations, and higher retrieval efficiency, but also more quadtree levels and slightly increased storage overhead. Conversely, a shorter prefix length results in a larger spatial range for 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," allowing users to dynamically adjust the parameters based on trade location density. The system will calculate the adjusted node load and retrieval efficiency in real time and provide adjustment suggestions. For example, when trade location density is high, it is recommended to increase the prefix length to reduce the load on individual nodes; when 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 location. The default value is 2-5 seconds. Users can manually adjust it through the "Frequency Statistics Configuration Interface". The adjustment takes effect immediately. Statistical Scope: Only coordinate updates of trade locations within the map boundaries are counted; updates outside the boundaries are not included in the statistics. Statistical 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 to release storage resources. The choice of the statistical period needs to balance accuracy and performance overhead. A period that is too short may lead to misjudgments of relay locations, while a period that is too long may not be able to 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, configured differently according to trade location type: Relay Locations: With a threshold 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. Destination Locations: With a threshold 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 and a relay location threshold set to 2 times, relay locations with coordinate updates at least 2 times within 3 seconds are assigned to the hot storage area, while those without updates are assigned to the cold storage area.

[0057] Differentiated storage strategies are employed for hot storage areas and cold storage areas 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 random read and 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 and write operations to reduce storage costs; Partition switching: Dynamic switching between hot and cold storage areas is possible. When the number of trade location coordinate updates in the cold storage area reaches a threshold, it automatically migrates to the hot storage area; when the 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 location request response.

[0058] The association index is a mapping table that records the relationship between "encoding prefix - node - storage area - trade location identifier". The core design is as follows: Index Structure: A B+ tree index is used for fast queries based on the encoded prefix, with a query efficiency of no more than 8 milliseconds. Index Updates: The index is updated synchronously with the trade location storage. When the trade location storage location changes (such as migrating to other nodes or switching storage areas), the index is updated in real time to ensure that the index and storage status are consistent. Index Maintenance: The system automatically performs index optimization (such as defragmentation and redundant deletion) every day at midnight 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 (such as exceeding 10 milliseconds), the system will pop up 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 of optimizing retrieval accuracy is as follows: The search radius parameter in the location request is obtained, and an exponential index optimization algorithm is used to establish a mapping relationship between the search radius and the Morton code prefix length. The target prefix length corresponding to the current search radius is calculated based on the mapping relationship, and the search radius and prefix length are negatively correlated. Based on the calculated target prefix length, the prefix part of the Morton code corresponding to the center coordinates is truncated to form the target encoded prefix. If the number of matching nodes deviates from the suitable range during the retrieval process, the target prefix length is dynamically fine-tuned, and node matching is performed again until the number of matching nodes is in the preset optimal retrieval range, thereby 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 Morton code prefix length and the spatial range: for every 1 bit increase in the code prefix length, the corresponding spatial range shrinks to one-quarter of its original size, which is suitable for quadtrees. The specific mapping logic is as follows: Baseline setting: Preset the base prefix length (e.g., 6 bits) and the corresponding base space range (e.g., 6-bit prefix corresponds to 100 trade units) as the base for the mapping relationship; The mapping table is dynamically generated based on a geometric progression. The core generation rule is that "for every 1-bit increase in prefix length, the corresponding space range shrinks to one-quarter of the previous position; for every 1-bit decrease in prefix length, the corresponding space range expands to four times the previous position." The specific generation steps are as follows: Starting with the basic prefix length and basic spatial range, the algorithm proceeds 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; it then proceeds backward (prefix length increases): for every 1 bit increase in prefix length, the spatial range is divided by 4, until the spatial range is less than the minimum search radius; a mapping table entry is generated: each entry contains "search radius range - corresponding prefix length", and so on; non-square map correction method: for non-square maps (different numbers 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 x-direction spatial range coefficient = 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 x-direction spatial range coefficient > 1 (the x-axis is longer), the candidate prefix length is increased by 1 bit; if the x-direction spatial range coefficient < 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 the optimal search interval is a key parameter for balancing search efficiency and coverage. Its value ranges from 5 to 15 nodes, and the specific configuration rules are as follows: High-performance servers: Set the interval to 5-10 nodes to prioritize retrieval speed; Low-performance servers: Set the interval to 10-15 nodes to prioritize coverage. Interval configuration is achieved through the "Retrieval Interval Configuration Interface." After configuration, the system automatically monitors the number of matching nodes during the retrieval process. When the number of nodes in 10 consecutive retrievals exceeds the interval, a warning message will pop up, prompting adjustments to the interval parameters or server configuration. The optimal retrieval interval setting should avoid two extremes: too many nodes will increase traversal overhead (e.g., 20 nodes need to be traversed one by one), leading to retrieval delays; too few nodes may miss target trading locations (e.g., only 3 nodes are matched, 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 explicit and configurable. Fine-tuning trigger conditions: The number of matched nodes exceeds the upper limit 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 a fine-tuning is performed to avoid excessive adjustment that could cause significant changes in the retrieval range; For non-square maps, the prefix length correction along the long axis is prioritized during fine-tuning. For example, for maps with a longer x-axis, the prefix length is increased or decreased first to adapt to the x-axis coverage requirements, ensuring that target trade locations are not missed along the long axis; Fine-tuning limit: A maximum of 3 fine-tuning operations are 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 matched nodes, and the prefix length after adjustment. For example, if the preset optimal retrieval interval is 5-10 nodes, and the number of matched nodes during retrieval is 16 (exceeding the upper limit), the prefix length is increased by 1 bit, and nodes are rematched; if the number of matched nodes is 3 (below the lower limit), the prefix length is decreased by 1 bit, and nodes are rematched, until the number of nodes is within the interval.

[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 effective directional expansion is as follows: The system determines the basic directions for valid directional expansion, which are up / down, left / right, and the four diagonals. It obtains the position of the center coordinates in a unified coordinate system and calculates the vertical distances from the center coordinates to the four boundaries of the route map. It compares each vertical distance with a preset boundary threshold and automatically prunes expansion directions that exceed the range of the route map. For the remaining valid expansion directions, it sequentially searches 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.

[0067] A detailed description of the effective directional expansion is shown below: The basic directions are 8 fixed spatial directions: up, down, left, right, upper left, upper right, lower left, and lower right, covering all spatial areas around the center 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" corresponds to code 02) to facilitate system identification and retrieval; Directional Angles: The angle range for each direction is preset, such as "up" corresponding to 90°±22.5°, and "upper right" corresponding to 45°±22.5°, to ensure accurate determination of trade location direction; Customization Support: Users can adjust the directional angle range through the "Directional Configuration Interface" to adapt to special shaped maps (e.g., circular maps, diamond maps). After adjustment, the system automatically updates the directional identifiers and retrieval logic.

[0068] Vertical distance is calculated using a coordinate difference algorithm, with the core logic as follows: Boundary parameter acquisition: The extreme coordinates 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 (for circular maps, the center coordinates and radius are read; for rhomboid maps, the diagonal endpoint coordinates are read), ensuring 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 calculation steps for the distance to the map boundary are: First, calculate the distance between the center coordinates and the map center... The calculation process involves several steps: first, calculating the difference in the horizontal direction; second, calculating the difference in the vertical direction; third, squaring both differences; fourth, summing the squared results; fifth, taking the square root of the sum to obtain the straight-line distance between the two points; and sixth, subtracting this straight-line distance from the map radius. A final result greater than or equal to 0 indicates the point is inside the map, while a result 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: results are rounded to integers and are in units of trade. The calculation efficiency is no more than 1 millisecond per calculation to ensure fast distance calculation and avoid impacting search response speed. Calculation results are stored in a temporary cache, used only for this direction expansion judgment, and automatically cleared after the search is complete 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 effective direction retrieval adopts a "direction-node" association query mechanism, and the specific process is as follows: Associative 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." Search Order: The system searches in the order of "up → down → left → right → upper left → upper right → lower left → lower right" to ensure that each valid direction is traversed. Parallel Processing: Multi-directional parallel searching is employed, with a search speed of no less than 20 nodes / second. Search results are aggregated in real time to the candidate trade location set, sorted by trade location type (relay locations first, destination locations last). If no associated node is found in a certain direction during the search process, the system automatically skips that direction and continues searching the next valid direction, avoiding unnecessary waiting and improving search 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 coding prefix. The neighboring nodes are nodes whose coding prefixes differ only in the last bit. Perform supplementary retrieval on the neighboring nodes to 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 coding prefix boundary and ensure the integrity of the positioning coverage.

[0073] The detailed content of code 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 encoded prefix. The specific rules are as follows: Recognition criteria: Two nodes are considered adjacent only if their Morton code prefixes are 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. Recognition 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. Recognition efficiency: The recognition speed is no less than 3 milliseconds per node. Multiple adjacent nodes are identified in batches, and the results are stored in a temporary list for subsequent supplementary retrieval. During the recognition 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 a smaller last bit), non-existent adjacent nodes are automatically skipped to avoid invalid recognition.

[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: Search Priority: Prioritize searching the hot storage area of ​​adjacent nodes, then search the cold storage area, ensuring that frequently updated relay positions can be captured first; Search Content: Only extract the spatial coordinate data and unique identifier of trade positions among adjacent nodes, without extracting other redundant information (such as trade position attributes and status), reducing data transmission overhead; Search Limits: The number of adjacent nodes to be supplemented for retrieval is limited to a maximum of 8. If the number of adjacent nodes exceeds the limit, they are sorted by spatial distance from the target node, and the closest node is retrieved first; Search Speed: The search speed is no less than 15 nodes / second, and the search results are transmitted to the distance calculation module in real time to avoid data backlog.

[0075] The actual straight-line distance is calculated using Euclidean distance. The specific calculation steps are as follows: The first step is to obtain the spatial coordinates (x1, y1) of the supplementary search trade location and the coordinates (x0, y0) of the search center. The second step is to calculate the horizontal difference (the difference between x1 and x0) and the vertical difference (the difference between y1 and y0). The third step is to square both differences. The fourth step is to sum the squared results. The fifth step is to 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, 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] To be included in the candidate trade location set, supplementary search results must meet distance requirements. 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 trade locations retrieved have 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] like Figure 3 As shown, this application embodiment provides a cross-border trade planning device 200, including a control section 21 and a planning section 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: 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 unified two-dimensional rectangular coordinate system is established. The initial coordinate data of trade locations are mapped to the coordinate system through translation and scaling transformations to obtain standardized integer coordinate data that conforms to the map grid range. The standardized coordinate data is associated and bound with the unique identifier of the corresponding trade location to build a regular gridded route map and determine the unified coordinate system. Based on the unified coordinate system, binary cross-combination operation is performed on the two-dimensional coordinates of the regular gridded route map. The x and y coordinates are converted into binary numbers of a preset number of bits and zeros are padded to the high bits. The bits are alternately extracted and combined in order from high bits to low bits to form an intermediate binary code. After decimal format conversion, a Morton spatial code that is fully adapted to the regular gridded route map is generated. A multi-way search tree storage system is built based on the generated Morton code as the core index. The trade location data is aggregated and classified according to the association relationship of the Morton code encoding prefix and stored in the corresponding node of the multi-way search tree storage system. At the same time, according to the update frequency of each trade location data, a location update frequency statistical period is set to count the number of times the spatial coordinates of each trade location are updated in real time. Each tree node is divided into a hot storage area using memory-first storage and a cold storage area using disk cache storage. Trade locations whose update frequency reaches a preset threshold within the statistical period are assigned to the hot storage area, and trade locations without coordinate updates are assigned to the cold storage area, thereby realizing hierarchical storage management of data. After obtaining a retrieval request containing the coordinates of the retrieval center and the corresponding search radius, the retrieval center coordinates are converted into the corresponding Morton code and the target encoding prefix is ​​extracted based on the multi-way search tree storage system. During the retrieval process, high-frequency updated trade positions within the hot storage area are prioritized for matching. An exponential index optimization algorithm is used to establish a mapping relationship between the search radius and the Morton code prefix length to dynamically adjust the encoding prefix length and optimize retrieval accuracy. The exponential index optimization algorithm constructs a mapping relationship based on the exponential correlation between the Morton code prefix length and the spatial range. For every increase of one bit in the prefix length, the corresponding spatial range shrinks to one-quarter of the previous bit. The search radius is negatively correlated with the prefix length. During retrieval, the prefix length is dynamically fine-tuned according to the number of matching nodes until the number of matching nodes is within the preset optimal retrieval range. Combined with the two core mechanisms of effective direction expansion and encoding boundary completion, The effective direction expansion is based on eight directions. The vertical distance from the center coordinates to the four boundaries of the route map is calculated. Expansion directions with a vertical distance less than a preset boundary threshold are clipped. Only the remaining effective directions are used for node retrieval, achieving full coverage of cross-regional target trade locations. The coding boundary completion identifies adjacent nodes at the same level whose coding prefixes differ only in the last bit. Trade locations within adjacent nodes are retrieved, and their actual straight-line distances to the center coordinates are calculated. Trade locations with distances less than or equal to the search radius are included in the candidate set, achieving accurate capture of targets missed at the coding boundary. Finally, after a multi-dimensional filtering process including trade location type, level range, faction affiliation, and interaction status, the remaining trade locations are filtered layer by layer according to preset priorities. The distances of these remaining trade locations are then double-checked to exclude objects that actually exceed the search radius, accurately locking the spatial location of all target trade locations within the search radius.

2. 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, and the central control section is electrically connected to the planning section. When the central control section receives the route signal output by the planning section, it executes the cross-border trade planning method as described in claim 1.

3. 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 of claim 1.

Images