A method for generating urban bridge models based on parameterized rules

Abstract

This invention discloses a method for generating urban bridge models based on parametric rule-driven principles, belonging to the field of bridge model generation technology. The method includes: S1, determining the workflow design mode and generating a skeleton model using different generation methods based on different design modes; S2, inputting the skeleton model into urban 3D modeling software and using CGA rules to drive the skeleton model to generate a 3D model of the bridge superstructure; S3, inputting the skeleton model into urban 3D modeling software and using CGA rules to drive the skeleton model to generate a 3D model of the bridge substructure; S4, using an interactive parameter adjustment interface to dynamically adjust the parameters of the 3D models of the bridge superstructure and substructure; and S5, outputting the adjusted 3D models of the bridge superstructure, substructure, and terrain layer as scene assets. This invention uses CGA rule code to achieve automated modeling, improving model generation efficiency and accuracy while reducing modeling costs and data delivery difficulty.

Description

Technical Field

[0001] This invention relates to the field of bridge model generation technology, and in particular to a method for generating urban bridge models based on parameterized rules. Background Technology

[0002] Digital twin technology, as the digital foundation for the development of smart cities and smart transportation, provides core support for the digital management of urban transportation infrastructure. Currently, transportation digital twin engineering is a labor- and technology-intensive industry, with model creation primarily relying on traditional 3D modeling software (such as Autodesk Civil3D and Bentley tools) or manual modeling methods. Existing solutions typically rely on design documents or remote sensing data, manually constructing 3D models of bridges step-by-step. For example, technicians must first process the bridge's horizontal and vertical design parameters, then model each component in BIM software; or they may use open-source geographic information systems (such as ArcGIS) to import satellite imagery and digital elevation models (DEMs), manually extracting the bridge outline and generating a preliminary model. While these methods can achieve model creation, they have significant drawbacks.

[0003] First, existing modeling technologies are inefficient and have a low return on investment. The modeling process relies heavily on manual intervention, such as drawing bridge centerlines point-by-point and manually adjusting model parameters, resulting in long modeling cycles and high costs. This is especially problematic for large urban bridge projects, which require collaboration among multiple technicians, easily introducing human error and leading to poor model consistency. Second, existing technologies lack flexibility and are ill-suited to different working conditions. For example, when bridge design documents are lacking, existing methods often fail to quickly generate accurate models; and for different superstructure types such as precast beams and cast-in-place beams, existing software lacks a unified parametric driving mechanism, making model adjustments difficult. Furthermore, existing technologies struggle to balance model accuracy and cost: manual modeling ensures accuracy but is time-consuming and labor-intensive; while automated tools (such as some GIS plugins) often sacrifice model details, failing to meet the high-precision requirements of digital twins. These problems stem from the fact that existing modeling paradigms lack a fully integrated parametric rule-driven process, failing to provide integrated processing for bridge skeleton generation, superstructure, substructure, and dynamic adjustments. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for generating urban bridge models based on parameterized rules.

[0005] The objective of this invention is achieved through the following technical solution: a method for generating urban bridge models based on parameterized rules, comprising the following steps:

[0006] S1. Design Pattern Identification and Skeleton Model Generation Stage: Identify the design patterns of the workflow and generate skeleton models using different generation methods based on different design patterns;

[0007] S2, Bridge Superstructure Generation Stage: Input the skeleton model into the urban 3D modeling software, and use CGA rules to drive the skeleton model to generate the 3D model of the bridge superstructure.

[0008] S3. Bridge Substructure Generation Stage: Input the skeleton model into the urban 3D modeling software, and use CGA rules to drive the skeleton model to generate a 3D model of the bridge substructure. The 3D model of the bridge substructure includes the bridge foundation structure and the bridge load-bearing structure.

[0009] S4. Parametric Adjustment Stage: Use the interactive parameter adjustment interface to dynamically adjust the parameters of the 3D model of the bridge superstructure and the 3D model of the bridge substructure.

[0010] S5. Model Data Output Stage: Output the adjusted 3D model of the bridge superstructure, the 3D model of the bridge substructure, and the terrain layer as scene assets.

[0011] Preferably, the design mode includes a first preset mode based on a design document and a second preset mode without a design document; when generating a skeleton model based on the first preset mode, the target parameters of the horizontal and vertical curves in the design document are read and the skeleton model is generated; when generating a skeleton model based on the second preset mode, the centerline of the bridge is initially modeled using open-source public data and then the skeleton model is generated.

[0012] Preferably, step S1 further includes the following step:

[0013] S1-1, Design mode determination steps: After the user determines the data production mode, if the user already has the horizontal and vertical design parameters of the target bridge, the first preset mode is selected; otherwise, the second preset mode is selected.

[0014] S1-2, Skeleton Model Generation Steps: When using the first preset mode, the user sorts out the geometric morphology information of each pile of the bridge design centerline according to the bridge design documents to generate the skeleton model; when using the second preset mode, the user collects publicly available satellite images and digital elevation models of the target road section, and outputs raster image data based on the geographic information system software, and then performs planar alignment prediction and longitudinal profile prediction to generate a pile-by-pile coordinate table, and then generates the skeleton model.

[0015] Preferably, the three-dimensional model of the bridge superstructure includes a three-dimensional model of the prefabricated bridge superstructure and a three-dimensional model of the cast-in-place bridge superstructure.

[0016] Preferably, the process of generating a 3D model of the prefabricated bridge superstructure includes the following steps:

[0017] S2-1-1, Skeleton Model Preprocessing Steps: Read the skeleton model using urban 3D modeling software, then simplify the number of geometric vertices by setting a threshold, then smooth and optimize the curve segments, and finally add lane models to the skeleton model to complete the preprocessing.

[0018] S2-1-2, Model Family Library Construction Steps: Create an assembly 3D model family library that includes precast small box girders, precast T-beams, precast hollow slab beams, concrete guardrails, and expansion joint models;

[0019] S2-1-3, Beam Model Generation Steps: Use CGA rule codes to drive the models in the assembly 3D model family library to generate a complete and continuous bridge beam model along the lane model;

[0020] S2-1-4, Road surface model generation steps: Generate a road surface model by referencing the target road construction rules;

[0021] S2-1-5, Steps for generating auxiliary structures: Write CGA rules to generate the expansion joint and guardrail models of the bridge respectively and reference them to the main rule to generate the expansion joint and guardrail models.

[0022] Preferably, the process of generating a three-dimensional model of the superstructure of a cast-in-place bridge includes the following steps:

[0023] S2-2-1, Skeleton Model Preprocessing Steps: Read the skeleton model using urban 3D modeling software, then simplify the number of geometric vertices by setting a threshold, then smooth and optimize the curve segments, and finally add lane models to the skeleton model to complete the preprocessing.

[0024] S2-2-2, Model Family Library Construction Steps: Create a 3D model family library for casting, including models of cast-in-place beam segments, concrete guardrails, and expansion joints;

[0025] S2-2-3, Beam Model Generation Steps: Use CGA rule codes to drive the on-site cast beam segment models in the cast-in-place 3D model family library to generate a complete and continuous bridge beam model along the lane model;

[0026] S2-2-4, Road surface model generation steps: Generate a road surface model by referencing the target road construction rules;

[0027] S2-2-5, Steps for generating auxiliary structures: Write CGA rules to generate the expansion joint and guardrail models of the bridge respectively and reference them to the main rule to generate the expansion joint and guardrail models.

[0028] Preferably, the process of generating the bridge foundation structure includes the following steps:

[0029] S3-1-1, Steps for generating the pier model: First, determine whether it is necessary to generate the pier model. If there is no pier structure, then it is not necessary to generate it. If it is necessary to generate the pier model, then use the cube construction function to generate the pier model.

[0030] S3-1-2, Pile Foundation Model Generation Steps: Generate the pile foundation model through the splitting operation and the cylinder constructor.

[0031] Preferably, the process of generating the bridge load-bearing structure includes the following steps:

[0032] S3-2-1, Pier Model Generation Steps: Use the segmentation operation to further subdivide the pier area on the z-axis; then determine the shape of the pier; when it is determined to be a circular cross-section, use the cylinder constructor function to generate the pier model; when it is determined to be a rectangular cross-section, use the cube constructor function to generate the pier model; when it is determined to be an irregular pier, use the irregular pier family model to place and complete the generation of the pier model.

[0033] S3-2-2, Steps for generating the cap beam model: Use the model placement function to place the cap beam family model to complete the generation of the cap beam model.

[0034] Preferably, the dynamically adjusted parameters in S4 include: longitudinal spacing parameters to control the spacing between the superstructure beams; beam length parameters to control the length of a single beam; pier body parameters to control the pier width, pier thickness, and pier depth; pier quantity parameters to control the number of piers; pile quantity parameters to control the number of piles; beam type parameters to control the switching between small box girder and T-beam types when generating a 3D model of the prefabricated bridge superstructure; pier type parameters to control the switching between circular, rectangular cross-section, and irregular pier types; and beam file path parameters and irregular pier file path parameters to control the model file path, so as to introduce model files with different appearance forms.

[0035] The beneficial effects of this invention are:

[0036] 1) This invention realizes the process of directly generating a three-dimensional digital twin model of a bridge from a skeleton model through programmed CGA rules. Compared with traditional three-dimensional digital twin modeling software and traditional road and bridge modeling methods, it has advantages in efficiency and cost, enabling technicians to quickly convert the bridge skeleton into a parametric model.

[0037] 2) This invention is highly flexible and provides generation modes for two types of superstructures, namely precast beams and cast-in-place beams, under different working conditions. It can also generate T-beam and small box girder models for different types of precast beams. For cast-in-place beams, it also provides a section replacement entry, which can generate cast-in-place beam models with different geometric shapes by only providing a standard section model.

[0038] 3) This invention decouples the superstructure and substructure of the bridge and the parameterized adjustment module through modular design, and maintains different modules through independent CGA code files, which improves scalability and overall system robustness, and prevents chain defects caused by errors in a single code file.

[0039] 4) This invention has wide applicability. Whether or not bridge design drawings are available, the creation of a digital twin model of a bridge can be achieved through step S1. In particular, for some old engineering projects that do not have electronic design drawings, the model creation cost is low. At the same time, when design drawings are available, the accuracy of the bridge model can be guaranteed.

[0040] 5) This invention is natively compatible with 3D geographic information systems, making data delivery easier. Unlike design software systems such as Autodesk and Bently, which often encounter data format compatibility issues and coordinate registration and conversion problems when delivering data to 3D geographic information systems (such as Cesium or ArcGIS), this method outputs multiple format types and can natively support ArcGIS or automatically calculate the center point of the project's geographic coordinate system using the coordinate system model center point conversion function built into CityEngine software. This allows for rapid geographic registration, shortens model deployment time, and reduces the difficulty of data delivery. Attached Figure Description

[0041] Figure 1 This is a flowchart illustrating the overall method of the present invention;

[0042] Figure 2 A schematic diagram of the beam segmentation logic for the superstructure of a prefabricated bridge.

[0043] Figure 3 This is a schematic diagram of the S2-1-3 process;

[0044] Figure 4 Generate a logical schematic diagram for the bridge substructure;

[0045] Figure 5 This is a schematic diagram of the dynamic parameter adjustment logic in S4;

[0046] Figure 6 Write a flowchart for the CGA rules of expansion joints;

[0047] Figure 7Write a flowchart for the CGA rules of the guardrail;

[0048] Figure 8 Write a logic diagram for the CGA rules of the beam model in S2-2-3;

[0049] Figure 9 This is a schematic diagram of a beam segment model;

[0050] Figure 10 Refer to the diagram for the geometric meaning of the pier column segmentation operation. Detailed Implementation

[0051] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] See Figures 1-10 This invention provides a technical solution: a method for generating urban bridge models based on parameterized rules, comprising the following steps:

[0053] S1. Design Pattern Identification and Skeleton Model Generation Stage: Identify the design patterns of the workflow and generate skeleton models using different generation methods based on different design patterns;

[0054] S2, Bridge Superstructure Generation Stage: Input the skeleton model into the urban 3D modeling software, and use CGA rules to drive the skeleton model to generate the 3D model of the bridge superstructure.

[0055] S3. Bridge Substructure Generation Stage: Input the skeleton model into the urban 3D modeling software, and use CGA rules to drive the skeleton model to generate a 3D model of the bridge substructure. The 3D model of the bridge substructure includes the bridge foundation structure and the bridge load-bearing structure.

[0056] S4. Parametric Adjustment Stage: Use the interactive parameter adjustment interface to dynamically adjust the parameters of the 3D model of the bridge superstructure and the 3D model of the bridge substructure.

[0057] S5. Model Data Output Stage: Output the adjusted 3D model of the bridge superstructure, the 3D model of the bridge substructure, and the terrain layer as scene assets.

[0058] In some embodiments, the design mode includes a first preset mode based on a design document and a second preset mode without a design document; when generating a skeleton model based on the first preset mode, the target parameters of the horizontal and vertical curves in the design document are read and the skeleton model is generated; when generating a skeleton model based on the second preset mode, the centerline of the bridge is initially modeled using open-source public data and then the skeleton model is generated.

[0059] In this embodiment, step S1: Design mode discrimination and model skeleton generation module. This module's main function is to generate skeleton vector elements for model generation. These elements are vector graphic data based on ArcGIS Shapefile format, with the format extension ".shp", denoted as the skeleton model. The design mode is determined by the design mode discrimination module. It determines whether the workflow's design mode is a modeling mode based on a design file (denoted as the first preset mode) or a modeling mode without a design file (denoted as the second preset mode). Based on the first preset mode, the target parameters of the horizontal and vertical curves in the design file are read, and a skeleton model is generated and output. The core feature of this vector data is that it carries Z-coordinates to store the elevation information of the coordinate points. Based on the second preset mode, the centerline of the bridge is initially modeled using open-source public data, and a skeleton model of the second preset mode is output, with the same characteristics as the skeleton model in the first preset mode.

[0060] Step S2: Bridge Superstructure Generation Module. Based on the skeleton model output from the first or second skeleton generation submodule, import it into CityEngine software and write code according to CGA rules and syntax to drive the skeleton model to generate a 3D model of the prefabricated or cast-in-place bridge superstructure. This module forms the modeling skeleton by inputting the skeleton model from Step S1, and sets two bridge superstructure generation methods according to actual business needs. Technicians can choose the type according to actual needs. The smallest functional unit of this module is a single polyline segment of the skeleton model, which is denoted as the first smallest functional primitive, and it is represented as the smallest selectable unit in CityEngine software. The engineering construction range targeted by this module in the process of outputting a single and complete bridge superstructure is denoted as the first output unit, characterized by a bridge engineering unit with an independent bridge centerline. This module includes a prefabricated bridge superstructure generation submodule and a cast-in-place bridge superstructure generation submodule.

[0061] Step S3: Substructure Generator. Based on the skeleton model output by the first or second skeleton generation submodule, import it into the CityEngine software and write code according to CGA rules and syntax to drive the skeleton model to generate a 3D model of the bridge substructure (i.e., piers). The 3D model includes the foundation structure and load-bearing structure. This module also forms a modeling skeleton by inputting the skeleton model from Step S1, and sets the method for generating bridge substructure components according to actual business needs. Technicians can select the type according to actual needs. The engineering construction range targeted by this module in the process of outputting a single and complete superstructure of a bridge is denoted as the second output unit, characterized by a bridge engineering unit with an independent bridge centerline. This module includes a foundation structure generation submodule and a load-bearing structure generation submodule. Due to the continuous vertical space of the piers, this solution integrates the CGA code required by the substructure generator into a single file to complete the generation of the substructure with complete and independent logic. The specific execution logic is as follows: Figure 4As shown. Similar to step S2-1-3, initial rule header declaration, global function declaration, and variable declaration are performed. The difference is that when declaring the global function, it is not necessary to declare the proportional calculation function. Instead, a pier width calculation function is declared to calculate the width of the substructure's outer envelope (the substructure's outer envelope is the smallest cube that completely encloses the complete and independent substructure). The logic is to obtain the transverse beam value through the middle beam counting function, multiply it by the beam width, and then subtract twice the fixed value q. The value of q is in the range [1, 2], which can be adjusted according to the bridge conditions. Its physical meaning is the width of the edge beam's flange. The variable declaration adds pier main parameters, representing the width, thickness, and depth of the substructure's outer envelope; adds pier type to represent the pier's geometric shape classification, including circular cross-section, rectangular cross-section, and irregular piers; adds the number of pier columns to control the number of pier columns generated; adds the number of pile foundations to control the number of pile foundations generated; and removes the two variables: the length of the second segment and the beam type. Unlike S2-1-3, this step performs U-axis segmentation based on the first lane model, using a form like "split(u){~W: Lower main body initialization|L: The splitting operation of "NIL}*" is performed to obtain the model of the sixth lane. Subsequently, the number of transverse beams is obtained by using the middle beam counting function, and then the pier width is counted by the pier width calculation function. Based on the main parameters of the pier (pier width, pier thickness, pier depth), the substructure is initialized. The method is to use the "center(xz)" function to center the envelope, and then use the "s(sx,sy,sz)" function to scale the size, with the scaling relationship satisfying sx=pier thickness, sy=pier depth, and sz=pier width. Then, based on the initialized envelope, the model is split along the y-axis using a splitting operation of the form "split(y){D1: cap beam model generation operation|D2: pier column model generation operation|D3: abutment model generation operation|D4: pile foundation model generation operation}", where D1 is the depth of the cap beam area; D2 is the depth of the pier column area; D3 is the depth of the abutment area; and D4 is the depth of the pile foundation area. Based on each depth region (including the cap beam region, pier region, abutment region, and pile foundation region), spatial scaling is performed on each region using the "s(sx,sy,sz)" function for size scaling. Subsequently, targeted model component generation operations are performed in each region to obtain the complete bridge substructure model. Refer to the complete flowchart for this step. Figure 4 .

[0062] Step S4: Parametric Adjuster. To facilitate real-time adjustment of some bridge structural parameters by technical personnel implementing modeling, an interactive port needs to be reserved during CGA code writing. This allows for dynamic parameter adjustment in the controller window located in the "inspector" after selecting the model. This solution provides interactive ports for the superstructure and substructure, including: longitudinal spacing parameters to control the spacing between superstructure beams; beam length parameters to control the length of a single beam; pier body parameters to control the pier width, thickness, and depth; pier quantity parameters to control the number of piers; pile quantity parameters to control the number of piles; beam type parameters to control the switching between small box girder and T-beam types when using the prefabricated bridge superstructure generation submodule; pier type parameters to control the switching between circular, rectangular cross-section, and irregular pier types; and beam file path parameters and irregular pier file path parameters to control the model file path, allowing the import of model files with different appearances. The specific execution logic of the parametric adjuster is as follows: Figure 5 .

[0063] Step S5: Model Data Output Module. The generated terrain models and related terrain layers from S2-S4 are output as scene assets. This primarily uses the CityEngine Python scripting library for export. The code "ce.getObjectsFrom(ce.scene)" defines the output model as all models in the current scene (i.e., the model retrieval domain is "ce.scene"). The output parameters are then limited using either "USDExportModelSettings()" or "UnrealExportModelSettings()". The former corresponds to the Ominiverse USD data exchange standard, and the latter to Unreal's DataSmith data exchange standard. Finally, the target model is output using ce.export({objects}, {settings}). The {objects} parameter corresponds to the selected model and DEM layer, while {settings} corresponds to the data output settings. Notably, technicians can choose other common output formats, such as obj, FBX, DAE, 3ds, etc., with the output method being the same as the scene asset output process described above, and will not be repeated here.

[0064] In some embodiments, S1 further includes the following step:

[0065] S1-1, Design mode determination steps: After the user determines the data production mode, if the user already has the horizontal and vertical design parameters of the target bridge, the first preset mode is selected; otherwise, the second preset mode is selected.

[0066] S1-2, Skeleton Model Generation Steps: When using the first preset mode, the user sorts out the geometric morphology information of each pile of the bridge design centerline according to the bridge design documents to generate the skeleton model; when using the second preset mode, the user collects publicly available satellite images and digital elevation models of the target road section, and outputs raster image data based on the geographic information system software, and then performs planar alignment prediction and longitudinal profile prediction to generate a pile-by-pile coordinate table, and then generates the skeleton model.

[0067] In this embodiment, step S1-1 is included: a design mode discrimination module. The design mode refers to the mode of the preliminary data production in the current design workflow, namely the first preset mode and the second preset mode in step S1. This module requires the user to judge and select the data production mode. If the user already has the horizontal and vertical design parameters of the target bridge, the first preset mode is selected; if the user does not have the horizontal and vertical design parameters of the target bridge, the second preset mode is selected.

[0068] Step S1-2: Skeleton Model Generation Module. The skeleton model generation module provides two generation modules for the first and second preset modes in Step S1, respectively denoted as the first skeleton generation module and the second skeleton generation module. These modules are used to handle the skeleton model generation tasks for bridges with and without horizontal and vertical design parameters. The skeleton model is a three-dimensional polyline segment formed by connecting the coordinates of the bridge centerline in three-dimensional space according to the station number sequence. The output format is the shapefile vector data described in Step S1. In the first preset mode, the user needs to organize the station-by-station geometric information of the bridge design centerline according to the bridge design documents, import it into the first skeleton generation module, and generate the skeleton model. In the second preset mode, the user needs to collect publicly available satellite imagery and publicly available digital elevation models (DEMs) of the target road section, output raster image data in .tif format using geographic information system software such as ArcGIS Pro or GeoScene, and import it into the second skeleton generation module for further horizontal alignment prediction and vertical profile prediction, thereby generating a station-by-station coordinate table and the skeleton model.

[0069] Step S1-2-1 First Skeleton Generation Module. This module constructs the skeleton model based on the horizontal and vertical parameters in the existing bridge design files. Specifically, firstly, the horizontal and vertical parameters of the road centerline are imported into Autodesk Civil3D software to generate a three-dimensional bridge centerline model. This model is then converted into a feature line using the "CreateFeatureLineFromAlign" command. Secondly, a sequence of point markers is generated along the feature line using the "Generate Points at Fixed Intervals" command, which is called "CreatePointMeasureObject". Subsequently, the point sequence is selected, and the "Export Points" tool is used to output the point sequence as a planar point coordinate file, using the "ExportPoints" command. The output planar coordinate file uses commas for delimitation and conforms to UTF-8 encoding. Its content, increasing in line number, represents the coordinate values ​​of each point, containing three columns representing the X, Y, and Z coordinates of the point, in meters. Based on the previous... The aforementioned planar point coordinate file is used to write a program using the csv module in the Python programming language. The function `writer.writerows(row_fields)` is used to inject the first row of field names Point_X, Point_Y, and Point_Z, separated by commas, corresponding to the aforementioned X, Y, and Z coordinate values ​​of the point. The input parameter `row_fields` should be in the form of `['Point_X','Point_Y','Point_Z']`. The aforementioned planar point coordinate file is then processed using the Python-based Arcpy library (hereinafter referred to as Arcpy), using the coordinate table turning line (the function call format is: `arcpy.management.XYTableToPoint(in_table, ...`). The function `out_feature_class, x_field, y_field, {z_field}, {coordinate_system}` takes the aforementioned planar point coordinate file as input and obtains a set of point coordinates for each station. The parameter `in_table` is the path to an input file in the form of ` / path / to / input / data / points.txt`, `out_feature_class` is the path to an output data file in the form of ` / path / to / output / data / points`, `x_field` is the name of the corresponding input X-coordinate field (i.e., the aforementioned `Point_X`), `y_field` is the name of the corresponding input Y-coordinate field (i.e., the aforementioned `Point_Y`), `{z_field}` is the name of the corresponding input Z-coordinate field (i.e., the aforementioned `Point_Z`), and `{coordinate_system}` is a parameter in the form of `arcpy`.The coordinate system parameters of "SpatialReference(4544,5737)" are used. Based on the aforementioned stake point coordinates, the skeleton model is obtained by inputting the aforementioned stake point coordinate set through the function "point set to line (function call form: arcpy.management.PointsToLine(Input_Features, Output_Feature_Class, {Line_Field}, {Sort_Field}, {Close_Line})". The parameter "Input_Features" is the input data path in the form of " / path / to / input / data / points", the parameter "Output_Feature_Class" is the output file path in the form of " / path / to / output / data / polyline.shp", the parameter "{Line_Field}" is the label field merged by field value, "{Sort_Field}" is the label field sorted for the point sequence, and "{Close_Line}" is the line segment closure identifier. For the input in the above Arcpy function... The usage of subsequent related functions for the output data path parameters is the same and will not be repeated here. Among the parameters of the called Arcpy function methods, parameters in the form of "{……}" are optional. Except for "{z_field}" and "{coordinate_system}" in the coordinate table turning lines, which need to be filled according to the coordinate parameters, the rest can be ignored. "..." will be used to refer to such ignorable parameters thereafter. Preferably, the skeleton models corresponding to bridge projects with different independent design centerlines need to be distinguished according to the mainline bridge and ramp bridges. The skeleton model corresponding to the mainline bridge is denoted as the first skeleton model, and the skeleton model corresponding to the ramp bridge is denoted as the second skeleton model. The first skeleton model and the second skeleton model are the skeleton models output by the first skeleton generation module.

[0070] Step S1-2-2: Second skeleton generation module. This module generates the skeleton model based on open-source data and rules. Specifically, firstly, relevant satellite orthophoto map (DOM) data for the project area is collected and downloaded from publicly available image sources such as Google Earth and Bing Maps. Simultaneously, digital elevation model (DEM) data, such as ALOS or ASTER-GDEM-V3, is obtained from data sources like ASF and EarthData. Then, Arcpy is used to import and project the aforementioned DOM and DEM data, storing it as raster data with a specific projection method and a file extension ".tif". In some scenarios, the coordinate system used will be based on the CGCS2000 geodetic datum and use the Gauss-Kruger projection, such as "CGCS2000 3 Degree GK CM 105E". All tools and processes involved in this solution are based on this coordinate system. Subsequently, the OpenStreetMap "overpass-api" interface is used with commands like: "curl -o . / test_map.osm The command "https: / / overpass-api.de / api / map?bbox=Left_X,Top_Y,Right_X,Bottom_Y" defines and downloads the map vector data of the target modeling area, outputting a vector file with the ".osm" extension. The "curl" command parameter "-o" is followed by a path and filename in the form ". / test_map.osm". The URL link uses HTTPS by default. The "bbox=Left_X,Top_Y,Right_X,Bottom_Y" at the end of the link defines the bounding box for the data request. "bbox" is short for bounding box. The four parameters "Left_X", "Top_Y", "Right_X", and "Bottom_Y" are the latitude and longitude coordinates of the easternmost, northernmost, westernmost, and southernmost points of the requested data's bounding box, respectively. These values ​​are floating-point numbers accurate to five decimal places. Except for these four coordinate parameters, the bounding box can be varied as needed. The remaining characters in the URL link are fixed and should not be changed. Then, the Arcpy function "arcpy.interop.QuickImport(input_osm, output_gdb)" is used to import the vector file with the ".osm" extension into the URL with the ".osm" extension.The database is labeled "gdb". Further, Arcpy's feature export function "arcpy.conversion.ExportFeatures(Input_Features, Output_Feature_Class,{where_clause}, ...)" is used to export bridge-related map data. This function is designated as the first export function. It requires the parameter "{where_clause}" to be set to "highway IS NOT NULL And other_tags LIKE '%bridge%'". The parameter "{where_clause}" is designated as the first input parameter, meaning that the "highway" field is not empty and "other_tags" contains the string "bridge". The purpose is to filter polyline elements of type highway that contain the bridge tag. The filtered and exported bridge map data is designated as the first bridge element. It should be noted that the input data path for this function should be the "map_lines" layer in the aforementioned ".gdb" database. Further, the exported bridge-related map data is segmented by sequentially using the first export function with the first input parameter set to "highway NOT LIKE '%link%'" and "highway LIKE...". The '%link%' parameter outputs two sets of data, denoted as the second and third bridge primitives, representing the main road bridge and the connecting ramp bridge, respectively. Further, Arcpy's graphics buffer function "arcpy.analysis.GraphicBuffer(Input_Features, Output_Feature_Class, buffer_distance_or_field, ...The first bridge primitive is used as input to perform buffer operations. The relevant redline index value is determined according to national standard GB / T51328-2018 and recorded as the first index. This first index value is then passed as a parameter to the "buffer_distance_or_field" parameter in the function to obtain the buffer area. Subsequently, the "Export Raster" pane is used with the buffer area as a mask to export only the DEM data within the buffer area and record its maximum elevation value Emax. The relevant under-bridge clearance index value is determined according to national standard GB / T 51328-2018 and recorded as the second index (or HBridge). Arcpy's constant raster creation function "CreateConstantRaster(constantValue, "FLOAT", cellSize,outExtent)" is used to create a constant raster with a value of V = Emax + HBridge. The "constantValue" parameter is specified as V, the "cellSize" parameter is generally set to 30, and the "outExtent" parameter is in the form of "Extent(Left_X, Top_Y,Right_X, The value in parentheses, "Bottom_Y", is consistent with the four parameters of the aforementioned bounding box. Finally, Arcpy's interpolation shape function "arcpy.ddd.InterpolateShape(in_surface, in_feature_class, out_feature_class, ...)" is used, with the first and second bridge primitives as input parameters "in_feature_class" and a constant raster as input parameter "in_surface", respectively, to obtain the first and second bridge primitives with elevation values, denoted as the third and fourth skeleton models. These third and fourth skeleton models are the skeleton models output by the second skeleton generation module.

[0071] In some embodiments, the three-dimensional model of the bridge superstructure includes a three-dimensional model of a prefabricated bridge superstructure and a three-dimensional model of a cast-in-place bridge superstructure.

[0072] In some embodiments, generating a three-dimensional model of the prefabricated bridge superstructure includes the following steps:

[0073] S2-1-1, Skeleton Model Preprocessing Steps: Read the skeleton model using urban 3D modeling software, then simplify the number of geometric vertices by setting a threshold, then smooth and optimize the curve segments, and finally add lane models to the skeleton model to complete the preprocessing.

[0074] S2-1-2, Model Family Library Construction Steps: Create an assembly 3D model family library that includes precast small box girders, precast T-beams, precast hollow slab beams, concrete guardrails, and expansion joint models;

[0075] S2-1-3, Beam Model Generation Steps: Use CGA rule codes to drive the models in the assembly 3D model family library to generate a complete and continuous bridge beam model along the lane model;

[0076] S2-1-4, Road surface model generation steps: Generate a road surface model by referencing the target road construction rules;

[0077] S2-1-5, Steps for generating auxiliary structures: Write CGA rules to generate the expansion joint and guardrail models of the bridge respectively and reference them to the main rule to generate the expansion joint and guardrail models.

[0078] In this embodiment, step S2-1 is included: a sub-module for generating prefabricated bridge superstructures. This module targets three types of bridge superstructures: prefabricated small box girders, prefabricated T-beams, and prefabricated slab girders, and is applicable to the first output unit of general straight sections or sections with large curvature radii. The module includes five sub-steps: skeleton model preprocessing, model family library construction, beam model generation, pavement model generation, and auxiliary structure generation. Details are as follows: Step S2-1-1: Skeleton model preprocessing. All skeleton models involved in step S1 are read using CityEngine software. Then, the number of geometric inflection points is simplified by setting a threshold. Subsequently, smoothing optimization is performed on curve segments. Finally, lane models are added to the skeleton model, thus completing the preprocessing. Specifically, import the skeleton model through the data import tab. The tab must check "Simplify Graphic Tools After Import" and "Map Shape FileAttributes" while unchecking other options. Click the "Finish" button to execute the import operation and obtain the imported skeleton model, denoted as the first skeleton layer. For the second and fourth skeleton models, ensure that the "Maximum Simplified Line Segment Length" in "Simplified Graphic Attributes" is set to 20-30 (meters), specifically determined based on the average spacing of the bridge openings of the ramp. Further, select the first skeleton layer and execute the "Set Curve Smoothing" operation under the "Graphics" tab, setting the smoothing threshold to 0.75~1 to obtain the smoothed first skeleton layer, denoted as the second skeleton layer. Based on the second skeleton layer, create a lane model using the default street template and set the lane model width according to the actual bridge width to obtain the lane model created based on the second skeleton layer, denoted as the first lane model.

[0079] Step S2-1-2: Model Family Library Construction. A model family library related to the bridge superstructure is created using 3D modeling software. These models include precast small box girders, precast T-beams, precast hollow slab beams, concrete railings, and expansion joints. Technicians can create these models using 3D parametric modeling software such as Revit, 3DS Max, and CATIA, and export them to a common 3D model interactive data format. The format must have the suffix ".gltf" or ".obj". Since there is a wealth of publicly available information on the specific operation methods for model creation in these software programs, this technical solution will not elaborate further. For the modeling dimensions of precast small box girders and precast T-beams, it is advisable to refer to the standards "Post-tensioned Prestressed Concrete Winged Box Girder" (JC / T 2506-2019) and "Prestressed Concrete T-beam" (JC / T 2506-2019). (2359-2016) The two beam models need to be divided into three segment models: front, middle, and rear. These are denoted as the first segment of the T-beam, the second segment of the T-beam, the third segment of the T-beam, the first segment of the small box girder, the second segment of the small box girder, and the third segment of the small box girder, respectively. See [link to specific segmentation logic] for details. Figure 2 The constructed concrete guardrail model is a 1-meter-long standard unit under a standard cross-section, and the dimensions of the standard cross-section refer to the standard "Design Specification for Highway Traffic Safety Facilities" (JT / G D81-2017); the precast hollow slab beam model is 15 meters long, and its appearance dimensions should refer to the standard "Prestressed Concrete Hollow Slab Beam of Pre-tensioned Method" (JC / T 2088-2011); the appearance dimensions of the expansion joint model should refer to the "General Technical Conditions for Expansion Joints of Highway Bridges" (JT / T 327-2016); the series of models described in this step are recorded as a model family library.

[0080] Step S2-1-3: Beam Model Generation. Based on the first lane model in Step S2-1-1, the CGA rule code drives the bridge type models involved in the model family library described in Step S2-1-2 to generate a complete and continuous bridge beam along the first lane model. The beam is a general term for the superstructure beam type entity without considering classification and segmentation. The CGA rule code is the core content driving model generation, and its writing logic is as follows: In the initial stage, declare the initial rule header of the file, use the keyword "extension" to indicate that this rule is an extension rule, and use "rulename-->rulename." to initialize the extension rule name (rulename). Then, use "@StartRule" as a guide to indicate the initial rule entry point and name the initial rule "Start". Subsequently, global function and variable declarations are performed. A "size acquisition function" is written, using the "assetInfo()" method to obtain the dimensions of the external family file along the z-axis. A "middle beam counting function" is written to calculate the number of middle beams outside the side beams. Side beams are a general term for beams placed on the left or right side of the bridge with wider outer flanges; they are further divided into left and right beams, with all beams outside being middle beams. The logic of the "middle beam counting function" is to obtain the width of the first lane model, subtract the x-axis width of the left and right side beams respectively, and divide the remaining value by the x-axis width of the middle beam family to obtain the counting result. The x-axis width of the beam is calculated using the "size acquisition function." A "half-length calculation function" is written to calculate the half-length of the beam. The logic is to obtain the z-axis length of the first segment of the T-beam or the first segment of the small box girder using the "size acquisition function," and record it as the first segment length. Simultaneously, the z-axis length of the second segment of the T-beam or the second segment of the small box girder is obtained, divided by two, and recorded as the second segment length. The first segment length is added to the second segment length, and the output result is recorded as the beam half-length. A "proportional calculation function" is written to calculate the ratio of the first, second, and third segments of the T-beam to the total length of the T-beam, or the ratio of the first, second, and third segments of the small box girder to the total length of the small box girder. Furthermore, the "const" keyword is used to declare the "longitudinal spacing," "family library file path," and "second segment length" to control subsequent calculations, and the "attr" keyword is used to declare the "beam type" parameter, including two enumerated values: "T-beam" and "small box girder," to control subsequent changes in beam type. In the above parameters, the longitudinal spacing is denoted as S, such as... Figure 2 As shown, the lengths of the first, second, and third segments are denoted as l1, l2, and l3, respectively. The length L of a single beam is defined as the sum of the lengths of the first, second, and third segments, i.e., L = l1 + l2 + l3. All of these are obtained through a dimension acquisition function. The lengths of the first and third segments are generally fixed, while the length of the second segment needs to be dynamically adjusted according to the actual length of the beam. Therefore, it is generally used as a variable to drive the dynamic change of the beam length L.

[0081] Furthermore, the beam half-length is calculated based on the half-length calculation function. Using this half-length as the segmentation length, a segmentation operation of the form “split(u){~W / 2: NIL|L / 2: NIL|d: Operation 1|L / 2: NIL|~W / 2: NIL}*” is used to subdivide the first lane model along the u-axis in the model's uv-axis system, i.e., along the axial direction of the skeleton model, according to the following formula 1: In the formula: S is the total length of the beam model unit along the u-axis of the first lane model in a single repetition; W is the distance between two beams along the u-axis of the first lane model; L is the length of any beam model along the u-axis of the first lane model; d is the minimum indivisible length along the u-axis of the first lane model, generally taken as d=0.001; the aforementioned segmentation code strictly follows the repetition of "half-length interval + half-length beam + minimum axial length + half-length beam + half-length interval" to achieve the repeated batch placement of the bridge superstructure, while segmenting with the minimum axial length. The obtained unit can be regarded as a normal line perpendicular to the u-axis. Placing the beam model within it can solve the problem of precise control of the beam direction. In the segmentation operation, "~" is the adaptive equal division operator. The algorithm automatically divides the part that cannot be divided evenly according to the situation. "NIL" is a placeholder that does no operation. "Operation 1" is the subsequent series of operations for beam generation. "|" is the operation separator. "*" is the automatic loop calculation operator, which means that the program will automatically repeat the division of the target geometry according to the rules until the geometry can no longer be subdivided. The "Operation 1" specifically involves using "alignScopeToGeometry(yUp,0,0)" to redistribute the axis system along the y-axis normal in the segmented region of length d (all subsequent modeling axis systems are y-axis upwards). This results in several uniformly distributed model planes on the first lane model, with z-axis length equal to the lane width and x-axis length equal to d, denoted as the second lane model. Further, a beam counting function is used with the width of the second lane model as input to determine the number of beams along the u-axis normal. If the number of beams is less than or equal to 3, the second lane model is designated as the third lane model; if the number of beams is greater than 3, the second lane model is designated as the fourth lane model. Subsequently, based on the third and fourth lane models, the input beam type parameters are determined to further use a size acquisition function to obtain the z-axis length (i.e., beam width) of the small box girder or T-beam. Based on the obtained z-axis length, a function of the form "split(v){s1: Operation 2|s2: Operation 3|……|sn: The segmentation operation "m" divides the third or fourth lane model along the v-axis (i.e., the direction perpendicular to the aforementioned u-axis); further, based on the above segmentation results, there are operations 2, 3...m in each segmented interval s1, s2...sn; all operations are based on obtaining the y-axis length (i.e., the height of each beam segment) of the second segment of the T-beam and the second segment of the small box girder based on the size acquisition function, and performing an axial offset along the y-axis based on the y-axis length, with the offset rule being an offset distance of its own height in the opposite direction of the y-axis (i.e., moving downwards and the amount of movement is the beam height).Based on the above operations, calculate the proportion of the front, middle, and rear segment models to the total beam length, and then proportionally arrange the third or fourth lane model along the x-axis in a manner resembling "split(x){'r1: segment layout|'r2: segment layout|'r3: The segmentation operation "}" performs x-axis segmentation and subsequent segment layout, where the "'" operator is the segmentation identifier according to the scaling factor, r1 is the ratio of the first segment of the T-beam or the first segment of the small box girder to the total beam length, r2 is the ratio of the second segment of the T-beam or the second segment of the small box girder to the total beam length, and r3 is the ratio of the third segment of the T-beam or the third segment of the small box girder to the total beam length. The segmented units are "XX beam Nth segmentation unit" and correspond to the area occupied by "XX beam Nth segment" ("XX" can be T-beam or small box girder, and N can be one, two, or three). The "segment layout" specifically controls "XX beam Nth segmentation unit" to use "s(sx)". The model is scaled using the function "sx, sy, sz" (where sx, sy, and sz represent the resulting dimensions along the x, y, and z axes, respectively). Then, it is moved spatially using the function "t(tx, ty, tz)" (where tx, ty, and tz represent the relative movement distances along the x, y, and z axes, respectively). Finally, it is placed using the function "i(" / path / to / file")" (where " / path / to / file" is the file path, typically the family library file path). This sequence of function executions is denoted as "XX Beam Segment Layout Function" (XX can be T-beam or small box girder). The result of the aforementioned "T-beam segment layout function" is a continuous T-beam or small box girder structure. The overall process for this step can be referenced. Figure 3 .

[0082] At the end of this step, technicians can add a function execution sequence to modify the texture of the model in the "XX beam segment layout function" as needed to achieve flexible texture adaptation. The method is to add a function like "setMaterial(" / path / to / file")" after the "XX beam segment layout function" (" / path / to / file" is the file path, generally the path of the material texture file is passed in).

[0083] Finally, the CGA rule file described in step S2-1-3 (with the file extension ".cga") needs to be added as a sub-rule, and referenced in the middle and at the end of the main rule file. These are respectively referred to as the first reference addition operation and the second reference addition operation. The method for the first reference addition operation is to add something like "import Rule_Name : "path / to / rule / file / rule.cga" in the middle of the main rule file. The rule import content is defined as follows: {parameter1=assignment1, parameter2=assignment2……parametern=assignmentn, rulename-->LinkRule.start}. Here, "import" is the import keyword, "Rule_Name" is the custom extended rule name, "path / to / rule / file / rule.cga" is the path to the referenced extended rule file, and an expression like "parameterx=assignmentx" represents the initial assignment of the parameter. "rulename-->LinkRule.start" indicates adding a chain reference to the extended rule named "rulename," associating it with other extended rules. "LinkRule.start" refers to the other rules that are chained together. The second reference addition operation involves adding a line of code like "rulename.Start" to the end of the main rule file, ensuring that "rulename" is added to the end of the referenced sub-rules (the last one or more functions or methods in the execution logic order) to close the extended rule loop. The "rulename" is not fixed and can be modified by technical personnel according to requirements.

[0084] Step S2-1-4: Road Surface Model Generation. The road surface generation module mainly generates a road surface model that floats on the second lane model. This is achieved by using the target road construction rule provided by the ESRI.lib library in CityEngine, such as "Street_Modern_Standard.cga," and referencing it as a node rule. The referencing method involves adding an extension header "extension rulename --> rulename." to the header of the target road construction rule to be referenced, and then performing a first reference addition operation and a second reference addition operation based on the target road construction rule in the main rule file.

[0085] Step S2-1-5: Generation of Auxiliary Structures. Write CGA rules for generating the bridge's expansion joints and guardrails respectively, and reference them to the main rule. For specific instructions on writing CGA rules for expansion joints, refer to [link to relevant documentation]. Figure 6This diagram is formed based on the execution logic of the first part of step S2-1-3. The difference is that when declaring the global environment, the middle beam counting function and the proportion calculation function are removed, and a joint length calculation function is added; when declaring the variable, only the family library file path is declared and a joint spacing variable is added; after the initial rule, the joint length calculation function is directly used to calculate the joint length; after the shaft system is assigned, the output result is recorded as the third lane model; then the model layout function is directly written to lay out the model, and the completed expansion joint model is output, which ends the process. The joint length calculation function is related to the joint spacing. A joint refers to all bridge structures along the line between two expansion joints in bridge engineering, typically called a joint. The joint length is the distance along the line between the two expansion joints. Further, the joint length calculation function calculates the joint length by multiplying the result by 6 after calculating the half-length of the beam using the half-length calculation function. The U-axis segmentation logic is similar to steps S2-1-3 and will not be elaborated further. The third lane model, divided by the joint length as the evenly distributed spacing, is similar to the second lane model; the former is only used for generating the expansion joint model. The model layout function logic is to obtain the v-axis length (lane width) of the third lane model, then use the "s(sx,sy,sz)" function for scaling, and use the "i(" / path / to / file")" function to access the expansion joint library file for model placement, thus completing the model generation. For specific execution methods of writing CGA rules for guardrails, refer to... Figure 7 This image is by Figure 6Derived from this, the difference is that after the joint length calculation function is executed, the U-axis segmentation of the second lane model does not need to use the minimum normal parameter. The segmentation should use a segmentation operation of the form "split(u){Du:V-axis segmentation operation}*", where Du is the joint length. Further, based on the aforementioned V-axis segmentation result, a V-axis segmentation operation is performed, i.e., using a segmentation operation of the form "split(u){Dv:UV insertion operation|space:NIL|Dv:insert along UV}", where Dv is the width of the concrete guardrail model along the V-axis direction, and space is the road surface area, which is left untouched. Further, the fourth lane model is obtained through axis system allocation, using "insertAlongUV(uvSet, filePath, height, The function "heightDirection,heightAlignment)" inserts the concrete guardrail model along the fourth lane model, thus completing the creation of the continuous guardrail model. In the above function, the parameter "uvSet" is the UV layer index with a value range of [0,9], which is generally 0 by default. The parameter "filePath" is the file path, which can be directly placed in the family library file path. The parameter "hight" is the normal height of the model along the UV plane, which is the height value of the guardrail model. The parameter "heightDirection" is filled with scope.y by default, and the parameter "heightAlignment" is filled with alignPosition by default.

[0086] In some embodiments, generating a three-dimensional model of the superstructure of a cast-in-place bridge includes the following steps:

[0087] S2-2-1, Skeleton Model Preprocessing Steps: Read the skeleton model using urban 3D modeling software, then simplify the number of geometric vertices by setting a threshold, then smooth and optimize the curve segments, and finally add lane models to the skeleton model to complete the preprocessing.

[0088] S2-2-2, Model Family Library Construction Steps: Create a 3D model family library for casting, including models of cast-in-place beam segments, concrete guardrails, and expansion joints;

[0089] S2-2-3, Beam Model Generation Steps: Use CGA rule codes to drive the on-site cast beam segment models in the cast-in-place 3D model family library to generate a complete and continuous bridge beam model along the lane model;

[0090] S2-2-4, Road surface model generation steps: Generate a road surface model by referencing the target road construction rules;

[0091] S2-2-5, Steps for generating auxiliary structures: Write CGA rules to generate the expansion joint and guardrail models of the bridge respectively and reference them to the main rule to generate the expansion joint and guardrail models.

[0092] In this embodiment, step S2-2-1 is included: skeleton model preprocessing. The method is the same as step S2-1-1. It should be noted that cast-in-place bridges should have independent skeleton models, and the preprocessing result of the skeleton model is also the first lane model.

[0093] Step S2-2-2: Model Family Library Construction. The construction method and reference standards for the family library are the same as in Step S2-1-2. The content of the family library creation includes: cast-in-place beam segments, concrete guardrails, and expansion joints. The functions of the concrete guardrails and expansion joints are the same as in S2-1. The cast-in-place beam segments are 1-meter-long segments along the skeleton model direction. Their typical cross-sections should refer to the standard "Post-tensioned Prestressed Concrete Winged Box Girder" (JC / T 2506-2019). Standard segment models of different sizes should be constructed as needed for subsequent calls. It should be noted that the origin of the axis system of the beam segment model should be located at the intersection of the upper surface of the beam and the center line of the beam segment. Specifically, as shown below... Figure 9 As shown.

[0094] Step S2-2-3: Beam Model Generation. Based on the first lane model in Step S2-2-1, the CGA rule code drives the standard segment model described in Step S2-2-2, generating a complete and continuous bridge beam along the first lane model. The CGA rule code is the core content driving model generation, and its writing logic is similar to that of the guardrail CGA rule writing logic described in S2-1-5. For specific methods, refer to... Figure 7 It can be derived to Figure 8 The differences are as follows: After the length calculation function, the U-axis is directly segmented, and the size acquisition function is used to obtain the width of the standard segment model and control the axis system allocation accordingly, thereby obtaining the fifth lane model; based on the fifth lane model, the standard segment model is inserted along the fifth lane model using the "insertAlongUV(uvSet, filePath, height, heightDirection,heightAlignment)" UV insertion function, and then the creation of the continuous cast-in-place beam model is completed.

[0095] Step S2-2-4: Road surface model generation. The method is the same as step S2-1-4;

[0096] Step S2-2-5: Generation of auxiliary structures. The method is the same as step S2-1-5.

[0097] In some embodiments, generating a bridge foundation structure includes the following steps:

[0098] S3-1-1, Steps for generating the pier model: First, determine whether it is necessary to generate the pier model. If there is no pier structure, then it is not necessary to generate it. If it is necessary to generate the pier model, then use the cube construction function to generate the pier model.

[0099] S3-1-2, Pile Foundation Model Generation Steps: Generate the pile foundation model through the splitting operation and the cylinder constructor.

[0100] In some embodiments, generating a bridge load-bearing structure includes the following steps:

[0101] S3-2-1, Pier Model Generation Steps: Use the segmentation operation to further subdivide the pier area on the z-axis; then determine the shape of the pier; when it is determined to be a circular cross-section, use the cylinder constructor function to generate the pier model; when it is determined to be a rectangular cross-section, use the cube constructor function to generate the pier model; when it is determined to be an irregular pier, use the irregular pier family model to place and complete the generation of the pier model.

[0102] S3-2-2, Steps for generating the cap beam model: Use the model placement function to place the cap beam family model to complete the generation of the cap beam model.

[0103] In this embodiment, step S3-1 is included: the basic structure generation module. The bridge foundation structure includes pile foundations and abutments. After the spatial scaling operation described in step S3, the process continues to refer to... Figure 4 The operation is performed via the "Basic Structure Branch" path, as follows:

[0104] Step S3-1-1: Foundation Model Generation. Since the foundation is not a necessary component, a logical judgment is made as to whether foundation generation is required. If there is no foundation structure, it is determined that no generation is needed, and the relevant operations are replaced with the "NIL" placeholder, thus ending the branch loop. If a foundation model needs to be generated, a cube construction function of the form "primitiveCube(width, height, depth)" is used to generate a foundation model in cube shape with the corresponding width, height, and depth, thus completing the generation of this part of the foundation model.

[0105] Step S3-1-2: Generation of Pile Foundation Model. Pile foundations are generally matrix-like regularly distributed entities. Therefore, the pile foundation area needs to be further subdivided along the x-axis and z-axis. The x-axis is divided using a split operation of the form "split(x){~dx: z-axis split operation}*", and the z-axis is divided using a split operation of the form "split(z){~dz: pile foundation construction operation}*". dx is the spacing along the x-axis, and dz is the spacing along the z-axis. The pile foundation construction operation uses a cylinder constructor of the form "primitiveCylinder(sides, radius, height)" to generate cylinders with the corresponding number of sides (sides), radius (radius), and height (height). The number of sides is kept at 16 by default, thus completing the generation of this part of the pile foundation model.

[0106] Step S3-2: Load-bearing structure generation module. The bridge load-bearing structure includes cap beams and piers. After the spatial scaling operation described in step S3, continue to refer to... Figure 4 Perform the operation on the "Bearing Structure Branch" path as follows:

[0107] Step S3-2-1: Pier Model Generation. The piers are horizontally arranged columns, therefore the pier region needs to be further subdivided along the z-axis. A typical segmentation operation is used, such as “split(z){~dv1:NIL|dr:pier construction operation|dv2:NIL|dr:pier construction operation|~dv1:NIL}”, where the geometric meanings of dv1, dr, and dv2 are as follows... Figure 10 Technicians can repeat the first set of dr and dv2 structures according to the number of piers, and control the number of piers through program logic. Furthermore, the pier construction operation requires first judging the shape of the pier. When it is judged to be a circular cross section, a cylinder constructor function in the form of "primitiveCylinder(sides, radius, height)" is used to generate a cylinder with the corresponding number of sides, radius, and height, where the number of sides is kept at 16 by default. When it is a rectangular cross section, a cube constructor function in the form of "primitiveCube(width, height, depth)" is used to generate a cube with the corresponding width, height, and depth. When it is judged to be an irregular pier, a function in the form of "i(" / path / to / file")" (" / path / to / file" is the file path) is used to place the irregular pier family model, thus completing the generation of the pier model.

[0108] Step S3-2-2: Generation of the cap beam model. Place the cap beam family model according to the cap beam region using a function of the form "i(" / path / to / file")" (where " / path / to / file" is the file path), thus completing the generation of the cap beam model.

[0109] In some embodiments, the parameters dynamically adjusted in S4 include: longitudinal spacing parameters to control the spacing between superstructure beams; beam length parameters to control the length of a single beam; pier body parameters to control the pier width, pier thickness, and pier depth; pier quantity parameters to control the number of piers; pile quantity parameters to control the number of piles; beam type parameters to control the switching between small box girder and T-beam types when generating a 3D model of the prefabricated bridge superstructure; pier type parameters to control the switching between circular, rectangular cross-section, and irregular pier types; and beam file path parameters and irregular pier file path parameters to control the model file path, thereby introducing model files with different appearances.

[0110] In this embodiment, step S4-1: Upper structure adjustment module. Logic is written according to the CGA rules described in S2, which distinguishes between main rules, sub-rules, etc. All logic in this part is based on the main rule, and the main rule header corresponding to S2 is denoted as the first initial rule header. The variables of the sub-rules are introduced in the first initial rule header: longitudinal spacing, beam type, family library file path, and second segment length; then the controlled parameters are explicitly declared by type: floating-point parameters include longitudinal spacing parameters and beam length parameters, enumerated parameters include beam type parameters, and string parameters include beam file path parameters; then the variables of the introduced sub-rules are replaced with parameters; the upper structure is used as a group, and the group name "upper structure adjustment module" and group number 1 are declared using the form "@Group("upper structure adjustment module", 1)"; then "@Order(11)", "@Range(min=0.05, max=1, stepsize=0.001, restricted=false)", "attr longitudinal spacing= 0.1” declares that the longitudinal spacing parameter is group 1, the serial number of the group is 1, the parameter is a floating-point range value with a minimum of 0.05 meters, a maximum of 1 meter, and an interval of 0.001 meters and does not force the approximate value, the parameter name is “Longitudinal Spacing” (Chinese characters can be used), and the default value of the parameter is 0.1 meters; further, in three lines, “@Order(12)”, “@Range(min=5, max=30, stepsize=0.1, restricted=false)”, “attr Second Segment Length = 20” declares that the second segment length parameter is group 1, the serial number of the group is 2, the parameter is a floating-point range value with a minimum of 5 meters, a maximum of 30 meters, and an interval of 0.1 meters and does not force the approximate value, the parameter name is “Second Segment Length”, and the default value of the parameter is 20 meters; further, in three lines, “@Order(13)”, “@Enum(“Small Box Girder”, “T-beam”)”, “attr Beam Type = The "small box girder" parameter is declared as group 1, with the number 3 in the group. The parameter is an enumeration type with two values: "small box girder" and "T-beam". The parameter name is "beam type" and the default value is "small box girder". Further, the "@Order(14)", "@File", and "attr" parameters are used in three lines to declare the family library file path parameter as group 1, with the number 4 in the group. The parameter type is file type, the parameter name is "beam file path", and the default value is " / path / to / file.obj".

[0111] Step S4-2: Lower Structure Adjustment Module. The logic is written according to the CGA rules described in S3, with distinctions between main rules and sub-rules. All logic in this section is based on the main rule, and the main rule header corresponding to S3 is denoted as the second initial rule header. The variables of the sub-rules are introduced in the second initial rule header: pier width, pier thickness, pier depth, number of piers, number of pile foundations, pier type, and family library file path; then the controlled parameters are explicitly declared by type, floating-point parameters include pier width, pier thickness, pier depth, number of piers, and number of pile foundations, enumerated parameters include pier type, and string parameters include pier file path; then the variables of the introduced sub-rules are replaced with parameters; the upper structure is used as a group, and the group name of the lower structure adjustment module, "lower structure adjustment module", and the group number 2 are declared using "@Group("lower structure adjustment module", 2)"; then "@Order(21)", "@Range(min=5, max=50, stepsize=0.1, restricted=false)", "attr pier width= 10” declares that the pier width parameter is grouped into 2, with the sequence number 1 within the group. The parameter is a floating-point range of minimum 5 meters, maximum 50 meters, and interval of 0.1 meters, and does not force approximation. The parameter name is “pier width” and the default value is 10 meters. Further, “@Order(22)”, “@Range(min=1, max=5, stepsize=0.01, restricted=false)”, and “attr pier thickness= 2” declare that the pier thickness parameter is grouped into 2, with the sequence number 2 within the group. The parameter is a floating-point range of minimum 1 meter, maximum 5 meters, and interval of 0.01 meters, and does not force approximation. The parameter name is “pier thickness” and the default value is 2 meters. Further, “@Order(23)”, “@Range(min=20, max=200, stepsize=0.1, restricted=false)”, and “attr pier depth= The 40” statement declares that the pier depth parameter is group 2, with the sequence number 3 within group 2, and the parameter is a floating-point range of minimum 20 meters, maximum 200 meters, and interval 0.1 meter and does not force approximation, parameter name is "pier depth" parameter default value is 40 meters; further, in three lines, use "@Order(24)", "@Range(min=2, max=6,stepsize=1, restricted=true)", "attr pier number = 2" to declare the pier number parameter group as 2, the sequence number in the group is 4, the parameter is a floating point range value minimum 2, maximum 6, interval 1 and force approximation, parameter name is "pile foundation number" parameter default value is 2; further, in three lines, use "@Order(25)", "@Range(min=2, max=8, stepsize=1, restricted=true)", "attr pile foundation number = 4” declares the pile foundation quantity parameter as group 2, with the serial number 5 in group 2. The parameter is a floating-point range of 2 minimum, 8 maximum, 1 interval and forced approximation value. The parameter name is “Pile Foundation Quantity” and the default value is 4. Further, in three lines, “@Order(26)”, “@Enum(“Cylindrical Pier”, “Square Pier”, “Irregular Pier”)” and “attr Pier Type = “Cylindrical Pier”” declare the beam type parameter as group 2, with the serial number 6 in group 6. The parameter is an enumeration type with three values: “Cylindrical Pier”, “Square Pier”, and “Irregular Pier”. The parameter name is “Pier Type” and the default value is “Cylindrical Pier”. Further, in three lines, “@Order(27)”, “@File”, and “attr Irregular Pier File Path = The " / path / to / file.obj" parameter declares the library file path parameter as group 2, index 7 within group 2, as a file type, named "Irregular Pier File Path", and with a default value of " / path / to / file.obj".

[0112] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for generating urban bridge models based on parameterized rules, characterized in that: Includes the following steps: S1. Design Pattern Identification and Skeleton Model Generation Stage: Identify the design patterns of the workflow and generate skeleton models using different generation methods based on different design patterns; S2, Bridge Superstructure Generation Stage: Input the skeleton model into the urban 3D modeling software, and use CGA rules to drive the skeleton model to generate the 3D model of the bridge superstructure. S3. Bridge Substructure Generation Stage: Input the skeleton model into the urban 3D modeling software, and use CGA rules to drive the skeleton model to generate a 3D model of the bridge substructure. The 3D model of the bridge substructure includes the bridge foundation structure and the bridge load-bearing structure. S4. Parametric Adjustment Stage: Use the interactive parameter adjustment interface to dynamically adjust the parameters of the 3D model of the bridge superstructure and the 3D model of the bridge substructure. S5. Model Data Output Stage: Output the adjusted 3D model of the bridge superstructure, the 3D model of the bridge substructure, and the terrain layer as scene assets; The design modes include a first preset mode based on design documents and a second preset mode without design documents; When generating the skeleton model based on the first preset mode, the target parameters of the horizontal and vertical curves in the design file are read and the skeleton model is generated. When generating the skeleton model based on the second preset mode, the centerline of the bridge is initially modeled using open-source public data to generate the skeleton model. The S1 further includes the following steps: S1-1, Design mode determination steps: After the user determines the data production mode, if the user already has the horizontal and vertical design parameters of the target bridge, the first preset mode is selected; otherwise, the second preset mode is selected. S1-2, Skeleton Model Generation Steps: When using the first preset mode, the user sorts out the geometric morphology information of each pile of the bridge design centerline according to the bridge design documents to generate the skeleton model; when using the second preset mode, the user collects publicly available satellite images and digital elevation models of the target road section, and outputs raster image data based on the geographic information system software, and then performs planar alignment prediction and longitudinal profile prediction to generate a pile-by-pile coordinate table, and then generates the skeleton model.

2. The method for generating urban bridge models based on parameterized rules according to claim 1, characterized in that: The aforementioned three-dimensional models of bridge superstructures include three-dimensional models of prefabricated bridge superstructures and three-dimensional models of cast-in-place bridge superstructures.

3. The method for generating urban bridge models based on parameterized rules according to claim 2, characterized in that: The steps involved in generating a 3D model of the superstructure of a prefabricated bridge are as follows: S2-1-1, Skeleton Model Preprocessing Steps: Read the skeleton model using urban 3D modeling software, then simplify the number of geometric vertices by setting a threshold, then smooth and optimize the curve segments, and finally add lane models to the skeleton model to complete the preprocessing. S2-1-2, Model Family Library Construction Steps: Create an assembly 3D model family library that includes precast small box girders, precast T-beams, precast hollow slab beams, concrete guardrails, and expansion joint models; S2-1-3, Beam Model Generation Steps: Use CGA rule codes to drive the models in the assembly 3D model family library to generate a complete and continuous bridge beam model along the lane model; S2-1-4, Road surface model generation steps: Generate a road surface model by referencing the target road construction rules; S2-1-5, Steps for generating auxiliary structures: Write CGA rules to generate the expansion joint and guardrail models of the bridge respectively and reference them to the main rule to generate the expansion joint and guardrail models.

4. The method for generating urban bridge models based on parameterized rules according to claim 2, characterized in that: When generating a 3D model of the superstructure of a cast-in-place bridge, the following steps are included: S2-2-1, Skeleton Model Preprocessing Steps: Read the skeleton model using urban 3D modeling software, then simplify the number of geometric vertices by setting a threshold, then smooth and optimize the curve segments, and finally add lane models to the skeleton model to complete the preprocessing. S2-2-2, Model Family Library Construction Steps: Create a 3D model family library for casting, including models of cast-in-place beam segments, concrete guardrails, and expansion joints; S2-2-3, Beam Model Generation Steps: Use CGA rule codes to drive the on-site cast beam segment models in the cast-in-place 3D model family library to generate a complete and continuous bridge beam model along the lane model; S2-2-4, Road surface model generation steps: Generate a road surface model by referencing the target road construction rules; S2-2-5, Steps for generating auxiliary structures: Write CGA rules to generate the expansion joint and guardrail models of the bridge respectively and reference them to the main rule to generate the expansion joint and guardrail models.

5. The method for generating urban bridge models based on parameterized rules according to claim 1, characterized in that: The steps involved in generating the bridge foundation structure are as follows: S3-1-1, Steps for generating the pier model: First, determine whether it is necessary to generate the pier model. If there is no pier structure, then it is not necessary to generate it. If it is necessary to generate the pier model, then use the cube construction function to generate the pier model. S3-1-2, Pile Foundation Model Generation Steps: Generate the pile foundation model through the splitting operation and the cylinder constructor.

6. The method for generating urban bridge models based on parameterized rules according to claim 1, characterized in that: The steps involved in generating the load-bearing structure of a bridge are as follows: S3-2-1, Pier Model Generation Steps: Use the segmentation operation to further subdivide the pier area on the z-axis; then determine the shape of the pier; when it is determined to be a circular cross-section, use the cylinder constructor function to generate the pier model; when it is determined to be a rectangular cross-section, use the cube constructor function to generate the pier model; when it is determined to be an irregular pier, use the irregular pier family model to place and complete the generation of the pier model. S3-2-2, Steps for generating the cap beam model: Use the model placement function to place the cap beam family model to complete the generation of the cap beam model.

7. The method for generating urban bridge models based on parameterized rules according to claim 1, characterized in that: The dynamically adjusted parameters in S4 include: longitudinal spacing parameters to control the spacing between superstructure beams; beam length parameters to control the length of a single beam; pier body parameters to control the pier width, thickness, and depth; pier quantity parameters to control the number of piers; pile quantity parameters to control the number of piles; beam type parameters to control the switching between small box girder and T-beam types when generating a 3D model of the prefabricated bridge superstructure; pier type parameters to control the switching between circular, rectangular cross-section, and irregular pier types; and beam file path parameters and irregular pier file path parameters to control the model file path, allowing the introduction of model files with different appearances.

Images