Link to libkml for improved KML support and compatibility with Google Earth

[heroku]

Link to libkml for improved KML support and compatibility with Google Earth

[KevinBrolly]

Hey @thclark - Sorry, looks like I forgot to include the libkml files in the gdal package at runtime 🤦‍♂

Thanks for the test app, that's really helpful. I will let you know when libkml is properly deployed.

[CaseyFaist]

😂 "become" familiar, I know a little about what that feels like

Your work looks more thorough than what I found after a quick google; we'd probably want to move the steps into formulas and trigger files but the steps will likely look similar. If you want to take a crack at formulize-ing it, go for it 💯

[KevinBrolly]

Hey @thclark I have added libkml support in this commit - 7330193

Could you give it a test and let me know how you get on? If you are already using this buildpack in an application the new binary should get pulled down the next time you do a build.

I have done it slightly differently than you have in your PR (#4) as it is faster and easier to just compile libkml and its dependencies to a custom prefix and shipping that over with the gdal binary rather than trying to apt-get during the build phase.

[thclark]

Getting there! Great work @KevinBrolly - thanks for your efforts on this.

This builds and releases, but unfortunately, the libraries aren't found at runtime... I have an error that looks like:

~ $ gdalinfo
gdalinfo: error while loading shared libraries: libkmlbase.so.1: cannot open shared object file: No such file or directory

I've just made my test app public which deploys successfully to heroku (use this buildpack and heroku/python), so you're welcome to use that to help.

I shelled in to that deployed app, and found the other libraries hd been deployed by the buildpack, but not libkml. Perhaps there's a build cache somewhere that needs to flushed?

[KevinBrolly]

Hey @thclark I have updated the gdal packages for the heroku-18 stack (gdal takes an age to build!). I spun up a dyno with your test app and it looks good:

~ $ gdalinfo
Usage: gdalinfo [--help-general] [-json] [-mm] [-stats] [-hist] [-nogcp] [-nomd]
                [-norat] [-noct] [-nofl] [-checksum] [-proj4]
                [-listmdd] [-mdd domain|`all`]*
                [-sd subdataset] [-oo NAME=VALUE]* datasetname

Let me know if that is working for you now.

[thclark]

Woohooo! This is great, working well. Thankyou so much @KevinBrolly - this issue has been completely killing my project.

Perhaps the following will be useful to add to the README (maybe edited slightly ;) ):

Notes for switching over from using the GDAL that gets vendored with heroku/python

You have to completely remove the BUILD_WITH_GEO_LIBRARIES environment variable :

• Note: setting it to 0 won't work, heroku/python has a really dumb test for it, but I won't bother raising an issue there, as presumably it'll be deprecated soon anyway.

You have to flush your application build cache.

You have to monkey around with the Heroku CI cache:

• Heroku CI is a total PITA when it comes to cache; AFAICT it uses a separate cache from the build cache, and there's no documented way of flushing it.
• Running it in debug mode from the cli, you can run with no cache. This doesn't purge the cache, though, so everything working nicely here will still pick up outdated libraries when rerun or automated.
• There's an extremely well hidden button in the UI, to the top right of the test console (see screenshot). It seems like the "run again with no cache" option does actually purge the cache, but only if you wait for all other tests to finish (failing, on the old cached GDAL library), then click this button from the UI, wait for that test to finish (now passing) then repeat for every active branch.
  

Phew! Job done! Thank you @KevinBrolly and @CaseyFaist you're my heroes of the month, and I'll allow you the honour of closing this issue ;)

[KevinBrolly]

Thanks for the README suggestions @thclark that will be really useful for people switching over, I will get that in the README now.

You are right that the Heroku CI cache functionality could be documented better.

Heroku CI does have a separate build cache for CI builds. The way the "Run Again Without Cache" works in Heroku CI is that there is a single cache for your test run, if you click "Run Again Without Cache" then at the end of that run the build cache from that run replaces the previous build cache.

This is why you have to wait for the tests to fail, then run again without cache, then after that run the new cache from that build will be used and your tests then pass. I will make a note to document this better.