heroku/heroku-geo-buildpack

Heroku Buildpack: Geo

Heroku Buildpack Geo is a Heroku buildpack that installs the Geo/GIS libraries GDAL, GEOS and PROJ

It can be used to get GeoDjango or RGeo running on Heroku.

Usage

This buildpack is designed to be used in combination with other buildpacks by using Heroku's multiple buildpack support.

Ensure that Heroku Buildpack Geo is the first buildpack on your list of buildpacks:

$ heroku buildpacks
=== Buildpack URLs
1. https://github.com/heroku/heroku-geo-buildpack.git
2. heroku/python

Default Versions

The buildpack will install the following versions by default for new apps:

• GDAL: 3.9.0
• GEOS: 3.12.1
• PROJ: 9.4.0

Note: Existing apps that don't specify an explicit version will continue to use the version used by the last successful build (unless the build cache is cleared).

You can change the version of each library that will be installed by setting the GDAL_VERSION, GEOS_VERSION or PROJ_VERSION config variables.

Available Versions

• GDAL:
  • 2.4.0 (Heroku-20 only)
  • 2.4.2 (Heroku-20 only)
  • 3.5.0 (Heroku-20 and Heroku-22 only)
  • 3.6.4
  • 3.7.3
  • 3.8.5
  • 3.9.0
• GEOS:
  • 3.7.2 (Heroku-20 and Heroku-22 only)
  • 3.10.2 (Heroku-20 and Heroku-22 only)
  • 3.10.6
  • 3.11.3
  • 3.12.1
• PROJ:
  • 5.2.0 (Heroku-20 and Heroku-22 only)
  • 8.2.1 (Heroku-20 and Heroku-22 only)
  • 9.4.0

Migrating from heroku/python GEO support

If you were previously using the undocumented BUILD_WITH_GEO_LIBRARIES functionality of the official Heroku Python Buildpack here are instructions for changing to this buildpack:

1. You have to completely remove the BUILD_WITH_GEO_LIBRARIES config variable like so - heroku config:unset BUILD_WITH_GEO_LIBRARIES
2. You should consider flushing your applications build cache by following these instructions - https://help.heroku.com/18PI5RSY/how-do-i-clear-the-build-cache

heroku-geo-buildpack's Issues

heroku-buildpack-python overwrites GEOS and GDAL exports

Hi. I had troubles using heroku-geo-buildpack along with heroku-buildpack-python. My Django application was complaining it couldn't find the GDAL and GEOS libraries. Looking into heroku-geo-buildpack I can see this:

echo 'export GDAL_LIBRARY_PATH="$HOME/.heroku-geo-buildpack/vendor/lib/libgdal.so"' >> $PROFILE_PATH
echo 'export GEOS_LIBRARY_PATH="$HOME/.heroku-geo-buildpack/vendor/lib/libgeos_c.so"' >> $PROFILE_PATH

And in https://github.com/heroku/heroku-buildpack-python/blob/master/bin/steps/geo-libs I can see this:

set_env GDAL_LIBRARY_PATH "/app/.heroku/vendor/lib/libgdal.so"
set_env GEOS_LIBRARY_PATH "/app/.heroku/vendor/lib/libgeos_c.so"

Because heroku-geo-buildpack is the first one in the list, I believe heroku-buildpack-python will actually overwrite the paths set by the first one or not use them properly.

Install PROJ-8.2.1

Hello,

How can I install PROJ-8.2.1 ?

https://bucketeer-9aa8f376-a619-404c-b004-6db0317bcfe8.s3.amazonaws.com/heroku-20/PROJ/PROJ-8.2.1.tar.gz does not exist, do you have any version > 6.2 on heroku 20 ?

thank you

Pip installation of GDAL fails with GCC undeclared identifer errors

STR:

$ mkdir -p testapp-geo && cd $_ && git init && h create
$ h buildpacks:add https://github.com/heroku/heroku-geo-buildpack
$ h buildpacks:add heroku/python
$ echo 'GDAL' > requirements.txt
$ git add -A && git commit -m '.' && git push heroku main

This uses buildpack default Python (currently 3.6.12), default stack (currently Heroku-20), and latest GDAL (currently 3.2.1).

Expected

The pip install of the GDAL package succeeds.

Actual

The pip install fails during the GCC compilation step, with 12 thousand lines of GCC output, the first/last parts of which are below. Example error:

remote:          extensions/gdalconst_wrap.c: In function ‘PyInit__gdalconst’:
remote:          extensions/gdalconst_wrap.c:3879:71: error: ‘GDAL_OF_MULTIDIM_RASTER’ undeclared (first use in this function)
remote:           3879 |   SWIG_Python_SetConstant(d, "OF_MULTIDIM_RASTER",SWIG_From_int((int)(GDAL_OF_MULTIDIM_RASTER)));
remote:                |                                                                       ^~~~~~~~~~~~~~~~~~~~~~~

The GDAL package has had a few releases recently:
https://pypi.org/project/GDAL/#history
https://github.com/OSGeo/gdal/blob/v3.2.1/gdal/NEWS

However trying older releases (eg GDAL==3.1.3) didn't help.

Build log:

$ mkdir -p testapp-geo && cd $_ && git init && h create
$ h buildpacks:add https://github.com/heroku/heroku-geo-buildpack
$ h buildpacks:add heroku/python
$ echo 'GDAL' > requirements.txt
$ git add -A && git commit -m '.' && git push heroku main
...
remote: -----> Building on the Heroku-20 stack
remote: -----> Geo Packages (GDAL/GEOS/PROJ) app detected
remote: -----> Installing GDAL-2.4.0
remote: -----> Installing GEOS-3.7.2
remote: -----> Installing PROJ-5.2.0
remote: -----> Python app detected
remote: -----> Installing python-3.6.12
remote: -----> Installing pip 20.1.1, setuptools 47.1.1 and wheel 0.34.2
remote: -----> Installing SQLite3
remote: -----> Installing requirements with pip
remote:        Collecting GDAL
remote:          Downloading GDAL-3.2.1.tar.gz (604 kB)
remote:        Building wheels for collected packages: GDAL
remote:          Building wheel for GDAL (setup.py): started
remote:          Building wheel for GDAL (setup.py): finished with status 'error'
remote:          ERROR: Command errored out with exit status 1:
remote:           command: /app/.heroku/python/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-_ae9v2xt/GDAL/setup.py'"'"'; __file__='"'"'/tmp/pip-install-_ae9v2xt/GDAL/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-rmcrkk4o
remote:               cwd: /tmp/pip-install-_ae9v2xt/GDAL/
remote:          Complete output (6667 lines):
remote:          WARNING: numpy not available!  Array support will not be enabled
remote:          running bdist_wheel
remote:          running build
remote:          running build_py
remote:          creating build
remote:          creating build/lib.linux-x86_64-3.6
remote:          creating build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/ogr.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/__init__.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/gnm.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/gdal_array.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/gdalnumeric.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/osr.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/gdal.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          copying osgeo/gdalconst.py -> build/lib.linux-x86_64-3.6/osgeo
remote:          creating build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/__init__.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdalchksum.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_pansharpen.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdalident.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/epsg_tr.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_polygonize.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/esri2wkt.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal2xyz.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gcps2wld.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_fillnodata.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/rgb2pct.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gcps2vec.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_proximity.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdalimport.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_auth.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdalmove.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_edit.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/pct2rgb.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdalcompare.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/mkgraticule.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_retile.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_merge.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/ogrmerge.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_calc.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          copying osgeo/utils/gdal_sieve.py -> build/lib.linux-x86_64-3.6/osgeo/utils
remote:          /app/.heroku/python/lib/python3.6/site-packages/setuptools/lib2to3_ex.py:44: SetuptoolsDeprecationWarning: 2to3 support is deprecated. If the project still requires Python 2 support, please migrate to a single-codebase solution or employ an independent conversion process.
remote:            SetuptoolsDeprecationWarning)
remote:          Fixing build/lib.linux-x86_64-3.6/osgeo/ogr.py build/lib.linux-x86_64-3.6/osgeo/__init__.py build/lib.linux-x86_64-3.6/osgeo/gnm.py build/lib.linux-x86_64-3.6/osgeo/gdal_array.py build/lib.linux-x86_64-3.6/osgeo/gdalnumeric.py build/lib.linux-x86_64-3.6/osgeo/osr.py build/lib.linux-x86_64-3.6/osgeo/gdal.py build/lib.linux-x86_64-3.6/osgeo/gdalconst.py build/lib.linux-x86_64-3.6/osgeo/utils/__init__.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalchksum.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_pansharpen.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalident.py build/lib.linux-x86_64-3.6/osgeo/utils/epsg_tr.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_polygonize.py build/lib.linux-x86_64-3.6/osgeo/utils/esri2wkt.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal2xyz.py build/lib.linux-x86_64-3.6/osgeo/utils/gcps2wld.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_fillnodata.py build/lib.linux-x86_64-3.6/osgeo/utils/rgb2pct.py build/lib.linux-x86_64-3.6/osgeo/utils/gcps2vec.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_proximity.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalimport.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_auth.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalmove.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_edit.py build/lib.linux-x86_64-3.6/osgeo/utils/pct2rgb.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalcompare.py build/lib.linux-x86_64-3.6/osgeo/utils/mkgraticule.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_retile.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_merge.py build/lib.linux-x86_64-3.6/osgeo/utils/ogrmerge.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_calc.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_sieve.py
remote:          Skipping optional fixer: ws_comma
remote:          Fixing build/lib.linux-x86_64-3.6/osgeo/ogr.py build/lib.linux-x86_64-3.6/osgeo/__init__.py build/lib.linux-x86_64-3.6/osgeo/gnm.py build/lib.linux-x86_64-3.6/osgeo/gdal_array.py build/lib.linux-x86_64-3.6/osgeo/gdalnumeric.py build/lib.linux-x86_64-3.6/osgeo/osr.py build/lib.linux-x86_64-3.6/osgeo/gdal.py build/lib.linux-x86_64-3.6/osgeo/gdalconst.py build/lib.linux-x86_64-3.6/osgeo/utils/__init__.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalchksum.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_pansharpen.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalident.py build/lib.linux-x86_64-3.6/osgeo/utils/epsg_tr.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_polygonize.py build/lib.linux-x86_64-3.6/osgeo/utils/esri2wkt.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal2xyz.py build/lib.linux-x86_64-3.6/osgeo/utils/gcps2wld.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_fillnodata.py build/lib.linux-x86_64-3.6/osgeo/utils/rgb2pct.py build/lib.linux-x86_64-3.6/osgeo/utils/gcps2vec.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_proximity.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalimport.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_auth.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalmove.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_edit.py build/lib.linux-x86_64-3.6/osgeo/utils/pct2rgb.py build/lib.linux-x86_64-3.6/osgeo/utils/gdalcompare.py build/lib.linux-x86_64-3.6/osgeo/utils/mkgraticule.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_retile.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_merge.py build/lib.linux-x86_64-3.6/osgeo/utils/ogrmerge.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_calc.py build/lib.linux-x86_64-3.6/osgeo/utils/gdal_sieve.py
remote:          Skipping optional fixer: ws_comma
remote:          running build_ext
remote:          gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I../../port -I../../gcore -I../../alg -I../../ogr/ -I../../ogr/ogrsf_frmts -I../../gnm -I../../apps -I/app/.heroku/python/include/python3.6m -I. -I/tmp/tmp.s8g7jc8xnf/include -c gdal_python_cxx11_test.cpp -o gdal_python_cxx11_test.o
remote:          building 'osgeo._gdal' extension
remote:          creating build/temp.linux-x86_64-3.6
remote:          building 'osgeo._gdalconst' extension
remote:          creating build/temp.linux-x86_64-3.6/extensions
remote:          creating build/temp.linux-x86_64-3.6/extensions
remote:          gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I../../port -I../../gcore -I../../alg -I../../ogr/ -I../../ogr/ogrsf_frmts -I../../gnm -I../../apps -I/app/.heroku/python/include/python3.6m -I. -I/tmp/tmp.s8g7jc8xnf/include -c extensions/gdal_wrap.cpp -o build/temp.linux-x86_64-3.6/extensions/gdal_wrap.o -I/tmp/tmp.s8g7jc8xnf/include
remote:          gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I../../port -I../../gcore -I../../alg -I../../ogr/ -I../../ogr/ogrsf_frmts -I../../gnm -I../../apps -I/app/.heroku/python/include/python3.6m -I. -I/tmp/tmp.s8g7jc8xnf/include -c extensions/gdalconst_wrap.c -o build/temp.linux-x86_64-3.6/extensions/gdalconst_wrap.o -I/tmp/tmp.s8g7jc8xnf/include
remote:          extensions/gdalconst_wrap.c: In function ‘PyInit__gdalconst’:
remote:          extensions/gdalconst_wrap.c:3879:71: error: ‘GDAL_OF_MULTIDIM_RASTER’ undeclared (first use in this function)
remote:           3879 |   SWIG_Python_SetConstant(d, "OF_MULTIDIM_RASTER",SWIG_From_int((int)(GDAL_OF_MULTIDIM_RASTER)));
remote:                |                                                                       ^~~~~~~~~~~~~~~~~~~~~~~
remote:          extensions/gdalconst_wrap.c:3879:71: note: each undeclared identifier is reported only once for each function it appears in
remote:          extensions/gdalconst_wrap.c:3903:68: error: ‘GDAL_DCAP_UNIQUE_FIELDS’ undeclared (first use in this function); did you mean ‘GDAL_DCAP_DEFAULT_FIELDS’?
remote:           3903 |   SWIG_Python_SetConstant(d, "DCAP_UNIQUE_FIELDS",SWIG_FromCharPtr(GDAL_DCAP_UNIQUE_FIELDS));
remote:                |                                                                    ^~~~~~~~~~~~~~~~~~~~~~~
remote:                |                                                                    GDAL_DCAP_DEFAULT_FIELDS
...
<several thousand lines removed>
...
remote:            extensions/gdal_wrap.cpp:44258:100: error: ‘GVOT_MIN_TARGET_HEIGHT_FROM_GROUND’ was not declared in this scope
remote:            44258 |   SWIG_Python_SetConstant(d, "GVOT_MIN_TARGET_HEIGHT_FROM_GROUND",SWIG_From_int(static_cast< int >(GVOT_MIN_TARGET_HEIGHT_FROM_GROUND)));
remote:                  |                                                                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
remote:            extensions/gdal_wrap.cpp: At global scope:
remote:            extensions/gdal_wrap.cpp:5542:15: warning: ‘MDArrayReadWriteCheckArguments’ defined but not used [-Wunused-variable]
remote:             5542 | static CPLErr MDArrayReadWriteCheckArguments(GDALMDArrayHS* array,
remote:                  |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
remote:            extensions/gdal_wrap.cpp:5519:13: warning: ‘CheckNumericDataType’ defined but not used [-Wunused-variable]
remote:             5519 | static bool CheckNumericDataType(GDALExtendedDataTypeHS* dt)
remote:                  |             ^~~~~~~~~~~~~~~~~~~~
remote:            g++ -pthread -shared build/temp.linux-x86_64-3.6/extensions/gnm_wrap.o -L../../.libs -L../../ -L/tmp/tmp.s8g7jc8xnf/lib -lgdal -o build/lib.linux-x86_64-3.6/osgeo/_gnm.cpython-36m-x86_64-linux-gnu.so
remote:            error: command 'gcc' failed with exit status 1
remote:            ----------------------------------------
remote:        ERROR: Command errored out with exit status 1: /app/.heroku/python/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-_ae9v2xt/GDAL/setup.py'"'"'; __file__='"'"'/tmp/pip-install-_ae9v2xt/GDAL/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-3fwdlt_2/install-record.txt --single-version-externally-managed --compile --install-headers /app/.heroku/python/include/python3.6m/GDAL Check the logs for full command output.
remote:  !     Push rejected, failed to compile Python app.

Interaction with the APT buildpack can cause "libblas.so.3: cannot open shared object file"

Filing this in case it helps anyone else debugging.

Builds using this buildpack can fail with the following error:
OSError: libblas.so.3: cannot open shared object file: No such file or directory

...if all of the following are true:

• the app is also using the APT buildpack
• the APT buildpack runs after the Geo buildpack
• the Aptfile contains gdal related dependencies (such as gdal-bin)

Example:

$ mkdir testapp-geo-buildpack && cd $_ && git init && h create --stack heroku-18
$ h buildpacks:add https://github.com/heroku/heroku-geo-buildpack
$ h buildpacks:add heroku-community/apt
$ h buildpacks:add heroku/python
$ echo 'gdal-bin' > Aptfile
$ echo 'python-3.8.3' > runtime.txt
$ touch requirements.txt
$ mkdir -p bin
$ cat > bin/post_compile <<EOF
#!/usr/bin/env python
from ctypes import CDLL
from ctypes.util import find_library

lib_path = find_library('gdal')
print(lib_path)
CDLL(lib_path)
EOF
$ git add -A; git commit -m '.' && git push heroku main
...
remote: -----> Running post-compile hook
remote: libgdal.so.20
remote: Traceback (most recent call last):
remote:   File "bin/post_compile", line 9, in <module>
remote:     CDLL(lib_path)
remote:   File "/app/.heroku/python/lib/python3.8/ctypes/__init__.py", line 373, in __init__
remote:     self._handle = _dlopen(self._name, mode)
remote: OSError: libblas.so.3: cannot open shared object file: No such file or directory

If you experience the above error, the way to resolve is to either:

1. Remove gdal related dependencies from Aptfile (and leave them to the Geo buildpack)
2. Or, if you really need those dependencies for some reason (even though they duplicate the libraries used in this buildpack), then change the buildpack order, such that the Geo buildpack is after the APT buildpack, so that the GDAL libraries are used from the Geo buildpack and not the broken install from the APT buildpack

The long term solution is for the APT buildpack to fix heroku/heroku-buildpack-apt/issues/64.

GDAL 3.5.0 fails to compile with `PROJ 6 symbols not found`

Trying to compile GDAL 3.5.0 using a new build script based on those already in this repo, results in:

$ make build-heroku-20
...
root@e32c108174cb:/heroku-geo-buildpack# ./builds/gdal/gdal-3.5.0.sh 
...
checking for SQLite3 library >= 3.0.0... disabled
checking for PROJ >= 6 library... checking for proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -linternalproj... no
configure: error: PROJ 6 symbols not found
./config.status --recheck
make: ./config.status: Command not found
GNUmakefile:1: GDALmake.opt: No such file or directory
make: *** [GNUmakefile:171: config.status] Error 127
./config.status --recheck
make: ./config.status: Command not found
GNUmakefile:1: GDALmake.opt: No such file or directory
make: *** [GNUmakefile:171: config.status] Error 127

It seems proj is now required at build time too:
OSGeo/gdal#1352

Vendoring like this buildpack already does for libkml is one option, but then we'll end up with duplicate proj installs, given we build it separately too.

Buildpack not working

The buildpack now returns error for every stack.
For example:
Requested GDAL Version (3.5.0) is not available for this stack (heroku-18)

I am suspecting that it is a problem with the S3 storage. It is probably no longer active/accessible

OSError: libkmldom.so.1: cannot open shared object file: No such file or directory

Try to build a geodjango app.

1. https://github.com/heroku/heroku-geo-buildpack.git
2. heroku/python

Using the heroku-geo-buildpack I get the error OSError: libkmldom.so.1: cannot open shared object file: No such file or directory when Django starts and tries to import GDAL.

I have tried adding the apt buildpack and installing libkmldom1 (and also tried libkml-dev as well) but with the same result.

1. heroku-community/apt
2. https://github.com/heroku/heroku-geo-buildpack.git
3. heroku/python

Any suggestions?

Auto-detection of library locations not working

With the legacy Python buildpack BUILD_WITH_GEO_LIBRARIES feature, the GDAL library that was vendored was auto-detectable by Django, without the need to set GDAL_LIBRARY_PATH in the Django settings file.

Django's auto-detection is here:
https://github.com/django/django/blob/f63f3cdf0969c23fd0c05de0f4a2a1df0cd5112e/django/contrib/gis/gdal/libgdal.py#L13-L47

But in short it does the equivalent of:

from ctypes.util import find_library

find_library('gdal')

Trying this using the legacy feature works:

$ mkdir testapp-geo-legacy && cd $_ && git init && h create --stack heroku-18
$ h buildpacks:add https://github.com/heroku/heroku-buildpack-python#v184
$ h config:set BUILD_WITH_GEO_LIBRARIES=1
$ echo 'python-2.7.16' > runtime.txt
$ touch requirements.txt
$ git add -A; git commit -m '.' && git push heroku main
...
$ h run -- python -c 'from ctypes.util import find_library; print(find_library("gdal"))'
libgdal.so.20

However using this buildpack it doesn't:

$ mkdir testapp-geo-buildpack && cd $_ && git init && h create --stack heroku-18
$ h buildpacks:add https://github.com/heroku/heroku-geo-buildpack
$ h buildpacks:add heroku/python
$ echo 'python-2.7.16' > runtime.txt
$ touch requirements.txt
$ git add -A; git commit -m '.' && git push heroku main
...
$ h run -- python -c 'from ctypes.util import find_library; print(find_library("gdal"))'
None

Interestingly, if I change the Python version from 2.7 to 3.6, it does work.

# <continued from testapp-geo-buildpack example above>
$ echo 'python-3.6.12' > runtime.txt
$ git add -A; git commit -m '.' && git push heroku main
...
$ h run -- python -c 'from ctypes.util import find_library; print(find_library("gdal"))'
libgdal.so.20

Looking at https://docs.python.org/3/library/ctypes.html#finding-shared-libraries I see:

On Linux, find_library() tries to run external programs (/sbin/ldconfig, gcc, objdump and ld) to find the library file. It returns the filename of the library file.

Changed in version 3.6: On Linux, the value of the environment variable LD_LIBRARY_PATH is used when searching for libraries, if a library cannot be found by any other means.

Troubles with Heroku 22

I want to change version of GDAL (3.5.0 by default, and I want to set by 2.4.0)

The app is development in Django

In docker i don't have any trouble, but when I update stack and buildpacks the map doesn't display in heroku.

• Last versión deployment

• Same row of database in docker

I have many problems with this because, I don't know how change the current default versión in heroku (The terminal gives me an error of envars and I can't see my map well)

Missing GDAL_DATA environment variable

When invoking the GDAL library for certain operations, I'm getting:

2019-10-11T15:21:20.186674+00:00 app[web.1]: ERROR 2019-10-11 15:21:19,743 libgdal 10 139856534753408 GDAL_ERROR 4: b'Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.'

I shelled into an app running this buildpack, and the output of find . -name "gcs.csv" is ./.heroku-geo-buildpack/vendor/share/gdal/gcs.csv

So, I rebooted my app with the config var:
GDAL_DATA=/app/.heroku-geo-buildpack/vendor/share/gdal/
and everything is now hunky dory.

The heroku/python buildpack exports some envvars for gdal which provide hints for programs as to where to find GDAL, perhaps GDAL_DATA (and other?) envvars should be set in the buildpack?

libkml build failing

libkml is a dependency of the GDAL build, and so needs to be built for Heroku-24 so I can build GDAL for Heroku-24.

However, the libkml build is currently failing with:

Install the project...
-- Install configuration: "Release"
-- Installing: /tmp/tmp.ul8utM3CPi/include/minizip/crypt.h
-- Installing: /tmp/tmp.ul8utM3CPi/include/minizip/ioapi.h
-- Installing: /tmp/tmp.ul8utM3CPi/include/minizip/mztools.h
-- Installing: /tmp/tmp.ul8utM3CPi/include/minizip/unzip.h
-- Installing: /tmp/tmp.ul8utM3CPi/include/minizip/zip.h
-- Installing: /tmp/tmp.ul8utM3CPi/lib/libminizip.so
[  6%] Completed 'MINIZIP'
[  6%] Built target MINIZIP
[  7%] Creating directories for 'URIPARSER'
[  7%] Performing download step (download, verify and extract) for 'URIPARSER'
-- Downloading...
   dst='/tmp/tmp.zpELfYAgk1/libkml-libkml-0da164d/URIPARSER/src/uriparser-0.7.5.tar.bz2'
   timeout='none'
   inactivity timeout='none'
-- Using src='http://sourceforge.net/projects/uriparser/files/Sources/0.7.5/uriparser-0.7.5.tar.bz2/download'
CMake Error at URIPARSER-stamp/download-URIPARSER.cmake:170 (message):
  Each download failed!

    error: downloading 'http://sourceforge.net/projects/uriparser/files/Sources/0.7.5/uriparser-0.7.5.tar.bz2/download' failed
          status_code: 22
          status_string: "HTTP response code said error"
          log:
          --- LOG BEGIN ---
            Trying 104.18.12.149:80...

  Connected to sourceforge.net (104.18.12.149) port 80 (#0)

  GET
  /projects/uriparser/files/Sources/0.7.5/uriparser-0.7.5.tar.bz2/download
  HTTP/1.1

  Host: sourceforge.net

  User-Agent: curl/7.81.0

  Accept: */*

  

  Mark bundle as not supporting multiuse

  HTTP/1.1 301 Moved Permanently

  Date: Fri, 17 May 2024 07:16:34 GMT

  Content-Type: text/html

  Transfer-Encoding: chunked

  Connection: keep-alive

  location:
  https://sourceforge.net/projects/uriparser/files/Sources/0.7.5/uriparser-0.7.5.tar.bz2/download

...

Use cache busting to ensure apt-get update runs correctly

I'll leave this to the maintainers in case there's a reason for it I haven't seen; but I believe
apt-get update and apt-get install should be on the same line (in the dockerfile here), based on the best practices from docker (scroll down to 'APT-GET' section).

Which GDAL versions are available ?

It seems that not all released GDAL versions are available ?
I would need GDAL 3.2.X.

Thank you in advance,

Huge slug size

Following this announcement we switched a Django app over from using the old way to using this buildpack.

Before, the slug size was 200.2MB. After, it was 312.2MB, which exceeds Heroku's soft slug size limit.

Looking on a one-off dyno:

$ du -hs .heroku-geo-buildpack/
714M    .heroku-geo-buildpack/

This seems pretty huge! Is there anything that can be done to improve this?

Thanks :)

PROJ 7.2.0 or above

Hey there - I tried to install PROJ 7.2.0 as this is the minimum required for pyproj==3.2.1, but it looks like either the heroku stack or the buildpack doesn't support it.

Is there a workaround I could use?

Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 12 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 1.36 KiB | 1.36 MiB/s, done.
Total 4 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Building on the Heroku-20 stack
remote: -----> Using buildpacks:
remote:        1. https://github.com/heroku/heroku-geo-buildpack.git
remote:        2. heroku/python
remote: -----> Geo Packages (GDAL/GEOS/PROJ) app detected
remote: -----> Installing GDAL-2.4.0
remote: -----> Installing GEOS-3.7.2
remote: -----> Installing PROJ-7.2.0
remote:  !     Requested PROJ Version (7.2.0) is not available for this stack (heroku-20).
remote:  !     Aborting.
remote:  !     Push rejected, failed to compile Geo Packages (GDAL/GEOS/PROJ) app.
remote:

The error when I try with the defaults:

remote:        Collecting pyproj==3.2.1
remote:          Downloading pyproj-3.2.1.tar.gz (213 kB)
remote:          Installing build dependencies: started
remote:          Installing build dependencies: finished with status 'done'
remote:          Getting requirements to build wheel: started
remote:          Getting requirements to build wheel: finished with status 'error'
remote:          ERROR: Command errored out with exit status 1:
remote:           command: /app/.heroku/python/bin/python /app/.heroku/python/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py get_requires_for_build_wheel /tmp/tmp4ozi2bq8
remote:               cwd: /tmp/pip-install-5wi8xvbd/pyproj_b7297c30ebd24095b9eaf930a66f0e3f
remote:          Complete output (1 lines):
remote:          ERROR: Minimum supported PROJ version is 7.2.0, installed version is 5.2.0. For more information see: https://pyproj4.github.io/pyproj/stable/installation.html

gdal_merge.py support?

Is there any workarounds to get gdal_merge.py to work or do we need to manually install gdal with python support?

From the docs.
gdal_merge.py is a Python script, and will only work if GDAL was built with Python support.

https://gdal.org/programs/gdal_merge.html

Set {GDAL,GEOS,PROJ4}_LIBRARY_PATH in export too

Currently the various library PATH env vars are only set at runtime:

heroku-geo-buildpack/bin/compile

Lines 78 to 80 in 333a3f8

	echo 'export GDAL_LIBRARY_PATH="$HOME/.heroku-geo-buildpack/vendor/lib/libgdal.so"'
	echo 'export GEOS_LIBRARY_PATH="$HOME/.heroku-geo-buildpack/vendor/lib/libgeos_c.so"'
	echo 'export PROJ4_LIBRARY_PATH="$HOME/.heroku-geo-buildpack/vendor/lib/libproj.so"'

This means if they are required during eg a command run in a Python buildpack post_compile hook, they won't be found. There may be some users relying on this, since they were set for the legacy Python buildpack feature:
https://github.com/heroku/heroku-buildpack-python/blob/41f657fbff4dd90efa7705737bc6fee4fba05dba/bin/steps/geo-libs#L52-L57

To resolve this they would need to be added here:

heroku-geo-buildpack/bin/compile

Lines 64 to 70 in 333a3f8

	{
	echo "export PATH=\"$BUILD_DIR/.heroku-geo-buildpack/vendor/bin:\$PATH\""
	echo "export LIBRARY_PATH=\"$BUILD_DIR/.heroku-geo-buildpack/vendor/lib:\$LIBRARY_PATH\""
	echo "export LD_LIBRARY_PATH=\"$BUILD_DIR/.heroku-geo-buildpack/vendor/lib:\$LD_LIBRARY_PATH\""
	echo "export CPLUS_INCLUDE_PATH=\"$BUILD_DIR/.heroku-geo-buildpack/vendor/include:\$CPLUS_INCLUDE_PATH\""
	echo "export C_INCLUDE_PATH=\"$BUILD_DIR/.heroku-geo-buildpack/vendor/include:\$C_INCLUDE_PATH\""
	} >> "$BP_DIR/export"

ERROR 4: Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.

Hi all,

I was wondering if anyone could lend any insight and/or provide any help with an issue I'm facing, which was previously asked two years ago (#5) but I can't quite follow the follow-up responses:

I thought adding a Config Var: GDAL_DATA = /app/.heroku-geo-buildpack/vendor/share/gdal would solve the issue but it didn't. I retrieved this filepath from line 91 in the following doc: https://github.com/heroku/heroku-geo-buildpack/blob/master/bin/compile

I'm new to heroku so any help would be greatly appreciated! Thank you.

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

Hi @KevinBrolly great work!

About this new buildpack: Thankyou! If we can get this issue solved, it'll keep me on heroku (I hate to leave, but have been really struggling to get GDAL installed with libkml linked, so have been dockerizing and moving to Google Cloud, which is a nightmare to set up!).

WHAT I'D LOVE
If the version of GDAL vendored into this buildpack was linked against google's libkml library

WHY
GDAL already has a default KML file parser, so why build it with an additional engine for parsing KML files?

• It is a reference implementation of the standard
• default implementation only supports vector layers, not raster layers
• default implementation drops 'description' tags on folders
• libkml gives more reliable (in my experience) flattening of nested feature sets
• supports *.kmz files too, allowing persistence of icons and rasters
• libkml supports Google Earth extensions, pretty common among ppl using KML files (I don't, the other reasons are motivation enough for me, but suspect many do use these).

HOW
If it helps, here are relevant parts of a Dockerfile that adds a version of GDAL with libkml included to the heroku stack (it'll obviously be a bit different for you, since you'll build proj and geos etc, but hopefully is useful):

FROM heroku/heroku:18-build as build

# ...  stuff ...

# These libraries should always be done first. GDAL takes *ages* to build, so if done later in the Dockerfile, then any
# change that invalidates the cache will trigger an extremely long rebuild.

ARG GDAL_VERSION=v2.4.1

# Install proj, geos, libkml and build tools needed to compile gdal
RUN apt-get update -y && apt-get install -y --fix-missing --no-install-recommends \
        libkml-dev libproj-dev libgeos-dev \
        curl autoconf automake bash-completion

RUN ldconfig

# GDAL has a range of install options. Most of them specialized. Some add a lot of size to the slug, so be careful! Some options (may not be exhaustive):
#       python3-dev python3-numpy libboost-dev  libpng-dev libjpeg-dev libgif-dev \
#       libcharls-dev libopenjp2-7-dev libcairo2-dev \
#       liblzma-dev curl libcurl4-gnutls-dev libxml2-dev libexpat-dev libxerces-c-dev \
#       libnetcdf-dev libpoppler-dev libpoppler-private-dev \
#       libspatialite-dev swig libhdf4-alt-dev libhdf5-serial-dev \
#       libfreexl-dev unixodbc-dev libwebp-dev libepsilon-dev \
#       liblcms2-2 libpcre3-dev libcrypto++-dev libdap-dev libfyba-dev \
#       libmysqlclient-dev libogdi3.2-dev \
#       libcfitsio-dev openjdk-8-jdk libzstd1-dev \
#       libpq-dev libssl-dev

# Build GDAL
RUN mkdir gdal \
    && curl -L https://github.com/OSGeo/gdal/archive/${GDAL_VERSION}.tar.gz | tar xz -C gdal --strip-components=1 \
    && cd gdal/gdal \
    && ./configure \
        --without-libtool \
        --with-geos=yes \
        --with-libkml \
        --with-proj \
    && make \
    && make install \
    && cd ../.. \
    && rm -rf gdal

RUN ldconfig

AN OFFER
I'm not that familiar with heroku buildpacks, but have ahem "become" familiar with building GDAL. If it'll save me porting everything to google cloud, I'll happily spend a day of dev time helping with this in any way I can. Just ping me.

Building newer GDAL fails due to removal of autoconf support

Trying to build newer GDAL fails with:

./builds/gdal/gdal.sh: line 16: ./configure: No such file or directory

This is because of:

CMake is the only build system available in-tree. autoconf and nmake build systems have been removed

https://github.com/OSGeo/gdal/blob/v3.6.0/NEWS.md#in-a-nutshell

We'll have to switch to CMake instead:
https://gdal.org/development/building_from_source.html

Remove support for Heroku-16

The Heroku-16 stack reached end-of-life on May 1st, 2021, and in a few days (June 1st, 2021) the Heroku-16 build system will be decommissioned, meaning no further builds will be possible:
https://help.heroku.com/0S5P41DC/heroku-16-end-of-life-faq

As such, support for Heroku-16 can shortly be dropped:
https://github.com/heroku/heroku-geo-buildpack/search?q=16

heroku-22 stack - error: [Errno 2] No such file or directory: 'gdal-config'

On heroku-22 stack I got an error during build:

remote:        Collecting pygdal==2.4.0.10        
remote:          Downloading pygdal-2.4.0.10.tar.gz (522 kB)        
remote:          Preparing metadata (setup.py): started        
remote:          Preparing metadata (setup.py): finished with status 'error'        
remote:          error: subprocess-exited-with-error        
remote:                  
remote:          × python setup.py egg_info did not run successfully.        
remote:          │ exit code: 1        
remote:          ╰─> [10 lines of output]        
remote:              /app/.heroku/python/lib/python3.10/site-packages/setuptools/installer.py:27: SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements should be satisfied by a PEP 517 installer.        
remote:                warnings.warn(        
remote:              running egg_info        
remote:              creating /tmp/pip-pip-egg-info-37tb9fpi/pygdal.egg-info        
remote:              writing /tmp/pip-pip-egg-info-37tb9fpi/pygdal.egg-info/PKG-INFO        
remote:              writing dependency_links to /tmp/pip-pip-egg-info-37tb9fpi/pygdal.egg-info/dependency_links.txt        
remote:              writing requirements to /tmp/pip-pip-egg-info-37tb9fpi/pygdal.egg-info/requires.txt        
remote:              writing top-level names to /tmp/pip-pip-egg-info-37tb9fpi/pygdal.egg-info/top_level.txt        
remote:              writing manifest file '/tmp/pip-pip-egg-info-37tb9fpi/pygdal.egg-info/SOURCES.txt'        
remote:              error: [Errno 2] No such file or directory: 'gdal-config'        
remote:              [end of output]        
remote:                  
remote:          note: This error originates from a subprocess, and is likely not a problem with pip.        
remote:        error: metadata-generation-failed        
remote:                
remote:        × Encountered error while generating package metadata.        
remote:        ╰─> See above for output.        
remote:                
remote:        note: This is an issue with the package mentioned above, not pip.        
remote:        hint: See above for details.        
remote:  !     Push rejected, failed to compile Python app.        
remote: 
remote:  !     Push failed        
remote: Verifying deploy...

My requirements.txt is:

Django==4.1.4
Pillow==9.3.0
boto==2.49.0
django-money==3.0.0
django-paypal==2.0.0
django-settings-context-processor==0.2
djangorestframework-camel-case==1.3.0
django-registration-redux==2.11
djorm-ext-pgfulltext==0.10
isbnlib==3.10.4
psycopg2-binary==2.9.5
pycrypto==2.6.1
pydantic==1.10.2
pyelasticsearch==1.4.1
requests==2.28.1
simplejson==3.18.0
django-email-bandit==2.0
django-bootstrap3==22.2
-e git+https://github.com/Avenza/django-google-tag-manager.git@24adfd5a25f31d0c53113d057cab3aaef6014671#egg=django-google-tag-manager
-e git+https://github.com/Avenza/django-ping.git@38982cbff0303d626ee55248ec859884b2696953#egg=django-ping
-e git+https://github.com/Avenza/django-http-auth.git@213d02d6242df50ad0811ccaaae0f693e5aa61c8#egg=django-http-auth
-e git+https://github.com/Avenza/geolucidate.git@75228c77d5b925cd06970e5a85cb36e2cbe1ee34#egg=geolucidate
shapely==1.8.4
pyproj==3.4.0
dj-database-url==1.0.0
numpy==1.23.5
pyjwt==2.6.0
django_replicated==2.7
Pint==0.20.1
area==1.1.1
pygdal==2.4.0.10
nameparser==1.0.6
ujson==4.3.0
django-redis==5.2.0

django-oauth-toolkit==2.2.0

djangorestframework==3.14.0
django-filter==22.1
maxminddb-geolite2==2018.703

django-storages==1.13.1
gunicorn==20.1.0
gevent==22.10.2
newrelic==4.18.0.118

celery[sqs]==5.2.7
pyqrcode==1.2
pypng==0.0.20
cairosvg==2.5.2
svgutils==0.3.4
qrcodegen==1.6.0
protobuf==4.21.10

google-api-core==2.11.0
google-api-python-client==2.68.0
google-auth==2.15.0
google-auth-oauthlib==0.7.1
gspread==5.7.2

django-webpack-loader==1.7.0
ShopifyAPI==12.0.1
django-simple-captcha==0.5.17
algoliasearch==2.0
algoliasearch-django==2.0.0
py-moneyed==2.0
drf-yasg==1.21.4
boto3==1.26.16

Build log before installing requirements:

remote: Compressing source files... done.        
remote: Building source:        
remote: 
remote: -----> Building on the Heroku-22 stack        
remote: -----> Using buildpacks:        
remote:        1. https://github.com/heroku/heroku-geo-buildpack.git        
remote:        2. https://github.com/heroku/heroku-buildpack-pgbouncer        
remote:        3. heroku/python        
remote: -----> Geo Packages (GDAL/GEOS/PROJ) app detected        
remote: -----> Installing GDAL-2.4.0        
remote: -----> Installing GEOS-3.10.2        
remote: -----> Installing PROJ-8.2.1        
remote: -----> pgbouncer app detected        
remote: -----> pgbouncer-buildpack: Vendoring pgbouncer into slug        
remote: -----> pgbouncer-buildpack: Installed pgbouncer 1.17.0        
remote: -----> pgbouncer-buildpack: Moving the configuration generation script into app/bin        
remote: -----> pgbouncer-buildpack: Moving the start-pgbouncer script into app/bin        
remote: -----> pgbouncer-buildpack: Moving the (legacy) start-pgbouncer-stunnel script into app/bin        
remote: -----> pgbouncer-buildpack: Moving the use-pgbouncer script into app/bin        
remote: -----> pgbouncer-buildpack: done        
remote: -----> Python app detected        
remote: -----> Using Python version specified in runtime.txt        
remote:  !             
remote:  !     A Python security update is available! Upgrade as soon as possible to: python-3.10.9        
remote:  !     See: https://devcenter.heroku.com/articles/python-runtimes        
remote:  !             
remote: -----> Installing python-3.10.4        
remote: -----> Installing pip 22.3.1, setuptools 63.4.3 and wheel 0.37.1        
remote: -----> Installing SQLite3        
remote: -----> Installing requirements with pip   

But it works on heroku-20 stack

error in GDAL setup command: use_2to3 is invalid

I'm trying to deploy my GeoDjango app to Heroku.

First of all, I'm using the pack and followed the instructions.

I got the mentioned error and tried to search for answers. I took a look at this one

and tried but the same error comes up every single time. The project is built on Python 3.7.10 - I even tried this answer and changed the Python version to 3.9.13 - but nothing.

I get this error "error in GDAL setup command: use_2to3 is invalid."

Additionally, it says Numpy not available but I later installed it and refreshed the requirements.txt file.

### The error I get in detail:

remote:        Collecting GDAL==2.4.2
remote:          Downloading GDAL-2.4.2.tar.gz (564 kB)
remote:          Preparing metadata (setup.py): started
remote:          Preparing metadata (setup.py): finished with status 'error'
remote:          error: subprocess-exited-with-error
remote:
remote:          × python setup.py egg_info did not run successfully.
remote:          │ exit code: 1
remote:          ╰─> [6 lines of output]
remote:              WARNING: numpy not available!  Array support will not be enabled
remote:              /app/.heroku/python/lib/python3.9/site-packages/setuptools/_distutils/dist.py:275: UserWarning: Unknown distribution option: 'use_2to3_fixers'
remote:                warnings.warn(msg)
remote:              /app/.heroku/python/lib/python3.9/site-packages/setuptools/_distutils/dist.py:275: UserWarning: Unknown distribution option: 'use_2to3_exclude_fixers'
remote:                warnings.warn(msg)
remote:              error in GDAL setup command: use_2to3 is invalid.
remote:              [end of output]
remote:
remote:          note: This error originates from a subprocess, and is likely not a problem with pip.
remote:        error: metadata-generation-failed
remote:
remote:        × Encountered error while generating package metadata.
remote:        ╰─> See above for output.
remote:
remote:        note: This is an issue with the package mentioned above, not pip.
remote:        hint: See above for details.
remote:  !     Push rejected, failed to compile Python app.
remote:
remote:  !     Push failed
remote: Verifying deploy...
remote:
remote: !       Push rejected to project

### Requirements .txt:

asgiref==3.5.2
backports.zoneinfo==0.2.1
beautifulsoup4==4.11.1
certifi==2022.6.15
charset-normalizer==2.1.0
dj-database-url==1.0.0
Django==3.2.14
django-cors-headers==3.13.0
django-filter==22.1
django-heroku==0.3.1
djangorestframework==3.13.1
djangorestframework-gis==1.0
docopt==0.6.2
GDAL==2.4.2
gunicorn==20.1.0
idna==3.3
Js2Py==0.71
numpy==1.21.6
packaging==21.3
pipwin==0.5.2
psycopg2==2.9.3
pyjsparser==2.7.1
pyparsing==3.0.9
PyPrind==2.11.3
pySmartDL==1.3.4
python-dotenv==0.20.0
pytz==2022.1
pytz-deprecation-shim==0.1.0.post0
requests==2.28.1
Shapely==1.8.2
six==1.16.0
soupsieve==2.3.2.post1
sqlparse==0.4.2
typing_extensions==4.3.0
tzdata==2022.1
tzlocal==4.2
urllib3==1.26.11
whitenoise==6.2.0

Add support for Heroku-20

We'll soon want support for Heroku-20. The docker image is available now at heroku/heroku:20-build.