Method and device for cross-platform installation-free integration of GDAL in a Java program

Abstract

The application provides a method and device for cross-platform installation-free integration of GDAL in a Java program, comprising obtaining GDAL source data corresponding to multiple platforms, compiling and classifying the GDAL source data to obtain a GDAL achievement package; creating corresponding GDAL interface instances according to all types of platforms, embedding the GDAL achievement package in the GDAL interface instances to obtain a GDAL resource package; obtaining a matching GDAL resource package according to the platform on the host computer, copying the data in the matching GDAL resource package to the corresponding directory of the host computer to complete the GDAL deployment on the host computer; a large number of GDAL resource packages corresponding to different types of platforms are prepared in advance, so that when a user needs to deploy GDAL on a corresponding platform subsequently, the matching GDAL resource package can be directly called and deployed, and it is not necessary to temporarily design and compile GDAL source data, thereby greatly improving the deployment efficiency of GDAL.

Description

Technical Field

[0001] This invention belongs to the field of database technology, and more specifically, relates to a method and apparatus for cross-platform, installation-free integration of GDAL in a Java program. Background Technology

[0002] GDAL (Geospatial Data Abstraction Library) is an open-source library for converting raster and vector geospatial data formats. It supports reading, writing, and converting over 200 data formats. Deploying GDAL on different platforms typically requires compiling and installing the source code separately for each platform's framework and system, presenting a certain technical hurdle. Therefore, in practice, deploying GDAL to different platforms necessitates compiling and processing the source data according to the corresponding platform's operating system and Central Processing Unit (CPU) architecture. This step is relatively complex and has a high barrier to entry. Furthermore, in practical applications, GDAL may need to be deployed on multiple platforms simultaneously, requiring corresponding compilation and installation for each platform, further reducing deployment efficiency and impacting subsequent data conversion and reading / writing efficiency.

[0003] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0004] The problem this invention aims to solve is how to improve deployment efficiency when deploying GDAL to host machines on different platforms.

[0005] Firstly, a method for cross-platform, installation-free integration of GDAL in Java programs is provided, including: Obtain GDAL source data corresponding to various types of platforms, compile and classify the GDAL source data to obtain GDAL result packages; For all types of platforms, a corresponding GDAL interface instance is created, and the GDAL result package is embedded into the corresponding GDAL interface instance to obtain the GDAL resource package. Obtain the matching GDAL resource package based on the platform on the host machine, copy the data in the matching GDAL resource package to the corresponding directory on the host machine, and complete the GDAL deployment on the host machine.

[0006] Preferably, the process of compiling and classifying the GDAL source data to obtain the GDAL result package specifically includes: The GDAL source data is compiled and processed to output resource files, dynamic link library files, binary program files, and JNI JAR packages; The resource files are stored in the data directory, the dynamic link library files are stored in the lib directory, the binary program files are stored in the bin directory, and the JNI JAR is imported as a dependency to obtain the GDAL package.

[0007] Preferably, creating corresponding GDAL interface instances for all types of platforms specifically includes: Based on the platform's dynamic link library file search strategy, add deployment implementation classes for the corresponding platform to the project, and add corresponding interface declaration files to the META-INF subdirectory under the project's resource directory based on the service provider interface mechanism, and package and generate the GDAL resource package jar library. When a user calls the corresponding GDAL resource package to the corresponding host machine for GDAL deployment, the host machine can scan and call all GDAL resource packages through the GDAL resource package jar library.

[0008] Preferably, the step of copying the data from the matching GDAL resource package to the corresponding directory on the host machine to complete the GDAL deployment on the host machine specifically includes: Copy the resource files from the matching GDAL resource package to the data subdirectory of the host machine, copy the dynamic link library files from the matching GDAL resource package to the lib subdirectory of the host machine, and copy the binary program files from the matching GDAL resource package to the bin subdirectory of the host machine to complete the deployment of each data in the GDAL resource package on the host machine.

[0009] Preferably, since the resource files corresponding to different platforms are the same, the directory on the host machine used for restoring resource files is named gdal-resource; since the dynamic link library files and binary program files corresponding to different platforms are different, the directory on the host machine used for restoring dynamic link library files and binary program files is named according to the platform's operating system and CPU architecture.

[0010] Preferably, when maintaining a type of GDAL resource package in the server, a set of resource files is stored for different platform sharing methods; and when it is necessary to send the corresponding GDAL resource package to the host platform, the resource file stored in the corresponding sharing method is temporarily obtained to obtain the complete GDAL resource package to be sent.

[0011] Preferred options also include: When the GDAL source data corresponding to the Linux platform is obtained and compiled and classified, a declaration text file is added to the lib directory. The declaration text file is used to record the symbol link files generated during the output of the dynamic link library file. When the dynamic link library files in the GDAL resource package are copied from the lib directory to the lib subdirectory of the host machine, the host machine generates a recorded symbolic link file based on the declaration text file in the lib subdirectory. Once GDAL is deployed on the host machine, the resource files in the data subdirectory, the dynamic link library files in the lib directory, and the binary program files in the bin subdirectory are initialized to complete the loading of GDAL on the host machine.

[0012] Preferred options also include: Once deployment is complete, based on Java's characteristics, the dynamic link library files are loaded and released in the current process, following these steps: the directory containing the locally deployed GDAL dynamic link library files is added to the current Java process's dynamic link library file search directory; the dynamic link library files are loaded by calling the `system.loadlibrary` function, with the loading order being: first, GDAL dependency library files are loaded, then the GDAL library file is loaded, and finally the GDAL JNI library file is loaded. This process completes the initialization of the dynamic link library files.

[0013] Secondly, an apparatus for cross-platform, installation-free integration of GDAL in a Java program is provided, comprising at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor to perform the method for cross-platform, installation-free integration of GDAL in a Java program.

[0014] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors to perform the method described in the first aspect.

[0015] Fourthly, a chip is provided, comprising: a processor and an interface for calling and running a computer program stored in memory, performing the method as described in the first aspect.

[0016] Fifthly, a computer program product containing instructions is provided that, when executed on a computer or processor, causes the computer or processor to perform the method as described in the first aspect.

[0017] In a sixth aspect, an apparatus for cross-platform, installation-free integration of GDAL in a Java program is provided, comprising the apparatus for cross-platform, installation-free integration of GDAL in a Java program as described in the second aspect, and using the method for cross-platform, installation-free integration of GDAL in a Java program as described in the first aspect.

[0018] Unlike existing technologies, the present invention has at least the following beneficial effects: By pre-preparing the GDAL source data required by a large number of different types of platforms on the market, and packaging this GDAL source data into GDAL resource packages that can be matched and deployed with these platforms according to the operating system and CPU architecture required by the platform, when users need to deploy GDAL on the corresponding platform, they can directly call the matching GDAL resource package from these pre-prepared GDAL resource packages, restore the data files in it to the host machine of the corresponding platform, and complete the deployment. In the whole process, users can directly call the pre-prepared GDAL resource packages for deployment without having to design and compile GDAL source data on the spot, which greatly improves the deployment efficiency of GDAL. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0020] Figure 1 This is a flowchart of a method for cross-platform, installation-free integration of GDAL in a Java program, provided by the present invention. Figure 2 This is a flowchart of the GDAL source data compilation and processing method in a cross-platform, installation-free GDAL integration method for Java programs provided by this invention; Figure 3 This is a flowchart of the method for generating GDAL interface instances in a cross-platform, installation-free GDAL integration method for Java programs provided by this invention. Figure 4 This is a flowchart of the method for obtaining a platform-matched GDAL resource package in a cross-platform, installation-free GDAL integration method for Java programs provided by this invention. Figure 5 This is a schematic diagram of a device for cross-platform, installation-free integration of GDAL in a Java program, provided by the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0022] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

[0023] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0024] In the description of this invention, the expression “A and / or B” (where A and B are used to formally represent specific features) will be used. The corresponding expression includes the following three combinations: only A, only B, and a combination of A and B.

[0025] As used in this invention, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from a particular value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0026] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0027] Example 1: In the existing technology, deploying GDAL to different platforms requires compiling and processing the source data related to GDAL according to the operating system and CPU architecture of the corresponding platform. This step is relatively complex and has a high threshold, requiring those skilled in the art to perform temporary compilation and installation, resulting in low deployment efficiency of GDAL and affecting the efficiency of subsequent data conversion and reading / writing.

[0028] This embodiment provides a method for cross-platform, installation-free integration of GDAL in a Java program, such as... Figure 1 As shown, the method flow includes: In step 101, GDAL source data corresponding to various types of platforms are obtained, and the GDAL source data is compiled and classified to obtain GDAL result packages.

[0029] In this embodiment, the GDAL source data includes GDAL-related source code and data files. Compiling the GDAL source data requires following the official GDAL compilation and build documentation, and simultaneously compiling the GDAL Java language package bindings. The compilation classification primarily categorizes the compiled data into resource files, dynamic link library files, binary program files, and JNI JAR packages. The JNI JAR package refers to a JAR file containing JNI-related class libraries or interfaces. In this embodiment, after compiling and classifying the GDAL source data, the output files are stored in designated directories, and all directories are collectively used as the directory for the GDAL output package.

[0030] It is worth mentioning that in this embodiment, since step 101 is used to prepare a large amount of GDAL source data required by various platforms in advance, so that users can directly obtain the corresponding GDAL source data for deployment on the corresponding platforms without needing to design on the spot, thus improving the overall deployment efficiency, step 101 needs to obtain as much GDAL source data as possible for each platform to give users more choices. In practical application, it was found that in the GDAL deliverable package, the resource files and JNI JAR packages are basically the same for all platforms, while the dynamic link library files and binary program files for different platforms are different. Therefore, when restoring the file data later, the dynamic link library files and binary program files need to be processed separately.

[0031] In step 102, a corresponding GDAL interface instance is created for all types of platforms, and the GDAL result package is embedded into the corresponding GDAL interface instance to obtain the GDAL resource package.

[0032] Furthermore, to deploy GDAL to different platforms, a process interface matching the platform's operating system and CPU architecture is needed to restore (i.e., copy) the files within the GDAL deliverable package to the host machine of the corresponding platform. Therefore, in step 102, corresponding GDAL interface instances need to be created based on the operating system and CPU architecture of all potentially used platforms. Simultaneously, the GDAL deliverable package is embedded into the corresponding GDAL interface instance for packaging, resulting in the GDAL resource package. For example, among all pre-prepared GDAL deliverable packages, the GDAL deliverable package corresponding to the Windows platform is embedded into the corresponding GDAL interface instance for the Windows platform, resulting in the GDAL resource package corresponding to the Windows platform. By pre-packaging GDAL resource packages for multiple platforms in the above manner, users can easily select the GDAL resource package matching the corresponding platform from all the GDAL resource packages when they need to deploy GDAL on one or more platforms, and then call the GDAL resource package and restore the files within it.

[0033] In this embodiment, all pre-prepared GDAL resource packages can be stored as a resource library on the local machine or a private server. When the corresponding host machine needs to deploy GDAL, it can directly call the GDAL resource package in the resource library on the local machine or the private server.

[0034] In step 103, a matching GDAL resource package is obtained based on the platform on the host machine, and the data in the matching GDAL resource package is copied to the corresponding directory on the host machine to complete the GDAL deployment on the host machine.

[0035] After preparing all the GDAL resource packages in advance, during actual application, based on the platform type on the host machine where the user needs to deploy, obtain the GDAL resource package that matches the operating system and CPU architecture of the platform from all the pre-prepared GDAL resource packages. Copy the resource files, dynamic link library files, binary program files, and JNI JAR packages in the GDAL resource package to the corresponding directories on the corresponding host machine to complete the deployment of GDAL on the corresponding host machine.

[0036] In this embodiment, GDAL source data for a large number of different types of platforms are prepared in advance. Based on the operating system and CPU architecture required by the platform, these GDAL source data are packaged into GDAL resource packages that can be deployed to these platforms. When users need to deploy GDAL on the corresponding platform, they can directly call the matching GDAL resource package from these pre-prepared GDAL resource packages, restore the data files in it to the host machine of the corresponding platform, and complete the deployment. In the whole process, users can directly call the pre-prepared GDAL resource packages and deploy them without having to design and compile GDAL source data on the spot, which greatly improves the deployment efficiency of GDAL.

[0037] Furthermore, in this embodiment, since it is necessary to pre-package the GDAL source data into a GDAL result package to facilitate the subsequent construction of GDAL resource packages for different platform operating systems and CPU architectures, this embodiment involves the following design for the GDAL result package: The GDAL source data is compiled and classified to obtain the GDAL result package, such as... Figure 2 As shown, the method flow includes: In step 201, the GDAL source data is compiled and processed to output resource files, dynamic link library files, binary program files, and JNI JAR packages.

[0038] In step 202, the resource files are stored in the data directory, the dynamic link library files are stored in the lib directory, the binary program files are stored in the bin directory, and the JNI JAR is imported as a dependency to obtain the GDAL result package.

[0039] Furthermore, in this embodiment, since the data in GDAL needs to be deployed in a form that matches the corresponding operating system and CPU architecture during GDAL deployment, this embodiment involves the following design for each GDAL interface instance corresponding to each result package: creating corresponding GDAL interface instances for all types of platforms, such as... Figure 3 As shown, the method flow includes the following:

[0040] In step 301, obtain the operating system and CPU architecture corresponding to all the required platforms.

[0041] In step 302, a corresponding GDAL interface instance is generated based on each group of operating systems and CPU architectures.

[0042] In this embodiment, the GDAL interface instance has customized a restoration process for restoring file data from the GDAL result package to the host machine. This restoration process is matched and bound to the operating system and CPU architecture of the corresponding platform. When the GDAL result package is embedded into the GDAL interface instance, the resource files, dynamic link library files and binary program files in the GDAL result package are all restored with defined processes, thus obtaining the GDAL resource package.

[0043] Furthermore, based on the platform's dynamic link library file search strategy, deployment implementation classes for the corresponding platform are added to the project. Based on the service provider interface mechanism, corresponding interface declaration files are added to the META-INF subdirectory under the project's resource directory, and then packaged to generate a GDAL resource package JAR library. When a user deploys the corresponding GDAL resource package to the appropriate host machine, the host machine can scan and call all GDAL resource packages through the GDAL resource package JAR library.

[0044] In this embodiment, once all GDAL resource packages are prepared, they can be applied to the deployment of GDAL on the corresponding platform in a real-world scenario. During actual application, the host machine needs to scan all GDAL resource packages to determine if any of the pre-prepared packages match the platform on the host machine, ensuring the feasibility of subsequent steps. Therefore, this embodiment also involves the following design: obtaining the matching GDAL resource package based on the platform on the host machine, such as... Figure 4 As shown, the method flow includes the following.

[0045] In step 401, the operating system and CPU architecture corresponding to the platform on the host machine are obtained.

[0046] In step 402, the class loader determines whether there is a GDAL resource package corresponding to the operating system and CPU architecture among all GDAL resource packages.

[0047] In step 403, if any, the corresponding GDAL resource package is used as the GDAL resource package that matches the platform.

[0048] In step 404, if not, the corresponding GDAL resource package is downloaded from the server as the matching GDAL resource package.

[0049] In this embodiment, since there are a large number of platforms available on the market, it is difficult to guarantee that all GDAL resource packages corresponding to all platforms are ready in actual applications. Therefore, a public server can be prepared in advance to prepare GDAL resource packages corresponding to all platforms on the market. When the local server or private server does not store a matching GDAL resource package, the user can download the matching GDAL resource package from the public server according to the platform they need.

[0050] Furthermore, after obtaining the GDAL resource package that matches the corresponding platform, the data files in the GDAL resource package need to be restored (i.e. copied) to the host machine to complete the GDAL deployment. Therefore, this embodiment also involves the following design: the method of copying the data in the matching GDAL resource package to the corresponding directory on the host machine to complete the GDAL deployment on the host machine includes the following steps.

[0051] Copy the resource files from the matching GDAL resource package to the data subdirectory of the host machine, copy the dynamic link library files from the matching GDAL resource package to the lib subdirectory of the host machine, and copy the binary program files from the matching GDAL resource package to the bin subdirectory of the host machine to complete the deployment of each data in the GDAL resource package on the host machine.

[0052] In this embodiment, the data directory contains projection files, coordinate system definition files, GDAL driver configuration files, metadata, format specification files, other auxiliary resources, and some example data issues (raster data). The data directory mainly contains resource data and metadata required by GDAL during operation, i.e., the resource files. These data are defined in conventional formats (such as SQLite database files, text, and CSV formats), and can be effectively loaded and used by GDAL on any platform. Since the resource files corresponding to different platforms are the same, the directory on the host machine used for restoring resource files is named gdal-resource. Since the dynamic link library files and binary program files corresponding to different platforms are different, the directory on the host machine used for restoring dynamic link library files and binary program files is named according to the platform's operating system and CPU architecture. For example, when the platform's operating system is Windows and the CPU architecture is x86, the corresponding directory can be named gdal-resource-win-x86. When the platform's operating system is Linux and the CPU architecture is aarch64, the corresponding directory can be named gdal-resource-Linux-aarch64.

[0053] When maintaining a type of GDAL resource package on the server, a set of resource files is stored for different platform sharing methods; and when it is necessary to send the corresponding GDAL resource package to the host platform, the resource files stored in the corresponding sharing method are temporarily obtained to obtain the complete GDAL resource package to be sent.

[0054] In this embodiment, when restoring binary program files to the corresponding directory on the host machine on a Linux platform, it is necessary to add executable permissions to the corresponding files according to the file permission characteristics of the Linux platform.

[0055] Furthermore, it should be noted that in this embodiment, when preparing the GDAL result package for the Linux platform, the GDAL source data corresponding to the Linux platform will also generate additional symbolic link files during the compilation and classification of dynamic link library files. When the dynamic link library files are subsequently restored (i.e., copied) to the host machine, these symbolic link files cannot be synchronously restored to the host machine. However, the actual deployment of GDAL requires these symbolic link files. Therefore, during the pre-compilation and classification of the GDAL source data, all generated symbolic link files need to be recorded. When the dynamic link library files are subsequently restored (i.e. copied) to the host machine, the host machine can generate the same symbolic link files based on this record to ensure the correctness of the deployment. In summary, this embodiment also involves the following design: The method for cross-platform, installation-free integration of GDAL in the Java program further includes: when the GDAL source data corresponding to the Linux platform is obtained and compiled and classified, a declaration text file is added to the lib directory. The declaration text file is used to record the symbolic link files generated during the output of the dynamic link library file.

[0056] The method for cross-platform, installation-free integration of GDAL in a Java program further includes: when the dynamic link library file in the GDAL resource package is copied from the lib directory to the lib subdirectory of the host machine, the host machine generates a recorded symbolic link file in the lib subdirectory based on the declaration text file.

[0057] In Linux systems, symbolic link files are generated simultaneously when compiling dynamic link library files. This is because Linux platforms generate multiple versions of .so (shared object) files during the compilation process. This is usually because version control is used during compilation, primarily for library compatibility and backward compatibility. GDAL compilation itself depends on many other libraries. On the one hand, it has version requirements for other libraries, and on the other hand, it writes the dependent versions of libraries into the dependency metadata during compilation. Therefore, it is necessary to generate corresponding symbolic link files to point to the corresponding real files.

[0058] During the GDAL compilation process, the compiled output needs to be located in the ` / usr / local / lib` or ` / usr / local / lib64` directory based on the generated files. For example, for `libz.so`, three files will be generated: `libz.so.1.3.1`, `libz.so.1`, and `libz.so`. These three files are in the same directory, where `libz.so.1.3.1` and `libz.so.1` are symbolic links to `libz.so`. When organizing the declaration text file, each generated `.so` file and all its corresponding symbolic links are recorded based on the output of the compilation process. In this embodiment, the declaration file needs to record all generated `.so` files and the filenames of the symbolic links corresponding to each `.so` file.

[0059] The following is an example of a declaration text file for a symbolic link (using GDAL version 3.10.3 on the Linux platform as an example): The left side indicates the original file, and the right side indicates the linked file. libz.so.1.3.1 libz.solibz.so.1 libpcre2-8.solibpcre2-8.so.0.14.0 libpcre2-8.solibpcre2-8.so.0 libpcre2-posix.solibpcre2-posix.so.3.0.6 libpcre2-posix.solibpcre2-posix.so.3 libcrypto.so libcrypto.so.3 libssl.so libssl.so.3 libpsl.so libpsl.so.5.3.5 libpsl.so libpsl.so.5 ... libgdal.solibgdal.so.36.3.10.3 libgdal.solibgdal.so.36 The above shows some of the dependencies.

[0060] The declaration text file is used to record all library files (i.e. symbolic link files) generated after compilation. In this way, the host machine can restore the soft links of version files by using the symbolic link file information recorded in the declaration text file. Combined with the custom library search path LD_LIBRARY_PATH, it is possible to effectively establish complete library dependencies on the Linux platform.

[0061] Furthermore, in this embodiment, after restoring the file data within the GDAL resource package to the host machine, it is also necessary to initialize the GDAL-related data files on the host machine so that the partially deployed GDAL can be used normally on the host machine. Therefore, this embodiment also involves the following design: The method for cross-platform, installation-free integration of GDAL in a Java program further includes: Once GDAL is deployed on the host machine, the resource files in the data subdirectory, the dynamic link library files in the lib directory, and the binary program files in the bin subdirectory are initialized to complete the loading of GDAL on the host machine.

[0062] In this embodiment, after deployment is complete, based on the characteristics of Java, the dynamic link library file is loaded and released in the current process, following these steps: the directory where the locally deployed GDAL dynamic link library file is located is added to the dynamic link library file search directory of the current Java process; the dynamic link library file is loaded by calling the system.loadlibrary function, where the loading order is: first load the GDAL dependency library file, then load the GDAL library file, and finally load the GDAL JNI library file. The initialization of the dynamic link library file is completed through the above process.

[0063] After initializing all dynamic link library files, resource files are initialized, completing the deployment of GDAL on the current host machine and its loading into the current Java process. A proxy implementation for the executable program is defined. On Windows platforms, the dynamic link library files and binary program files are in the same directory, requiring no special handling. On Linux platforms, the directory containing the GDAL dynamic link library files needs to be added to the current process's LD_LIBRARY_PATH environment variable to resolve the issue of not being able to find the dynamic library when calling the executable. Through these steps, GDAL deployment and loading on different platform host machines are completed, and the GDAL executable file can be called by invoking the provided Java interface. The library is then packaged into a JNI JAR file. Other Java applications only need to import this JNI JAR file and call the initialization function within it to complete initialization, enabling calls to the GDAL Java JNI API and command-line calls to the executable file through the executable proxy interface.

[0064] Example 2: Based on Example 1, this example provides a complete and feasible implementation process in practical application scenarios, as follows: 1. GDAL Deliverable Package Construction: (1) Compile the relevant source code and data files included in the GDAL source data. The compilation process needs to be carried out in accordance with the official GDAL compilation and build documentation, and the GDAL Java language package binding is also compiled at the same time.

[0065] (2) The classification in the compilation classification is mainly used to classify the compiled data into resource files, dynamic link library files, binary program files and JNI JAR packages; wherein, the resource files are stored in the data directory, the dynamic link library files are stored in the lib directory, the binary program files are stored in the bin directory, and the JNI JAR is introduced as a dependency to obtain the GDAL result directory containing the data directory, lib directory and bin directory, that is, the GDAL result package is obtained.

[0066] (3) When the GDAL source data corresponding to the Linux platform is obtained and compiled and classified, symbolic link files will be generated during the output of dynamic link library files, recording the names of all symbolic link files. Declaration text files are added to the lib directory. The declaration text files are used to record the symbolic link files generated in the lib directory and record the mapping relationship between the original files of the symbolic link files and the directory file names of the lib directory. Each line defines one. When the dynamic link library files in the GDAL resource package are copied from the lib directory to the lib subdirectory of the host machine, the host machine generates the recorded symbolic link files in the lib subdirectory according to the declaration text files.

[0067] 2. Building the GDAL resource package library (i.e., building a GDAL interface instance): (1) Obtain the operating system and CPU architecture corresponding to all required platforms, and generate the corresponding GDAL interface instance according to each set of operating system and CPU architecture.

[0068] The GDAL interface instance provides a restoration process for restoring file data from the GDAL result package to the host machine. This restoration process is matched and bound to the operating system and CPU architecture of the corresponding platform. After embedding the GDAL result package into the GDAL interface instance, the restoration process for the resource files, dynamic link library files, and binary program files in the GDAL result package is defined, thus obtaining the GDAL resource package. The directories on the host machine used for restoring resource files can be named gdal-resource, and the resource files in the data directory are copied to gdal-resource (i.e., the resource directory).

[0069] (2) The process of restoring the resource files in the data directory in the GDAL interface instance is as follows: Since the resource files in the data directory are consistent on all platforms, the process is as follows on all platforms: copy the resource files in the data directory to the data subdirectory of the host machine.

[0070] (3) The process of restoring the binary program files in the bin directory in the GDAL interface instance is as follows: copy the binary program files in the bin directory to the bin subdirectory of the host machine, and at the same time, add the corresponding executable permissions to the file based on the file permission characteristics of the Linux platform.

[0071] (4) The process of restoring the dynamic link library files in the lib directory in the GDAL interface instance is as follows: the dynamic link library files in the lib directory are copied to the lib subdirectory of the host machine; in the specific example of the Windows platform, based on the dynamic link library search strategy in the current directory, the dynamic link library files in the lib directory are released to the lib subdirectory of the host machine; in the specific example of the Linux platform, the dynamic link library files in the lib directory are released to the lib subdirectory of the host machine, and at the same time, in the lib subdirectory, the symbolic link files corresponding to each dynamic link library file are restored according to the contents of the declaration text files under the lib directory.

[0072] (5) Based on the platform’s dynamic link library file search strategy, add a deployment implementation class for the corresponding platform to the project, and add the corresponding interface declaration file to the META-INF subdirectory under the resource directory of the project based on the service provider interface mechanism.

[0073] (6) Package the GDAL interface instance obtained above into a GDAL resource package jar library.

[0074] (7) Repeat the above steps of building GDAL interface instances for each different platform to obtain GDAL resource package jar library for different platform characteristics.

[0075] 3. GDAL library loading and construction: (1) Create a GDAL loading library. The GDAL loading library references the JNI JAR package and the corresponding GDAL resource package jar library for each platform (one or more are introduced according to the characteristics of the deployment platform). The main purpose is to integrate the library files and binary files under different platforms according to the platform. In actual use, if it is deployed on a certain platform, only the library files and binary files of the certain platform need to be introduced. If it is deployed on an uncertain platform, multiple can be introduced, and automatic matching can be attempted according to the CPU and platform characteristics.

[0076] (2) Implement the GDAL initialization process. Based on all the obtained GDAL interface instances (determined according to the introduction situation), match all GDAL interface instances according to the operating system and CPU characteristics of the current host platform. When a match is found, complete the local deployment of GDAL on the current host by calling the corresponding GDAL interface instance.

[0077] (3) After deployment, based on Java's characteristics, the dynamic link library file is loaded and released in the current process, following these steps: The directory containing the locally deployed GDAL dynamic link library file is added to the current Java process's dynamic link library file search directory; the dynamic link library file is loaded by calling the `system.loadlibrary` function, with the loading order being: first, load the GDAL dependency library files; then load the GDAL library file; and finally load the GDAL JNI library file. This process completes the initialization of the dynamic link library file. The Java system function `system.loadlibrary` is used to load the dynamic library via a file path. Its main purpose is to introduce the complete GDAL library dependencies into the corresponding Java process, avoiding library dependency exceptions when using the GDAL API.

[0078] (4) After the initialization of all dynamic link library files is completed, the resource files are initialized, and the deployment of GDAL on the current host machine and its loading in the current Java process are completed.

[0079] (5) Define the proxy implementation for the executable program. On the Windows platform, the dynamic link library file and the binary program file are in the same directory and do not require special processing. On the Linux platform, the directory where the GDAL dynamic link library file is located needs to be added to the LD_LIBRARY_PATH environment variable of the current process to solve the problem of not being able to find the dynamic library when calling the executable file. The above steps provide a complete version restoration of the library file in the system and provide a complete library dependency environment. Combined with LD_LIBRARY_PATH to declare the directory as the system library search directory, the problem of not being able to find the corresponding dependent library when loading the library file is effectively avoided.

[0080] (6) Complete the deployment and loading of GDAL on different platform host machines, and implement the calling of GDAL executable file by calling the provided Java interface.

[0081] (7) Package the library into a JNI JAR file. Other Java applications only need to import the JNI JAR file and call the initialization function in the JNI JAR file to complete the initialization, realize the calling of GDAL's Java JNI API, and realize the command-line calling of the executable file through the executable file proxy interface. Among them, GDAL implements the definition of the corresponding calling interface (corresponding to GDAL JNI JAR) in the Java layer through JNI technology, and completes the corresponding calling implementation (corresponding to JNI dynamic link library). In the process of use, the ability to call GDAL API can be achieved by using the GDAL JNI JAR interface in the Java program.

[0082] Example 3: like Figure 5 The diagram shown is a schematic representation of a device for cross-platform, installation-free integration of GDAL in a Java program according to an embodiment of the present invention. The device for cross-platform, installation-free integration of GDAL in a Java program according to this embodiment includes one or more processors 41 and a memory 42.

[0083] Processor 41 and memory 42 can be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0084] The memory 42, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the method for cross-platform, installation-free integration of GDAL in a Java program in the above embodiment. The processor 41 executes the method for cross-platform, installation-free integration of GDAL in a Java program by running the non-volatile software program and instructions stored in the memory 42.

[0085] Memory 42 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 42 may optionally include memory remotely located relative to processor 41, which can be connected to processor 41 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0086] The program instructions / modules are stored in the memory 42. When executed by one or more processors 41, they perform the method of cross-platform, installation-free integration of GDAL in the Java program described in the above embodiments.

[0087] This invention also provides a computer storage medium storing computer program instructions; when these computer program instructions are executed by a processor, they implement the method for cross-platform, installation-free integration of GDAL in a Java program provided in this invention.

[0088] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for cross-platform, installation-free integration of GDAL in a Java program, characterized in that, include: Obtain GDAL source data corresponding to various types of platforms, compile and classify the GDAL source data to obtain GDAL result packages; For all types of platforms, a corresponding GDAL interface instance is created, and the GDAL result package is embedded into the corresponding GDAL interface instance to obtain the GDAL resource package. Obtain the matching GDAL resource package based on the platform on the host machine, copy the data in the matching GDAL resource package to the corresponding directory on the host machine, and complete the GDAL deployment on the host machine.

2. The method for cross-platform, installation-free integration of GDAL in a Java program according to claim 1, characterized in that, The process of compiling and classifying the GDAL source data to obtain the GDAL output package specifically includes: The GDAL source data is compiled and processed to output resource files, dynamic link library files, binary program files, and JNI JAR packages; The resource files are stored in the data directory, the dynamic link library files are stored in the lib directory, the binary program files are stored in the bin directory, and the JNI JAR is imported as a dependency to obtain the GDAL package.

3. The method for cross-platform, installation-free integration of GDAL in a Java program according to claim 1, characterized in that, The creation of corresponding GDAL interface instances for all types of platforms specifically includes: Based on the platform's dynamic link library file search strategy, add deployment implementation classes for the corresponding platform to the project, and add corresponding interface declaration files to the META-INF subdirectory under the project's resource directory based on the service provider interface mechanism, and package and generate the GDAL resource package jar library. When a user calls the corresponding GDAL resource package to the corresponding host machine for GDAL deployment, the host machine can scan and call all GDAL resource packages through the GDAL resource package jar library.

4. The method for cross-platform, installation-free integration of GDAL in a Java program according to claim 1, characterized in that, The step of copying the data from the matching GDAL resource package to the corresponding directory on the host machine to complete the GDAL deployment on the host machine specifically includes: Copy the resource files from the matching GDAL resource package to the data subdirectory of the host machine, copy the dynamic link library files from the matching GDAL resource package to the lib subdirectory of the host machine, and copy the binary program files from the matching GDAL resource package to the bin subdirectory of the host machine to complete the deployment of each data in the GDAL resource package on the host machine.

5. The method for cross-platform, installation-free integration of GDAL in a Java program according to claim 1, characterized in that, Since the resource files are the same across different platforms, the directory on the host machine used for restoring resource files is named gdal-resource. Since the dynamic link library files and binary program files are different across different platforms, the directory on the host machine used for restoring dynamic link library files and binary program files is named according to the operating system and CPU architecture of the platform.

6. The method for cross-platform, installation-free integration of GDAL in a Java program according to claim 1, characterized in that, When maintaining a type of GDAL resource package on the server, a set of resource files is stored for different platform sharing methods; and when it is necessary to send the corresponding GDAL resource package to the host platform, the resource files stored in the corresponding sharing method are temporarily obtained to obtain the complete GDAL resource package to be sent.

7. The method for cross-platform, installation-free integration of GDAL in a Java program according to claim 2, characterized in that, Also includes: When the GDAL source data corresponding to the Linux platform is obtained and compiled and classified, a declaration text file is added to the lib directory. The declaration text file is used to record the symbol link files generated during the output of the dynamic link library file. When the dynamic link library files in the GDAL resource package are copied from the lib directory to the lib subdirectory of the host machine, the host machine generates a recorded symbolic link file based on the declaration text file in the lib subdirectory. Once GDAL is deployed on the host machine, the resource files in the data subdirectory, the dynamic link library files in the lib directory, and the binary program files in the bin subdirectory are initialized to complete the loading of GDAL on the host machine.

8. The method for cross-platform, installation-free integration of GDAL in a Java program according to claim 2, characterized in that, Also includes: Once deployment is complete, based on Java's characteristics, the dynamic link library files are loaded and released in the current process, following these steps: the directory containing the locally deployed GDAL dynamic link library files is added to the current Java process's dynamic link library file search directory; the dynamic link library files are loaded by calling the `system.loadlibrary` function, with the loading order being: first, GDAL dependency library files are loaded, then the GDAL library file is loaded, and finally the GDAL JNI library file is loaded. This process completes the initialization of the dynamic link library files.

9. A device for cross-platform, installation-free integration of GDAL in a Java program, characterized in that, The system includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing a method for cross-platform, installation-free integration of GDAL in a Java program according to any one of claims 1-8.

10. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer program instructions that, when executed by one or more processors, implement the method for cross-platform, installation-free integration of GDAL in a Java program as described in any one of claims 1-8.

Images