Error on centos 7 with vrt (jp2)

[caleb87]

I'm processing a .vrt created from a .jp2 file. On Ubuntu it works, but on Centos 7 it throws the error:

Traceback (most recent call last):
  File "/home/centos/gdal2tilesp.py", line 2759, in <module>
    total = queue.get(timeout=1)
  File "/usr/lib64/python2.7/multiprocessing/queues.py", line 132, in get
    raise Empty
Queue.Empty

I can process tif files without issue. I can also use gdalwarp on the vrt/jp2, so it would seem that it's not a driver issue.

I used yum to install : yum install gdal gdal-devel gdal-python

Any ideas?

[roblabs]

Maybe the python version in your Centos?

Two things to try:

• Use the official docker images from OSGEO.
  • Notes on how to do that: https://github.com/roblabs/gdal-docker#update-for-jul-2019
• gdal2tilesP.py now has an equivalent in those docker images called
• gdal2tiles.py # note no P`

# gdal2tiles.py -h
Usage: gdal2tiles.py [options] input_file [output]
<snip>
--processes=NB_PROCESSES
                        Number of processes to use for tiling

[roblabs]

When I first forked this version of gdal2tilep.py, I needed to add support for WebP and parallel processing. Since I forked, the OSGEO GDAL, which is supported, has added both of those.

[caleb87]

Interesting, when I use the built in gdal2tiles, it throws a warning but it still works :

ERROR 6: EPSG PCS/GCS code 900913 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
Generating Base Tiles:

It does generate the tiles without issue, the only issue with it and other gdal2tiles is partial tiles. I added like 5 lines of code to this fork so it wouldn't process partial tiles like this:

That way I could create a seamless area without blank spots. I also couldn't cut a single vrt image, because I'm cutting the entire country. The memory was 1TB already with only 4,000 square miles.

It's strange, because the warning may be why this fork is failing. It claims an empty SRS, but the gdalinfo shows the EPSPG as 26914 for both the vrt and input jp2 file. I tried adding " -s 26914 " to it, but it just threw the same error.