[gdal-dev] Unexpected behavior on gdal2tiles.py

[jratike80]

Hi,

By looking at the messages the installation on Machine B has an error: "It
[means proj.db] comes from another PROJ installation." Because of that error
gdal2tiles "works". If you fix the installation on Machine B it will fail
for the same reason than Machine A: "Cannot find coordinate operations from
[something in Mars] to EPSG:4326 [that is in Tellus].

I believe that you must fool gdal2tiles somehow and make it to believe that
the source data are also from our planet. Unfortunately I don't know how.
But does it even make sense to project data from Mars into EPSG:4326?
Perhaps "-p raster" would create something usable.

-Jukka Rahkonen-



erentar2002 wrote
> Machine A:
> 
> user at machineA:~/mars$ gdal2tiles.py -z 6-8 -p geodetic -v debris.jp2
> Options: {'profile': 'geodetic', 'resampling': 'average', 's_srs': None,
> 'zoom': '6-8', 'resume': False, 'srcnodata': None, 'tmscompatible': None,
> 'xyz': None, 'verbose': True, 'exclude_transparent': None, 'quiet': None,
> 'nb_processes': None, 'tilesize': 256, 'kml': False, 'url': '',
> 'webviewer': 'all', 'title': 'debris.jp2', 'copyright': '', 'googlekey':
> 'INSERT_YOUR_KEY_HERE', 'bingkey': 'INSERT_YOUR_KEY_HERE',
> 'mapml_template': None, 'processes': 1}
> Input: debris.jp2
> Output: debris
> Cache: 1604.5949211120605 MB
> 
> Begin tiles details calc
> Input file: ( 29232P x 20669L - 4 bands)
> NODATA: []
> Preprocessed file: ( 29232P x 20669L - 4 bands)
> ERROR 1: PROJ: proj_create_operations: Source and target ellipsoid do not
> belong to the same celestial body
> ERROR 6: Cannot find coordinate operations from
> `GEOGCRS["GCS_Mars_2000",DATUM["D_Mars_2000",ELLIPSOID["Mars_2000_IAU_IAG",3396190,169.894447223612,LENGTHUNIT["metre",1,ID["EPSG",9001]]]],PRIMEM["Reference_Meridian",0,ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]],CS[ellipsoidal,2],AXIS["latitude",north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]],AXIS["longitude",east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]]]'
> to `EPSG:4326'
> Traceback (most recent call last):
>   File "/usr/bin/gdal2tiles.py", line 3242, in sys.exit(main(sys.argv))
> File "/usr/bin/gdal2tiles.py", line 3234, in
> main single_threaded_tiling(input_file, output_folder, options) File
> "/usr/bin/gdal2tiles.py", line 3154, in single_threaded_tiling conf,
> tile_details = worker_tile_details(input_file, output_folder, options)
> File "/usr/bin/gdal2tiles.py", line 3070, in worker_tile_details
> gdal2tiles.open_input() File "/usr/bin/gdal2tiles.py", line 1742, in
> open_input self.warped_input_dataset =
> update_alpha_value_for_non_alpha_inputs( File "/usr/bin/gdal2tiles.py",
> line 1061, in update_alpha_value_for_non_alpha_inputs if
> warped_vrt_dataset.RasterCount in [1, 3]: AttributeError: 'NoneType'
> object has no attribute 'RasterCount'
> 
> Machine B:
> 
> user at machineB:~/mars$ gdal2tiles.py -z 6-8 -p geodetic -v debris.jp2
> Options: {'profile': 'geodetic', 'resampling': 'average', 's_srs': None,
> 'zoom': '6-8', 'resume': False, 'srcnodata': None, 'tmscompatible': None,
> 'xyz': None, 'verbose': True, 'exclude_transparent': None, 'quiet': None,
> 'nb_processes': None, 'tilesize': 256, 'kml': False, 'url': '',
> 'webviewer': 'all', 'title': 'debris.jp2', 'copyright': '', 'googlekey':
> 'INSERT_YOUR_KEY_HERE', 'bingkey': 'INSERT_YOUR_KEY_HERE', 'processes': 1}
> Input: debris.jp2
> Output: debris
> Cache: 384.14570236206055 MB
> 
> Begin tiles details calc
> Input file: ( 29232P x 20669L - 4 bands)
> NODATA: []
> Preprocessed file: ( 29232P x 20669L - 4 bands)
> ERROR 1: PROJ: proj_create_from_database:
> /home/user/OTB-7.2.0-Linux64/share/proj/proj.db lacks
> DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It
> comes from another PROJ installation.
> Projected file: tiles.vrt ( 29232P x 20669L - 4 bands)
> ERROR 1: PROJ: proj_create_from_database:
> /home/user/OTB-7.2.0-Linux64/share/proj/proj.db lacks
> DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It
> comes from another PROJ installation.
> KML autotest OK!
> Bounds (output srs): 77.42551250577 18.429672337269487 77.47613730177316
> 18.465467490135833
> Bounds (latlong): 77.42551250577002 18.429672337269487 77.47613730177316
> 18.465467490135833
> Generating Base Tiles:
> 
> Tiles generated from the max zoom level:
> ----------------------------------------
> 
> dataBandsCount:  3
> tilebands:  4
> 1 / 1 debris/8/183/77.png
> 	Native Extent (querysize 76443 ):  (0, 0, 29232, 20669) (47211, 705631,
> 29232, 20669)
> Tiles details calc complete.
> 	ReadRaster Extent:  (0, 0, 29232, 20669) (59, 889, 36, 26)
> Generating Overview Tiles:
> 01 / 2 debris/7/91/38.png
> 	build from zoom 8  tiles: (182, 76) (183, 76) (182, 77) (183, 77)
> 2 / 2 debris/6/45/19.png
> 	build from zoom 7  tiles: (90, 38) (91, 38) (90, 39) (91, 39)
> 
> Why does this succeed in machine B and fail in machine A with identical
> inputs?
> 
> both machines run fresh copies of gdal-bin 3.2.1+dfsg-1+b1 amd64 from
> debian sid.
> 
> machine B is my desktop and machine A is a headless server.
> 
> will provide more information as asked.
> 
> 
> 
> _______________________________________________
> gdal-dev mailing list

> gdal-dev at .osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html