Announcement

Collapse
No announcement yet.

GDAL update

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GDAL update

    hi,

    are their any plans to update GDAL to a newer release? Im not able to change this by myself, since you have modified the original GDAL sources to patch the classloader paths as far as I have seen...

    Their are a lot of Coordinate system bugs in the old release, I it would be great if we could use a version which is not more than 4 years old...

    THX!

    -Marco

  • #2
    I'd like to know where I can get a copy of the modified GDAL source that WWJ uses. It really should be in the GitHub repository with the rest of the source code...

    Comment


    • #3
      Were I to have access to the source, I'd be inclined to upgrade GDAL, and all the libraries...

      Comment


      • #4
        I'm in the process of updating the GDAL libraries with the latest version as of this date. I notice that for the standard GDAL 1.7.2 release, the WorldWind staff changed the build scripts to create a single DLL for the four GDAL modules (gdal, ogr, osr, gdalconst). Although this is convenient, especially when distributing both 32 and 64 bit editions for several platforms, it requires changes to the SWIG code. They introduced a new method (setLibraryLoader) to the org.gdal.gdal.gdal class, and other features to disable the stock native library loading mechanism (see src\gov\nasa\worldwind\util\gdal\GDALUti ls.java).

        It seems to me that this creates a maintenance headache going forward. So my question is, is there any technical reason to combine the 4 DLL's that are generated by the stock GDAL build for the JNI interface, or is it simply a matter of simplifying packaging?

        Also, in the 2.2.2 GDAL release, the SWIG code generates duplicates of the functions VeryQuietErrorHandler, UseExceptions, DontUseExceptions, and JavaProgressProxy in several of the JNI DLL's that are built. Creating a single 'gdalalljni.dll' requires modification of the SWIG code to make these functions static.

        It seems to me that GDAL DLL's should be left "as is", and GDALUtils.java modified accordingly.

        Comment


        • #5
          I've created a pull request with updated libraries: https://github.com/NASAWorldWind/WorldWindJava/pull/146

          Comment


          • #6
            I've also posted a pull request to the GDAL source to create a single JNI shared library, as was done for the GDAL code currently included in WorldWind:
            https://github.com/OSGeo/gdal/pull/286
            gdal - GDAL is an open source X/MIT licensed translator library for raster and vector geospatial data formats. This is a mirror of the GDAL Subversion repository.

            Comment


            • #7
              We updated the GDAL library in worldwind 2.1 to GDAL 2.3.2 by compiling GDAL ourselves and then loading it. I can confirm that it seems to work fine, and it definitely fixes the issues with using maps that have a web mercator coordinate system. It also greatly reduces CPU utilization when processing JP2 maps into the cache.

              Comment


              • #8
                Thats great! Could you push to a github fork?

                Comment


                • #9
                  Originally posted by graspinggrasper View Post
                  Thats great! Could you push to a github fork?
                  Hi there. We are currently discussing a community-edition of WorldWind. I saw your GDAL upgrade and thought that it might be a useful merge once the community edition gets going. Please join in on the discussion at: https://github.com/NASAWorldWind/Wor...Java/issues/81

                  Comment

                  Working...
                  X