Gdal 2.2.3

[gbburkhardt]

Note: Filling out this template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the
maintainer's discretion.

Description of the Change

Update the GDAL native libraries to version 2.2.3. Modify GDAL library loader to support loading of multiple native libraries, instead of the previous fixed single library 'gdalalljni'. Include facility for overriding list of native libraries in configuration files.

All source used for the build is included, save the MrSID libraries. Instructions for replicating the build are included.

Why Should This Be In Core?

The current GDAL 1.7.2 version was released in April 2010. Numerous improvements in the library have been made since then

Benefits

Make current technology available to users.

Potential Drawbacks

Only 64 bit libraries for Windows and Linux are included. Previously, a custom build was used to create a single JNI native library, and changes were made to the GDAL JNI interface to allow use of a custom loader. I've dispensed with that so that future maintenance is minimized. The standard GDAL build produces 4 or 5 native libraries, and the MrSID libraries are kept separate. This creates more files, but it also allows the possiblity of using stock binary GDAL releases by changing the configuration file to set the "gov.nasa.worldwind.avkey.GDAL.Libs" property.

Applicable Issues

Obsolete GDAL library

[caller]

PLEASE MERGE THIS... It would be awsome to have this in the main codeline
-Marco

[gbburkhardt]

Thanks for the vote of confidence. However, with 30+ pull requests outstanding, and the last update to the code having been on Nov 8, 2017, I get the feeling that NASA has diverted resources to other projects. It looks to me as though their current focus is WebWorldWind, and, possibly the Android edition.

[wcmatthysen]

Jip, they don't merge any external pull requests. That is why I tried to push for a community edition a while ago: #81

[wcmatthysen]

Hi @gbburkhardt. Can you rebase these changes on the latest version of the development branch. We would like to merge these changes in the community edition of WorldWind located at: https://github.com/WorldWindEarth/WorldWindJava

[gbburkhardt]

Sure.  Do you have a timeframe?  I'm in the middle of rebuilding GDAL with version 2.4.1.  There were several formats omitted from the build that's in GitHub.  I still have a few formats to go. I only plan to provide builds for Windows and Linux in 64 bit.  I hope that's OK.

…

On 4/7/2019 1:36 PM, Wiehann Matthysen wrote: Hi @gbburkhardt <https://github.com/gbburkhardt>. Can you rebase these changes on the latest version of the development branch. We would like to merge these changes in the community edition of WorldWind located at: https://github.com/WorldWindEarth/WorldWindJava — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFHjlKDLSJjmQYfC2uUSsxviLFulnXwgks5veiyxgaJpZM4RBey9>.

[wcmatthysen]

We don't have any time-frames for anything yet. We should probably plan a road-map of sort. I think the JOGL and GDAL upgrades would be nice to get in (especially the JOGL upgrade seeing as we require it for newer versions of Java). A couple of the bug-fixes (like your MGRS fix) and a couple of the other more serious ones that have been lying around unmerged for ages would be nice to get in as well.

I think Windows and Linux 64-bit is fine for now (but that is just my view on this). If anyone wants Mac support they should contact you and help out to get it working.

If you are interested, I think you should be added to the WorldWindEarth/worldwindjava team seeing as you made quite a bit of contributions already (just contact Bruce regarding this).

[gbburkhardt]

I've been thinking about how to minimize long term maintenance of the GDAL support. What I've been doing isn't viable - it's been taking days to accumulate the source code, and build it. And some packages (e.g., librasterlite2) don't build easily on Windows, and depend on lots of other packages. One thing I've tried to do is build only static libraries, thinking that having it all in one place is an advantage, but I'm beginning to think that I should give that up. It certainly made the loadLibrary stuff easier.

It would seem that if we rely on existing binary builds, updating is likely to be a lot easier in the future. I just checked the 'gisinternals' (http://www.gisinternals.com/release.php) releases, and the current one includes the JNI interface. Ubuntu also includes the JNI interface in the 'libgdal-java' package. Both have a fairly full set of formats supported. I have no idea what minimal set the community needs. Ubuntu is lacking the MrSID and ECW formats out of the box, presumably because those are released in binary only, read only packages without source, with some licensing restrictions.

So for Windows, I'm leaning toward grabbing the DLLs from GisInternals and the gdal.jar file, and for Linux, relying on the distributor to supply the packages, and assume that 'gdal.jar' and libgdalalljni.so will be available.

How does that sound?

[caller]

sounds good! Am Do., 11. Apr. 2019 um 04:05 Uhr schrieb gbburkhardt < [email protected]>:

…

I've been thinking about how to minimize long term maintenance of the GDAL support. What I've been doing isn't viable - it's been taking days to accumulate the source code, and build it. And some packages (e.g., librasterlite2) don't build easily on Windows, and depend on lots of other packages. One thing I've tried to do is build only static libraries, thinking that having it all in one place is an advantage, but I'm beginning to think that I should give that up. It certainly made the loadLibrary stuff easier. It would seem that if we rely on existing binary builds, updating is likely to be a lot easier in the future. I just checked the 'gisinternals' ( http://www.gisinternals.com/release.php) releases, and the current one includes the JNI interface. Ubuntu also includes the JNI interface in the 'libgdal-java' package. Both have a fairly full set of formats supported. I have no idea what minimal set the community needs. Ubuntu is lacking the MrSID and ECW formats out of the box, presumably because those are released in binary only, read only packages without source, with some licensing restrictions. So for Windows, I'm leaning toward grabbing the DLLs from GisInternals and the gdal.jar file, and for Linux, relying on the distributor to supply the packages, and assume that 'gdal.jar' and libgdalalljni.so will be available. How does that sound? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACJPAPlLRQvOADNmbHYsc-J4QrjH5uZaks5vfphSgaJpZM4RBey9> .

-- Dr. Marco Möller mobile: +49 (0)173 2051706 Münzweg 2 76698 Ubstadt-Weiher Germany

[wcmatthysen]

Great, that sounds good.

If we can rely on an externally maintained source for the JNI bindings then it will make our lives a lot easier. The restrictions with MrSID and ECW should definitely be something that we take into consideration. The fact that they are left out of the Ubuntu builds should tell us that we couldn't just blindly go forward and include them.

Are the JNI interfaces from Ubuntu and GisInternals relatively similar? Would you be able to provide a single Java API class that links through to the underlying native library?

[ghost]

Moved the discussion to WorldWindEarth/WorldWindJava.

[gbburkhardt]

Obsolete now. See more recent code in https://github.com/WorldWindEarth/WorldWindJava
commits:
9e6e504
81731e8
6225f20
63a0346