Method and system for automatically renaming a seismic safety evaluation borehole database

Abstract

This application provides an automatic renaming method and system for a borehole database for seismic safety evaluation, relating to the field of seismic data processing technology. The method includes: determining a target folder and generating target borehole numbers; storing the coordinates of cells containing cross-bore reference keywords and their neighboring cells in a protection whitelist; parsing the main table, extracting the header label text associated with the original borehole number and encapsulating it as an identity fingerprint, and retrieving cells containing the original borehole number in each worksheet based on the identity fingerprint to construct a logical dependency graph; using the identity fingerprint to navigate and locate the cell to be modified and performing dual verification; updating the original borehole number in the verified cell to the target borehole number; and simultaneously renaming the borehole subfolders and internal file prefixes. This application improves the accuracy and efficiency of batch renaming of borehole databases.

Description

Technical Field

[0001] This application relates to the field of seismic data processing technology, and in particular to an automatic renaming method and system for seismic safety evaluation borehole databases. Background Technology

[0002] In earthquake safety assessment, borehole exploration data is one of the core basic data. Each borehole data is organized in an independent folder, containing a data table file and several image files. The data table file contains multiple worksheets. When the borehole data is submitted to the National Earthquake Disaster Prevention Data Center, the provincial number needs to be uniformly converted to the national database number. This number also serves as the prefix for the folder name and file name. The scope of modification involves the file system naming and the numbering fields of multiple worksheets within the data table file.

[0003] Because the number of earthquake safety assessment projects completed by each province each year is enormous, the amount of borehole data to be submitted can reach hundreds or even thousands. Moreover, each data table file contains multiple numbering information, and the reference position and format of the numbers are different in different worksheets. Manual modification consumes a lot of manpower and is very easy to miss or make mistakes, resulting in a decline in the quality of the submitted data.

[0004] Existing batch renaming tools can only handle filename replacement and cannot delve into the data table file to identify the numbering information scattered across multiple worksheets. They also lack a protection mechanism for cross-hole reference description areas, making it easy to mistakenly modify the reference numbers of adjacent boreholes. In addition, existing tools do not have the ability to automatically construct reference relationships between worksheets based on the header label characteristics of the numbering field, and cannot achieve fine-grained control and consistency verification of renaming operations. Summary of the Invention

[0005] This application provides an automatic renaming method and system for a borehole database for seismic safety evaluation, which solves the technical problems in the prior art where it is impossible to accurately locate the number information inside the data table file when renaming borehole data in batches, there is a lack of cross-hole reference protection mechanism, and it is easy to miss or mistakenly rename the data.

[0006] To address the aforementioned technical problems, in a first aspect, this application provides an automatic renaming method for a seismic safety evaluation borehole database, comprising: Determine the target folder, and generate corresponding target borehole numbers for each borehole subfolder under the target folder based on the determined borehole starting number; Traverse the data table files in the borehole subfolder and store the coordinates of cells containing preset cross-hole reference keywords and their neighboring cells into the write protection whitelist; The main table in the data table file is parsed, the header label text associated with the original borehole number in the main table is extracted, the header label text is encapsulated as an identity feature fingerprint, and the cells containing the original borehole number are retrieved in each worksheet based on the identity feature fingerprint to construct a logical dependency graph. The identity feature fingerprint is used to navigate and locate the cell to be modified in each worksheet, and it is determined whether the coordinates of the cell to be modified are outside the write protection whitelist. The logical dependency graph is used to determine whether there is a reference association between the cell to be modified and the main table. When it is determined that the cell to be modified is not in the write protection whitelist and has a reference association with the main table, the original borehole number in the cell to be modified is updated to the target borehole number; Based on the target borehole number, the prefix of the borehole subfolder and its internal files are renamed synchronously.

[0007] Optionally, the step of retrieving cells containing the original borehole number in each worksheet based on the identity feature fingerprint to construct a logical dependency graph includes: Using the identity feature fingerprint as the root node, scan the candidate regions in each worksheet that have the same associated title attribute as the identity feature fingerprint; Search the data cells in the candidate area for content that matches the original borehole number. If a match is found, establish a directional connection between the worksheet and the main table to generate a logical dependency graph.

[0008] Optionally, the step of using the identity fingerprint to navigate and locate the cell to be modified in each worksheet includes: Parse the header structure of each worksheet and retrieve the navigation cell that matches the header label text in the identity feature fingerprint; Starting from the navigation cell, search for a cell that matches the original borehole number in the data row of the column where the navigation cell is located, or search for a cell that matches the original borehole number in the cell to the right of the row where the navigation cell is located. The matched cell is then identified as the cell to be modified.

[0009] Optionally, before updating the original borehole number in the cell to be modified to the target borehole number, the method further includes: A data format compatibility test is performed on the cell to be modified. The data format identifier of the cell to be modified is read, and it is determined whether the data type of the target borehole number is compatible with the data format identifier. If they are not compatible, the data format identifier of the cell to be modified is adjusted to a format that matches the data type of the target borehole number to ensure that the replaced target borehole number can be displayed correctly in the cell.

[0010] Optionally, updating the original borehole number in the cell to be modified to the target borehole number includes: Store the original borehole number and the target borehole number into a cache queue; After determining that the cell to be modified is not in the write protection whitelist and has a reference association with the main table, the write permission of the cell to be modified is locked, the content is rewritten according to the mapping relationship in the cache queue, and the spatial coordinate information of the successful rewriting is recorded.

[0011] Optionally, a write-protection whitelist can be constructed, including: Traverse the text content in the data table file, and when a preset cross-hole reference feature word is identified, extract the row index of the cell where the preset cross-hole reference feature word is located; Add the coordinates of the entire row cell corresponding to the row index, as well as the coordinates of cells within a preset number of rows adjacent to the row index, to the write protection whitelist.

[0012] Optionally, the step of extracting the header label text associated with the original borehole number in the main table and encapsulating the header label text into an identity feature fingerprint includes: Locate the target cell containing the original borehole number in the main table; The header labels associated with the target cell are retrieved as follows: for standard table format areas with headers at the top and data at the bottom, cells matching the preset set of numbered field labels are retrieved upwards from the column where the target cell is located as column labels; for key-value pair format areas with labels on the left and data on the right, cells matching the preset set of numbered field labels are retrieved to the left from the row where the target cell is located as row labels. The retrieved header label text content and the corresponding layout type are encapsulated together as an identity feature fingerprint.

[0013] Optionally, before updating the original borehole number in the cell to be modified to the target borehole number, the method further includes: performing a complete binary file copy of the current data table file, storing the copy in the same directory as the original data table file and identifying it with a preset suffix, as an initial snapshot; After updating the original borehole number in the cell to be modified to the target borehole number, the process further includes: reloading the updated data table file and extracting the updated cell content based on the spatial coordinate information; comparing the updated cell content with the target borehole number; if the comparison result is inconsistent, triggering a reversal command to restore the data table file to the initial snapshot state before the update, and recording an anomaly identifier in the verification file.

[0014] Optionally, the step of synchronously renaming the prefix of the borehole subfolder and its internal files according to the target borehole number includes: Obtain the original filename prefix of the non-data table files within the borehole subfolder; The original file name prefix is ​​matched with the original borehole number. If the match is found, the original file name prefix is ​​replaced with the target borehole number, while keeping the file extension unchanged.

[0015] Secondly, this application provides an automatic renaming system for a borehole database for seismic safety evaluation, comprising: The determination module is used to determine the target folder and generate corresponding target borehole numbers for each borehole subfolder under the target folder according to the determined borehole starting number; The traversal module is used to traverse the data table files in the borehole subfolder and store the coordinates of cells containing preset cross-hole reference feature words and neighboring cells into the write protection whitelist. The parsing module is used to parse the main table in the data table file, extract the header label text associated with the original borehole number in the main table, encapsulate the header label text into an identity feature fingerprint, and search for cells containing the original borehole number in each worksheet based on the identity feature fingerprint to construct a logical dependency graph. The positioning module is used to navigate and locate the cell to be modified in each worksheet using the identity feature fingerprint, and to determine whether the coordinates of the cell to be modified are outside the write protection whitelist, and to determine whether there is a reference association between the cell to be modified and the main table based on the logical dependency graph. The update module is used to update the original borehole number in the cell to be modified to the target borehole number when it is determined that the cell to be modified is not in the write protection whitelist and has a reference association with the main table. The renaming module is used to synchronously rename the prefix of the borehole subfolder and its internal files based on the target borehole number.

[0016] The technical solution provided in this application has the following beneficial effects: By establishing identity fingerprints based on the header labels of the master table, the distribution of borehole numbers can be automatically retrieved and located in each worksheet based on the header label text. This eliminates the need for fixed row and column offsets, adapts to the layout differences of different worksheets, and improves the accuracy and versatility of batch renaming. Logical dependency graphs are used to filter worksheets that have reference relationships with the master table, and a write protection whitelist mechanism is used to shield areas containing cross-bore reference keywords, effectively preventing accidental modification of adjacent borehole reference numbers. A write-back verification mechanism can promptly detect rewrite anomalies and automatically restore data, reducing the risk of data corruption. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is an overall flowchart of an automatic renaming method for a borehole database for seismic safety evaluation disclosed in an embodiment of this application.

[0019] Figure 2 This is a schematic diagram of the drilling data folder organization structure disclosed in an embodiment of this application.

[0020] Figure 3 This is a schematic diagram of the protection whitelist construction process disclosed in the embodiments of this application.

[0021] Figure 4 This is an example diagram of the protection whitelist neighborhood expansion disclosed in the embodiments of this application.

[0022] Figure 5 This is a schematic diagram of the identity feature fingerprint generation process disclosed in an embodiment of this application.

[0023] Figure 6 This is a schematic diagram illustrating the spatial relationship between the reference anchor point and the target cell in the main table disclosed in this application embodiment.

[0024] Figure 7 This is a schematic diagram illustrating a structural example of the logical dependency graph disclosed in an embodiment of this application.

[0025] Figure 8 This is a schematic diagram of the logical dependency graph construction process disclosed in an embodiment of this application.

[0026] Figure 9 This is a schematic diagram of the navigation, positioning, and dual verification process disclosed in an embodiment of this application.

[0027] Figure 10 This is a schematic diagram of the numbering update and write-back verification process disclosed in an embodiment of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only some embodiments of this application, and not all embodiments.

[0029] Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] In seismic safety assessment, borehole exploration is a fundamental means of obtaining site engineering geological conditions, and the exploration results of each borehole are stored and managed in the form of a set of standardized basic data.

[0031] During the process of converting borehole data from a provincial numbering system to a national database numbering system, it is necessary to synchronously update all cells containing the original borehole number within the data table file, and to synchronously replace the file name prefix of the borehole subfolder and its internal files with the new target borehole number. Due to the large volume of borehole data and the varying distribution of numbers within each data table file depending on the worksheet type, a method is needed that can automatically identify, accurately locate, and securely update the numbering information.

[0032] See Figure 1 As shown in the figure, this application discloses an automatic renaming method for a borehole database for seismic safety evaluation, including the following steps: S1: Determine the target folder, and generate corresponding target borehole numbers for each borehole subfolder under the target folder based on the determined borehole starting number.

[0033] In this step, the original borehole number refers to the provincial code currently used by each borehole subfolder, which is obtained by directly reading the folder name of the borehole subfolder. Since the borehole data organization standard requires that the name of each borehole subfolder be the provincial code string for that borehole, the name of the borehole subfolder is used as the original borehole number, and the user does not need to enter it separately. For example, if the borehole subfolder name is 370102SK20230510D0003, then the original borehole number is 370102SK20230510D0003.

[0034] See Figure 2As shown, the specific implementation process of this step is as follows: First, the user selects the target folder containing the borehole data to be renamed through the operation interface. The target folder is the top-level directory in the file system that stores all the subfolders of the boreholes to be renamed. The target folder contains multiple subfolders of boreholes, and each subfolder of boreholes uses the current provincial borehole number as its folder name.

[0035] The basic data for each borehole is organized in a separate borehole subfolder under the target folder. The borehole subfolder is used to centrally store all data files related to a single borehole, including a data table file and several image files.

[0036] A datasheet file is a structured data file stored in spreadsheet format. The file extension for a datasheet file is .xlsx or .xls. A datasheet file contains multiple worksheets. Each worksheet records a specific type of information about the borehole. For example, the basic parameters worksheet records the borehole number, coordinates, borehole depth, and other basic attributes; the formation description worksheet records the lithology, thickness, and depth of each formation; the standard penetration test worksheet records the number of penetration blows at each depth; and the wave velocity test worksheet records the shear wave velocity measurement results.

[0037] Image files typically include borehole columnar diagrams, core photographs, and other image data. The file format of image files is .jpg or .png, etc. The file name of the image file is prefixed with the borehole number, followed by the serial number and the file format extension.

[0038] Then, the user enters the borehole start number, which is a positive integer used to specify the starting point of the first borehole subfolder in the national database numbering system.

[0039] Based on this, according to the order of the borehole subfolders under the target folder, a target borehole number is assigned to each borehole subfolder. The target borehole number is a number string that conforms to the unified standard of the national borehole database. The target borehole number is used to replace the provincial number currently used in each borehole subfolder.

[0040] The generation rule for the target borehole number is to concatenate the area identifier prefix with a serial number that increases in natural numbers. The area identifier prefix is ​​a fixed string identifier assigned to each province by the national database. The serial number part adopts a fixed number of zero-padding format, and the number of digits can be set according to actual needs.

[0041] The formula for generating the target borehole number is shown in equation (1): (1) In equation (1), For the first The target borehole number corresponding to each borehole subfolder. The prefix is ​​the area identifier, W is the fixed number of bits in the sequence number, and ZeroPad is the zero-padding function that converts the integer n into a zero-padding string of W bits. In equation (1), n ​​takes the value of , which is the sequence number corresponding to the i-th borehole subfolder, and S is the starting number of the borehole entered by the user.

[0042] In practical engineering applications, assuming the target folder path is / data / sdata, there are 26 borehole subfolders under the target folder, the user-input borehole starting number S=1, the area identifier prefix P=SD, and the number of digits W=5.

[0043] According to equation (1), the target borehole number corresponding to the first borehole subfolder is: ; The second one is ; And so on, the 26th is .

[0044] In another specific implementation, if the number of drilling subfolders under the target folder is large, such as containing 500 drilling subfolders, the number of serial numbers W can be set to 6 digits so that the generated target drilling number has enough numbering space, for example, T(1)=SD000001, T(500)=SD000500.

[0045] It should be noted that the order of the drilling subfolders under the target folder is determined by the lexicographical order of the file system, that is, arranged in ascending order according to the character encoding of the folder name. When generating the target drilling numbers, the serial numbers are assigned sequentially according to this arrangement. Before use, users should ensure that the arrangement of the drilling subfolders is consistent with the expected numbering order.

[0046] This step generates target borehole numbers in batches by combining the borehole starting number with the area identifier prefix and incrementing by natural numbers. This establishes a clear correspondence between the original borehole numbers and the target borehole numbers, facilitating the construction of the protection whitelist in subsequent step S2 and the number replacement operation in subsequent step S5.

[0047] S2: Traverse the data table files in the drilling subfolder and save the coordinates of cells containing preset cross-hole reference keywords and neighboring cells into the protection whitelist.

[0048] After generating the corresponding target borehole number for each borehole subfolder in step S1, since the data table file not only contains the number information of this borehole, but may also reference the numbers of adjacent boreholes as reference descriptions in some worksheets, it is necessary to identify and protect these cross-hole reference areas before performing the number replacement operation to avoid mistakenly modifying the reference number of adjacent boreholes to the target borehole number of this borehole.

[0049] For example, the wave velocity test worksheet may record a reference hole number field to mark the adjacent borehole numbers for comparison. If all content in the data table file that is similar to the original borehole number text is replaced indiscriminately, the reference numbers of adjacent boreholes will be incorrectly modified, thereby destroying the cross-reference relationship between boreholes.

[0050] See Figure 3 As shown, the specific implementation process of this step is as follows: First, open the data table files in the borehole subfolder one by one, and traverse the text content of all worksheets in the data table files. During the traversal, scan the text value of each cell to detect whether the cell text contains preset cross-hole reference feature words. The preset cross-hole reference feature words are a set of predefined keywords used to identify the descriptive areas in the data table files that involve references to adjacent boreholes. The preset cross-hole reference feature words include terms such as reference hole, adjacent hole, comparison hole, and adjacent borehole. The specific terms can be set according to the actual content of the data table files and the terminology standards of the seismic safety assessment industry.

[0051] The matching method is exact substring matching, which means that as long as the cell text contains any word in the preset cross-hole reference feature word set, it is considered a hit; after the preset cross-hole reference feature word is identified, the row index of the cell where the preset cross-hole reference feature word is located is extracted.

[0052] Then, the coordinates of the entire row of cells corresponding to the row index are added to the protection whitelist. The protection whitelist is a data container that stores a set of cell coordinates. The protection whitelist is used to record the positions of all cells that are not allowed to perform number replacement operations. In subsequent steps S4 and S5, cells whose coordinates are in the protection whitelist are skipped and no modifications are performed.

[0053] Simultaneously, the cell coordinates within a preset number of rows adjacent to the row index are also added to the protection whitelist to achieve simultaneous shielding of the cross-bore reference description area. The preset number of rows controls the vertical expansion range of the protection area. The preset number of rows can be adjusted according to actual needs and can be specified through a configuration file. In practical applications, the recommended value for the preset number of rows is 1 to 5 rows, with 2 rows being the preferred value. A value that is too small (e.g., 0 rows) may result in the reference borehole numbers stored in adjacent rows of the row containing the feature word not being protected and being mistakenly modified; a value that is too large (e.g., more than 5 rows) may result in the protection range being over-expanded, mistakenly including the borehole number field that should be modified in the protection range and failing to modify it. In the actual format of the seismic safety evaluation data table, cross-bore reference information is usually concentrated within 2 to 3 rows above and below the feature word, so a preset number of 2 to 3 rows is sufficient to cover most cases.

[0054] The reason for the need for cross-hole reference description information is that it is usually not limited to a single cell, but is distributed in the range of several rows above and below the row where the feature word is located. For example, the title of the reference hole number field may be in row 15, while the actual reference number value may be in row 16 or row 17. Therefore, it is necessary to protect the adjacent fields above and below the row where the feature word is located.

[0055] For example, such as Figure 4 As shown, the process of constructing the protection whitelist is illustrated using the worksheet "Wave Speed ​​Test" as an example, with the preset number of rows N set to 2. Figure 4 The diagram shows a portion of the worksheet's contents: Row 12 records standard wave velocity data; Rows 13 and 14 record test depth and test method, respectively; Column B of Row 15 contains the text "reference borehole number," which belongs to the preset cross-bore reference feature word set, thus Row 15 is identified as a feature word hit row; Column B of Row 16 stores the actual numbers of adjacent boreholes (e.g., 370102SK20230510D0004); Row 17 contains remarks; and Row 18 contains other subsequent data. After identifying the feature word hit in Row 15, the row index of Row 15 is used as a reference, expanding upwards by N=2 rows to Row 13 and downwards by N=2 rows to Row 17, adding all cell coordinates within the range of Rows 13 to 17 to the protection whitelist. This protection range is marked in light gray in the diagram. The adjacent borehole numbers stored in row 16, column B, which are within the protection range, will be skipped in subsequent step S5 and will not be replaced with the target borehole number; while the cells in rows 12 and 18, which are outside the protection range, are not subject to the protection whitelist.

[0056] In this application, a neighboring cell refers to all cells within the range covered by extending upwards and downwards by a preset number of rows, based on the row index of the cell containing the preset cross-hole reference feature word. In the implementation scheme of this application, the extension direction of the neighboring range is the row direction, not the column direction. The reason is that cross-hole reference information is usually distributed in the form of continuous rows in the data table file. The extension in the column direction cannot effectively cover the actual distribution pattern of cross-hole references and will excessively expand the protection scope, leading to omissions.

[0057] It should be noted that the aforementioned neighborhood expansion method based on row indexing applies to data table formats where cross-hole reference information and hole number information are separated in the row direction. In practical applications, some data table files may use a parameter comparison table format, that is, the same parameters of the hole and the reference hole are arranged and compared in the same row or adjacent rows. For example, in a worksheet, row 10 is "hole wave velocity", row 11 is "reference hole wave velocity", row 12 is "hole number", and row 13 is "reference hole number" and its corresponding number value. In this format, if the 13th row is the target row for the keyword and is expanded upwards by N=2 rows, then rows 11 to 15 will all be included in the protection whitelist. The hole number that should be replaced in row 12 will also be mistakenly included in the protection scope, resulting in omission of modification.

[0058] To address the aforementioned parameter comparison table format, this application provides a supplementary whitelist construction strategy: whitelist rules can be configured according to the specific table format of the data table file. Specifically, when the data table file uses a parameter comparison table format, the protection scope of the whitelist can be narrowed from whole-row protection to column-oriented protection. That is, only the cell coordinates within the column containing the feature word and its preset right-hand column range in the row where the feature word is hit are included in the whitelist, without locking the entire row. For example, if "reference hole number" is located in row 13, column A, and its corresponding number value is located in row 13, column B, then only the coordinates in row 13, columns A and B are included in the whitelist; the hole information in other columns of the same row remains unaffected. The selection of the aforementioned whitelist rules can be set through a configuration file, which contains rule identifiers and corresponding parameters. The rule identifier specifies the currently used whitelist construction strategy: when the rule identifier is "row expansion," the aforementioned row-index-based neighborhood expansion method is used; when the rule identifier is "column orientation," the aforementioned column-oriented protection method is used. If no rule identifier is specified, the "row expansion" strategy is used by default.

[0059] This step constructs a protection whitelist for the cross-hole reference area by using a preset cross-hole reference feature word matching and neighborhood expansion mechanism. This provides a shielding basis for the dual verification in step S4 and the secure rewriting in step S5, effectively preventing the reference number of adjacent boreholes from being mistakenly modified.

[0060] Protection Whitelist S3: Parses the main table in the data table file, generates an identity feature fingerprint based on the spatial offset of the original borehole number in the main table relative to the table header, and analyzes the reference relationship between each worksheet based on the identity feature fingerprint to construct a logical dependency graph.

[0061] After the protection whitelist has been built in step S2, since the data table file contains multiple worksheets and the original borehole numbers are scattered in different locations in each worksheet, and the header structure and data layout of each worksheet are not exactly the same, it is not possible to simply perform a global replacement of the original borehole number text appearing in all worksheets.

[0062] Based on this, the idea of ​​this step is to first extract the spatial location feature of the original borehole number relative to the table header from the main table, encapsulate this location feature as an identity feature fingerprint, and then use the identity feature fingerprint to perform association addressing in other work tables, thereby determining whether each work table references the borehole number field in the main table, and then constructing a logical dependency graph.

[0063] See Figure 5 As shown, the process of generating an identity fingerprint is as follows: First, identify the master table in the data table file. The master table is the core worksheet in the data table file that records basic borehole information. The master table typically contains basic borehole attributes such as the original borehole number, borehole coordinates, borehole elevation, and borehole depth. The master table's format is usually different from other sub-tables; it can be quickly located by its filename, which can be configured according to the specific situation.

[0064] Next, locate all target cells containing the original borehole number in the main table. A target cell is the cell in the main table that actually stores the text value of the original borehole number. The location method involves traversing all cells in the main table, precisely matching the text content of each cell with the original borehole number, and recording all successfully matched cells as target cells, forming a set of target cells. Since the original borehole number may appear in multiple different locations within the same main table (e.g., below the "Borehole Number" column and the "Number" column respectively), and the header environment of each target cell is different, it is necessary to generate a corresponding identity fingerprint for each target cell, forming a set of identity fingerprints. After finding the target cells, it is necessary to determine the layout type of the area where each target cell is located and retrieve the corresponding associated header as the basis for cross-worksheet location.

[0065] The reason for not directly recording the absolute row and column coordinates of the target cell (e.g., "Row 2, Column 1") is that absolute coordinates are only valid within a specific table layout of the main sheet. The row and column layouts of other worksheets are usually different from those of the main sheet, and the absolute position of the same borehole number field will vary across different worksheets. Instead, the associated header text (e.g., "Borehole Number") and the offset of the number relative to that header constitute a relative position description. This relative description does not depend on the specific absolute row and column numbers and can be used universally across different worksheets with the same or similar headers.

[0066] The methods for determining layout type and the rules for anchor point retrieval are as follows: For each target cell, the column header of its corresponding column is first retrieved. The column header is retrieved by scanning each row in ascending order of row number, starting from the first row of the target cell's column. The first non-empty cell encountered is the column anchor point, and the text content within the anchor point is the column header. If the anchor point and the target cell are not in the same row, the target cell is considered to be in a standard table format area (header at the top, data at the bottom). A row offset Δr is used as the positioning parameter, calculated as: Δr = (Angle Point R_target / Angle Point - Angle Point R_col_anchor), where R_target is the row index of the target cell and R_col_anchor is the row index of the anchor point, generating a Δr-type fingerprint.

[0067] If the column anchor point and the target cell are in the same row (i.e., all cells above the column are empty, and the target cell itself is the first non-empty content in that column), then the row label is further searched. The row label search method is as follows: starting from the first column of the row containing the target cell, scan each column in ascending order of column number; the first non-empty cell encountered is the row anchor point. If the row anchor point and the target cell are not the same cell, then the target cell is determined to be in a key-value pair format area (label on the left, data on the right), and the column offset Δc is used as the positioning parameter. The calculation formula is Δc = C_target - C_row_anchor, where C_target is the column index of the target cell, and C_row_anchor is the column index of the row anchor point. The index generates a Δc-type fingerprint.

[0068] It should be noted that, in this application, "not empty" means that the actual text content of the cell is not an empty string and is not a string containing only spaces. If the cell content is a zero-length formula return value, it is treated as an empty cell.

[0069] Furthermore, the associated title text and its corresponding offset are encapsulated together into an identity feature fingerprint. The identity feature fingerprint is a composite data structure containing the associated title text, the offset direction, and the offset amount. The offset direction can be either row-wise (Δr type) or column-wise (Δc type). The purpose of the identity feature fingerprint is to encode the relative positional characteristics of the original borehole number in the main table into a set of positioning parameters that can be reused in other worksheets. Since the original borehole number may appear in multiple different positions within the same main table, and the layout type and associated title may differ at each position, it is necessary to generate a corresponding identity feature fingerprint for each target cell, thus forming an identity feature fingerprint set.

[0070] See Figure 6 As shown below, the retrieval process for column reference anchors and row reference anchors is illustrated through a specific embodiment.

[0071] Example 1: Standard table format.

[0072] Assuming the main table uses a standard table format, some of its contents are shown in Table 1 below: Table 1. Partial content of the main table (standard table format)

[0073] In Table 1 above, the original borehole number 370102SK20230510D0003 is located in cell A2. When retrieving the column reference anchor point, the scan starts from the first row of column A. The content of A1 is "Borehole Number", which is not empty, and is therefore identified as the column reference anchor point. The column reference anchor point A1 and the target cell A2 are not in the same row (A1 is in the first row, A2 is in the second row), so it is determined to be a standard table format. The row offset Δr is calculated as follows: Protection whitelist = Protection whitelist2 Protection whitelist - Protection whitelist1 Protection whitelist = Protection whitelist1.

[0074] Generate a Δr-type fingerprint: {Associated title text: "Drill Number", Offset direction: Row direction, Offset amount Δr: 1}. This means that in other worksheets, if the header of a column is "Drill Number", then moving down one row from that header will lead to the data cell for the drill number.

[0075] Example 2: Key-value pair format.

[0076] Assuming another main table uses a key-value pair format, part of its content is shown in Table 2 below: Table 2: Partial content of the main table (key-value pair format)

[0077] In Table 2 above, the original borehole number is located in cell B2. When retrieving the column reference anchor, the scan starts from row 1 of column B. The content of B1 is "A certain project in City A," which is not empty, and is therefore identified as the column reference anchor. However, although the column reference anchor B1 and the target cell B2 are not in the same row, the content of B1, "A certain project in City A," is not a unified header title for column B, but rather the data value of another key-value pair. In the key-value pair format, each row of column B stores data values ​​for different fields, and column B does not have a unified column header.

[0078] To accurately handle this situation, when the text content of the column base anchor point clearly does not match the text pattern of the original borehole number (i.e., the column base anchor point text neither contains borehole number-related keywords such as "number" nor is consistent with the known header titles of other worksheets in the data table file), the row labels are further searched: starting from the first column of the row containing B2, the content of A2 is "Brehole Number", which is determined to be the row base anchor point. Since the row base anchor point A2 and the target cell B2 are in the same row but not the same cell, it is determined to be a key-value pair format, and the column offset Δc = 2 - 1 = 1 is calculated.

[0079] Generate a Δc-type fingerprint: {Associated title text: "Drill Number", Offset direction: Column direction, Offset amount Δc: 1}. This means that in other worksheets, if the text content of a cell is "Drill Number", then moving one column to the right from that cell will reach the data cell for the drill number.

[0080] Example 3: Multiple numbering entries appear in the same worksheet.

[0081] In actual data tables, some worksheets have an information summary area (key-value pair format) at the top and a data details area (standard table format) at the bottom, with the original borehole number appearing once in each area. Assume that part of the content of the main table is shown in Table 3 below.

[0082] Table 3: Partial content of the main table (numbers appear twice)

[0083] In Table 3 above, the original borehole numbers appear in two places: cell B1 (information summary area) and cells B5 and B6 (data details area). After traversing the main table, the target cell set contains three elements: B1, B5, and B6. B5 and B6 are in the same column with the same column header, so only one fingerprint needs to be generated for this column (taking B5, which is closest to the column header, as the representative). Therefore, it is actually necessary to generate fingerprints for B1 and B5 separately.

[0084] For target cell B1: Retrieve the column reference anchor point, scanning from row 1 of column B. B1 itself is the first non-empty cell in that column, so the column reference anchor point and the target cell are the same cell. Further retrieve the row labels, scanning from row 1, column A. A1 contains "Drilling Number", which is determined to be the row reference anchor point. It is determined to be a key-value pair format, Δc=2-1=1. Generate a Δc-type fingerprint: {Associated title text: "Drilling Number", Offset direction: column direction, Offset amount Δc: 1}.

[0085] For target cell B5: Retrieve column anchor point, scanning from row 1 of column B, B1 is not empty, but its content is a serial number value, not a table header. Continuing to scan downwards, B4 contains "Drill Number," which is the column header for the data details area. Since B4 and B5 are not in the same row, it is determined to be a standard table format, Δr=5-4=1. Generate a Δr-type fingerprint: {Associated header text: "Drill Number", Offset direction: row direction, Offset amount Δr: 1}.

[0086] At this point, the identity feature fingerprint set contains two fingerprints: a Δc-type fingerprint covering a key-value pair format worksheet (such as a worksheet containing only a message summary area), and a Δr-type fingerprint covering a standard table format worksheet (such as a worksheet containing a data detail area). Subsequent steps will use these two fingerprints for navigation and positioning in other worksheets, automatically selecting to jump down (Δr-type) or right (Δc-type) based on the offset direction in the fingerprint. A successful match between any fingerprint establishes a directional connection between that worksheet and the main table.

[0087] It should be noted that the specific values ​​of the row offset Δr and column offset Δc depend on the actual table layout. In standard table formats, the header and data rows are adjacent, and Δr=1 is the most common value; in key-value pair formats, the label and data value are adjacent on the same row, and Δc=1 is the most common value. The purpose of identity feature fingerprints is to record this relative offset relationship so that the positioning rules can adapt to different table layouts, without relying on fixed absolute row and column coordinates.

[0088] After obtaining the identity feature fingerprint, it is necessary to analyze the reference relationships between the worksheets based on the identity feature fingerprint to construct a logical dependency graph. A logical dependency graph is a directed graph structure used to describe the reference dependencies between worksheets in a data table file on the borehole number field. Nodes in the logical dependency graph represent the worksheets in the data table file, and directed edges represent the reference relationships between worksheets on the borehole number field.

[0089] In this context, the direction of the directional join is from the referenced master table to the subordinate worksheet with the referenced number. The directional join is stored in the logical dependency graph as an adjacency list. Each record in the adjacency list contains three fields: source node identifier, target node identifier, and the coordinates of the addressed cell. The coordinates of the addressed cell refer to the coordinates of the cell whose original borehole number content is actually read after addressing it using spatial offsets in the subordinate worksheet. These coordinates are used as a reference for locating the cell to be modified in subsequent step S4.

[0090] See Figure 7 As shown, the structure of the logical dependency graph is as follows: Assume that the data table file contains five worksheets: main table, formation description, standard penetration test, wave velocity test, and geotechnical test. After the construction process, directional connections are established between the main table and the formation description, between the main table and the standard penetration test, and between the main table and the geotechnical test. However, no connection is established between the main table and the wave velocity test because the addressing content is inconsistent with the original borehole number.

[0091] In the logical dependency graph, only worksheets that have a direct connection to the main table are included in the numbering range of the subsequent step S4. The content of worksheets that are not connected will not be modified. This filtering mechanism based on reference relationships avoids accidental operations on irrelevant worksheets.

[0092] See Figure 8 As shown, the specific process of constructing the logical dependency graph is as follows: First, scan each worksheet in the data file except the main table. For each fingerprint in the identity feature fingerprint set, search each worksheet for candidate regions with the same text content as the column baseline anchor text attribute of that fingerprint. If multiple candidate regions in a worksheet can be successfully matched with fingerprints, only one directional connection is established to avoid duplication.

[0093] The associated header attributes include two fields: column base anchor text attribute and row base anchor text attribute. During candidate area retrieval, the column base anchor text attribute is used as the primary matching condition; that is, cells with the exact same column base anchor text attribute are searched within the worksheet. The search scope is initially limited to the first 20 rows of the worksheet. If no matching cell is found within the first 20 rows, the search scope is expanded to all rows of the worksheet. For headers with merged cells, the text attribute of the top-left cell in the merged cell area is used as the representative text for that merged area in the matching process. The column range containing the matched cells is then defined as the candidate area.

[0094] After finding the candidate region, the column reference anchor cell matched in the candidate region is used as the origin of the coordinate system, and the row offset in the identity feature fingerprint is used as the reference anchor cell. Perform a primary addressing, which means starting from the anchor cell and moving downwards along the row direction. Okay, read the content of the cell that is reached after the jump.

[0095] If the content addressed by the primary address matches the original borehole number, content validation is performed: the content of the cell addressed by the primary address is compared precisely with the original borehole number. If the comparison matches, it confirms that the worksheet contains a borehole number field identical to the main table, and a directive connection is established between the current worksheet and the main table. This connection is then added to the adjacency list of the logical dependency graph. If the content addressed by the primary address does not match the original borehole number, no directive connection is established. Within the same worksheet, if multiple fingerprints in the identity feature fingerprint set pass both the primary address and content validation, only one directive connection is established, and the coordinates of the matched cells record all matched positions.

[0096] In addition, optional auxiliary cross-validation can be performed to further improve matching reliability: search for cells in the same worksheet that have the exact same text attribute as the row reference anchor. If the cell is found, move Δc columns to the right from that cell and read the content of the cell reached after the jump. If the content is also consistent with the original borehole number, the cross-validation passes. If no matching cell with the row reference anchor text attribute is found or the cross-validation fails, it does not affect the judgment result of the main addressing, and only records the cross-validation failure prompt message in the verification file.

[0097] During the addressing process, if the content of the cell reached after the jump is inconsistent with the original borehole number, or if no anchor cell matching the column baseline anchor text attribute is found in the candidate area, no directional connection will be established, and the cell at that position in the current worksheet will not be included in the subsequent number replacement range.

[0098] In practical engineering applications, assuming that cell C1 in the worksheet's stratigraphic description contains the borehole number and cell A5 contains basic information, using C1 as the column anchor point, and based on the row offset Δr=4 in the identity fingerprint, moving down 4 rows from C1 to cell C5, the content of cell C5 is read. Cell C5 contains 370102SK20230510D0003, which is completely consistent with the original borehole number, indicating successful primary addressing. Further cross-validation is performed by retrieving the row reference anchor point: using A5 as the row anchor point, based on the column offset... =2, starting from A5, move 2 columns to the right to reach cell C5, and read the content of cell C5. If the content of cell C5 is 370102SK20230510D0003, and both the primary addressing and cross-validation point to the same cell C5 and the content is completely consistent with the original borehole number, then the match is confirmed to be successful, and a record is added to the adjacency list of the logical dependency graph: the source node is "main table", the target node is "stratum description", and the addressing hit cell coordinates are C5.

[0099] If a cell D1 in the Wave Speed ​​Test worksheet contains the borehole number, but cell D5, located 4 rows down from D1, contains either empty text or other text that is inconsistent with the original borehole number 370102SK20230510D0003, then no directional connection will be established for the Wave Speed ​​Test worksheet.

[0100] The reason for using identity feature fingerprinting for associative addressing instead of simple full-text search and replacement is that the data table file may contain content that is similar to the original borehole number text but has a different meaning. For example, a worksheet may store the administrative division code 370102 in the provincial code as an independent field. If full-text replacement is used, the administrative division code will be incorrectly modified. However, identity feature fingerprinting, through the dual constraints of table header title attributes and spatial offset, only locates the cells that are actually located in the borehole number field, thus avoiding mismatches.

[0101] This step extracts identity feature fingerprints from the main table and uses them as a basis to construct a logical dependency graph, connecting the scattered numbering information in the data table file through structured reference relationships, laying the foundation for navigation and positioning in step S4 and security rewriting in step S5.

[0102] S4: Use identity feature fingerprints to navigate and locate the cell to be modified in each worksheet, determine whether the coordinates of the cell to be modified are outside the protection whitelist, and determine whether there is a reference relationship between the cell to be modified and the main table based on the logical dependency graph.

[0103] After the identity feature fingerprint and logical dependency graph have been constructed in step S3, the logical dependency graph only records the reference relationship between each worksheet and the main table, but the precise coordinates of the cells to be modified in each worksheet have not yet been determined.

[0104] Therefore, this step requires using identity feature fingerprints to navigate and locate in each worksheet, while combining protection whitelists and logical dependency graphs for dual verification to ensure that only the numbered cells that truly belong to the core attributes of this hole are modified.

[0105] See Figure 9 As shown, the specific process of navigation and positioning is as follows: First, the header structures of each worksheet in the logical dependency graph that has a directional connection with the main table are analyzed in turn. Navigation cells that match the text attributes of the column reference anchors in the identity feature fingerprint are retrieved in the header structure. Navigation cells are header cells in the worksheet whose text content is completely consistent with the text attributes of the column reference anchors. Navigation cells are used as the coordinate origin for subsequent spatial offset jumps.

[0106] Then, using the navigation cell as the origin, the position is jumped according to the row offset Δr indicated by the spatial offset in the identity feature fingerprint. The jump is calculated as follows: the row index of the cell to be modified = the row index of the navigation cell + Δr, and the column index of the cell to be modified = the column index of the navigation cell (if it is in the same column as the navigation cell, the column index will not be offset). The cell reached after the jump is determined as the cell to be modified.

[0107] It should be noted that only the column reference anchor text attribute and row offset are used during navigation and positioning. To ensure proper positioning, the cell to be modified and the navigation cell are in the same column, the column index is not shifted, and column offset is not used. This is because, in the definition of identity feature fingerprints, the column reference anchor text attribute corresponds to the header title of the column containing the borehole number (e.g., "Borehole Number"), and the row offset... This indicates the row spacing from the column header to the actual data row for the borehole number. Combining these two parameters allows for precise positioning of the borehole number within the column. (Row reference anchor text attribute and column offset) It is only used for cross-validation in the logical dependency graph construction in step S3, and does not participate in the navigation and positioning in step S4.

[0108] After identifying the cell to be modified, two validations are required: The first verification step is to determine whether the coordinates of the cell to be modified are outside the protection whitelist constructed in step S2. Specifically, the worksheet name and row and column index of the cell to be modified are combined into a coordinate triplet, and the cell is searched in the protection whitelist. If the coordinate triplet exists in the protection whitelist, it means that the cell is located in the cross-hole reference description area, and the cell should be skipped and the number replacement operation should not be performed.

[0109] The second verification step is to determine whether there is a reference relationship between the worksheet containing the cell to be modified and the main table based on the logical dependency graph. Specifically, the step is to query the adjacency table of the logical dependency graph to see if the name of the worksheet containing the cell to be modified appears as a target node. If there is no reference relationship, it means that the number information in the worksheet does not originate from the drill number field of the main table, and should also be skipped.

[0110] In addition, during the navigation and positioning process described above, it is also necessary to perform environmental attribute detection on the cells to be modified. Environmental attribute detection refers to reading the data format identifier of the cell to be modified. The data format identifier refers to the cell format type set in the spreadsheet, such as text format, number format, or date format. The data format identifier is obtained by reading the numeric format attribute string of the spreadsheet cell object. For example, a format string of "General" or "@" indicates text format, while a format string of "0" or "0.00" indicates number format.

[0111] The environmental attribute detection criteria include two dimensions: character length detection and data format identifier detection. Both must pass to be considered compatible. Character length detection is performed as follows: obtain the character length of the original content string of the cell to be modified, denoted as Lc; obtain the character length of the original borehole number string, denoted as Lo; if Lc is not equal to Lo, the character length is considered mismatched, and the character length of the cell to be modified does not match the original borehole number, thus it is considered a non-core attribute cell for this borehole. The above character lengths are based on the actual text content of the cell, excluding leading zeros or other display formatting effects. Data format identifier detection is performed by reading the numeric format attribute string set in the spreadsheet for the cell to be modified, and determining whether the data type of the target borehole number is compatible with this format identifier. Specifically, if the target borehole number contains alphanumeric characters and is of text type, while the data format identifier of the cell to be modified is of numeric format (e.g., the format string is "0" or "0.00"), then the two data formats are considered incompatible. For example, if the original content of the cell to be modified is "370102SK20230510D0003", with a character length of 22, and the original borehole number "370102SK20230510D0003" also has a character length of 22, the character length detection passes; the data format identifier is text format, and the target borehole number "SD00001" is also text type, so the data format identifier detection passes; if both detections pass, then the cell passes the environment attribute detection.

[0112] For example, if the data format identifier of the cell to be modified is a number format, while the target borehole number "SD00001" contains alphanumeric characters and is of text type, the two data formats are incompatible, and therefore a mismatch is determined.

[0113] If there is a mismatch, the cell to be modified is determined to be a non-core attribute cell of this borehole. A non-core attribute cell refers to a cell that, although it coincides with the fingerprint positioning result of the identity feature in spatial location, actually stores data that is not the borehole number of this borehole but other types of data, such as the stratum number, test sequence number, or other numerical fields unrelated to the borehole number. The coordinates of the non-core attribute cell are added to the protection whitelist, and no number replacement operation is performed on it subsequently.

[0114] In practical engineering applications, assuming that C5 in the worksheet "Formation Description" is determined to be the cell to be modified through navigation positioning, and the content of C5 is 370102SK20230510D0003, the data format identifier is text format, and the target borehole number SD00001 is also text type, both of which are text format identifiers, so they are determined to be compatible, and C5 passes the environmental attribute detection.

[0115] In another specific implementation, if the worksheet standard penetration test determines that D8 is the cell to be modified through navigation positioning, but the content of D8 is 15, the character length is 2, and the data format identifier is in numeric format, while the target borehole number SD00001 is text type, the two data format identifiers are incompatible. Therefore, D8 is determined to be a non-core attribute cell of this borehole, and the coordinates of D8 are added to the protection whitelist.

[0116] The environmental attribute detection mechanism described above can effectively identify offset positioning deviations caused by differences in worksheet header structure, excluding non-numbered cells from the replacement range, thereby further improving the accuracy of number replacement.

[0117] This step utilizes the navigation and positioning capabilities of identity feature fingerprints and a dual verification mechanism of protection whitelist and logical dependency graph to achieve precise filtering of cells to be modified, ensuring that the number update operation in step S5 only applies to the core number field of this hole that truly needs to be modified.

[0118] S5: When it is determined that the cell to be modified is not in the protection whitelist and has a reference relationship with the main table, update the original borehole number in the cell to be modified to the target borehole number.

[0119] After the cells to be modified have been filtered out through navigation positioning and dual verification in step S4, this step performs the actual number replacement operation.

[0120] See Figure 10 As shown, the specific implementation process of this step is as follows: First, the original borehole number and the target borehole number are paired as key-value pairs and stored in a cache queue. The cache queue is an ordered in-memory mapping table. The cache queue uses the original borehole number as the key and the target borehole number as the value. The cache queue is used to manage the number mapping relationship of all boreholes when batch processing multiple borehole data, so that the replacement operation can quickly obtain the corresponding target borehole number by looking up the table, without having to recalculate it each time.

[0121] The table format of the cache queue is shown in Table 4 below.

[0122] Table 4 Examples of Cache Queues

[0123] In this application, the cache queue serves as the sole data source for number replacement operations. The replacement target for all cells to be modified is obtained by querying the cache queue with the original borehole number as the key. This ensures that the replacement results for the same original borehole number are completely consistent across different worksheets, avoiding inconsistencies that may arise during distributed replacements.

[0124] Then, for each cell to be modified that passes the double verification in step S4, perform the following replacement operation: The first step is to lock the write permissions of the cells to be modified. Locking refers to serializing write operations on the current data table file during the modification process using a thread mutex lock. This ensures that only one write operation is performed on the data table file at a time, preventing write conflicts caused by asynchronous callbacks or multi-threaded scheduling during batch processing. Specifically, before each data table file modification operation begins, a mutex lock object associated with that file path is acquired; after the modification operation is completed and the file is saved, the mutex lock is released.

[0125] The second step is to read the current text content in the cell to be modified, denoted as cell_value, and use cell_value as the query key to perform an exact match search in the cache queue. If there is a record in the cache queue with cell_value as the key, the value of that record is retrieved as the replacement target text, denoted as target_value.

[0126] Before performing the replacement operation, the storage type of the cell to be modified must be determined. If the cell stores static text values, the string replacement is performed directly as in step three. If the cell stores a formula, the formula string is extracted, and the text substring that exactly matches cell_value is replaced with target_value. The replaced formula string is then rewritten back to the cell, retaining the formula format and not converting it to static text values. The cell storage type is determined by reading the data type attribute of the spreadsheet cell object: when the data type attribute is string (str), it is static text; when the data type attribute is formula (formula), it is formula storage. If the formula string does not contain a substring that exactly matches cell_value, the cell content is determined not to be directly related to the original borehole number, the replacement operation is not performed, and the cell's coordinates and the message "Formula content does not contain the original borehole number" are recorded in the verification file for manual verification by the user.

[0127] The third step is to replace the text content in the cell to be modified from cell_value to target_value. The replacement method is to replace the entire string. The specific operation process is as follows: find the substring in the text content of the cell that completely matches cell_value, and replace the matched substring with target_value. If cell_value appears multiple times in the cell, only the position of the first occurrence will be replaced, keeping the other text content and format of the cell unchanged.

[0128] The pseudocode logic for the replacement operation is: new_content = cell_content.replace(cell_value, target_value, 1), where cell_content is the original text content of the cell, the third parameter 1 of the replace function indicates that only the first occurrence of the match is replaced, new_content is the new text content after replacement, and new_content is written back to the cell to be modified.

[0129] In practical engineering applications, assuming the current text content in cell C5 to be modified is 370102SK20230510D0003, the cache queue is searched using 370102SK20230510D0003 as the key. The key-value pair 370102SK20230510D0003 is found and mapped to SD00001. Therefore, the content of cell C5 is replaced from 370102SK20230510D0003 to SD00001.

[0130] The fourth step is to record the spatial coordinate information of the successful replacement after the replacement is completed. The spatial coordinate information includes three fields: worksheet name, row index, and column index of the cell. The spatial coordinate information is used for the write-back verification operation performed in this step.

[0131] After all the replacement operations for the cells to be modified are completed, a write-back verification operation needs to be performed.

[0132] The specific process of write-back verification is as follows: The updated data table file is reloaded, and the updated cell content is extracted one by one based on the recorded spatial coordinate information. The updated cell content is then compared character by character with the corresponding target borehole number in the cache queue. The specific method for character-by-character comparison is: the updated cell text content is recorded as `verify_value`, and the corresponding target borehole number in the cache queue is recorded as `target_value`.

[0133] The comparison process consists of two stages: the first stage is length comparison, which calculates the character length of verify_value. and the character length of target_value ,like Not equal to If the comparison results are inconsistent, then it is directly determined that the comparison results are inconsistent, and there is no need to proceed to the second stage.

[0134] The second stage involves character-by-character comparison, following the character position index k starting from 1 to... Compare them one by one. For each position k, check if the kth character of verify_value is equal to the kth character of target_value.

[0135] The formula for determining whether the comparison results are consistent is: ,in This indicates that the comparison results are consistent. Indicates the character length of the verification value. Indicates the character length of the target value. Indicates the first value in the verification value One character, Indicates the first value in the target value One character, For logical AND operator, k∈[1,Lt] means that the corresponding characters are equal at all positions from 1 to Lt. The comparison result is considered to be consistent if and only if Match is true.

[0136] If the comparison results match, the cell number update operation is confirmed to be successful.

[0137] If the comparison results are inconsistent, it indicates an anomaly during the update process. For example, text may be truncated or converted due to cell formatting settings. In this case, an undo command is triggered, restoring the data table file to its initial snapshot state before the update. The initial snapshot state refers to the backup copy generated by performing a complete binary file copy of the data table file before executing the numbering update operation. The backup copy is stored in the same directory as the original data table file and is identified with the .bak suffix. The undo operation is achieved by overwriting the current data table file with the backup copy. The initial snapshot is created when, before performing any cell replacement operation on each borehole subfolder, the data table file within that borehole subfolder is independently copied once. The backup copies of each borehole subfolder are independent and do not affect each other. Only after the initial snapshot is created can the subsequent numbering replacement process begin.

[0138] At the same time, anomaly identifiers are recorded in the verification file. The verification file is a log file stored in comma-separated value format. The anomaly identifiers include fields such as the name of the borehole subfolder where the anomaly occurred, the worksheet name, the cell coordinates, the target borehole number to be written, and the cell content actually read.

[0139] In practical engineering applications, assuming the original borehole number is 370102SK20230510D0003 and the target borehole number is SD00001, cell C5 in the main table and cell C5 in the formation description of the worksheet both passed double verification and performed a replacement operation. During the write-back verification, the content of C5 is reread as SD00001, and compared character by character with the target borehole number. Both have a character length of 7. The first character matches S with S, the second character matches D with D, the third character matches 0 with 0, the fourth character matches 0 with 0, the fifth character matches 0 with 0, the sixth character matches 0 with 0, and the seventh character matches 1 with 1. All of these match, therefore, the C5 verification passes. In cases where a column contains multiple cells to be modified (e.g., cells B5 to B8 in the wave speed test worksheet have all been replaced), during write-back verification, the contents of B5, B6, B7, and B8 are read one by one and compared with the target borehole number. Only when all are consistent is the worksheet considered to have passed verification. If the comparison result of any cell is inconsistent, an undo command is triggered, restoring the entire data table file to the initial snapshot state.

[0140] Suppose that the content of a cell in another worksheet becomes SD0001 due to a formatting issue, with a character length of 6, which is not equal to the character length of 7 of the target borehole number. Therefore, the comparison result is determined to be inconsistent, triggering an undo command, restoring the data table file to a backup copy, and recording the cell update anomaly in the verification file.

[0141] This step ensures the uniqueness of the number replacement source by uniformly managing the mapping relationship through a cache queue, ensures the atomicity of the rewrite operation by writing locks, and ensures the integrity of the data table file by creating an initial snapshot, writing back for verification, and an automatic restoration mechanism. This provides a verified data table file for the file system-level renaming in step S6.

[0142] S6: Based on the target borehole number, synchronously rename the prefix of the borehole subfolder and its internal files.

[0143] After the numbering within the data table file has been updated and the write-back verification has been completed in step S5, since the borehole number serves as both the name of the borehole subfolder and the prefix for the filenames of each file within it, it is also necessary to synchronously update the naming information at the file system level to ensure that the naming in the file system is consistent with the numbering within the data table file.

[0144] The specific implementation process for this step is as follows: First, obtain a list of all files within the drilling subfolder. Then, distinguish between spreadsheet files and non-spreadsheet files based on their file extensions. Non-spreadsheet files are those whose file extensions do not belong to the spreadsheet format extension set. The spreadsheet format extension set includes .xlsx and .xls extensions. Files not belonging to this set are non-spreadsheet files; for example, files with extensions like .jpg, .png, and .doc are all non-spreadsheet files.

[0145] Then, rename the data table files and non-data table files respectively.

[0146] For data table files, since the filename is simply the borehole number plus a spreadsheet format suffix, the original borehole number in the filename is directly replaced with the target borehole number, while keeping the format suffix unchanged. For example, if the original data table filename is 370102SK20230510D0003.xlsx, the replaced filename is SD00001.xlsx.

[0147] For non-data table files, obtain the original filename prefix of each non-data table file. The original filename prefix refers to the part of the filename before the last extension separator. For example, in the filename 370102SK20230510D0003_01.jpg, the last extension separator is the dot before .jpg, so the original filename prefix is ​​370102SK20230510D0003_01.

[0148] After obtaining the original file name prefix, it is necessary to determine whether the prefix is ​​associated with the original borehole number. The determination method is to perform substring inclusion matching between the original file name prefix and the original borehole number, that is, to check whether the original file name prefix contains the complete text of the original borehole number.

[0149] A successful match means that the file's naming rules follow the standard format of using the borehole number as the filename prefix, so a renaming operation needs to be performed; if the original filename prefix does not contain the complete text of the original borehole number, it is considered a failed match, indicating that the file's naming is unrelated to the borehole number, and the filename should remain unchanged.

[0150] When a match is successful, the part of the original filename prefix that matches the original borehole number is replaced with the target borehole number, while keeping the file extension unchanged.

[0151] It should be noted that the renaming operation targets the file entity itself in the file system, not the hyperlink text or file path references that may exist inside the data table file.

[0152] If a folder contains files named with both the new and old borehole numbers, only the files that match the original borehole number will be renamed; files that do not match will retain their original names. If the prefix of the original filename does not match the original borehole number, the filename will remain unchanged.

[0153] After renaming the internal files, update the name of the borehole subfolder itself from the original borehole number to the target borehole number.

[0154] In practical engineering applications, assuming the original borehole number is 370102SK20230510D0003 and the target borehole number is SD00001, the borehole subfolder contains a data table file 370102SK20230510D0003.xlsx and image files 370102SK20230510D0003_01.jpg to 370102SK20230510D0003_09.jpg, a total of 9 image files.

[0155] For the data table file 370102SK20230510D0003.xlsx, replace the original borehole number 370102SK20230510D0003 with the target borehole number SD00001, and rename the file to SD00001.xlsx.

[0156] For the image file 370102SK20230510D0003_01.jpg, the original filename prefix is ​​370102SK20230510D0003_01. The original borehole number 370102SK20230510D0003 is included in the original filename prefix, so the match is successful. Replace 370102SK20230510D0003 with SD00001, leaving _01 as the remaining part. The file extension is .jpg, so the renamed file is SD00001_01.jpg. Similarly, the nine image files are renamed from SD00001_01.jpg to SD00001_09.jpg, the data table file is renamed to SD00001.xlsx, and finally, the borehole subfolder name is changed from 370102SK20230510D0003 to SD00001.

[0157] After renaming all borehole subfolders, a verification file is automatically generated in the target folder. The verification file includes an error report file and a name change comparison file. The error report file records the names of borehole subfolders that encountered errors during the renaming process and the reasons for the errors. The name change comparison file records the correspondence between the original and new names of all borehole subfolders, facilitating user verification and subsequent backtracking.

[0158] This step combines file format suffix determination and filename prefix matching to achieve synchronous renaming of the drilling subfolder and its internal files. It also generates a proofreading file to provide users with a complete renaming record, thus completing the entire renaming process for this application.

[0159] This application also provides an automatic renaming system for a seismic safety evaluation borehole database, the system comprising: The determination module is used to determine the target folder and generate corresponding target borehole numbers for each borehole subfolder under the target folder based on the determined borehole starting number.

[0160] The traversal module is used to traverse the data table files in the borehole subfolder and store the coordinates of cells containing preset cross-hole reference keywords and neighboring cells into a protection whitelist.

[0161] The parsing module is used to parse the main table in the data table file, generate an identity feature fingerprint based on the spatial offset of the original borehole number in the main table relative to the table header, and analyze the reference relationship between each worksheet based on the identity feature fingerprint to construct a logical dependency graph.

[0162] The positioning module is used to navigate and locate the cell to be modified in each worksheet using identity feature fingerprints, determine whether the coordinates of the cell to be modified are outside the protection whitelist, and determine whether there is a reference relationship between the cell to be modified and the main table based on the logical dependency graph.

[0163] The update module is used to update the original borehole number in the cell to be modified to the target borehole number when it is determined that the cell to be modified is not in the protection whitelist and has a reference relationship with the main table.

[0164] The renaming module is used to synchronously rename the prefix of the borehole subfolder and its internal files based on the target borehole number.

[0165] The automatic renaming system for the seismic safety assessment borehole database in this application is used to implement the aforementioned automatic renaming method for the seismic safety assessment borehole database. Therefore, the specific implementation of the automatic renaming system for the seismic safety assessment borehole database can be found in the embodiment section of the automatic renaming method for the seismic safety assessment borehole database above. The specific implementation can be referred to the description of the corresponding embodiments, and will not be repeated here.

[0166] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the automatic renaming method for the seismic safety evaluation borehole database described above.

[0167] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for automatically renaming a borehole database for seismic safety evaluation.

[0168] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory, random access memory, portable hard drives, magnetic disks, or optical disks.

[0169] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the automatic renaming method for seismic safety evaluation borehole databases.

[0170] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0171] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with relevant laws, regulations, and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse. The above provides a detailed description of an automatic renaming method and system for a seismic safety evaluation borehole database provided by this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and its core ideas. It should be pointed out that for those skilled in the art, several improvements and modifications can be made to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. An automatic renaming method for a borehole database for seismic safety evaluation, characterized in that, include: Determine the target folder, and generate corresponding target borehole numbers for each borehole subfolder under the target folder based on the determined borehole starting number; Traverse the data table files in the borehole subfolder and store the coordinates of cells containing preset cross-hole reference keywords and their neighboring cells into the write protection whitelist; The main table in the data table file is parsed, the header label text associated with the original borehole number in the main table is extracted, the header label text is encapsulated as an identity feature fingerprint, and the cells containing the original borehole number are retrieved in each worksheet based on the identity feature fingerprint to construct a logical dependency graph. The identity feature fingerprint is used to navigate and locate the cell to be modified in each worksheet, and it is determined whether the coordinates of the cell to be modified are outside the write protection whitelist. The logical dependency graph is used to determine whether there is a reference association between the cell to be modified and the main table. When it is determined that the cell to be modified is not in the write protection whitelist and has a reference association with the main table, the original borehole number in the cell to be modified is updated to the target borehole number; Based on the target borehole number, the prefix of the borehole subfolder and its internal files are renamed synchronously.

2. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 1, characterized in that, The step of retrieving cells containing the original borehole number from each worksheet based on the identity feature fingerprint to construct a logical dependency graph includes: Using the identity feature fingerprint as the root node, scan the candidate regions in each worksheet that have the same associated title attribute as the identity feature fingerprint; Search the data cells in the candidate area for content that matches the original borehole number. If a match is found, establish a directional connection between the worksheet and the main table to generate a logical dependency graph.

3. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 1, characterized in that, The step of using the identity fingerprint to navigate and locate the cell to be modified in each worksheet includes: Parse the header structure of each worksheet and retrieve the navigation cell that matches the header label text in the identity feature fingerprint; Starting from the navigation cell, search for a cell that matches the original borehole number in the data row of the column where the navigation cell is located, or search for a cell that matches the original borehole number in the cell to the right of the row where the navigation cell is located. The matched cell is then identified as the cell to be modified.

4. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 1, characterized in that, Before updating the original borehole number in the cell to be modified to the target borehole number, the process also includes: A data format compatibility test is performed on the cell to be modified. The data format identifier of the cell to be modified is read, and it is determined whether the data type of the target borehole number is compatible with the data format identifier. If they are not compatible, the data format identifier of the cell to be modified is adjusted to a format that matches the data type of the target borehole number to ensure that the replaced target borehole number can be displayed correctly in the cell.

5. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 1, characterized in that, The step of updating the original borehole number in the cell to be modified to the target borehole number includes: Store the original borehole number and the target borehole number into a cache queue; After determining that the cell to be modified is not in the write protection whitelist and has a reference association with the main table, the write permission of the cell to be modified is locked, the content is rewritten according to the mapping relationship in the cache queue, and the spatial coordinate information of the successful rewriting is recorded.

6. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 1, characterized in that, Construct a write-protected whitelist, including: Traverse the text content in the data table file, and when a preset cross-hole reference feature word is identified, extract the row index of the cell where the preset cross-hole reference feature word is located; Add the coordinates of the entire row cell corresponding to the row index, as well as the coordinates of cells within a preset number of rows adjacent to the row index, to the write protection whitelist.

7. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 1, characterized in that, The step of extracting the header label text associated with the original borehole number in the main table and encapsulating the header label text into an identity feature fingerprint includes: Locate the target cell containing the original borehole number in the main table; The header labels associated with the target cell are retrieved as follows: for standard table format areas with headers at the top and data at the bottom, cells matching the preset set of numbered field labels are retrieved upwards from the column where the target cell is located as column labels; for key-value pair format areas with labels on the left and data on the right, cells matching the preset set of numbered field labels are retrieved to the left from the row where the target cell is located as row labels. The retrieved header label text content and the corresponding layout type are encapsulated together as an identity feature fingerprint.

8. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 5, characterized in that, Before updating the original borehole number in the cell to be modified to the target borehole number, the process also includes: Perform a complete binary copy of the current data table file, store the copy in the same directory as the original data table file and identify it with a preset suffix, as an initial snapshot; After updating the original borehole number in the cell to be modified to the target borehole number, the process also includes: Reload the updated data table file and extract the updated cell content based on the spatial coordinate information; The updated cell content is compared with the target borehole number. If the comparison results are inconsistent, an undo command is triggered to restore the data table file to the initial snapshot state before the update, and an anomaly identifier is recorded in the verification file.

9. The automatic renaming method for a borehole database for seismic safety evaluation according to claim 1, characterized in that, The step of synchronously renaming the prefix of the borehole subfolder and its internal files according to the target borehole number includes: Obtain the original filename prefix of the non-data table files within the borehole subfolder; The original file name prefix is ​​matched with the original borehole number. If the match is found, the original file name prefix is ​​replaced with the target borehole number, while keeping the file extension unchanged.

10. An automatic renaming system for a borehole database for seismic safety evaluation, characterized in that, include: The determination module is used to determine the target folder and generate corresponding target borehole numbers for each borehole subfolder under the target folder according to the determined borehole starting number; The traversal module is used to traverse the data table files in the borehole subfolder and store the coordinates of cells containing preset cross-hole reference keywords and neighboring cells into the write protection whitelist. The parsing module is used to parse the main table in the data table file, extract the header label text associated with the original borehole number in the main table, encapsulate the header label text into an identity feature fingerprint, and search for cells containing the original borehole number in each worksheet based on the identity feature fingerprint to construct a logical dependency graph. The positioning module is used to navigate and locate the cell to be modified in each worksheet using the identity feature fingerprint, and to determine whether the coordinates of the cell to be modified are outside the write protection whitelist, and to determine whether there is a reference association between the cell to be modified and the main table based on the logical dependency graph. The update module is used to update the original borehole number in the cell to be modified to the target borehole number when it is determined that the cell to be modified is not in the write protection whitelist and has a reference association with the main table. The renaming module is used to synchronously rename the prefix of the borehole subfolder and its internal files based on the target borehole number.

Images