Multi-source heterogeneous spatio-temporal data fusion modeling method and system

Abstract

The invention relates to a multi-source heterogeneous spatio-temporal data fusion modeling method and system. The method comprises the steps that a root directory is created on a computer system to serve as a physical address of a spatial data model; under the structure of the root directory, creating a subdirectory corresponding to each storage object type as a physical address of the storage object type; the storage object type comprises vector data, two-dimensional raster data and three-dimensional model data; adding related data of each storage object type in the core metadata system table; creating a database file corresponding to the storage object type under each subdirectory, initializing the database file, and generating an exclusive metadata table corresponding to the storage object type in the database file; the method comprises the following steps: acquiring two-dimensional and three-dimensional joint data of a live-action three-dimensional scene as to-be-stored data, calling a corresponding data conversion tool to convert the to-be-stored data based on the type of the to-be-stored data, storing the to-be-stored data in a corresponding database file in a corresponding storage mode, and associating the to-be-stored data with an exclusive metadata table in the database file.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data fusion, and in particular to a multi-source heterogeneous spatio-temporal data fusion modeling method and system. BACKGROUND

[0002] With the rapid development of smart cities and digital twin technology, multi-source heterogeneous spatio-temporal data is growing explosively, covering multi-modal data sources such as vector data, two-dimensional raster data, and three-dimensional model data. The existing spatio-temporal data model has significant bottlenecks in cross-dimension expression and heterogeneous data fusion: two-dimensional data mainly uses planar topology, and three-dimensional models emphasize stereo geometric structure features. There are significant differences between the two in terms of spatio-temporal reference, semantic expression, and precision level, which seriously restricts the collaborative analysis capability in the fields of natural resource monitoring and urban emergency management.

[0003] The core problem of the existing spatio-temporal data model is the dimensional fragmentation of the storage architecture and the staticization of the fusion mechanism. Current mainstream storage models are mainly designed around a single dimension, and have limited cross-modal collaboration capabilities. For example, two-dimensional models such as OGCGeoPackage and Esri Shapefile support vector and raster data, but cannot directly express three-dimensional entities. Three-dimensional grids or point clouds often need to be converted into raster slices or external extensions, which compromises data integrity. In contrast, three-dimensional models such as SuperMap S3M and Cesium3D Tiles optimize rendering efficiency, but lack spatial analysis interfaces (such as S3M, which cannot perform buffer calculations internally), resulting in a separation between visualization and calculation. BIM-IFC has detailed semantic attributes, but lacks the ability to align with geographic coordinates, and integrating GIS data requires manual alignment of geometry and attributes, which is costly.

[0004] In terms of data fusion, there is a significant mismatch between the multi-level semantic structure of CityGML and the oblique photogrammetry grid model, especially in terms of lightweight expression and real-time rendering. Manual model simplification is often required. Indoor space models such as IndoorGML are not dynamically bound to geographic coordinate systems, which requires repeated coordinate system conversion for cross-floor or outdoor space analysis. In addition, common architectural design data (such as IFC and CAD) have complete semantics, but cannot be directly embedded in GIS platforms. Fusion analysis requires manual alignment of structured attributes and geographic references. Overall, current data models cannot support unified analysis and reasoning of multi-dimensional spatio-temporal data, and the fusion efficiency is low. SUMMARY

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

[0006] The scheme of the present application is as follows:

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

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

[0009] Creating a core metadata system table in the root directory, taking a database file as a global manager;

[0010] Under the structure of the root directory, creating subdirectories corresponding to each storage object type as 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 each other;

[0011] Adding related data of each storage object type in the core metadata system table;

[0012] Creating a database file corresponding to the storage object type under each subdirectory and initializing it, and generating a dedicated metadata table corresponding to the storage object type in the database file;

[0013] 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 a corresponding data conversion tool to convert the to-be-stored data, storing it in a corresponding database file through a corresponding storage mode, and associating it with the dedicated metadata table in the database file;

[0014] Among them, the storage mode corresponding to the vector data is Feature storage; the storage mode corresponding to the two-dimensional raster data is Raster storage; and the storage mode corresponding to the three-dimensional model data is Scene storage.

[0015] Preferably, the method further comprises:

[0016] Receiving a data access request, locating target storage data according to the data access request, obtaining the type, physical address, and dedicated metadata table of the target storage data;

[0017] According to the type of the target storage data, calling a corresponding driver, and accessing the target storage data according to the physical address and the dedicated metadata table of the target storage data.

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

[0019] The storage definition table, the storage type definition table, the data driver table, the spatial reference system table, and the server configuration information table each include a plurality of fixed fields and a plurality of extensible fields.

[0020] The storage definition table is registered as a unified registration center of the spatial data model, is initially empty, and dynamically inserts records when a new storage object is created, so as to realize synchronization of storage creation and metadata registration.

[0021] The storage type definition table supports integration and management of new storage types through an extension mechanism.

[0022] The data driving table provides differentiated data analysis, format conversion and access service capabilities for different storage types through a dynamic registration mechanism.

[0023] The spatial reference system table realizes fusion and cross-platform analysis of two-dimensional data and three-dimensional data under a unified spatial reference through multi-format compatible design.

[0024] The server configuration information table supports dynamic loading of service parameters and driver-level differentiated configuration through a key-value storage and driver binding mechanism.

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

[0026] Different storage object types have different data storage rules.

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

[0028] All data is stored through a Feature database file.

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

[0030] The exclusive metadata table is stored through a Raster database file.

[0031] A parallel subdirectory of the newly created Raster database file is used to store raster data files or tile slice files.

[0032] The data storage rules of three-dimensional model data include:

[0033] The exclusive metadata table is stored through a Scene database file.

[0034] A parallel subdirectory of the newly created Scene database file is used to store three-dimensional model files, material / texture files and other dependent resources, and the original directory structure of the three-dimensional model files is maintained to maintain the dependency relationship between resources.

[0035] Preferably, the metadata table design rules of different storage modes are different.

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

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

[0038] Construct a vector dataset type table as a core registration table of vector data, bind permissions, and configure a JSON dynamic expansion mechanism;

[0039] Construct a vector data type table as a standard library of vector data, and realize unified registration and standardized management of basic types and custom types of vector data through a JSON dynamic definition mechanism;

[0040] Construct a vector layer table as a layer registration center of vector data, and realize metadata management, spatial indexing, and version tracking of the layer level of newly imported vector data through a dynamic registration mechanism;

[0041] Construct a vector data table as a core metadata table of a spatial data model, and assume the functions of standardized definition and dynamic control of the attribute structure of a vector data layer; the vector data table realizes automatic registration of the table structure of newly imported vector data, value domain consistency, and business logic integration through field-level atomization control, constraint linkage, and semantic mapping;

[0042] Construct a vector data spatial table as a hub of multi-dimensional geometric expression of a spatial data model; the vector data spatial table configures a mechanism of coexistence of multiple geometric columns of the same vector layer, dynamic coordinate system adaptation, and mixed indexing strategy;

[0043] Construct a vector data spatial range statistics table as a dynamic range index engine of a spatial data model; the vector data spatial range statistics table configures an automatic range calculation and dynamic update mechanism;

[0044] The metadata table design rules of Raster storage include:

[0045] Construct a raster dataset table as a logical management hub of two-dimensional raster data; realize unified registration and spatio-temporal organization of raster data through path rules and multi-level type coding;

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

[0047] Construct a raster data type table as a basic type library of a two-dimensional raster data model; the raster data type table configures a JSON dynamic definition mechanism and a strong type association mechanism;

[0048] A grid dataset layer table is constructed as a core table of the two-dimensional grid data; the grid dataset layer table realizes unified layer registration, standardized service publishing and metadata management from original satellite images to real-time grid products through strong binding of a physical path and a spatial reference, service path decoupling and dynamic metadata extension;

[0049] A grid layer extension information table is constructed as an extension information record table of the two-dimensional grid data; the grid layer extension information table provides metadata support for remote sensing image analysis and digital terrain application through pyramid information, accurate spatial range double storage and scientific statistical precalculation;

[0050] The metadata table design rules of the Scene storage include:

[0051] A three-dimensional model dataset table is constructed as a logical management unit of the three-dimensional scene;

[0052] A three-dimensional model dataset type table is constructed as a registration hub of the three-dimensional model dataset type;

[0053] A three-dimensional model data type table is constructed to define a three-dimensional basic type system;

[0054] A three-dimensional model layer table is constructed as a layer-level registration center of the three-dimensional model data, and a dynamic registration mechanism is configured to realize layer-level metadata management, spatial indexing and version tracking of the newly stored three-dimensional model data;

[0055] A three-dimensional model table is constructed to store three-dimensional models and binary contents thereof constructed by assembling grids and materials;

[0056] A three-dimensional model material table is constructed to store three-dimensional model material data;

[0057] A three-dimensional model texture table is constructed to store texture map contents associated with materials;

[0058] A three-dimensional model grid table is constructed to store three-dimensional model grid data.

[0059] Preferably, the vector data is stored into a corresponding database file through the Feature storage, including:

[0060] A dataset record is created or associated in the vector dataset table as a first target data;

[0061] A layer record is created for the first target data in the vector layer table, the first target data is stored into the vector layer table, and a dataset ID to which the first target data belongs is associated;

[0062] Metadata of the layer record of the target data is filled in the vector data list, the vector data space list and the vector data space attribute table, and a layer ID of the first target data in the vector layer table is associated.

[0063] Store two-dimensional raster data to corresponding database files by Raster storage, including:

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

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

[0066] Create a layer record in the raster dataset layer table for the second target data, store the second target data in the raster dataset layer table, and associate the dataset ID thereof;

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

[0068] Store three-dimensional model data to corresponding database files by Scene storage, including:

[0069] Copy / move the three-dimensional model resource directory of three-dimensional model data to the parallel subdirectory of Scene database files, and keep the original file structure and resource dependency of three-dimensional model data by metadata table mapping;

[0070] Create or associate a dataset record in the three-dimensional scene dataset table as third target data;

[0071] Create a layer record in the three-dimensional model layer table for the third target data, store the third target data in the three-dimensional model layer table, and associate the dataset ID thereof;

[0072] Add the three-dimensional model of the third target data to the three-dimensional model table, create a record for each model file under the dataset directory, and associate the three-dimensional layer ID thereof;

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

[0074] Add the texture information of the three-dimensional model to the three-dimensional model texture table, and associate the material ID of the third target data in the three-dimensional model material table;

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

[0076] If the texture is embedded in the binary model file, the offset in the three-dimensional model table record model binary file is recorded.

[0077] Preferably, according to the type of target storage data, the corresponding driver is called, and the target storage data is accessed according to the physical address of the target storage data and the exclusive metadata table, comprising:

[0078] If the target storage data is vector data, the Feature database file is read, and the target storage data is located by using the vector data set table and the vector layer table;

[0079] If the target storage data is two-dimensional raster data, the Raster database file is read, and the target storage data is located by using the raster data set table and the raster data set layer table;

[0080] If the target storage data is three-dimensional model data, the Scene database file is read, and the target storage data is located by using the three-dimensional model data set table and the three-dimensional model layer table.

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

[0082] A processor and a memory;

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

[0084] The processor is configured to call and execute the program stored in the memory.

[0085] The memory is configured to store a program, and the program is at least used to execute the multi-source heterogeneous spatio-temporal data fusion modeling method according to any one of the above.

[0086] The technical scheme provided in the application can include the following beneficial effects:

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

[0088] The exclusive metadata table corresponding to each storage object type database file is generated, so that data access can be based on metadata during data access, ensuring complete loading and lossless exchange of three-dimensional resources, solving the problem of data loss when using a two-dimensional data model to store three-dimensional model data, and realizing unified and reliable service data interface for cross-modal data.

[0089] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application. BRIEF DESCRIPTION OF DRAWINGS

[0090] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and serve to explain the principles of the application, in which, like reference numerals designate corresponding parts throughout the several views.

[0091] Figure 1 is a flowchart of a multi-source heterogeneous spatio-temporal data fusion modeling method provided by an embodiment of the application;

[0092] Figure 2 is a structural diagram of a multi-source heterogeneous spatio-temporal data fusion modeling system provided by an embodiment of the application.

[0093] Reference signs: processor-21; memory-22. DETAILED DESCRIPTION

[0094] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The following description is made with reference to the accompanying drawings in which like reference numerals represent like elements, unless the context dictates otherwise. The following description of exemplary embodiments is not representative of all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the appended claims.

[0095] Embodiment One

[0096] Figure 1 is a flowchart of a multi-source heterogeneous spatio-temporal data fusion modeling method provided by an embodiment of the application, with reference to Figure 1 A multi-source heterogeneous spatio-temporal data fusion modeling method comprises the following steps.

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

[0098] S12: creating a core metadata system table in the root directory, and taking a database file as a global manager;

[0099] S13: creating subdirectories corresponding to each storage object type under the structure of the root directory, as 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 each other;

[0100] S14: adding related data of each storage object type in the core metadata system table;

[0101] S15: New database files corresponding to the storage object types are created and initialized under each subdirectory, and the exclusive metadata table corresponding to the storage object type is generated in the database file;

[0102] S16: The two-three-dimensional joint data of the real scene three-dimensional scene are obtained as the to-be-stored data, the corresponding data conversion tool is called based on the type of the to-be-stored data to convert the to-be-stored data, and the to-be-stored data is stored in the corresponding database file through the corresponding storage mode and is associated with the exclusive metadata table in the database file;

[0103] The storage mode corresponding to the vector data is Feature storage; the storage mode corresponding to the two-dimensional raster data is Raster storage; and the storage mode corresponding to the three-dimensional model data is Scene storage.

[0104] The framework of the spatial data model in the embodiment stores the vector data, the two-dimensional raster data and the three-dimensional model data through the three physical storage schemes, adapts to the physical storage requirements of multi-source heterogeneous data, effectively overcomes the limitations of the previous spatial data model in storing three-dimensional models, and can be flexibly expanded through the three basic storage schemes to be compatible with more data formats.

[0105] It should be noted that the method further comprises:

[0106] The data access request is received, the target storage data is positioned according to the data access request, the type, the physical address and the exclusive metadata table of the target storage data are obtained;

[0107] The corresponding driver is called according to the type of the target storage data, and the target storage data is accessed according to the physical address and the exclusive metadata table of the target storage data.

[0108] Specifically, if the target storage data is vector data, the Feature database file is read, and the target storage data is positioned by using the vector data set table and the vector layer table;

[0109] If the target storage data is two-dimensional raster data, the Raster database file is read, and the target storage data is positioned by using the raster data set table and the raster data set layer table;

[0110] If the target storage data is three-dimensional model data, the Scene database file is read, and the target storage data is positioned by using the three-dimensional model data set table and the three-dimensional model layer table.

[0111] When data access is performed, data access can be performed based on metadata, complete loading and lossless exchange of three-dimensional resources are ensured, the problem of data loss caused by storing three-dimensional model data by using a two-dimensional data model in the past is solved, and unified and reliable service data interfaces of cross-modal data are realized.

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

[0113] The storage definition table, the storage type definition table, the data driver table, the spatial reference system table and the server configuration information table each include a plurality of fixed fields and a plurality of extensible fields;

[0114] The storage definition table serves as a unified registration center of a spatial data model, is initially empty, and dynamically inserts a record when a storage object is newly created, so as to realize synchronization of storage creation and metadata registration.

[0115] The storage type definition table supports integration and management of new storage types through an extension mechanism.

[0116] The data driver table provides differentiated data analysis, format conversion and access service capabilities for different storage types through a dynamic registration mechanism.

[0117] The spatial reference system table realizes fusion and cross-platform analysis of two-dimensional data and three-dimensional data under a unified spatial reference through multi-format compatible design.

[0118] The server configuration information table supports dynamic loading of service parameters and driver-level differentiated configuration through key-value storage and driver binding mechanism.

[0119] Specifically:

[0120] (1) The storage definition table (uss_meta_storages) serves as a unified registration center of a data model, and the core includes six fixed fields: storageid (global unique identifier of a storage object), storagename (user-defined storage name), storagetype (associated Feature / Raster / Scene type identifier), storeversion (format version), physicalpath (physical path pointing to a dedicated subdirectory or file), and datapath (external access path). Four types of extensible fields are also designed: storeversion supplements storage format version details, description records storage description information, storeinfo stores custom extended metadata in JSON, and driveruuid binds a dedicated data driver. The table is initially empty, and a record is dynamically inserted only when a storage object is newly created, so as to realize synchronization of storage creation and metadata registration.

[0121] (2) The storage type definition table (uss_meta_storage_types) is registered as the type center of the data model, and the core contains four fixed fields: typeid (storage type global unique identifier), storecode (storage type code, a total of 3 bits, the first bit is an identification code, and the last two bits are sequence codes), typename (storage type name), and description (storage function description), which are used to define the basic storage type template (such as Feature-vector storage / Raster-two-dimensional raster tile storage / Scene-three-dimensional model storage). Four extensible fields are designed: subtype (storage sub-type), permission (type-level operation permission), definition (JSON format extension definition), and extension (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) is registered as the driving center of the data model, and the core contains four fixed fields: driverid (driver type global unique identifier), storecode (associated with the storage type code of the previous table, a total of 3 bits, the first bit is an identification code, and the last two bits are sequence codes), drivername (driver name), and driverversion (driver version information), which are used to bind the storage type and data read-write capability. Four types of extensible fields are designed: owner (driver owner), description (function description), driverinfo (extension analysis parameter), and metadata (driver metadata), which provide differentiated data analysis, format conversion, and access service capabilities for different storage types (such as Feature driver for analyzing Shapefile / Scene driver for analyzing DTS) through a dynamic registration mechanism.

[0123] (4) Spatial reference system table (uss_meta_srs) as the spatial reference system registration center of the data model, the core contains 4 fixed fields: srsid (coordinate system standard ID, such as EPSG: 4326), srsname (spatial reference name), type (coordinate system type: Geographic / Projected / Custom), wkt (OGC WKT definition), which is used for standardized management of geospatial reference; At the same time, 6 kinds 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), organization (standard organization name such as EPSG / ESRI), which realizes the accurate fusion and cross-platform analysis of two-dimensional and three-dimensional data under unified spatial reference through multi-format compatible design.

[0124] (5) Server configuration information table (uss_meta_server) as the management center of the service end running parameters, the core contains 5 fixed fields: serverid (configuration item unique identification), servername (parameter name), type (configuration type), value (parameter actual value), drivername (bound data driver name, which realizes the driver-level parameter customization), which is used for centralized management of service end runtime configuration; At the same time, 2 kinds of extensible fields are designed: description (parameter function description), displayorder (configuration item sorting number).

[0125] It should be noted that the database file is used to manage the stored data and the relationship between the data.

[0126] Among them, different storage object types have different data storage rules.

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

[0128] All data is stored through the Feature database file;

[0129] The Feature database file contains all the subsequent generated special metadata tables and possible vector element tables. This type of storage stores all data in a database file, and there is no external data.

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

[0131] The special metadata table is stored through the Raster database file;

[0132] Parallel subdirectories of the newly created Raster database file are created to store raster data files or tile slice files;

[0133] The Raster database file stores a dedicated metadata table, and in addition, multiple parallel subdirectories (such as

[0134] / project.uss / Raster_Storage / RasterDataSet1 / ,

[0135] / project.uss / Raster_Storage / RasterDataSet2 / ) are created under the directory where the Raster database file is located. Such directories are used to store raster data files (such as TIFF) or tile slice files, and the organization form is optional. It can be stored according to the "satellite type / acquisition time" hierarchy (such as / RasterDataSet1 / Landsat8 / 20230701 / , / RasterDataSet1 / Sentinel2 / 20230702 / ), or according to the original directory structure of the slice set data (such as / RasterDataSet2 / Tiles_WebMercator / 15 / 1234 / 5678.png).

[0136] The data storage rules of three-dimensional model data include:

[0137] A dedicated metadata table is stored through the Scene database file;

[0138] Parallel subdirectories of the newly created Scene database file are created to store three-dimensional model files, material / texture files, and other dependent resources, and the original directory structure of the three-dimensional model file is maintained to maintain the dependency relationship between resources.

[0139] The Scene database file stores a dedicated metadata table, and in addition, multiple parallel subdirectories (such as / project.uss / Scene_Storage / Materials / , / project.uss / Scene_Storage / Models / ) are created under the directory where the Scene database file is located. Such directories are used to store three-dimensional model files (.obj,.fbx,.3dtiles,.gltf, etc.), material / texture files (.jpg,.png, etc.), and other dependent resources, and basically maintain the original directory structure to maintain the dependency relationship between resources.

[0140] It should be noted that the metadata table design rules are different for different storage methods.

[0141] Specifically:

[0142] 1. Feature storage (SQLite file inside subdirectory, e.g. FeatureMeta.db):

[0143] 1) Vector dataset table (uss_feature_datasets) as a logical management unit of vector data, which contains three fixed fields: datasetid (unique identification of dataset), datasetname (dataset name), and datasettype (dataset type, such as "general vector" / "address" / "geocoding"), which is used for structured organization of vector data; meanwhile, two types of extensible fields are designed: subtype (sub-type extension, such as extending point type to "simple model") and description (dataset function description), which realizes precise positioning and management of vector data in the logical hierarchy of storage -> dataset -> layer through type classification.

[0144] 2) Vector dataset type table (uss_feature_datasettypes) as a core registry of vector data types, which contains two fixed fields: datasettypeid (type unique identification) and datasetname (type name, such as "address dataset" / "place name dataset"), which is used for standardized definition of vector dataset type templates; meanwhile, four types of extensible fields are designed: definition (JSON structured storage extension definition), permission (permission identification, such as 'r' read / 'w' write / 'x' execute, combined value 'rw' indicates read and write), description (type detailed description), and extension (indicates whether it is a custom extended type), which realizes fine control and flexible extension capability of vector dataset type through permission binding and JSON dynamic extension mechanism.

[0145] 3) Vector data type table (uss_feature_datatypes) as a standard library of vector data types, the core contains three fixed fields: datatypeid (unique identification of data type), datasettype (data set type name associated with the Feature storage point 2) such as "address data set" / "name data set", datatypename (basic type name such as "point" / "line" / "surface"), used to define the basic geometric type system of vector data; At the same time, four kinds of extensible fields are designed: description (type detailed description), definition (JSON structured storage extension parameters such as topological rules), owner (type standard owner such as OGC / EPSG), extension (whether it is a custom extended type), unified registration and standardized management of basic types and custom types (such as "simple building model" extended from "point" type) are realized through dynamic JSON definition mechanism.

[0146] 4) Vector layer table (uss_feature_dataset_layers) as a vector data layer registration center, the core contains five fixed fields: layerid (unique identification of layer), datasetid (data set ID associated with the Feature storage point 1), layername (layer name / physical table name), oidcolumn (feature object ID column name), defaultgeocolumn (default geometry column name, default for 'geo'), used to establish the mapping relationship from data set to physical layer; At the same time, four kinds of extensible fields are designed: typecodecolumn (feature type code field name, supporting UInt32 classification), totalfeatures (total number of layer features), description (layer business description), versioninfo (version change record), through dynamic registration mechanism, the vector data layer level metadata management, spatial index optimization and version tracking ability of new database are realized.

[0147] 5) Vector data list (uss_feature_columns) as the core metadata table of the spatial data model, undertakes the standardized definition and dynamic control functions of the attribute structure of the vector layer. Its four fixed field layers build the field registration basic framework through columnid (global unique field identifier), layerid (strongly associated with the layer ID), columnname (unique naming constraint within the layer), columntype (binding enumeration type such as integer / character / BLOB); the extended layer integrates 15 fields and is divided into three control dimensions according to function: data integrity dimension (isnullable null value admission switch: 0 prohibited / 1 allowed, isprimarykey primary key identifier, allowblank non-empty verification strengthening, fielddomain value domain dictionary constraint), storage definition dimension (columnlength character maximum byte length, decimallength floating point decimal place precision, defaultvalue default value injection mechanism), business semantics dimension (fieldcode function code, description business semantics description, displayorder interface rendering serial number, extendinfo extension information). This table realizes the automatic registration of the structure of the newly entered vector data table, the value domain strong consistency guarantee and the seamless integration of business logic through field-level atomization control (such as isprimarykey = 1 triggering the construction of a database unique index), constraint linkage (such as allowblank = 0 + isnullable = 0 forming double non-empty protection), semantic mapping (such as fieldcode = "ROAD_LEVEL" automatically associating road classification rules), and provides accurate metadata support for spatial-attribute joint query (such as "retrieve roads with elevation > 100 meters").

[0148] 6) Vector data space list (uss_feature_geometry_columns) as the core of multi-dimensional geometric expression of spatial data model, through three fixed fields geocolumnid (geometric column global unique identifier), layerid (associated with the ID of the layer to which it belongs), geocolumn (geometric column physical name) to build a geometric storage basic framework; extended layer integration of 10 fields to realize two-dimensional and three-dimensional integration and fusion control: spatial reference (srsid associated with coordinate system definition), geometric type (datatype basic type + subtype / subtype2 two-level extended type, such as “point → simple building model”), storage format (storagetype supports WKB / WKT / BINARY), dimension mark (z elevation attribute / m temperature and other extended attributes), spatial index (rindex / hindex / mindex respectively activate R-tree / H3 grid / Mercator subdivision index). This table realizes unified management of single feature multi-expression form (such as storing two-dimensional linear and three-dimensional lane model of road feature) through multi-geometric column coexistence mechanism (such as containing “planar coordinate geometric column” and “three-dimensional model geometric column” in the same layer), dynamic coordinate system adaptation (each geometric column independently binds srsid) and mixed index strategy, and completely breaks through the limitation of traditional single geometric column, providing native data support for cross-dimensional spatial analysis (such as two-dimensional planar calculation and three-dimensional visibility analysis).

[0149] 7) Vector data space range statistics table (uss_feature_geometry_stats) as the dynamic range index engine of spatial data model, through fixed fields id (statistical record unique identifier), layerid (associated with the ID of the layer to which it belongs), geometrycolumn (target geometric column name) to build a spatial range management framework; extended layer integration of 6 spatial extreme value fields (minx / miny / minz / maxx / maxy / maxz) to record the global spatial boundary of the geometric column in real time. This table provides accurate filtering conditions for spatial queries (such as “quickly excluding layers with no intersection with the query rectangle”) through automatic range calculation (such as triggering BBox calculation when new data is imported) and dynamic update mechanism (such as recalculating the range after editing the feature), and relies on the Z value dimension (minz / maxz) to support three-dimensional scene clipping optimization (such as LOD loading only requests features within the elevation interval), significantly improving the spatial retrieval efficiency and visualization performance in two-dimensional and three-dimensional integrated scenes.

[0150] 2、Raster storage (SQLite file in the subdirectory, such as RasterMeta.db, manages raster metadata):

[0151] 1) The raster dataset table (uss_raster_datasets) is the logical management hub of raster data. It builds a logical container for raster data through fixed fields datasetid (global unique identifier of the dataset), name (dataset name such as "2023 Shanghai satellite image"), datasettype (type may include "satellite image set" / "terrain dataset" / "product dataset"), datapath (physical address, following the / Storage / DatasetName / DataName hierarchical rule), and storepath (external service path). The extended layer integrates three types of fields: description (dataset description such as "10-meter resolution multispectral image"), subtype (sub-type extension such as "satellite image set -> Sentinel 2A product"), and subtype2 (second extension such as "atmospheric correction surface reflectance"). Through path rules and multi-level type coding, it realizes the unified registration, spatio-temporal organization (such as automatic parsing of time series according to / 2023 / 07 in datapath), and service publishing of massive raster data, providing a standardized integration framework for multi-source raster data such as remote sensing images, digital elevation models, and real-time weather products.

[0152] 2) The raster dataset type table (uss_raster_datasettypes) is a standard definition library for raster data types. It builds a basic classification system through two fixed fields datasettypeid (unique identifier of the dataset type) and name (type name such as "satellite image set" / "terrain dataset"). The extended layer integrates six fields to realize scientific research-level control: description (detailed description of the type such as "Landsat series surface reflectance products"), definition (JSON dynamic definition of product specifications), permission (permission coding such as rw read-write permission / rx execution permission), owner (standard owner such as "USGS / NASA"), onlinepaper (associated technical white paper URL), and extension (marker for whether it is a user extended type).

[0153] 3) The grid data type table (uss_raster_datatypes) is the basic type library of the grid data model, which constructs a three-level classification system through the fixed fields datatypeid (unique identification of data type), datasettype (associated data set type name such as "satellite image set" / "terrain data set"), and datatypename (basic type name). Four fields are extended to realize scientific research-level fine control: description (data type technical description), definition (JSON dynamic definition type specification), owner (standard owner such as "ESA / NASA"), and extension (user extension type such as "water quality inversion index"). Through the dynamic JSON definition and strong type association mechanism, this table realizes the unified type registration from raw data collection (such as "Sentinel-2 multispectral") to thematic product derivation (such as "NDVI vegetation index"), and provides a core type benchmark for remote sensing data standardization analysis and thematic product automatic generation.

[0154] 4) The grid data set layer table (uss_raster_dataset_layers) is the core table of the grid data, which constructs the basic framework of the grid layer through the fixed fields layerid (global unique identification of the layer), datasetid (strongly associated data set ID), srsid (bind spatial reference system ID, associate with uss_meta_srs to realize coordinate system unity), rastername (layer business name), and datapath (physical storage absolute path). Five fields are extended to realize multi-source grid deep integration: storepath (external service virtual path), filetype (file format encoding), filesubtype (storage subtype), description (grid data description), and storeinfo (JSON storage information). Through the strong binding of physical path and spatial reference (datapath + srsid), service path decoupling (datapath internal storage orepath external release), and dynamic metadata extension (storeinfo custom parameters), this table realizes the unified layer registration, standardized service release, and scientific-level metadata management from raw satellite image (such as Landsat multispectral file) to real-time grid product, and provides core support for cross-platform grid data sharing and analysis.

[0155] 5) The raster layer extension table (uss_raster_dataset_layer_properties) is recorded as a raster data extension table, which builds a basic image parameter framework through fixed fields propertyid (unique identification of attribute record), layerid (ID of the associated raster layer), numbands (number of bands), pixeldepth (pixel bit depth such as 16 bit), ysizeize (image row and column size), haspyramids (pyramid construction state: 0 not built / 1 built). Ten fields are extended to realize deep spatial analysis and visualization optimization: spatial range (minx / miny / maxx / maxy records the geographical boundary box), acquisition attribute (sensortype marks the sensor such as “OLI_TIRS”), numerical definition (nodata sets the invalid value), vector boundary (polygonbounds stores the WKT format accurate range surface, the coordinate system is consistent with srsid), statistics engine (statistics stores the band statistical value {“Band1”:{“min”:0.1,“max”:0.8,“mean”:0.35}} in JSON), metadata warehouse (metadata stores the original header file in XML / JSON format), visualization auxiliary (thumbnail stores the JPEG binary thumbnail). The table provides real-time feedback through the pyramid state (haspyramids=1 triggers fast zooming), accurate spatial range double storage (boundary box + vector surface guarantees zero error of spatial query), and scientific statistics precalculation (statistics drives adaptive rendering), which provides metadata support for remote sensing image analysis (such as NDVI calculation) and digital terrain application.

[0156] 3) Scene storage (SQLite file in the subdirectory such as SceneMeta.db manages metadata):

[0157] 1) The three-dimensional model dataset table (uss_scene_datasets) is a logical management unit of the three-dimensional scene, which core contains five fixed fields: datasetid (unique identification of the dataset), datasetname (name), datasettype (dataset type), description (description), and createtime (creation time), which are used for structured organization of three-dimensional resources; the extended field subtype (subtype) realizes fine classification of the three-dimensional scene, and supports hierarchical positioning of storage-> dataset-> resource.

[0158] 2) Three-dimensional model dataset type table (uss_scene_datasettypes) as the registration hub of three-dimensional model dataset type, the core contains 2 fixed fields: datasettypeid (type unique identifier), datasetname (type name); The extended layer realizes type-level security control through definition (JSON storage format specification), permission (permission such as rw readable and writable), extension (extension type mark), and meets the flexible expansion from static model to dynamic semantic scene (such as digital twin).

[0159] 3) Three-dimensional model data type table (uss_scene_datatypes) defines three-dimensional basic type system, the core contains 3 fixed fields: datatypeid (type unique identifier), datasettype (associated dataset type), datatypename (basic type); The extended field definition (JSON storage parameters such as point cloud density), owner (standard owner such as "OGC I3S") extension (whether it is an extended type), supports custom type.

[0160] 4) Three-dimensional model layer table (uss_scene_dataset_layers) is a three-dimensional model layer registration center, which contains 5 fixed fields: layerid (layer unique identifier), datasetid (associated dataset ID), layername (layer name), resourcecount (model resource total number), defaultgeometry (default geometry type); At the same time, 4 kinds of expandable fields are designed: typecodecolumn (feature type code field name, supports UInt32 classification), totalfeatures (layer feature total number statistics), description (layer business description), versioninfo (version change record), through the dynamic registration mechanism, the three-dimensional model data newly entered into the database is realized. The ability of layer-level metadata management, spatial index optimization and version tracking.

[0161] 5) Three-dimensional model table (uss_scene_ <layerid>_model): used to store the three-dimensional model composed of material and mesh and its binary content, the core contains 3 fixed fields: modelid (model unique identification), modelname (model name), parentid (parent model ID); at the same time, 3 types of extension fields are designed: meshid (associated mesh ID), materialid (associated material ID), transform (float[4*4] array used to record transformation parameters).

[0162] 6) three-dimensional model material table (uss_scene_ <layerid>Material: stores the material information of the 3D model, the core contains 2 fixed fields: materialid (material unique identifier), materialname (material name); at the same time, 12 types of extended fields are designed: basecolor (base color (RGBA) float, metallic (metallic degree (float)), roughness (roughness (float)), emissive_factor (self-luminous color (RGB) float, alphacutoff (transparency threshold (float)), alphamode (transparency mode: OPAQUE / MASK / BLEND), doublesided (whether double-sided (bool)), basecolortexture (base color texture ID (int)), metallicroughnesstexture (metallic roughness texture ID (int)), normaltexture (normal texture ID (int)), emissivetexture (self-luminous texture ID (int)), occlusiontexture (ambient light occlusion texture ID (int)).

[0163] 7) Three-dimensional model texture table (uss_scene_ <layerid>texture): used to store the texture information of the three-dimensional model material, the core contains two fixed fields: textureid (texture unique identifier), texturename (texture name); at the same time, eight kinds of extension 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 (min filter mode (enum)), mag_filter (mag filter mode (enum)), path (storage address (string)).

[0164] 8) three-dimensional model mesh table (uss_scene_ <layerid>Meshes): The core contains 13 fixed fields: primitive type, vertex count, index count, has normal, has texcoord1, has texcoord2, has color, has tangent, has batchid, vertex data, index data, normal data, texcoord data1, texcoord data2, color data, tangent data, batchid data; and 6 extension fields: normal data, texcoord data1, texcoord data2, color data, tangent data, batchid data.

[0165] It should be noted that the vector data is stored in the corresponding database file by Feature storage, including:

[0166] A dataset record is created or associated in the vector dataset table as the first target data;

[0167] A layer record is created for the first target data in the vector layer table, the first target data is stored in the vector layer table, and the dataset ID to which it belongs is associated;

[0168] The metadata of the target data layer record is filled in the vector data list, the vector data space list, and the vector data space attribute table, and the layer ID of the first target data in the vector layer table is associated;

[0169] Specifically, a dataset record is created or associated in the vector dataset table, the vector data belongs to the dataset name, description, and type (derived from the file name / user input) → stored in the vector dataset table (Dataset_Name, Description, Dataset_Type);

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

[0171] Fill in the detailed metadata of the layer in the vector data list, vector data space list, and vector data space attribute table,

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

[0173] Store two-dimensional raster data into the corresponding database file under Raster storage, including:

[0174] Copy / move the raster file to the parallel subdirectory of the Raster database file, or migrate the complete directory structure of the slice file set to the parallel subdirectory of the Raster database file;

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

[0176] 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 the dataset ID to which it belongs;

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

[0178] Specifically, use tools to copy / move the raster file (TIFF) to the appropriate location under the Raster storage subdirectory (such as storing by satellite / time classification), or migrate the complete directory structure of the slice file set to the subdirectory.

[0179] In addition, a dataset record is created or associated in the raster dataset table, and its associated physical path is recorded (such as / RasterDataSet1 / Sentinel2 / 20230710 / or / RasterDataSet2 / Tiles_WebMercator / );

[0180] A layer record is created in the raster layer table for the raster data / tile set, the associated dataset ID is associated, and information such as spatial reference, geographic range resolution, band number, pyramid creation is stored in the layer for searching;

[0181] Parameters such as invalid value (NoData), compression method, tile size, etc. are written in the raster layer extension information table, and the layer ID is associated.

[0182] Three-dimensional model data is stored in the corresponding database file through Scene storage, including:

[0183] The three-dimensional model resource directory of the three-dimensional model data is copied / moved to the parallel subdirectory of the Scene database file, and the original file structure and resource dependency relationship of the three-dimensional model data are maintained through the metadata table mapping;

[0184] A dataset record is created or associated in the three-dimensional scene dataset table for the third target data;

[0185] A layer record is created in the three-dimensional model layer table for the third target data, the third target data is stored in the three-dimensional model layer table, and the dataset ID to which it belongs is associated;

[0186] The three-dimensional model of the third target data is added to the three-dimensional model table, a record is created for each model file under the dataset directory, and the three-dimensional layer ID to which it belongs is associated;

[0187] The material information of the three-dimensional model is added to the three-dimensional model material table, and the model ID of the third target data in the three-dimensional model table is associated;

[0188] The texture information of the three-dimensional model is added to the three-dimensional model texture table, and the material ID of the third target data in the three-dimensional model material table is associated;

[0189] The mesh information of the three-dimensional model is added to the three-dimensional model mesh table, and the model ID of the third target data in the three-dimensional model table is associated;

[0190] If the texture is embedded in the binary model file, the offset in the binary file of the model is recorded in the three-dimensional model table.

[0191] Specifically, the tool is used to copy / move the entire three-dimensional model resource directory (containing model files, texture subfolders, etc.) to the corresponding position of the Scene storage subdirectory (such as / Scene_Storage / Models / ), and the original file structure and resource dependency relationship are maintained through the metadata table mapping. For example, model files (such as / Models / model.dts), texture files (such as / Materials / wall.jpg, / Materials / roof.png), and associated resources (such as / Materials / metallic.mtl)

[0192] In addition, a dataset record is created or associated in the three-dimensional scene dataset table;

[0193] Subsequently, the three-dimensional model is added to the three-dimensional model table, and a record is created for each model file under the dataset directory, containing the model file name, file type, relative path, file version, geometry type, vertex number, texture number, and extended metadata. The model depends on the material and the mesh, and the material name ["glass_material"] corresponding to the id is stored in the materialid field of the model table record.

[0194] Then, the information of the three-dimensional model texture and material is added to the three-dimensional 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, and the texture path ["textures / wall.jpg"] is stored in the texture field of the material record.

[0195] If the texture is embedded in the binary model file, the binary offset is recorded in the Embedded_Resources field of the model table record, which facilitates quick positioning of the embedded texture position of the model through the three-dimensional model table.

[0196] Embodiment Two

[0197] Figure 2 is a structural schematic diagram of a multi-source heterogeneous spatio-temporal data fusion modeling system provided by an embodiment of the present application, referring to Figure 2 A multi-source heterogeneous spatio-temporal data fusion modeling system comprises:

[0198] a processor 21 and a memory 22;

[0199] The processor 21 and the memory 22 are connected through a communication bus:

[0200] The processor 21 is configured to call and execute the program stored in the memory 22.

[0201] The memory 22 is configured to store a program, which is used at least to execute the multi-source heterogeneous spatio-temporal data fusion modeling method according to one of the above embodiments.

[0202] It can be understood that the same or similar parts in the above embodiments can be mutually referred to, and the content not described in detail in some embodiments can be referred to the same or similar content in other embodiments.

[0203] It should be noted that, in the description of the present application, the terms "first", "second" and the like are used only for descriptive purposes, and should not be construed as indicating or implying relative importance. In addition, in the description of the present application, unless otherwise specified, the meaning of "a plurality of" is at least two.

[0204] Any process or method descriptions in flow charts or described herein in other ways can be understood as representing code modules, segments, or portions of code that include one or more executable instructions for performing specific logic functions or steps in the process, and that the various embodiments of the application include the use of additional or different modules, segments, or portions of code when performing the same functions or steps. The various embodiments of the application can be further understood from the following examples.

[0205] It should be understood that each part of the present application can be realized by hardware, software, firmware or their combination. In the above embodiments, a plurality of steps or methods can be realized by software or firmware stored in the memory and executed by a suitable instruction execution system. For example, if realized by hardware, and as in another embodiment, it can be realized by any one or their combination of the following technologies known in the art: discrete logic circuit with logic gate circuit for implementing logic function on data signal, application specific integrated circuit with suitable combination logic gate circuit, programmable gate array (PGA), field programmable gate array (FPGA) and the like.

[0206] Those skilled in the art of the present technology can understand that all or part of the steps carried out by the above-mentioned embodiment method can be completed by a program instructing the relevant hardware, and the program can be stored in a computer readable storage medium, and the program includes one or a combination of the steps of the method embodiment when executed.

[0207] In addition, each functional unit in each embodiment of the present application can be integrated in one processing module, or each unit can be physically present separately, or two or more units can be integrated in one module. The above integrated module can be realized in the form of hardware or in the form of a software function module. The integrated module, if realized in the form of a software function module and sold or used as an independent product, can also be stored in a computer readable storage medium.

[0208] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0209] In the description of the present specification, the description referring to the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Also, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

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

Claims

1. A multi-source heterogeneous spatio-temporal data fusion modeling method, characterized in that, The method comprises the following steps: creating a root directory as a physical address of a spatial data model on a computer system; creating a core metadata system table in the root directory, taking a database file as a global manager; under the structure of the root directory, creating subdirectories corresponding to respective storage object types as physical addresses of the storage object types; the storage object types include vector data, two-dimensional raster data and three-dimensional model data; the subdirectories are independent of each other; adding relevant data of the respective storage object types in the core metadata system table; creating and initializing a database file corresponding to the storage object type under the subdirectory, and generating a dedicated metadata table corresponding to the storage object type in the database file; obtaining two-dimensional and three-dimensional joint data of a real scene as to-be-stored data, converting the to-be-stored data by calling a corresponding data conversion tool based on the type of the to-be-stored data, storing the to-be-stored data in a corresponding database file by a corresponding storage mode, and associating the to-be-stored data with the dedicated metadata table in the database file; wherein the storage mode corresponding to the vector data is Feature storage; the storage mode corresponding to the two-dimensional raster data is Raster storage; and the storage mode corresponding to the three-dimensional model data is Scene storage.

2. The method of claim 1, wherein, The method further comprises the following steps: receiving a data access request, locating target storage data according to the data access request, and obtaining the type, physical address and dedicated metadata table of the target storage data; calling a corresponding driver according to the type of the target storage data, and accessing the target storage data according to the physical address and the dedicated metadata table of the target storage data.

3. The method of claim 1, wherein, The core metadata system table comprises a storage definition table, a storage type definition table, a data driver table, a spatial reference system table and a server configuration information table; the storage definition table, the storage type definition table, the data driver table, the spatial reference system table and the server configuration information table each comprise a plurality of fixed fields and a plurality of extensible fields; the storage definition table serves as a unified registration center of the spatial data model, is initially empty, and dynamically inserts a record when a storage object is newly created, so as to realize synchronization of storage creation and metadata registration; the storage type definition table supports integration and management of new storage types through an extension mechanism; the data driver table provides differentiated data analysis, format conversion and access service capabilities for different storage types through a dynamic registration mechanism; the spatial reference system table realizes fusion and cross-platform analysis of two-dimensional data and three-dimensional data under a unified spatial reference through a multi-format compatible design; the server configuration information table supports dynamic loading of service parameters and driver-level differentiated configuration through a key-value storage and driver binding mechanism.

4. The method of claim 1, wherein, The database file is used for managing stored data and the relationship between the data; wherein different storage object types have different data storage rules.

5. The method of claim 4, wherein, The data storage rules of the vector data include: storing all data through a Feature database file; the data storage rules of the two-dimensional raster data include: storing a dedicated metadata table through a Raster database file; Create a parallel subdirectory of the newly created Raster database file to store raster data files or tile slice files; The data storage rules of three-dimensional model data include: Store the exclusive metadata table through the Scene database file; Create a parallel subdirectory of the newly created Scene database file to store three-dimensional model files, material / texture files and other dependent resources, and maintain the original directory structure of the three-dimensional model files to maintain the dependency between resources.

6. The method of claim 5, wherein, The metadata table design rules of different storage methods are different.

7. The method of claim 6, wherein, The metadata table design rules of Feature storage include: Build a vector dataset table as a logical management unit of vector data, and configure the logical hierarchy of vector data between storage, dataset and layer; Build a vector dataset type table as a core register table of vector data, bind permissions, and configure a JSON dynamic expansion mechanism; Build a vector data type table as a standard library of vector data, and realize unified registration and standardized management of basic types and custom types of vector data through a JSON dynamic definition mechanism; Build a vector layer table as a layer registration center of vector data, and realize metadata management, spatial indexing and version tracking of the layer level of newly imported vector data through a dynamic registration mechanism; Build a vector data list as a core metadata table of a spatial data model, and undertake the functions of standardized definition and dynamic control of the attribute structure of the vector data layer; the vector data list realizes automatic registration, value domain consistency and business logic integration of the table structure of newly imported vector data through field-level atomization control, constraint linkage and semantic mapping; Build a vector data space list as a pivot of multi-dimensional geometric expression of a spatial data model; the vector data space list configures a mechanism for coexistence of multiple geometric columns of the same vector layer, dynamic coordinate system adaptation and mixed indexing strategy; Build a vector data space range statistics table as a dynamic range index engine of a spatial data model; the vector data space range statistics table configures an automatic range calculation and dynamic update mechanism; The metadata table design rules of Raster storage include: Build a raster dataset table as a logical management pivot of two-dimensional raster data; realize unified registration and spatio-temporal organization of raster data through path rules and multi-level type coding; Build a raster dataset type table as a standard definition library of two-dimensional raster dataset; Build a raster data type table as a basic type library of a two-dimensional raster data model; the raster data type table configures a JSON dynamic definition mechanism and a strong type association mechanism; Build a raster dataset layer table as the core table of two-dimensional raster data; the raster dataset layer table realizes unified layer registration, standardized service publishing and metadata management of original satellite images to real-time raster products through strong binding of physical path and spatial reference, service path decoupling and dynamic metadata expansion; Build a raster layer extension information table as a two-dimensional raster data extension information record table; the raster layer extension information table provides metadata support for remote sensing image analysis and digital terrain application through double storage of pyramid information and accurate spatial range and scientific statistical precalculation; The metadata table design rules of Scene storage include: Constructing a three-dimensional model dataset table as a logical management unit of a three-dimensional scene; Constructing a three-dimensional model dataset type table as a registration hub of three-dimensional model dataset types; Constructing a three-dimensional model data type table to define a three-dimensional basic type system; Constructing a three-dimensional model layer table as a layer level registration center of three-dimensional model data, and configuring a dynamic registration mechanism to realize metadata management, spatial indexing and version tracking of a layer level of newly-stored three-dimensional model data; Constructing a three-dimensional model table to store three-dimensional models and binary contents thereof constructed by assembling meshes and materials; Constructing a three-dimensional model material table to store three-dimensional model material data; Constructing a three-dimensional model texture table to store texture map contents associated with materials; Constructing a three-dimensional model mesh table to store three-dimensional model mesh data.

8. The method of claim 7, wherein, Storing vector data into corresponding database files through Feature storage, including: Creating or associating a dataset record in a vector dataset table as a first target data; Creating a layer record for the first target data in a vector layer table, storing the first target data into the vector layer table, and associating a dataset ID thereof; Filling metadata of the layer record of the target data in a vector dataset list, a vector data space list and a vector data space attribute table, and associating a layer ID of the first target data in the vector layer table; Storing two-dimensional raster data into corresponding database files through Raster storage, including: Copying / moving raster files to a parallel subdirectory of a Raster database file, or migrating a complete directory structure of a slice file set to the parallel subdirectory of the Raster database file; Creating or associating a dataset record in a raster dataset table as a second target data; Creating a layer record for the second target data in a raster dataset layer table, storing the second target data into the raster dataset layer table, and associating a dataset ID thereof; Writing parameters of the second target data in a raster layer extension information table, and associating a layer ID of the second target data in the raster dataset layer table; Storing three-dimensional model data into corresponding database files through Scene storage, including: Copying / moving a three-dimensional model resource directory of three-dimensional model data to a parallel subdirectory of a Scene database file, and maintaining an original file structure and resource dependency relationship of the three-dimensional model data through metadata table mapping; Creating or associating a dataset record in a three-dimensional scene dataset table as a third target data; Creating a layer record for the third target data in a three-dimensional model layer table, storing the third target data into the three-dimensional model layer table, and associating a dataset ID thereof; Adding a three-dimensional model of the third target data to a three-dimensional model table, creating a record for each model file under a dataset directory, and associating a three-dimensional layer ID thereof; Adding material information of the three-dimensional model to a three-dimensional model material table, and associating a model ID of the third target data in the three-dimensional model table; Adding texture information of the three-dimensional model to a three-dimensional model texture table, and associating a material ID of the third target data in the three-dimensional model material table; Add the grid information of the three-dimensional model to the three-dimensional model grid table, and associate the model ID of the third target data in the three-dimensional model table; If the texture is embedded in the binary model file, record the offset in the model binary file in the three-dimensional model table.

9. The method of claim 2, wherein, According to the type of the target storage data, a corresponding drive is called, and the target storage data is accessed according to the physical address of the target storage data and the exclusive metadata table, including: If the target storage data is vector data, read the Feature database file, and use the vector data set table and the vector layer table to locate the target storage data; If the target storage data is two-dimensional raster data, read the Raster database file, and use the raster data set table and the raster data set layer table to locate the target storage data; If the target storage data is three-dimensional model data, read the Scene database file, and use the three-dimensional model data set table and the three-dimensional model layer table to locate the target storage data.

10. A multi-source heterogeneous spatio-temporal data fusion modeling system, characterized in that, It comprises: a processor and a memory; the processor and the memory are connected through a communication bus: wherein the processor is used to call and execute the program stored in the memory; the memory is used to store a program, and the program is used to execute the multi-source heterogeneous spatio-temporal data fusion modeling method of any one of claims 1-9.

Images