A multi-source heterogeneous spatio-temporal data fusion modeling method and system

Abstract

The application relates to a multi-source heterogeneous space-time data fusion modeling method and system, which comprises the following steps: creating a root directory as a physical address of a space data model on a computer system; creating subdirectories corresponding to various storage object types under the structure of the root directory as physical addresses of the storage object types; the storage object types comprise vector data, two-dimensional raster data and three-dimensional model data; adding related data of the various storage object types in a core metadata system table; newly creating database files corresponding to the storage object types under the various subdirectories and initializing the database files, and generating exclusive metadata tables corresponding to the storage object types in the database files; obtaining two-dimensional and three-dimensional joint data of a real scene three-dimensional scene as to-be-stored data; based on the type of the to-be-stored data, calling corresponding data conversion tools to convert the to-be-stored data, storing the to-be-stored data in corresponding database files through corresponding storage modes, and associating the to-be-stored data with the exclusive metadata tables in the database files.

Description

Technical Field

[0001] This application relates to the field of data fusion technology, and in particular to a multi-source heterogeneous spatiotemporal data fusion modeling method and system. Background Technology

[0002] With the rapid development of smart city and digital twin technologies, multi-source heterogeneous spatiotemporal data is experiencing explosive growth, encompassing multimodal data sources such as vector data, 2D raster data, and 3D model data. Existing spatiotemporal data models face significant bottlenecks in cross-dimensional representation and heterogeneous data fusion: 2D data is primarily based on planar topology, while 3D models emphasize solid geometric structural features. The two differ significantly in spatiotemporal benchmarks, semantic representation, and accuracy levels, severely restricting collaborative analysis capabilities in fields such as natural resource monitoring and urban emergency management.

[0003] The core problem of existing spatiotemporal data models lies in the dimensional fragmentation of storage architecture and the static nature of fusion mechanisms. Current mainstream storage models are mostly designed around a single dimension, with limited cross-modal collaborative capabilities. Taking two-dimensional models as an example, while standards such as OGC GeoPackage and Esri Shapefile support vector and raster data, they struggle to directly represent three-dimensional entities. Three-dimensional meshes or point clouds often need to be converted into raster tiles or external extensions, compromising data integrity. In contrast, three-dimensional models such as SuperMap S3M and Cesium 3D Tiles optimize rendering efficiency but lack spatial analysis interfaces (e.g., S3M cannot perform built-in buffer calculations), leading to a disconnect between visualization and computation. While BIM-IFC possesses detailed semantic attributes, it lacks geographic coordinate alignment capabilities, requiring manual registration of geometry and attributes for GIS data integration, resulting in high integration costs.

[0004] At the data fusion level, there is a significant mismatch between CityGML's multi-level semantic structure and the oblique photogrammetry mesh model, particularly in terms of lightweight representation and real-time rendering, which are difficult to integrate and often require manual model simplification. Indoor space models, such as IndoorGML, lack dynamic binding to the geographic coordinate system, necessitate repeated coordinate system conversions for unified analysis across floors or with outdoor spaces. Furthermore, while common architectural design data (such as IFC and CAD) are semantically complete, they are difficult to directly embed into GIS platforms, requiring manual alignment of structured attributes with the geographic baseline for fusion analysis. Overall, current data models cannot support unified parsing and inference of multi-dimensional spatiotemporal data, resulting in low fusion efficiency. Summary of the Invention

[0005] To at least partially overcome the problem that data models in related technologies cannot support unified analysis and reasoning of multi-dimensional spatiotemporal data and have low fusion efficiency, this application provides a multi-source heterogeneous spatiotemporal data fusion modeling method and system.

[0006] The proposed solution is as follows:

[0007] According to a first aspect of the embodiments of this application, a method for multi-source heterogeneous spatiotemporal data fusion modeling is provided, comprising:

[0008] Create a root directory on the computer system as the physical address of the spatial data model;

[0009] Create a core metadata system table in the root directory and manage it globally based on the database file;

[0010] Under the root directory structure, subdirectories corresponding to each storage object type are created as the physical addresses of the storage object types; the storage object types include: vector data, two-dimensional raster data, and three-dimensional model data; each subdirectory is independent of the others.

[0011] Add relevant data for each storage object type to the core metadata system table;

[0012] Create and initialize database files corresponding to the storage object types in each subdirectory, and generate dedicated metadata tables for the storage object types in the database files;

[0013] The combined 2D and 3D data of the real-world 3D scene is acquired as the data to be stored. Based on the type of the data to be stored, the corresponding data conversion tool is called to convert the data to be stored. The data is then stored in the corresponding database file using the corresponding storage method and associated with the dedicated metadata table in the database file.

[0014] Among them, vector data is stored as Feature storage; two-dimensional raster data is stored as Raster storage; and three-dimensional model data is stored as Scene storage.

[0015] Preferably, the method further includes:

[0016] Receive data access requests, locate the target stored data according to the data access requests, and obtain the type, physical address and dedicated metadata table of the target stored data;

[0017] The corresponding driver is invoked based on the type of the target stored data, and the target stored data is accessed based on its physical address and dedicated metadata table.

[0018] Preferably, the core metadata system table includes a storage definition table, a storage type definition table, a data-driven table, a spatial reference system table, and a server configuration information table;

[0019] The storage definition table, storage type definition table, data-driven table, spatial reference system table, and server configuration information table all include multiple fixed fields and multiple expandable fields;

[0020] The storage definition table serves as the unified registration center for the spatial data model. It is initially empty, and records are dynamically inserted when a new storage object is created, thereby synchronizing storage creation with metadata registration.

[0021] The storage type definition table uses an extension mechanism to support the integration and management of new storage types;

[0022] The data-driven table provides differentiated data parsing, format conversion, and access services for different storage types through a dynamic registration mechanism;

[0023] The aforementioned spatial reference system table, through its multi-format compatible design, enables the fusion and cross-platform parsing of two-dimensional and three-dimensional data under a unified spatial benchmark;

[0024] The server configuration information table uses key-value storage and a driver binding mechanism to support on-demand dynamic loading of service parameters and driver-level differentiated configuration.

[0025] Preferably, the database file is used to manage the stored data and the relationships between the data;

[0026] Different types of stored objects have different data storage rules.

[0027] Preferably, the data storage rules for vector data include:

[0028] All data is stored in a Feature database file;

[0029] The data storage rules for two-dimensional raster data include:

[0030] A dedicated metadata table is stored in a Raster database file;

[0031] Create parallel subdirectories for the Raster database files to store raster data files or tile slice files;

[0032] The data storage rules for 3D model data include:

[0033] Store a dedicated metadata table in a Scene database file;

[0034] Create parallel subdirectories for the Scene database files to store 3D model files, material / texture files, and other dependent resources, while maintaining the original directory structure of the 3D model files to preserve the dependencies between resources.

[0035] Preferably, the design rules for metadata tables differ depending on the storage method.

[0036] Preferably, the design rules for the metadata table of Feature storage include:

[0037] Construct a vector dataset table as the logical management unit for vector data, and configure the logical hierarchy of vector data among storage, datasets, and layers;

[0038] A vector dataset type table is constructed as the core registry for vector data, permissions are bound, and a JSON dynamic expansion mechanism is configured.

[0039] A vector data type table is constructed as a standard library for vector data, and a unified registration and standardized management of basic and custom types of vector data is achieved through a JSON dynamic definition mechanism.

[0040] A vector layer table is constructed as a layer registry center for vector data, and a dynamic registration mechanism is used to manage layer-level metadata, spatial indexing, and version tracking of newly added vector data.

[0041] A vector data list is constructed as the core metadata table of the spatial data model, which undertakes the functions of standardizing the definition and dynamic management of the attribute structure of vector data layers. The vector data list realizes the automatic registration of newly added vector data table structures, value domain consistency and business logic integration through field-level atomic control, constraint linkage and semantic mapping.

[0042] A vector data space list is constructed as the central hub for the multidimensional geometric representation of the spatial data model; the vector data space list is configured with a mechanism for the coexistence of multiple geometric columns in the same vector layer, dynamic coordinate system adaptation, and a hybrid indexing strategy.

[0043] A vector data spatial range statistics table is constructed as a dynamic range indexing engine for the spatial data model; the vector data spatial range statistics table is configured with an automated range calculation and dynamic update mechanism;

[0044] The design rules for Raster storage's metadata tables include:

[0045] A raster dataset table is constructed as the logical management center for two-dimensional raster data; unified registration and spatiotemporal organization of raster data are achieved through path rules and multi-level type encoding.

[0046] Construct a raster dataset type table as a standard definition library for two-dimensional raster datasets;

[0047] A raster data type table is constructed as the basic type library for the two-dimensional raster data model; the raster data type table is configured with a JSON dynamic definition mechanism and a strong type association mechanism.

[0048] A raster dataset layer table is constructed as the core table for two-dimensional raster data. The raster dataset layer table realizes unified layer registration, standardized service publishing, and metadata management from raw satellite imagery to real-time raster products through strong binding of physical paths and spatial references, decoupling of service paths, and dynamic metadata extension.

[0049] A raster layer extended information table is constructed as a record table for extended information of two-dimensional raster data; the raster layer extended information table provides metadata support for remote sensing image analysis and digital terrain applications through dual storage of pyramid information and precise spatial range and scientific statistical pre-calculation;

[0050] The design rules for the metadata tables in Scene storage include:

[0051] A 3D model dataset table is constructed as the logical management unit for the 3D scene;

[0052] Construct a 3D model dataset type table as the registration center for 3D model dataset types;

[0053] Construct a 3D model data type table to define the basic 3D type system;

[0054] A 3D model layer table is constructed as a layer-level registry center for 3D model data. A dynamic registration mechanism is configured to realize layer-level metadata management, spatial indexing, and version tracking of newly added 3D model data.

[0055] Construct a 3D model table to store the 3D model of the assembled mesh material and its binary content;

[0056] Create a 3D model material table to store the 3D model material data;

[0057] A 3D model texture table is constructed to store the texture map content associated with the materials;

[0058] A 3D model mesh table is constructed to store the 3D model mesh data.

[0059] Preferably, storing vector data into the corresponding database file via Feature storage includes:

[0060] Create or associate a dataset record in the vector dataset table and designate it as the first target data;

[0061] Create a layer record for the first target data in the vector layer table, store the first target data in the vector layer table, and associate it with the dataset ID to which it belongs;

[0062] Fill the target data layer record metadata into the vector data list, vector data space list, and vector data space attribute table, and associate the first target data with the layer ID in the vector layer table;

[0063] Two-dimensional raster data is stored in the corresponding database file using Raster storage, including:

[0064] Copy / move raster files to a subdirectory alongside the Raster database file, or migrate the complete directory structure of a slice set to a subdirectory alongside the Raster database file;

[0065] Create or associate a dataset record in a raster dataset table as the second target data;

[0066] Create a layer record for the second target data in the raster dataset layer table, store the second target data in the raster dataset layer table, and associate it with the dataset ID to which it belongs;

[0067] Write the parameters of the second target data into the raster layer extended information table, and associate the layer ID of the second target data in the raster dataset layer table;

[0068] The 3D model data is stored in the corresponding database file through Scene storage, including:

[0069] Copy / move the 3D model resource directory of the 3D model data to a subdirectory adjacent to the Scene database file, and maintain the original file structure and resource dependencies of the 3D model data through metadata table mapping;

[0070] Create or associate a dataset record as third-party target data in the 3D scene dataset table;

[0071] Create a layer record for the third target data in the 3D model layer table, store the third target metadata in the 3D model layer table, and associate it with the dataset ID to which it belongs;

[0072] Add the 3D model of the third target data to the 3D model table, create a record for each model file in the dataset directory, and associate it with the 3D layer ID to which it belongs;

[0073] Add the material information of the 3D model to the 3D model material table, and associate the model ID of the third target data in the 3D model table;

[0074] Add the texture information of the 3D model to the 3D model texture table and associate the material ID of the third target data in the 3D model material table;

[0075] Add the mesh information of the 3D model to the 3D model mesh table, and associate the model ID of the third target data in the 3D model table;

[0076] If a binary model file is embedded within the texture, the offset within the binary model file is recorded in the 3D model table.

[0077] Preferably, the corresponding driver is invoked according to the type of the target stored data, and the target stored data is accessed according to its physical address and dedicated metadata table, including:

[0078] If the target stored data is vector data, read the Feature database file and use the vector dataset table and vector layer table to locate the target stored data;

[0079] If the target stored data is two-dimensional raster data, read the Raster database file and locate the target stored data through the raster dataset table and the raster dataset layer table;

[0080] If the target stored data is 3D model data, read the Scene database file and locate the target stored data using the 3D model dataset table and the 3D model layer table.

[0081] According to a second aspect of the embodiments of this application, a multi-source heterogeneous spatiotemporal data fusion modeling system is provided, comprising:

[0082] Processor and memory;

[0083] The processor and memory are connected via a communication bus:

[0084] The processor is used to call and execute the program stored in the memory;

[0085] The memory is used to store a program, which is at least used to execute a multi-source heterogeneous spatiotemporal data fusion modeling method as described in any of the above.

[0086] The technical solution provided in this application may include the following beneficial effects:

[0087] The spatial data model framework in this application stores vector data, two-dimensional raster data, and three-dimensional model data through three physical storage schemes, respectively. This adapts to the physical storage needs of multi-source heterogeneous data, effectively overcomes the limitations of previous spatial data models that only stored three-dimensional models, and can be flexibly expanded through these three basic storage schemes to be compatible with more data formats.

[0088] Generate a dedicated metadata table for each type of stored object in the database file so that data access can be performed based on the metadata. This ensures complete loading and lossless exchange of 3D resources, solves the problem of data loss that occurred when using 2D data models to store 3D model data, and realizes a unified and reliable service data interface for cross-modal data.

[0089] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0090] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0091] Figure 1 This is a flowchart illustrating a multi-source heterogeneous spatiotemporal data fusion modeling method provided in one embodiment of this application;

[0092] Figure 2 This is a schematic diagram of the structure of a multi-source heterogeneous spatiotemporal data fusion modeling system provided in one embodiment of this application.

[0093] Reference numerals: Processor-21; Memory-22. Detailed Implementation

[0094] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0095] Example 1

[0096] Figure 1 This is a flowchart illustrating a multi-source heterogeneous spatiotemporal data fusion modeling method according to an embodiment of this application. (Refer to...) Figure 1 A multi-source heterogeneous spatiotemporal data fusion modeling method, comprising:

[0097] S11: Create a root directory on the computer system as the physical address of the spatial data model;

[0098] S12: Create core metadata system tables in the root directory for global management based on database files;

[0099] S13: Under the root directory structure, create subdirectories corresponding to each storage object type, which serve as the physical addresses of the storage object types; the storage object types include: vector data, two-dimensional raster data, and three-dimensional model data; each subdirectory is independent of the others;

[0100] S14: Add relevant data for each storage object type to the core metadata system tables;

[0101] S15: Create and initialize database files corresponding to the storage object types in each subdirectory, and generate exclusive metadata tables corresponding to the storage object types in the database files;

[0102] S16: Obtain the combined 2D and 3D data of the real-world 3D scene as the data to be stored. Based on the type of the data to be stored, call the corresponding data conversion tool to convert the data to be stored, store it in the corresponding database file through the corresponding storage method, and associate it with the dedicated metadata table in the database file.

[0103] Among them, vector data is stored as Feature storage; two-dimensional raster data is stored as Raster storage; and three-dimensional model data is stored as Scene storage.

[0104] In this embodiment, the spatial data model framework stores vector data, two-dimensional raster data, and three-dimensional model data through three physical storage schemes, respectively. This adapts to the physical storage requirements of multi-source heterogeneous data, effectively overcoming the limitations of previous spatial data models that only stored three-dimensional models. Furthermore, these three basic storage schemes can be flexibly expanded to be compatible with more data formats.

[0105] It should be noted that the method also includes:

[0106] Receive data access requests, locate the target stored data according to the data access requests, and obtain the type, physical address and dedicated metadata table of the target stored data;

[0107] The corresponding driver is invoked based on the type of the target stored data, and the target stored data is accessed based on its physical address and dedicated metadata table.

[0108] Specifically, if the target stored data is vector data, the Feature database file is read, and the target stored data is located using the vector dataset table and the vector layer table;

[0109] If the target stored data is two-dimensional raster data, read the Raster database file and locate the target stored data through the raster dataset table and the raster dataset layer table;

[0110] If the target stored data is 3D model data, read the Scene database file and locate the target stored data using the 3D model dataset table and the 3D model layer table.

[0111] When accessing data, data can be accessed based on metadata, ensuring complete loading and lossless exchange of 3D resources. This solves the problem of data loss that occurred when using 2D data models to store 3D model data, and realizes a unified and reliable service data interface for cross-modal data.

[0112] It should be noted that the core metadata system tables include storage definition tables, storage type definition tables, data driver tables, spatial reference system tables, and server configuration information tables;

[0113] The storage definition table, storage type definition table, data-driven table, spatial reference system table, and server configuration information table all include multiple fixed fields and multiple expandable fields;

[0114] The storage definition table serves as the unified registration center for the spatial data model. It is initially empty, and records are dynamically inserted when a new storage object is created, thereby synchronizing storage creation with metadata registration.

[0115] The storage type definition table uses an extension mechanism to support the integration and management of new storage types;

[0116] Data-driven tables provide differentiated data parsing, format conversion, and access services for different storage types through a dynamic registration mechanism;

[0117] The spatial reference system table, through its multi-format compatible design, enables the fusion and cross-platform parsing of two-dimensional and three-dimensional data under a unified spatial benchmark;

[0118] The server configuration information table uses key-value storage and a driver binding mechanism to support on-demand dynamic loading of service parameters and driver-level differentiated configuration.

[0119] Specifically:

[0120] (1) The storage definition table (uss_meta_storages) serves as the unified registry center for the data model. Its core contains six fixed fields: storageid (globally unique identifier for the storage object), storagename (user-defined storage name), storagetype (associated with Feature / Raster / Scene type identifiers), storeversion (format version), physicalpath (physical path pointing to a dedicated subdirectory or file), and datapath (external access path). It also includes four extensible fields: storeversion supplements storage format version details, description records storage description information, storeinfo stores custom extended metadata in JSON format, and driveruuid binds to a dedicated data driver. This table is initially empty and records are dynamically inserted only when a new storage object is created, synchronizing storage creation with metadata registration.

[0121] (2) The storage type definition table (uss_meta_storage_types) serves as the type registration center for the data model. It contains four fixed fields: typeid (globally unique identifier of storage type), storecode (storage type code, a total of 3 digits, the first digit is the identifier code and the last two digits are the sequence code), typename (storage type name), and description (storage function description), which are used to define basic storage type templates (such as Feature-vector storage / Raster-2D raster tile storage / Scene-3D model storage). At the same time, four extensible fields are designed: subtype (storage subtype), permission (type-level operation permission), definition (JSON format extension definition), and extension (mark whether it is a custom extension type), which support the integration and management of new storage types through the extension mechanism.

[0122] (3) The data-driven table (uss_meta_storage_drivers) serves as the driver registration hub for the data model. Its core includes four fixed fields: driverid (globally unique identifier for driver type), storecode (storage type code associated with the previous table, a total of 3 digits, the first digit being the identifier and the last two digits being the sequence code), drivername (driver name), and driverversion (driver version information), which are used to bind storage type and data read / write capabilities. At the same time, four types of extensible fields are designed: owner (driver owner), description (functional description), driverinfo (extended parsing parameters), and metadata (driver metadata), which provide differentiated data parsing, format conversion, and access service capabilities for different storage types (such as Feature driver for parsing Shapefile / Scene driver for parsing DTS) through a dynamic registration mechanism.

[0123] (4) The spatial reference system table (uss_meta_srs) serves as the spatial reference registry for the data model. Its core contains four fixed fields: srsid (coordinate system standard ID, such as EPSG:4326), srsname (spatial reference name), type (coordinate system type: Geographic / Projected / Custom), and wkt (OGC WKT definition), which are used to standardize the management of geospatial references. At the same time, six types of extensible fields are designed: description (coordinate system description), js (JavaScript engine definition), esri (ESRI compatible WKT), proj4 (Proj4 parameter definition), unit (unit: metre / degree / unknown), and organization (standard organization name, such as EPSG / ESRI). Through multi-format compatibility design, it realizes accurate fusion and cross-platform parsing of two-dimensional and three-dimensional data under a unified spatial reference.

[0124] (5) The server configuration information table (uss_meta_server) serves as the management center for server runtime parameters. The core contains 5 fixed fields: serverid (unique identifier of configuration item), servername (parameter name), type (configuration type), value (actual value of parameter), and drivername (bound data driver name, realizing driver-level parameter customization), which are used to centrally manage server runtime configuration. At the same time, 2 types of extensible fields are designed: description (parameter function description) and displayorder (configuration item sorting number).

[0125] It should be noted that database files are used to manage the stored data and the relationships between the data;

[0126] Different types of stored objects have different data storage rules.

[0127] The data storage rules for vector data include:

[0128] All data is stored in a Feature database file;

[0129] The Feature database file contains all subsequently generated proprietary metadata tables and possible vector feature tables. This type of storage uses database files to store all data; there is no external data appended.

[0130] The data storage rules for two-dimensional raster data include:

[0131] A dedicated metadata table is stored in a Raster database file;

[0132] Create parallel subdirectories for the Raster database files to store raster data files or tile slice files;

[0133] The Raster database file stores a dedicated metadata table. Additionally, several parallel subdirectories are created within the directory containing the Raster database file (e.g., / project.uss / Raster_Storage / RasterDataSet1 / ).

[0134] The directory ` / project.uss / Raster_Storage / RasterDataSet2 / ` is used to store raster data files (such as TIFF) or tile files. Its organization is optional. It can be stored hierarchically according to "satellite type / acquisition time" (e.g., ` / RasterDataSet1 / Landsat8 / 20230701 / `, ` / RasterDataSet1 / Sentinel2 / 20230702 / `), or it can follow the original directory structure of the tile set data (e.g., ` / RasterDataSet2 / Tiles_WebMercator / 15 / 1234 / 5678.png`).

[0135] The data storage rules for 3D model data include:

[0136] Store a dedicated metadata table in a Scene database file;

[0137] Create parallel subdirectories for the Scene database files to store 3D model files, material / texture files, and other dependent resources, while maintaining the original directory structure of the 3D model files to preserve the dependencies between resources.

[0138] The Scene database file stores a dedicated metadata table. In addition, several parallel subdirectories are created under the directory where the Scene database file is located (such as / project.uss / Scene_Storage / Materials / , / project.uss / Scene_Storage / Models / ). These directories are used to store 3D model files (.obj, .fbx, .3dtiles, .gltf, etc.), material / texture files (.jpg, .png, etc.), and other dependent resources as is, and the original directory structure is basically maintained to maintain the dependencies between resources.

[0139] It should be noted that the design rules for metadata tables differ depending on the storage method.

[0140] Specifically:

[0141] 1. Feature storage (SQLite files in subdirectories, such as FeatureMeta.db):

[0142] 1) The vector dataset table (uss_feature_datasets) serves as the logical management unit for vector data. Its core contains three fixed fields: datasetid (unique identifier of the dataset), datasetname (dataset name), and datasettype (dataset type, such as "general vector" / "address" / "geocoding"), which are used to organize vector data in a structured manner. At the same time, two types of extensible fields are designed: subtype (subtype extension, such as extending the point type to "simple model") and description (dataset functional description). Through type hierarchy, the vector data can be accurately located and managed in the logical hierarchy of storage -> dataset -> layer.

[0143] 2) The vector dataset type table (uss_feature_datasettypes) serves as the core registry for vector data types. It contains two fixed fields: datasettypeid (a unique identifier for the type) and datasetname (the type name, such as "address dataset" / "place name dataset"), used to standardize the definition of vector dataset type templates. It also includes four extensible fields: definition (JSON structured storage extension definition), permission (permission identifier, such as 'r' for read / 'w' for write / 'x' for execute, with the combined value 'rw' indicating read / write capability), description (detailed type description), and extension (marker indicating whether it is a custom extension type). Through permission binding and a dynamic JSON extension mechanism, it enables fine-grained control and flexible expansion capabilities for vector dataset types.

[0144] 3) The vector data type table (uss_feature_datatypes) serves as the standard library for vector data types. Its core contains three fixed fields: datatypeid (a unique identifier for the data type), datasettype (associated with the dataset type name in the second point of the Feature storage, such as "address dataset" / "place name dataset"), and datatypename (the basic type name, such as "point" / "line" / "polygon"), used to define the basic geometric type system for vector data. It also includes four extensible fields: description (detailed type description), definition (JSON structured storage extension parameters, such as topology rules), owner (type standard owner, such as OGC / EPSG), and extension (marks whether it is a custom extension type). Through a dynamic JSON definition mechanism, it achieves unified registration and standardized management of basic types and custom types (such as "simple building model" extended from the "point" type).

[0145] 4) The vector layer table (uss_feature_dataset_layers) serves as the layer registration center for vector data. Its core contains five fixed fields: layerid (unique layer identifier), datasetid (dataset ID associated with the first point of the aforementioned Feature storage), layername (layer name / physical table name), oidcolumn (feature object ID column name), and defaultgeocolumn (default geometry column name, defaulting to 'geo'), used to establish the mapping relationship between datasets and physical layers. Simultaneously, four extensible fields are designed: typecodecolumn (feature type code field name, supporting UInt32 classification), totalfeatures (total number of layer features), description (layer business description), and versioninfo (version change record). Through a dynamic registration mechanism, it enables layer-level metadata management, spatial index optimization, and version tracking capabilities for newly added vector data.

[0146] 5) The vector data list (uss_feature_columns) serves as the core metadata table of the spatial data model, undertaking the standardized definition and dynamic management of the vector layer attribute structure. Its four fixed field layers construct the basic framework for field registration through columnid (globally unique field identifier), layerid (strongly associated layer ID), columnname (unique naming constraint within the layer), and columntype (bound to enumeration types such as integer / character / BLOB). The extension layer integrates 15 fields, functionally divided into three control dimensions: data integrity dimension (isnullable null value access switch: 0 forbid / 1 for allow, isprimarykey primary key identifier, allowblank enhanced non-null check, fielddomain value domain dictionary constraint), storage definition dimension (columnlength maximum character byte length, decimallength floating-point decimal precision, defaultvalue default value injection mechanism), and business semantic dimension (fieldcode function encoding, description business semantic description, displayorder interface rendering sequence number, extendinfo extended information). This table achieves automated registration of newly added vector data table structures, strong consistency of value domains, and seamless integration of business logic through field-level atomic control (such as isprimarykey=1 triggering the construction of a unique index in the database), constraint linkage (such as allowblank=0+isnullable=0 forming double non-null protection), and semantic mapping (such as fieldcode="ROAD_LEVEL" automatically associating with road classification rules). It provides accurate metadata support for spatial-attribute joint queries (such as "retrieving roads with elevation > 100 meters").

[0147] 6) The vector data spatial list (uss_feature_geometry_columns) serves as the central hub for the multidimensional geometric representation of the spatial data model. It constructs the basic framework for geometric storage through three fixed fields: geocolumnid (globally unique identifier of the geometric column), layerid (ID of the associated layer), and geocolumn (physical name of the geometric column). The extended layer integrates 10 fields to achieve integrated control of two-dimensional and three-dimensional data: spatial reference (srsid associated with coordinate system definition), geometric type (datatype basic type + subtype / subtype2 two-level extended types, such as "point → simple building model"), storage format (storagetype supports WKB / WKT / BINARY), dimension marker (z elevation attribute / m temperature and other extended attributes), and spatial index (rindex / hindex / mindex activate R-tree / H3 grid / Mercator subdivision index respectively). This table achieves unified management of multiple representation forms of a single element (such as storing two-dimensional line shapes and three-dimensional lane models for road elements) through a multi-geometric column coexistence mechanism (such as a layer containing "planar coordinate geometry column" and "3D model geometry column"), dynamic coordinate system adaptation (each geometry column is independently bound to srsid) and a hybrid indexing strategy. It completely breaks through the limitations of traditional single geometry columns and provides native data support for cross-dimensional spatial analysis (such as two-dimensional planar measurement and three-dimensional visibility analysis).

[0148] 7) The vector data spatial extent statistics table (uss_feature_geometry_stats) serves as the dynamic extent indexing engine for the spatial data model. It constructs a spatial extent management framework using fixed fields: id (unique identifier for statistical records), layerid (ID of the associated layer), and geometrycolumn (name of the target geometry column). The extended layer integrates six spatial extremum fields (minx / miny / minz / maxx / maxy / maxz) to record the global spatial boundaries of the geometry columns in real time. This table provides precise filtering conditions for spatial queries (such as "quickly excluding layers that do not intersect with the query rectangle") through automated extent calculation (e.g., triggering BBox calculation when new data is added) and a dynamic update mechanism (e.g., recalculating the extent after feature editing). Furthermore, it natively supports 3D scene clipping optimization based on the Z-value dimension (minz / maxz) (e.g., requesting only features within the elevation interval when loading LOD), significantly improving spatial retrieval efficiency and visualization performance in integrated 2D and 3D scenarios.

[0149] 2. Raster storage (SQLite files such as RasterMeta.db in subdirectories manage raster metadata):

[0150] 1) The raster dataset table (uss_raster_datasets) serves as the logical management center for raster data. It constructs a logical container for raster data through fixed fields: datasetid (globally unique identifier of the dataset), name (dataset name, such as "2023 Shanghai Satellite Imagery"), datasettype (type may include "Satellite Imagery Set" / "Terrain Dataset" / "Product Dataset"), datapath (physical address, following the / Storage / DatasetName / DataName hierarchical rules), and storepath (external service path). The extension layer integrates three types of fields: description (dataset description, such as "10-meter resolution multispectral imagery"), subtype (subtype extension, such as "Satellite Imagery Set → Sentinel 2A Product"), and subtype2 (secondary extension, such as "Atmospheric Corrected Surface Reflectance"). Through path rules and multi-level type encoding, it realizes unified registration, spatiotemporal organization (such as automatically parsing time series according to / 2023 / 07 / in the datapath), and service publishing of massive raster data, providing a standardized integration framework for multi-source raster data such as remote sensing imagery, digital elevation models, and real-time meteorological products.

[0151] 2) The raster dataset type table (uss_raster_datasettypes) serves as a standard definition library for raster data types. It constructs a basic classification system through two fixed fields: datasettypeid (a unique identifier for the dataset type) and name (a type name such as "satellite image set" / "terrain dataset"). The extension layer integrates six fields to achieve scientific research-level control: description (a detailed description of the type such as "Landsat series surface reflectance products"), definition (a dynamically defined product specification in JSON), permission (permission encoding such as rw read / write permission / rx execute permission), owner (a standard owner such as "USGS / NASA"), onlinepaper (a URL associated with a technical white paper), and extension (marks whether it is a user-defined extension type).

[0152] 3) The raster data type table (uss_raster_datatypes) serves as the foundational type library for raster data models. It constructs a three-tiered classification system using fixed fields: datatypeid (unique data type identifier), datasettype (associated with the dataset type name, such as "satellite image set" / "topography dataset"), and datatypename (basic type name). Four additional fields enable refined management at the research level: description (technical description of the data type), definition (dynamically defined type specification using JSON), owner (standard owner, such as "ESA / NASA"), and extension (marking user-defined extended types, such as "water quality inversion index"). Through dynamic JSON definitions and a strong type association mechanism, this table achieves unified type registration from raw data acquisition (such as "Sentinel-2 multispectral") to thematic product derivation (such as "NDVI vegetation index"), providing a core type benchmark for standardized remote sensing data analysis and automated thematic product generation.

[0153] 4) The raster dataset layer table (uss_raster_dataset_layers) serves as the core table for raster data. It constructs the basic framework of raster layers through fixed fields: layerid (globally unique layer identifier), datasetid (strongly associated dataset ID), srsid (bound spatial reference system ID, associated with uss_meta_srs to achieve coordinate system unification), rastername (layer business name), and datapath (absolute physical storage path). The extended layer integrates five fields to achieve deep integration of multi-source rasters: storepath (external service virtual path), filetype (file format encoding), filesubtype (storage subtype), description (raster data description), and storeinfo (JSON storage information). This table achieves unified layer registration, standardized service publishing, and scientific-grade metadata management from raw satellite imagery (such as Landsat multispectral files) to real-time raster products through strong binding of physical paths and spatial references (datapath + srsid), decoupling of service paths (datapath internal storage and external publication via orepath), and dynamic metadata extension (storeinfo custom parameters). This provides core support for cross-platform raster data sharing and analysis.

[0154] 5) The raster layer extended information table (uss_raster_dataset_layer_properties) serves as a record table for extended raster data information. It constructs a basic image parameter framework using fixed fields: propertyid (unique identifier for the attribute record), layerid (ID of the associated raster layer), numbands (number of bands), pixeldepth (pixel depth, e.g., 16-bit), ysizeize (image row and column size), and haspyramids (pyramid construction status: 0 not constructed / 1 constructed). It also expands upon this with 10 fields to enable depth spatial analysis and visualization optimization: spatial extent (minx / miny / ma). The table contains the following metadata components: xx / maxy (recording geographic bounding boxes), acquisition attributes (sensortype indicating the sensor, such as "OLI_TIRS"), numerical definitions (nodata setting invalid values), vector boundaries (polygonbounds storing precise WKT format extents, with coordinates consistent with srsid), a statistical engine (statistics storing band statistics in JSON format {"Band1":{"min":0.1,"max":0.8,"mean":0.35}}), a metadata repository (metadata storing raw header files in XML / JSON format), and visualization aids (thumbnail storing JPEG binary thumbnails). Through real-time pyramid status feedback (haspyramids=1 triggering fast zooming), precise spatial range dual storage (bounding boxes + vector surfaces ensuring zero error in spatial queries), and scientific statistical pre-calculation (statistics driving adaptive rendering), this table provides metadata support for remote sensing image analysis (such as NDVI calculation) and digital terrain applications.

[0155] 3. Scene storage (SQLite files such as SceneMeta.db in subdirectories manage metadata):

[0156] 1) The 3D model dataset table (uss_scene_datasets) serves as the logical management unit for 3D scenes. Its core contains five fixed fields: datasetid (unique dataset identifier), datasetname (name), datasettype (dataset type), description, and createtime (creation time), used for structured organization of 3D resources. The extended field subtype enables fine-grained classification of 3D scenes, supporting hierarchical location of storage → datasets → resources.

[0157] 2) The 3D model dataset type table (uss_scene_datasettypes) serves as the registration center for 3D model dataset types. Its core contains two fixed fields: datasettypeid (unique type identifier) ​​and datasetname (type name). The extension layer implements type-level security control through definition (JSON storage format specification), permission (read / write permissions such as read / write), and extension (extension type markers), satisfying flexible expansion from static models to dynamic semantic scenarios (such as digital twins).

[0158] 3) The 3D model data type table (uss_scene_datatypes) defines the basic 3D type system. The core includes three fixed fields: datatypeid (unique identifier of type), datasettype (associated dataset type), and datatypename (basic type); and extended fields definition (JSON storage parameters such as point cloud density), owner (standard owner such as "OGC I3S") and extension (whether it is an extended type). Custom types are also supported.

[0159] 4) The 3D model layer table (uss_scene_dataset_layers) is the layer-level registration center for 3D models. It contains 5 fixed fields: layerid (unique layer identifier), datasetid (associated dataset ID), layername (layer name), resourcecount (total number of model resources), and defaultgeometry (default geometry type). It also has 4 types of extensible fields: typecodecolumn (feature type code field name, supporting UInt32 classification), totalfeatures (total number of layer features), description (layer business description), and versioninfo (version change record). Through a dynamic registration mechanism, it realizes layer-level metadata management, spatial index optimization, and version tracking capabilities for newly added 3D model data.

[0160] 5) 3D model table (uss_scene_ <layerid>_models): Used to store 3D models composed of materials and meshes and their binary content. The core contains 3 fixed fields: modelid (unique identifier of the model), modelname (model name), and parentid (parent model ID); at the same time, 3 types of extended fields are designed: materialid (ID of the associated mesh), materialid (ID of the associated material), and transform(float[4]). 4] The array is used to record transformation parameters.

[0161] 6) 3D model material table (uss_scene_ <layerid>_materials: Used to store material information for 3D models. The core includes two fixed fields: materialid (unique material identifier) ​​and materialname (material name); it also includes 12 extended fields: basecolor (base color (RGBA) float), metallic (metallicity (float)), roughness (roughness (float)), emissive_factor (emissive color (RGB) float), alphacutoff (transparency threshold (float)), alphamode (transparency mode: OPAQUE / MASK / BLEND), doublesided (whether it is double-sided (bool)), basecolortexture (base color texture ID (int)), metallicroughnesstexture (metallicity and roughness texture ID (int)), normaltexture (normal texture ID (int)), emissivetexture (emissive texture ID (int)), and occlusiontexture (ambient occlusion texture ID (int)).

[0162] 7) 3D model texture table (uss_scene_ <layerid>_textures: Used to store texture information used by the materials of the 3D model. The core includes two fixed fields: textureid (unique texture identifier) ​​and texturename (texture name); at the same time, eight extended fields are designed: imagedata (image binary data (binary)), imageformat (image format MIME (string)), texcoord (corresponding texture coordinate ID (int)), wrap_s (texture wrapping mode S (enum)), wrap_t (texture wrapping mode T (enum)), min_filter (minimize filter mode (enum)), mag_filter (magnify filter mode (enum)), and path (storage address (string)).

[0163] 8) 3D model mesh table (uss_scene_ <layerid>_meshes: Used to store the mesh information of the model. The core contains 13 fixed fields: primitivetype, vertexcount, indexcount, hasnormal (whether there are normals), hastexcoord1 (whether there are texture coordinates 1), hastexcoord2 (whether there are texture coordinates 2), hascolor (whether there is color), hastangent (whether there is tangent vector), hasbatchid (whether there is batchid), vertexdata (vertex data), indexdata (index data), normaldata (normal data), texcoorddata1 (texture coordinates 1 data), texcoorddata2 (texture coordinates 2 data), colordata (color data), tangentdata (tangent vector data), and batchiddata (batchid data). At the same time, 6 extended fields are designed: normaldata (normal data), texcoorddata1 (texture coordinates 1 data), texcoorddata2 (texture coordinates 2 data), colordata (color data), tangentdata (tangent vector data), and batchiddata (batchid data).

[0164] It should be noted that storing vector data in the corresponding database file via Feature storage includes:

[0165] Create or associate a dataset record in the vector dataset table and designate it as the first target data;

[0166] Create a layer record for the first target data in the vector layer table, store the first target data in the vector layer table, and associate it with the dataset ID to which it belongs;

[0167] Populate the metadata of the target data layer record in the vector data list, vector data space list, and vector data space attribute table, and associate it with the layer ID of the first target data in the vector layer table;

[0168] Specifically, create or associate a dataset record in the vector dataset table, and store the dataset name, description, and type (derived from file name / user input) of the vector data in the vector dataset table (Dataset_Name, Description, Dataset_Type).

[0169] Create a layer record for this data in the vector layer table, store the vector data name and geometry type (point / line / polygon) in the vector layer table (LayerName, Geometry_Type,), and associate it with the vector dataset ID to which it belongs;

[0170] Populate the detailed metadata of this layer in the vector data list, vector data space list, and vector data space attribute table.

[0171] In the vector data table, specify the field name, type (integer / character / date, etc.), length, and whether it is a primary key / not null → store it in the vector data list (Field_Name, Data_Type, Field_Length, Is_PrimaryKey, Is_NotNull) to create a record and associate it with the layer ID; specify the spatial reference (SRID, derived from a .prj file or user-specified), storage format (WKB / WKT), and whether it includes Z / M values ​​→ store it in the vector data spatial list (SRID, Storage_Format, Has_Z, Has_M) and associate it with the layer ID; calculate the minimum / maximum X, Y, Z (if any) coordinates of all features in the layer → store them in the vector data spatial attribute table (Min_X, Min_Y, Min_Z, Max_X, Max_Y, Max_Z) and associate it with the layer ID.

[0172] Two-dimensional raster data is stored in the corresponding database file using Raster storage, including:

[0173] Copy / move raster files to a subdirectory alongside the Raster database file, or migrate the complete directory structure of a slice set to a subdirectory alongside the Raster database file;

[0174] Create or associate a dataset record in a raster dataset table as the second target data;

[0175] Create a layer record for the second target data in the raster dataset layer table, store the second target data in the raster dataset layer table, and associate it with the dataset ID to which it belongs;

[0176] Write the parameters of the second target data into the raster layer extended information table, and associate the second target data with the layer ID in the raster dataset layer table;

[0177] Specifically, tools can be used to copy / move raster files (TIFF) to a suitable location in the Raster storage subdirectory (e.g., by satellite / time level), or to migrate the complete directory structure of the slice file set to that subdirectory.

[0178] In addition, when creating or associating a dataset record in a raster dataset table, record its associated physical path (such as / RasterDataSet1 / Sentinel2 / 20230710 / or / RasterDataSet2 / Tiles_WebMercator / );

[0179] Create a layer record for the raster data / tile set in the raster layer table, associate it with the dataset ID, and store information such as spatial reference, geographic range resolution, number of bands, and pyramid creation into the layer for easy searching.

[0180] Enter parameters such as invalid values ​​(NoData), compression method, slice size, etc. into the raster layer extended information table, and associate them with the layer ID.

[0181] The 3D model data is stored in the corresponding database file through Scene storage, including:

[0182] Copy / move the 3D model resource directory of the 3D model data to a subdirectory adjacent to the Scene database file, and maintain the original file structure and resource dependencies of the 3D model data through metadata table mapping;

[0183] Create or associate a dataset record as third-party target data in the 3D scene dataset table;

[0184] Create a layer record for the third target data in the 3D model layer table, store the third target data in the 3D model layer table, and associate it with the dataset ID to which it belongs;

[0185] Add the 3D model of the third target data to the 3D model table, create a record for each model file in the dataset directory, and associate it with the 3D layer ID to which it belongs;

[0186] Add the material information of the 3D model to the 3D model material table and associate it with the model ID of the third target data in the 3D model table;

[0187] Add the texture information of the 3D model to the 3D model texture table and associate it with the material ID of the third target data in the 3D model material table;

[0188] Add the mesh information of the 3D model to the 3D model mesh table and associate it with the model ID of the third target data in the 3D model table;

[0189] If a binary model file is embedded within the texture, the offset within the binary model file is recorded in the 3D model table.

[0190] Specifically, the entire 3D model resource directory (including model files, texture subfolders, etc.) is copied / moved to the corresponding subdirectory of Scene storage (e.g., / Scene_Storage / Models / ), and the original file structure and resource dependencies are maintained through metadata table mapping. For example, model files (e.g., / Models / model.dts), texture files (e.g., / Materials / wall.jpg, / Materials / roof.png), and auxiliary resources (e.g., / Materials / metallic.mtl) are mapped.

[0191] In addition, create or associate a dataset record in the 3D scene dataset table;

[0192] Subsequently, the 3D model is added to the 3D model table, and a record is created for each model file in the dataset directory, containing information such as model file name, file type, relative path, file version, geometry type, number of vertices, number of textures, and extended metadata. The model depends on materials and meshes; for example, the materialid field in the model table record stores the ID corresponding to the material name ["glass_material"].

[0193] Next, the information of the 3D model texture and material is added to the 3D model material texture table, including the material texture file name, file type, relative path, texture / material type, width, height, etc. The material depends on the texture, such as storing the texture path ["textures / wall.jpg"] in the texture field of the material record.

[0194] If a binary model file is embedded within a texture, the offset within the binary file is recorded in the Embedded_Resources field of the model table, which facilitates quick location of the embedded texture position in the model through the 3D model table.

[0195] Example 2

[0196] Figure 2 This is a schematic diagram of the structure of a multi-source heterogeneous spatiotemporal data fusion modeling system provided in one embodiment of this application, with reference to... Figure 2 A multi-source heterogeneous spatiotemporal data fusion modeling system, comprising:

[0197] Processor 21 and memory 22;

[0198] Processor 21 and memory 22 are connected via a communication bus:

[0199] The processor 21 is used to call and execute the program stored in the memory 22;

[0200] The memory 22 is used to store a program, which is used to execute at least one multi-source heterogeneous spatiotemporal data fusion modeling method as described in the above embodiments.

[0201] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0202] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0203] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0204] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0205] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0206] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0207] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0208] In the description of this specification, the references to "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0209] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.< / layerid> < / layerid> < / layerid> < / layerid>

Claims

1. A method for modeling multi-source heterogeneous spatiotemporal data fusion, characterized in that, include: Create a root directory on the computer system as the physical address of the spatial data model; Create a core metadata system table in the root directory and manage it globally based on the database file; Under the structure of the root directory, create subdirectories corresponding to each storage object type, which will serve as the physical addresses of the storage object types; The types of stored objects include: vector data, two-dimensional raster data, and three-dimensional model data; each subdirectory is independent of the others. Add relevant data for each storage object type to the core metadata system table; Create and initialize database files corresponding to the storage object types in each subdirectory, and generate dedicated metadata tables for the storage object types in the database files; The combined 2D and 3D data of the real-world 3D scene is acquired as the data to be stored. Based on the type of the data to be stored, the corresponding data conversion tool is called to convert the data to be stored. The data is then stored in the corresponding database file using the corresponding storage method and associated with the dedicated metadata table in the database file. Among them, vector data is stored as Feature storage; 2D raster data is stored as Raster storage; and 3D model data is stored as Scene storage. The database file is used to manage the stored data and the relationships between the data. Different types of stored objects have different data storage rules; The data storage rules for vector data include: All data is stored in a Feature database file; The data storage rules for two-dimensional raster data include: A dedicated metadata table is stored in a Raster database file; Create parallel subdirectories for the Raster database files to store raster data files or tile slice files; The data storage rules for 3D model data include: Store a dedicated metadata table in a Scene database file; Create parallel subdirectories for the Scene database files to store 3D model files, material / texture files, and other dependent resources, while maintaining the original directory structure of the 3D model files to preserve the dependencies between resources.

2. The method according to claim 1, characterized in that, The method further includes: Receive data access requests, locate the target stored data according to the data access requests, and obtain the type, physical address and dedicated metadata table of the target stored data; The corresponding driver is invoked based on the type of the target stored data, and the target stored data is accessed based on its physical address and dedicated metadata table.

3. The method according to claim 1, characterized in that, The core metadata system tables include storage definition tables, storage type definition tables, data driver tables, spatial reference system tables, and server configuration information tables. The storage definition table, storage type definition table, data-driven table, spatial reference system table, and server configuration information table all include multiple fixed fields and multiple expandable fields; The storage definition table serves as the unified registration center for the spatial data model. It is initially empty, and records are dynamically inserted when a new storage object is created, thereby synchronizing storage creation with metadata registration. The storage type definition table uses an extension mechanism to support the integration and management of new storage types; The data-driven table provides differentiated data parsing, format conversion, and access services for different storage types through a dynamic registration mechanism; The aforementioned spatial reference system table, through its multi-format compatible design, enables the fusion and cross-platform parsing of two-dimensional and three-dimensional data under a unified spatial benchmark; The server configuration information table uses key-value storage and a driver binding mechanism to support on-demand dynamic loading of service parameters and driver-level differentiated configuration.

4. The method according to claim 1, characterized in that, The design rules for metadata tables differ depending on the storage method.

5. The method according to claim 4, characterized in that, The design rules for the metadata table of Feature storage include: Construct a vector dataset table as the logical management unit for vector data, and configure the logical hierarchy of vector data among storage, datasets, and layers; A vector dataset type table is constructed as the core registry for vector data, permissions are bound, and a JSON dynamic expansion mechanism is configured. A vector data type table is constructed as a standard library for vector data, and a unified registration and standardized management of basic and custom types of vector data is achieved through a JSON dynamic definition mechanism. A vector layer table is constructed as a layer registry center for vector data, and a dynamic registration mechanism is used to manage layer-level metadata, spatial indexing, and version tracking of newly added vector data. A vector data list is constructed as the core metadata table of the spatial data model, which undertakes the functions of standardizing the definition and dynamic management of the attribute structure of vector data layers. The vector data list realizes the automatic registration of newly added vector data table structures, value domain consistency and business logic integration through field-level atomic control, constraint linkage and semantic mapping. A vector data space list is constructed as the central hub for the multidimensional geometric representation of the spatial data model; the vector data space list is configured with a mechanism for the coexistence of multiple geometric columns in the same vector layer, dynamic coordinate system adaptation, and a hybrid indexing strategy. A vector data spatial range statistics table is constructed as a dynamic range indexing engine for the spatial data model; the vector data spatial range statistics table is configured with an automated range calculation and dynamic update mechanism; The design rules for Raster storage's metadata tables include: A raster dataset table is constructed as the logical management center for two-dimensional raster data; unified registration and spatiotemporal organization of raster data are achieved through path rules and multi-level type encoding. Construct a raster dataset type table as a standard definition library for two-dimensional raster datasets; A raster data type table is constructed as the basic type library for the two-dimensional raster data model; the raster data type table is configured with a JSON dynamic definition mechanism and a strong type association mechanism. A raster dataset layer table is constructed as the core table for two-dimensional raster data. The raster dataset layer table realizes unified layer registration, standardized service publishing, and metadata management from raw satellite imagery to real-time raster products through strong binding of physical paths and spatial references, decoupling of service paths, and dynamic metadata extension. A raster layer extended information table is constructed as a record table for extended information of two-dimensional raster data; the raster layer extended information table provides metadata support for remote sensing image analysis and digital terrain applications through dual storage of pyramid information and precise spatial range and scientific statistical pre-calculation; The design rules for the metadata tables in Scene storage include: A 3D model dataset table is constructed as the logical management unit for the 3D scene; Construct a 3D model dataset type table as the registration center for 3D model dataset types; Construct a 3D model data type table to define the basic 3D type system; A 3D model layer table is constructed as a layer-level registry center for 3D model data. A dynamic registration mechanism is configured to realize layer-level metadata management, spatial indexing, and version tracking of newly added 3D model data. Construct a 3D model table to store the 3D model of the assembled mesh material and its binary content; Create a 3D model material table to store the 3D model material data; A 3D model texture table is constructed to store the texture map content associated with the materials; A 3D model mesh table is constructed to store the 3D model mesh data.

6. The method according to claim 5, characterized in that, Vector data is stored in the corresponding database file through Feature storage, including: Create or associate a dataset record in the vector dataset table and designate it as the first target data; Create a layer record for the first target data in the vector layer table, store the first target data in the vector layer table, and associate it with the dataset ID to which it belongs; Fill the target data layer record metadata into the vector data list, vector data space list, and vector data space attribute table, and associate the first target data with the layer ID in the vector layer table; Two-dimensional raster data is stored in the corresponding database file using Raster storage, including: Copy / move raster files to a subdirectory alongside the Raster database file, or migrate the complete directory structure of a slice set to a subdirectory alongside the Raster database file; Create or associate a dataset record in a raster dataset table as the second target data; Create a layer record for the second target data in the raster dataset layer table, store the second target data in the raster dataset layer table, and associate it with the dataset ID to which it belongs; Write the parameters of the second target data into the raster layer extended information table, and associate the layer ID of the second target data in the raster dataset layer table; The 3D model data is stored in the corresponding database file through Scene storage, including: Copy / move the 3D model resource directory of the 3D model data to a subdirectory adjacent to the Scene database file, and maintain the original file structure and resource dependencies of the 3D model data through metadata table mapping; Create or associate a dataset record as third-party target data in the 3D scene dataset table; Create a layer record for the third target data in the 3D model layer table, store the third target data in the 3D model layer table, and associate it with the dataset ID to which it belongs; Add the 3D model of the third target data to the 3D model table, create a record for each model file in the dataset directory, and associate it with the 3D layer ID to which it belongs; Add the material information of the 3D model to the 3D model material table, and associate the model ID of the third target data in the 3D model table; Add the texture information of the 3D model to the 3D model texture table and associate the material ID of the third target data in the 3D model material table; Add the mesh information of the 3D model to the 3D model mesh table, and associate the model ID of the third target data in the 3D model table; If a binary model file is embedded within the texture, the offset within the binary model file is recorded in the 3D model table.

7. The method according to claim 2, characterized in that, The corresponding driver is invoked based on the type of the target stored data, and the target stored data is accessed based on its physical address and dedicated metadata table, including: If the target stored data is vector data, read the Feature database file and use the vector dataset table and vector layer table to locate the target stored data; If the target stored data is two-dimensional raster data, read the Raster database file and locate the target stored data through the raster dataset table and the raster dataset layer table; If the target stored data is 3D model data, read the Scene database file and locate the target stored data using the 3D model dataset table and the 3D model layer table.

8. A multi-source heterogeneous spatiotemporal data fusion modeling system, characterized in that, include: Processor and memory; The processor and memory are connected via a communication bus: The processor is used to call and execute the program stored in the memory; The memory is used to store a program, which is at least used to execute the multi-source heterogeneous spatiotemporal data fusion modeling method according to any one of claims 1-7.

Images