Figure library integrated industrial production software system based on modular low-coupling architecture

Abstract

The invention discloses a gallery integrated internal production software system based on a modular low-coupling architecture, which is characterized in that a system function is divided into a plurality of modularized modules and the modularized modules are packaged and deployed by a uniform interface, so that the coupling degree between the modules is remarkably reduced, and the problem of global code change caused by module dependence in a traditional single architecture is avoided; direct calling is replaced by an event-driven mechanism, asynchronous communication and decoupling cooperation between modules are realized, and the stability and maintainability of the system during function change or addition are improved; the configuration driving mechanism enables the business process to be dynamically adjusted, different business requirements can be met without modifying a program source code, the plug-in management mechanism provides a standardized third-party extension access channel and supports function loading according to requirements, and the limitation that a traditional system is fixed in function and closed in development is broken through; according to the method, the software can run consistently in Windows, Linux, MacOS and other environments, and the key problems that in the prior art, the coupling degree is high, the expansibility is poor, configuration is not flexible, and the platform adaptation capacity is weak can be effectively solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of atlas integrated office production software, in particular to an atlas integrated office production software system based on a modular low-coupling architecture. BACKGROUND

[0002] In the field of geographic information systems (GIS) and computer-aided design (CAD), atlas integrated office production software systems play a key role in land space management, real estate registration, cadastral survey, and other businesses. Such systems integrate geographic spatial data, surveying information, and ownership information, and realize functions such as terrain modeling, parcel management, and map output, serving as an important foundation platform for informationization construction of natural resource management departments. With the acceleration of land informationization construction, businesses have higher requirements for the flexibility, processing accuracy, and platform compatibility of software systems, and traditional software architectures have been unable to meet the complex and changing business needs.

[0003] Currently, atlas integrated office production software mostly uses monolithic architecture design, integrating functions such as graphics rendering, data processing, and information storage in a single executable file. Although this architecture is convenient for early system development, its shortcomings become increasingly apparent as functions become more diverse and business scenarios expand. First, the coupling between function modules is high, and changes to a single module can trigger a chain reaction of the entire code, increasing maintenance risks and development costs. Second, traditional software lacks versatility and flexibility in graphics rendering and data storage methods, resulting in poor cross-platform adaptability and making it difficult to meet deployment needs in multi-operating system environments. In addition, business processes and parameters are usually hard-coded within the system, making it difficult for users to respond quickly and dynamically configure when facing new business scenarios. In terms of functionality, existing systems have obvious shortcomings in surveying and delimiting accuracy, land mapping efficiency, real estate registration standardization, and image interpretation intelligence, affecting overall business processing quality and efficiency.

[0004] Therefore, in the design of atlas integrated office production software systems, high module coupling, difficulty in function expansion, weak platform adaptation capability, and lack of flexibility in business configuration are technical bottlenecks that need to be addressed. SUMMARY

[0005] The present application provides an atlas integrated office production software system based on a modular low-coupling architecture, aiming to solve the problems of high module coupling, difficulty in function expansion, weak platform adaptation capability, and lack of flexibility in business configuration in the design of existing atlas integrated office production software systems.

[0006] In a first aspect, an atlas integrated office production software method based on a modular low-coupling architecture is provided, the method comprising:

[0007] The functional module set includes multiple modules with independent functional responsibilities. Each module is encapsulated as a component unit and deployed in the form of a dynamic link library or shared object file. The modules are decoupled from each other through standard input / output interfaces to achieve data and control logic.

[0008] The module registration mechanism, including a module registrar, a module identifier resolver, and a lifecycle controller, is used to parse the module list in the configuration file during system initialization and complete module loading, initialization, and runtime status management.

[0009] The configuration-driven mechanism, including a configuration reader and a configuration injection engine, is used to load structured configuration files and dynamically construct the module execution order, parameter passing path, and data flow based on the information defined therein.

[0010] The event-driven communication mechanism includes an event registry, an event scheduling engine, and event listeners. Each module accesses the event bus through registration and subscription, enabling non-blocking communication across modules.

[0011] The plugin management submodule, including a plugin scanner, an interface validator, and a runtime adapter, is used to identify and integrate third-party extension modules that conform to the standard plugin interface specification.

[0012] The metadata management module is used to manage the metadata information of each functional module, including input and output parameters, dependent modules, version number, interface documentation path, etc.

[0013] The cross-platform compatibility subsystem, built on the Qt framework and OpenGL graphics library, is used to encapsulate platform-related calling logic, enabling the system to run on Windows, Linux, and macOS platforms.

[0014] The process orchestration tool provides a visual business process design interface, allowing users to set the order of module nodes, parameter connections, condition judgments, and logical jumps by dragging and dropping, and generate process configuration files that can be recognized by the system.

[0015] Optionally, in the above scheme, the set of functional modules includes:

[0016] The graphics rendering module is used to load and render vector data, raster images, and 3D model data, and supports coordinate transformation, layer overlay, and geographic projection processing.

[0017] The data storage module is used to support unified read and write management of SQLite databases, spatial data files, and intermediate cache files;

[0018] The surveying and demarcation module is used to automatically generate boundary points, measure land parcel boundaries, and automatically assign land parcel numbers.

[0019] The terrain mapping module is used to automatically extract contour lines, slope maps, and 3D terrain from DEM data;

[0020] The real estate registration module is used to construct the ownership information structure and complete the generation of land parcel maps and the output of certificate information;

[0021] The current status survey module is used for image interpretation, land use classification, and change detection and analysis.

[0022] Optionally, in the above scheme, the event-driven communication mechanism includes:

[0023] An event registry is used to register events of interest during the module initialization phase.

[0024] Event triggers are used to emit event signals after the business logic within a module is completed;

[0025] The event scheduling engine is used to schedule and forward events to subscribed modules based on event priority;

[0026] The event callback function manager is used to register callback interfaces and implement task processing logic after an event is triggered.

[0027] In the above scheme, optionally, the configuration file for the configuration-driven mechanism adopts XML or JSON format and contains the following structural information:

[0028] Module enable flag; call chain execution order; module input parameter binding rules; module output data path; exception handling strategy and retry logic definition; plugin loading path and permission configuration.

[0029] Optionally, in the above scheme, the plug-in management submodule includes:

[0030] Plugin directory scanner, used to scan plugin modules in the system's preset paths;

[0031] The plugin interface matcher is used to determine the consistency of plugin interfaces by comparing them with the interface specification document.

[0032] A plugin metadata parser is used to parse the feature descriptions and dependency descriptions embedded in plugins.

[0033] A plugin sandbox container is used to isolate plugin memory space and resource access permissions during system operation.

[0034] Optionally, in the above scheme, the process orchestration tool includes:

[0035] A graphical node editor for visually drawing business processing flows;

[0036] Data flow connectors are used to define the direction of data transfer and field mapping between modules;

[0037] The conditional decision-maker is used to configure the branching logic based on the rule engine;

[0038] A compiler is used to compile flowcharts into structured configuration scripts that can be recognized and executed by the host system.

[0039] Secondly, a method for operating an integrated image library production system, applicable to modular, plug-in business software systems, includes the following steps:

[0040] In response to the user's startup input, read the configuration file and parse the required functional modules and their execution order;

[0041] Register all functional modules and complete initialization and resource binding according to dependencies;

[0042] Start the event-driven bus and establish event subscription and listening channels between modules;

[0043] Receive user input or external task requests and start the main process scheduler;

[0044] The scheduler calls the functional modules to process the input data sequentially according to the process configuration;

[0045] If the configuration file contains a plugin path, then load the plugin module and add it to the processing flow;

[0046] After processing, the system exports graphics, tables, or database files as output.

[0047] In the above scheme, optionally, the configuration file is generated by the user through a process orchestration tool. The file contains the business process number, module type, execution priority, abnormal interruption conditions and task output requirements.

[0048] In the above scheme, optionally, in starting the event-driven bus and establishing event subscription and listening channels between modules, the event bus is constructed as a thread-safe asynchronous scheduling channel, the event subscription relationship is completed during the module registration phase, and the event handling callback function supports multi-level linkage triggering.

[0049] In the above scheme, optionally, the plug-in module exists in the form of a shared object file or a dynamic link library, and is loaded after being verified by interface standard and permission control policy. During operation, it is hosted by the plug-in container and executed in parallel with the system's main task chain.

[0050] Compared with the prior art, this application has at least the following beneficial effects:

[0051] Based on further analysis and research of existing technical problems, this application recognizes that existing monolithic image library production software systems suffer from issues such as high module coupling, difficulty in functional expansion, weak platform adaptability, and lack of flexibility in business configuration. By dividing system functions into multiple componentized modules and encapsulating them with a unified interface, the coupling between modules is significantly reduced, avoiding the global code changes caused by module dependencies in traditional monolithic architectures. An event-driven mechanism replaces direct calls, enabling asynchronous communication and decoupled collaboration between modules, improving the system's stability and maintainability during functional changes or additions. A configuration-driven mechanism allows for dynamic adjustment of business processes without requiring modification. The program source code can be adapted to different business needs, effectively solving the problems of poor scalability and weak adaptability of existing systems; the plug-in management mechanism provides a standardized third-party extension access channel, supports on-demand loading of functions, and breaks the limitations of fixed functions and closed development of traditional systems; at the same time, the cross-platform compatibility mechanism is built on Qt and OpenGL, avoiding operating system binding issues and enabling the software to run consistently in environments such as Windows, Linux, and MacOS, fundamentally solving the bottleneck of existing software in terms of platform portability. Therefore, this invention can effectively address the key problems of high coupling, poor scalability, inflexible configuration, and weak platform adaptability in existing technologies. Attached Figure Description

[0052] Figure 1 A business process diagram of a library-based internal production software method based on a modular, loosely coupled architecture, provided as an embodiment of this application;

[0053] Figure 2 A schematic diagram illustrating the dynamic expansion and configuration of a library-in-one internal production software method based on a modular, loosely coupled architecture, provided as an embodiment of this application.

[0054] Figure 3 This is a diagram of the overall architecture of a monolithic software system provided in one embodiment of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0056] In one embodiment, a unified image library production software system based on a modular, loosely coupled architecture is provided, the system comprising:

[0057] The functional module set includes multiple modules with independent functional responsibilities. Each module is encapsulated as a component unit and deployed in the form of a dynamic link library or shared object file. The modules are decoupled from each other through standard input / output interfaces to achieve data and control logic.

[0058] The module registration mechanism, including a module registrar, a module identifier resolver, and a lifecycle controller, is used to parse the module list in the configuration file during system initialization and complete module loading, initialization, and runtime status management.

[0059] The configuration-driven mechanism, including a configuration reader and a configuration injection engine, is used to load structured configuration files and dynamically construct the module execution order, parameter passing path, and data flow based on the information defined therein.

[0060] The event-driven communication mechanism includes an event registry, an event scheduling engine, and event listeners. Each module accesses the event bus through registration and subscription, enabling non-blocking communication across modules.

[0061] The plugin management submodule, including a plugin scanner, an interface validator, and a runtime adapter, is used to identify and integrate third-party extension modules that conform to the standard plugin interface specification.

[0062] The metadata management module is used to manage the metadata information of each functional module, including input and output parameters, dependent modules, version number, interface documentation path, etc.

[0063] The cross-platform compatibility subsystem, built on the Qt framework and OpenGL graphics library, is used to encapsulate platform-related calling logic, enabling the system to run on Windows, Linux, and macOS platforms.

[0064] The process orchestration tool provides a visual business process design interface, allowing users to set the order of module nodes, parameter connections, condition judgments, and logical jumps by dragging and dropping, and generate process configuration files that can be recognized by the system.

[0065] In this embodiment, the set of functional modules includes:

[0066] The graphics rendering module is used to load and render vector data, raster images, and 3D model data, and supports coordinate transformation, layer overlay, and geographic projection processing.

[0067] The data storage module is used to support unified read and write management of SQLite databases, spatial data files, and intermediate cache files;

[0068] The surveying and demarcation module is used to automatically generate boundary points, measure land parcel boundaries, and automatically assign land parcel numbers.

[0069] The terrain mapping module is used to automatically extract contour lines, slope maps, and 3D terrain from DEM data;

[0070] The real estate registration module is used to construct the ownership information structure and complete the generation of land parcel maps and the output of certificate information;

[0071] The current status survey module is used for image interpretation, land use classification, and change detection and analysis.

[0072] In this embodiment, the event-driven communication mechanism includes:

[0073] An event registry is used to register events of interest during the module initialization phase.

[0074] Event triggers are used to emit event signals after the business logic within a module is completed;

[0075] The event scheduling engine is used to schedule and forward events to subscribed modules based on event priority;

[0076] The event callback function manager is used to register callback interfaces and implement task processing logic after an event is triggered.

[0077] In this embodiment, the configuration file for the configuration-driven mechanism is in XML or JSON format and contains the following structural information:

[0078] Module enable flag; call chain execution order; module input parameter binding rules; module output data path; exception handling strategy and retry logic definition; plugin loading path and permission configuration.

[0079] In this embodiment, the plug-in management submodule includes:

[0080] Plugin directory scanner, used to scan plugin modules in the system's preset paths;

[0081] The plugin interface matcher is used to determine the consistency of plugin interfaces by comparing them with the interface specification document.

[0082] A plugin metadata parser is used to parse the feature descriptions and dependency descriptions embedded in plugins.

[0083] A plugin sandbox container is used to isolate plugin memory space and resource access permissions during system operation.

[0084] In this embodiment, the process orchestration tool includes:

[0085] A graphical node editor for visually drawing business processing flows;

[0086] Data flow connectors are used to define the direction of data transfer and field mapping between modules;

[0087] The conditional decision-maker is used to configure the branching logic based on the rule engine;

[0088] A compiler is used to compile flowcharts into structured configuration scripts that can be recognized and executed by the host system.

[0089] This embodiment proposes a modular, loosely coupled image library integrated production software system. The system consists of multiple functional modules, a module registration mechanism, a configuration-driven mechanism, an event-driven communication mechanism, a plug-in management mechanism, a metadata management module, a cross-platform compatible subsystem, and a process orchestration tool. Its overall architecture is based on the unified design concept of "component-based encapsulation + decoupled communication + configuration control + plug-in extension + cross-platform operation", which enables rapid adaptation and efficient execution in multiple business scenarios.

[0090] During implementation, developers first divide the system's functionality into multiple functional modules based on business requirements. Each module undertakes only one functional responsibility. For example, the graphics rendering module is only responsible for geographic map visualization, the data storage module is only responsible for data I / O management, the surveying and demarcation module focuses on coordinate calculation and parcel delineation, and the terrain mapping module focuses on terrain data processing. Each module uses a unified interface specification (such as standard input / output functions, JSON or GeoJSON format) and is encapsulated as a dynamic link library (Windows platform) or a shared object (Linux platform) to ensure that it has independent compilation, deployment, and testing capabilities.

[0091] The module registration mechanism loads the main configuration file at system startup, identifies modules marked as "enabled" in the configuration, and mounts them to the main runtime environment through the registrar. During registration, the module's metadata (such as version number, input / output parameters, dependent module names, etc.) is injected into the module management table, triggering its initialization process.

[0092] The configuration-driven mechanism is responsible for reading and parsing configuration files in XML or JSON format. These files define the complete module call chain, parameter mapping relationships, task flow order, exception rollback strategies, and more. Through the configuration injection engine, the system can automatically build processing pipelines based on the process structure, enabling business process switching without requiring code modifications.

[0093] Inter-module communication is built on an event-driven mechanism. The system maintains an event bus. Functional modules register events of interest through an event registry and publish these events to the event scheduler after completing their internal business logic processing. The event bus automatically forwards events based on subscription relationships, achieving decoupled communication between modules. For example, when the surveying and demarcation module completes parcel generation, it publishes a "parcel completed" event. Upon receiving this event, the land mapping module can then perform subsequent tasks such as contour line overlay rendering.

[0094] The plugin management mechanism supports third-party plugin integration. The system pre-defines plugin interface specifications (interface methods, data formats, exception handling specifications, etc.), and periodically scans for extended plugin files (DLLs or .so) in a specified directory using a plugin scanner. It then injects these files into the main system runtime environment using an interface adapter, enabling extensions such as AI image interpretation and 3D modeling.

[0095] To enable efficient collaboration among modules, the system also includes a metadata management module. This module generates standardized metadata files for each functional module, describing its input and output parameters, dependencies, usage restrictions, and interface signatures. These files are automatically parsed and verified by the system during runtime, enhancing the system's dynamic loading capabilities.

[0096] The cross-platform compatible subsystem is built on the Q graphics development framework and OpenGL rendering library. The system core does not depend on specific platform APIs. All file access, window management, and graphics interfaces are encapsulated as platform-independent interfaces, ensuring that the software can be deployed uniformly in Windows, Linux, and macOS environments.

[0097] The workflow orchestration tool provides a graphical configuration interface on the client side, allowing users to configure business process nodes and data paths through drag-and-drop. The system then compiles the user-edited graph structure into a structured configuration file for the main system to load. This mechanism significantly improves the system's flexibility and business adaptability.

[0098] This solution employs modular component encapsulation and an event-driven communication mechanism, avoiding direct function calls and data dependencies between modules. This significantly reduces coupling between system modules, ensuring that the development, testing, and deployment of a single module do not affect other modules, thus improving maintainability and code quality. Through configuration-driven and plugin loading mechanisms, the system can dynamically add or remove functional modules without recompilation. Visual workflow tools allow for adjustments to module order and processing logic, drastically shortening the new feature deployment cycle from traditional weekly deployments to hourly deployments. Built on Qt and OpenGL, this system is decoupled from specific operating system APIs, with standardized module interfaces and unified encapsulation of graphics and system calls. This allows the same software architecture to be applied to multiple platforms, including Windows, Linux, and macOS, expanding the system's application scope. Through metadata management and unified interface definitions, modules from different developers or sources can run collaboratively on the same platform, supporting seamless integration of various business processes such as land surveying, real estate registration, and current status investigation.

[0099] The integrated image library production software system provided in this embodiment is not only innovative and complete in terms of module encapsulation, system coupling, functional expansion and platform compatibility, but also fully covers the urgent needs for high precision, high scalability and high stability in the construction of land information systems, and has significant engineering applicability value.

[0100] In one embodiment, a modular, loosely coupled map library-based data processing software system is provided. In the fields of Geographic Information Systems (GIS) and Computer-Aided Design (CAD), this software plays a crucial role in processing geospatial data. However, traditional map library-based data processing software often employs a monolithic architecture, which exposes numerous drawbacks in practical applications. The specific design of traditional map library-based data processing software is as follows:

[0101] The architecture employs a monolithic approach, integrating all functionalities into a single executable file. The functional modules are tightly coupled, with complex inter-module calls and dependencies. For example, the data display module depends on the data processing module's specific output format, which in turn depends on the data storage module's specific data structure. In this architecture, modifying a single function can trigger global code changes, increasing the difficulty and risk of development and maintenance. Figure 3 This is a diagram of the overall architecture of a monolithic software system provided in one embodiment of this application.

[0102] Basic functional support: It adopts relatively traditional and simple graphics rendering technology, data storage methods, and general utility functions. Graphics rendering may only be compatible with the graphics interface of a specific operating system, lacking cross-platform compatibility; data storage may only rely on one database type, unable to flexibly cope with different types of data storage needs; general utility functions may be scattered in various functional modules, resulting in poor reusability.

[0103] The existing technical solutions have the following shortcomings:

[0104] High module coupling: In a monolithic architecture, functional modules are tightly connected and interdependent. The specific format and structure dependencies between data display, processing, and storage modules mean that modifying one module can trigger a chain reaction, leading to global code changes. This not only increases the difficulty of feature iteration and maintenance during development but also raises the risk of introducing new errors. A change in one part can have far-reaching consequences, significantly impacting development and maintenance efficiency.

[0105] Lack of scalability: The overall architecture limits the system's flexibility for expansion. Adding new features requires comprehensive consideration of the impact on existing modules, often leading to large-scale code modifications and recompilation and deployment. For example, adding data analysis functionality requires adjustments to multiple related modules, which is time-consuming, labor-intensive, and makes it difficult to quickly respond to changes in business needs.

[0106] Insufficient support for basic functions:

[0107] Graphics rendering lacks versatility: Traditional graphics rendering technologies may only be compatible with the graphics interfaces of specific operating systems. When used across platforms, they need to be redeveloped or adapted for different systems, which limits the use of software in multi-operating system environments.

[0108] Poor data storage flexibility: A single database type cannot meet diverse data storage needs. When dealing with multiple data types, such as structured, semi-structured, and unstructured data, it lacks flexibility and efficiency, impacting data management and processing efficiency.

[0109] Low reusability of general-purpose utility functions: General-purpose utility functions are scattered across various modules, failing to form a unified, reusable library. This leads to code redundancy, increased maintenance costs, and reduced development efficiency.

[0110] Professional business function defects:

[0111] Issues with accuracy and coordination in surveying and demarcation: Simple algorithms fail to consider complex factors such as the Earth's curvature and projection distortion, resulting in limited accuracy in coordinate calculations, area measurements, and parcel delineation. Poor coordination among functions hinders efficient workflows, impacting both the accuracy of surveying and demarcation results and overall work efficiency.

[0112] The terrain mapping is ineffective and inefficient: Insufficient optimization of contour line generation, slope analysis, and 3D terrain modeling algorithms results in poor accuracy and visualization of terrain data. When processing large-scale terrain data, rendering efficiency is low, failing to meet the actual business needs for terrain display and analysis.

[0113] The lack of standardization and automation in real estate registration: The management of ownership data lacks standardized processes, making it difficult to guarantee data integrity and accuracy. The creation of land parcel maps and the generation of title certificates rely on manual operations or simple templates, which is not only inefficient but also prone to human error, affecting the quality and efficiency of real estate registration services.

[0114] The current status survey suffers from low accuracy and efficiency: image interpretation, land cover identification, and change detection rely on manual interpretation or simple algorithms, which are ill-suited to handling complex and ever-changing geospatial information. Compared with methods based on advanced technologies such as deep learning, the accuracy and efficiency are significantly insufficient, failing to meet the need for rapid and accurate monitoring of land use status.

[0115] At the module interaction level, direct calls lead to high coupling: direct calls between modules result in tight coupling. Changes in one module can easily affect other modules, reducing system stability. For example, adjusting the functionality of a module may require simultaneous modifications to multiple modules that call it, increasing the difficulty and risk of system maintenance.

[0116] Lack of standard interfaces and abstractions: Without unified interaction standards and interface abstractions, inconsistencies arise in interactions between modules. During development and debugging, it is difficult to understand and manage the interaction logic, increasing development costs and the probability of errors.

[0117] At the system configuration and expansion level, the configuration lacks flexibility: business processes and parameters are hard-coded in the program, preventing users from flexibly customizing them according to different business scenarios. If a change in the business process is required, the source code must be modified and recompiled and deployed, making it impossible to quickly respond to business changes and reducing the system's adaptability and competitiveness.

[0118] Limited scalability: Support for third-party plugins is limited, and system function expansion relies on the internal development team. The lack of standard plugin interfaces and management mechanisms makes it difficult for third-party developers to participate in function expansion, limiting the system's functional richness and innovation capabilities, and hindering the ability to quickly meet diverse business needs with the help of external resources.

[0119] At the cross-platform level, the software suffers from severe platform lock-in: it is tightly bound to a specific operating system and relies on its APIs, libraries, or system calls. Porting the software between different operating systems is difficult, requiring extensive code modifications and adaptation work, limiting its application scope, and failing to meet users' needs for using the software in different operating system environments.

[0120] The technical solution of this embodiment aims to solve a series of technical problems that hinder the efficient operation, flexible expansion, and wide application of existing image library integrated production software based on a monolithic architecture:

[0121] Reducing module coupling and improving maintenance and development efficiency: Existing monolithic software architectures have extremely high coupling between modules, and modifying a single function may trigger global code changes. This application constructs a modular, loosely coupled architecture, dividing the software into multiple independent functional modules. Containerization encapsulation technologies (such as Docker) are used to enable independent deployment and operation of modules, defining unified input / output data formats and module metadata specifications to reduce dependencies between modules. Simultaneously, event-driven architecture and interface isolation and abstraction are employed to achieve loosely coupled interaction, minimizing the impact of module changes on other modules and improving development and maintenance efficiency.

[0122] Achieving convenient feature expansion and shortening business deployment cycles: In a monolithic architecture, feature expansion requires recompiling and deploying the entire system, which is costly and time-consuming. This application leverages a dynamic expansion and configuration mechanism, utilizing dynamic link libraries (DLLs, for Windows platforms) or shared libraries (.so, for Linux platforms) to dynamically load modules, and drives customized business processes through XML or JSON configuration files. This allows new features to be added without restarting the system, business processes to be quickly adjusted to meet the needs of different business scenarios, and significantly shortens the deployment cycle of new business scenarios from weeks to hours.

[0123] Enhancing system flexibility and meeting diverse customization needs: Traditional architectures, due to high module coupling and a lack of flexible configuration mechanisms, struggle to meet the customized requirements of different business scenarios through flexible combination of existing modules. This application provides a visual process orchestration tool, allowing users to customize business processes by dragging and dropping module nodes. It supports intelligent routing based on a rule engine, automatically matching processing modules according to input data, enabling the system to quickly adapt to diverse business needs in multiple fields such as real estate registration and land surveys, greatly enhancing system flexibility.

[0124] Enhancing cross-platform compatibility and expanding software applicability: Existing software is often tightly bound to specific operating systems, resulting in low module reuse and poor cross-platform compatibility. This application adopts a cross-platform technical framework (such as the Qt framework) and a graphics rendering library (such as OpenGL), and uses containerization technology to ensure the coexistence and compatibility of different versions of modules, achieving adaptation to multiple operating systems such as Windows, Linux, and macOS, meeting the operating system usage habits of different users, and expanding the application scope of the software.

[0125] The implementation method of this embodiment is divided into three parts: module development, system integration, and application examples. The specific implementation method is as follows:

[0126] Module Development: Choosing the Appropriate Development Language and Tools: The development language is selected based on the functional characteristics of each module. For the graphics rendering portion of the basic support modules, C++ combined with DirectX (Windows platform) or OpenGL (cross-platform) is used to achieve high-performance graphics processing capabilities. For data storage, C# (with ADO.NET to operate SQLite) or Python (with the SQLite3 library) is used to leverage their concise database operation interfaces. In professional business modules, parts involving complex algorithms (such as contour line generation and image interpretation) are developed using Python combined with relevant scientific computing libraries (such as NumPy and SciPy) and deep learning frameworks (such as TensorFlow and PyTorch) to facilitate algorithm prototyping. For user interface-related modules, C# (with WinForms or WPF for Windows platform) or Java (with Swing or JavaFX for cross-platform development) is used to provide a good user interaction experience. Simultaneously, integrated development environments (IDEs) such as Visual Studio (for C# and C++), PyCharm (for Python), and Eclipse (for Java) are used to improve development efficiency and code quality.

[0127] Adhering to modular design principles: Modular design principles are strictly followed throughout the module development process. Each module has a single, clearly defined functional responsibility, with high cohesion within modules and low coupling between them. For example, the surveying and demarcation module focuses on coordinate calculation, area measurement, and land parcel delineation, without involving business logic unrelated to other modules. Communication between modules is achieved through clearly defined interfaces and data structures, avoiding direct dependencies between modules and the misuse of global variables. Furthermore, detailed documentation is written for each module, including functional descriptions, interface definitions, and usage examples, facilitating understanding and maintenance by other developers.

[0128] System Integration: Building an Event-Driven Interaction System: In the client-side software, a custom event bus class is used to implement the event-driven architecture. For example, an `EventBus` class is created, containing methods for event registration, event publishing, and event handling. Each functional module binds the events it is interested in to the corresponding handling functions by calling the `EventBus`'s registration method. When a module completes a specific task, it calls the `EventBus`'s publish method, triggering the corresponding event. The event bus automatically distributes the event to all modules that have subscribed to that event. To ensure the order and priority of event handling, priority parameters can be set during event registration, and the event bus calls the event handling functions sequentially according to priority.

[0129] Dynamic module loading and configuration management are implemented: On the Windows platform, dynamic module loading is achieved using Dynamic Link Library (DLL) technology. A PluginManager class is created to scan the plugin directory and load compliant DLL files. Module classes defined in the DLL are obtained through reflection, and instances are created. On the Linux platform, shared library (.so) technology is used, employing functions such as dlopen and dlsym to achieve similar dynamic loading functionality. For configuration file management, a ConfigurationManager class is created to read and parse XML or JSON format configuration files. At software startup, ConfigurationManager reads the configuration file and initializes the state, parameters, and data flow of each module based on the configuration information. During runtime, if the configuration file changes, ConfigurationManager can reload the configuration file and dynamically adjust the system's business processes.

[0130] Application Example: Real Estate Data Production Scenario: After the user starts the client-server software, the system reads the configuration file to determine the modules and their order involved in the real estate data production business process. Real estate data production begins with basic data acquisition, collecting information such as cadastral districts, cadastral sub-districts, field survey data, and project materials; then, field data is imported to manage rights holder information; next, land parcels are generated, covering integrated land and building rights and operating rights; then, by processing boundary point numbers, attributes are automatically improved; subsequently, information such as building floors and units is converted from topographic data; then, pre-output results reports, maps, and databases are generated; finally, the parcel maps, land parcel sketches, and other results are adjusted to complete the entire process.

[0131] Extended Scenario for Surveying and Demarcation: Suppose that a new 3D modeling function based on UAV oblique photogrammetry data is needed in surveying and demarcation operations. Third-party developers develop corresponding plugin modules (such as a DLL file or a .so file) according to the extension interface specifications and place the plugin in a designated plugin directory. Users dynamically load the plugin through the plugin manager during software runtime. After loading, the plugin interacts with the surveying and demarcation module, using the UAV oblique photogrammetry data to perform 3D modeling, providing a more intuitive and accurate reference for surveying and demarcation. For example, the plugin can pass 3D model data to the surveying and demarcation module to assist in determining boundary points and delineating land parcel boundaries.

[0132] This application presents a modular, loosely coupled image library integrated production software system and method, which exhibits significant and beneficial technical effects in several aspects:

[0133] In terms of development and maintenance, improve development efficiency:

[0134] Parallel development accelerates progress: Each functional module can be developed and tested independently, allowing development teams to work in parallel. Different teams can be responsible for different modules simultaneously; for example, the surveying and demarcation module and the landform mapping module can be developed concurrently. Compared to the traditional monolithic architecture that develops sequentially, parallel development shortens the cycle by more than 40%, greatly accelerating the overall project progress.

[0135] Easy to test and debug: The independence of modules makes unit and integration testing easier to implement. Each module can be tested independently, reducing testing complexity and enabling quick problem localization and fixing. For example, when debugging the real estate registration module, it will not be affected by other modules, reducing debugging time and costs and further improving development efficiency.

[0136] Reduced maintenance costs: Enhanced fault isolation: Modules adopt modular encapsulation and loose coupling design, limiting the impact of a single point of failure to the module itself. If a business module (such as the status quo survey module) crashes due to a code vulnerability, other modules can still operate normally, ensuring the overall availability of the system and reducing the difficulty and cost of troubleshooting and repairing faults during maintenance.

[0137] Simplified feature iteration: When iterating on features, only the corresponding modules need to be updated, without modifying the entire system. Compared with the traditional monolithic architecture, the amount of code modification is reduced by 70%. For example, optimizing the area measurement algorithm of the surveying and demarcation module only requires modification and deployment of that module, without affecting the functionality of other modules, greatly reducing maintenance workload and risk.

[0138] In terms of scalability and flexibility, the system offers convenient feature expansion: it supports third-party plugin extensions, enabling rapid adaptation to the needs of different business sectors. In land survey operations, third-party developers can create specific data analysis plugins based on the standard plugin interface and integrate them into the system. This scalability allows the system to keep pace with industry developments and business changes, continuously enriching its functionality to meet new user demands.

[0139] Flexible business process customization: Through configuration file-driven customization, users can quickly adjust business processes to adapt to new business scenarios. The deployment cycle for new business scenarios is shortened from weeks to hours. For example, when a new land approval business scenario emerges, users can quickly customize the corresponding business process by modifying XML or JSON format configuration files, greatly improving the system's flexibility and responsiveness, enabling the system to quickly adapt to market changes.

[0140] In terms of cross-platform compatibility, the software is adapted to multiple systems: by employing cross-platform technical frameworks (such as the Qt framework) and graphics rendering libraries (such as OpenGL), it achieves compatibility with operating systems such as Windows, Linux, and macOS. For different operating systems, only minor adjustments to the system-related code are required to ensure stable operation on various platforms, meeting the operating system usage habits of different users and expanding the software's applicability.

[0141] High module reusability: Modular and standardized design enables modules to be highly reusable across different platforms. Data storage modules, graphics rendering modules, and other components can be reused in client-side software on different operating system platforms, reducing redundant development work, improving development efficiency and code quality, and further enhancing the software's compatibility and adaptability across different platforms.

[0142] At the overall business level, the accuracy and efficiency of business processing are improved: In specialized business modules, high-precision algorithms are used to perform functions such as coordinate calculation, area measurement, and terrain modeling. The surveying and demarcation module considers factors such as the Earth's curvature and projection distortion for accurate measurements, while the terrain mapping module utilizes optimized algorithms to generate accurate terrain data and render it efficiently. These measures improve the accuracy and efficiency of business processing, providing more reliable data support for land spatial planning, real estate registration, and other related businesses.

[0143] Optimizing user experience: From a user operation perspective, a visual workflow orchestration tool is provided, reducing the difficulty for users to customize business processes and enabling them to configure them more autonomously according to business needs. At the same time, the system's stability, efficiency, and cross-platform compatibility bring users a smoother and more convenient user experience, increasing user satisfaction and reliance on the software.

[0144] This embodiment focuses on a modular, loosely coupled image library integrated production software system and method, which possesses several key technical points. These technical points constitute the core competitiveness and innovative value of the invention:

[0145] The software system is constructed using a modular functional architecture with a scientific division of functional modules: Based on the business needs of Geographic Information Systems (GIS) and Computer-Aided Design (CAD), the software is subdivided into basic support modules, professional business modules, and extension interface modules. The basic support modules provide underlying support such as graphics rendering (using DirectX or OpenGL), data storage (combining SQLite and memory caching), and general-purpose utility function libraries. The professional business modules are designed with specific functions for professional scenarios such as surveying and demarcation, landform mapping, real estate registration, and current status surveys. The extension interface modules support third-party plugin integration through standard plugin interfaces and a plugin manager, enabling flexible functional expansion. This detailed and scientific division ensures that each module has a clear function and singular responsibility, improving the software's maintainability and scalability.

[0146] Strict module encapsulation standards: Component-based encapsulation: Each functional module is encapsulated as an independent component with a clear interface and independent functional implementation. Each module interacts with other modules through well-defined input / output interfaces, effectively reducing the coupling between modules and enabling modules to operate independently during development, testing, and maintenance without interference.

[0147] Data format standardization: Common geospatial data formats (such as GeoJSON) and standard CAD file formats (such as DWG and DXF) are adopted as the standard formats for data exchange between modules, and a detailed data dictionary is developed. This ensures accurate data transfer between different modules and avoids errors and compatibility issues caused by inconsistent data formats.

[0148] Metadata Description: Detailed metadata files (in XML or JSON format) are created for each module, including functional descriptions, input / output parameter descriptions, dependencies, version information, etc. Metadata helps developers quickly understand module features and usage methods, facilitating module management, integration, and updates.

[0149] A loosely coupled interaction mechanism and event-driven architecture are implemented: an event bus is built within the client-side software, and functional modules interact by subscribing to and publishing events to the event bus. For example, when the land surveying and demarcation module completes the land parcel area measurement, it publishes an "Area Measurement Completed" event, and other relevant modules can subscribe to this event to obtain data for subsequent processing. The event bus is responsible for event registration, distribution, and processing, ensuring accurate and efficient event transmission, achieving loosely coupled and asynchronous communication between modules, and improving the system's flexibility and response speed.

[0150] Interface isolation and abstraction: This involves abstracting and isolating the interaction interfaces between modules. Interaction methods are defined using abstract classes or interfaces, ensuring that each module depends only on the abstract interface and not on the concrete implementations of other modules. Simultaneously, the facade pattern is employed to provide a unified facade interface for complex module interactions, simplifying call relationships, reducing dependencies between modules, and enhancing system stability and maintainability.

[0151] The system employs a dynamic expansion and configuration mechanism, enabling dynamic module loading. This is achieved by utilizing dynamic link libraries (DLLs, for Windows platforms) or shared libraries (.so files, for Linux platforms) in the client-side software. Upon system startup, the system scans the specified plugin directory and loads compliant modules. During operation, users can load new plugin modules as needed. The system leverages reflection (as in Java or C#) or dynamic linking technology (as in C++) to integrate new modules without restarting the software. It also records module loading status and dependencies to ensure correct module loading and execution, thus achieving dynamic expansion of system functionality.

[0152] Configuration file-driven customization: Using XML or JSON formatted configuration files, users can customize business processes by modifying these files. The configuration file defines the enabled / disabled status of modules, data flow between modules, parameter settings, and other information. The system reads the configuration file upon startup and dynamically constructs the business process based on the configuration. For example, in real estate registration, users can specify the execution order and data transfer relationships of relevant modules through the configuration file, enabling rapid adaptation to different business scenarios and enhancing the system's flexibility and adaptability.

[0153] Cross-platform technology application and multi-system adaptation framework selection: Employing a cross-platform technology framework (such as the Qt framework), which provides rich libraries and tools for developing graphical user interfaces (GUIs) and non-GUI programs. Combined with cross-platform graphics rendering libraries (such as OpenGL), it achieves adaptation to multiple operating systems such as Windows, Linux, and macOS. For different operating systems, only minor system-related code adjustments are required to ensure stable software operation on various platforms, meeting the operating system usage habits of different users and expanding the software's application scope.

[0154] Cross-platform module reuse design: Through modular and standardized design, functional modules have high reusability across different platforms. Data storage modules, graphics rendering modules, etc., can be reused in client-side software on different operating system platforms, reducing redundant development work, improving development efficiency and code quality, and further enhancing the software's compatibility and adaptability across different platforms.

[0155] In one embodiment, such as Figure 1 and Figure 2 As shown, the operation method of the image library integrated internal production system is provided, which is applicable to modular and plug-in business software systems, including the following steps:

[0156] In response to the user's startup input, read the configuration file and parse the required functional modules and their execution order;

[0157] Register all functional modules and complete initialization and resource binding according to dependencies;

[0158] Start the event-driven bus and establish event subscription and listening channels between modules;

[0159] Receive user input or external task requests and start the main process scheduler;

[0160] The scheduler calls the functional modules to process the input data sequentially according to the process configuration;

[0161] If the configuration file contains a plugin path, then load the plugin module and add it to the processing flow;

[0162] After processing, the system exports graphics, tables, or database files as output.

[0163] In this embodiment, the configuration file is generated by the user through a process orchestration tool. The file contains the business process number, module type, execution priority, abnormal interruption conditions, and task output requirements. Figure 1 A business process diagram is provided for one embodiment of this application, taking real estate data production as an example; Figure 2 This is a schematic diagram illustrating dynamic expansion and configuration as provided in one embodiment of this application.

[0164] In this embodiment, the event-driven bus is started, and an event subscription and listening channel is established between modules. The event bus is constructed as a thread-safe asynchronous scheduling channel. The event subscription relationship is bound during the module registration phase, and the event handling callback function supports multi-level linkage triggering.

[0165] In this embodiment, the plug-in module exists in the form of a shared object file or a dynamic link library. It is loaded after being verified by interface standards and permission control policies. During operation, it is hosted by the plug-in container and executed in parallel with the system's main task chain.

[0166] The specific implementation details of each module can be found in the above description of the limitations of the integrated image library production software method based on a modular, loosely coupled architecture, and will not be repeated here.

[0167] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A modular, loosely coupled image library integrated production software system, characterized in that: The system includes: The functional module set includes multiple modules with independent functional responsibilities. Each module is encapsulated as a component unit and deployed in the form of a dynamic link library or shared object file. The modules are decoupled from each other through standard input / output interfaces to achieve data and control logic. The module registration mechanism, including a module registrar, a module identifier resolver, and a lifecycle controller, is used to parse the module list in the configuration file during system initialization and complete module loading, initialization, and runtime status management. The configuration-driven mechanism, including a configuration reader and a configuration injection engine, is used to load structured configuration files and dynamically construct the module execution order, parameter passing path, and data flow based on the information defined therein. The event-driven communication mechanism includes an event registry, an event scheduling engine, and event listeners. Each module accesses the event bus through registration and subscription, enabling non-blocking communication across modules. The plugin management submodule, including a plugin scanner, an interface validator, and a runtime adapter, is used to identify and integrate third-party extension modules that conform to the standard plugin interface specification. The metadata management module is used to manage the metadata information of each functional module, including input and output parameters, dependent modules, version number, interface documentation path, etc. The cross-platform compatibility subsystem, built on the Qt framework and OpenGL graphics library, is used to encapsulate platform-related calling logic, enabling the system to run on Windows, Linux, and macOS platforms. The process orchestration tool provides a visual business process design interface, allowing users to set the order of module nodes, parameter connections, condition judgments, and logical jumps by dragging and dropping, and generate process configuration files that can be recognized by the system.

2. The system according to claim 1, characterized in that, The set of functional modules includes: The graphics rendering module is used to load and render vector data, raster images, and 3D model data, and supports coordinate transformation, layer overlay, and geographic projection processing. The data storage module is used to support unified read and write management of SQLite databases, spatial data files, and intermediate cache files; The surveying and demarcation module is used to automatically generate boundary points, measure land parcel boundaries, and automatically assign land parcel numbers. The terrain mapping module is used to automatically extract contour lines, slope maps, and 3D terrain from DEM data; The real estate registration module is used to construct the ownership information structure and complete the generation of land parcel maps and the output of certificate information; The current status survey module is used for image interpretation, land use classification, and change detection and analysis.

3. The system according to claim 1, characterized in that, The event-driven communication mechanism includes: An event registry is used to register events of interest during the module initialization phase. Event triggers are used to emit event signals after the business logic within a module is completed; The event scheduling engine is used to schedule and forward events to subscribed modules based on event priority; The event callback function manager is used to register callback interfaces and implement task processing logic after an event is triggered.

4. The system according to claim 1, characterized in that, The configuration file for the configuration-driven mechanism is in XML or JSON format and contains the following structural information: Module enable flag; call chain execution order; module input parameter binding rules; module output data path; exception handling strategy and retry logic definition; plugin loading path and permission configuration.

5. The system according to claim 1, characterized in that, The plugin management submodule includes: Plugin directory scanner, used to scan plugin modules in the system's preset paths; The plugin interface matcher is used to determine the consistency of plugin interfaces by comparing them with the interface specification document. A plugin metadata parser is used to parse the feature descriptions and dependency descriptions embedded in plugins. A plugin sandbox container is used to isolate plugin memory space and resource access permissions during system operation.

6. The system according to claim 1, characterized in that, The process orchestration tool includes: A graphical node editor for visually drawing business processing flows; Data flow connectors are used to define the direction of data transfer and field mapping between modules; The conditional decision-maker is used to configure the branching logic based on the rule engine; A compiler is used to compile flowcharts into structured configuration scripts that can be recognized and executed by the host system.

7. A method for operating an integrated image library production system, applicable to modular, plug-in-based business software systems, characterized in that: Includes the following steps: In response to the user's startup input, read the configuration file and parse the required functional modules and their execution order; Register all functional modules and complete initialization and resource binding according to dependencies; Start the event-driven bus and establish event subscription and listening channels between modules; Receive user input or external task requests and start the main process scheduler; The scheduler calls the functional modules to process the input data sequentially according to the process configuration; If the configuration file contains a plugin path, then load the plugin module and add it to the processing flow; After processing, the system exports graphics, tables, or database files as output.

8. The method according to claim 7, characterized in that, The configuration file mentioned in the read configuration file is generated by the user through the process orchestration tool. The file contains the business process number, module type, execution priority, abnormal interruption conditions and task output requirements.

9. The method according to claim 7, characterized in that, The event-driven bus is started, and event subscription and listening channels are established between modules. The event bus is constructed as a thread-safe asynchronous scheduling channel. The event subscription relationship is bound during the module registration phase, and the event handling callback function supports multi-level linkage triggering.

10. The method according to claim 7, characterized in that, The plugin module exists in the form of a shared object file or a dynamic link library. It is loaded after being verified by interface standards and permission control policies. During runtime, it is hosted by the plugin container and executed in parallel with the system's main task chain.

Images