Re: [gdal-dev] Question about gdaladdo and raster mosaicking
Chaitanya, Thank you very much for your reply and suggestion. I have used LZW with predictor 2 compression and added external overviews compressed in LZW too and the image came perfect. The only downside is the size of each of the images has expanded from approx. 2 GB to 18-20 GB. So now I have to choose between quality and size! Attached are two screen shots showing the difference. Thanks again! Regards, Ammar From: Chaitanya kumar CH chaitanya...@gmail.com To: ammar8...@yahoo.com Cc: gdal dev gdal-dev@lists.osgeo.org Sent: Tuesday, January 21, 2014 6:27 PM Subject: Re: Question about gdaladdo and raster mosaicking Ammar, You are using lossy JPEG compression. I'm guessing that the white lines are are actually pixels with values near but not equal to 255. So, they are not treated as nodata pixels. My suggestion is to use another format with lossless compression for the 21 images or use a mask band if you prefer. Let me know how it goes. -- Best regards, Chaitanya Kumar CH On 21-Jan-2014 5:31 pm, ammar8...@yahoo.com wrote: Hello Chaitanya, I was looking online for solutions to my problem and I cam across some of your posts so I thought you might help me with my problem. I have 10,000+ TIFF files that I want to merge into one big Image and serve using GeoServer. I merged every 500 images at a time creating using gdalbuildvrt and gdal_translate along with JPEG compression creating 21 TIFF files. I added overviews then to each of the new 21 files. When adding the images together, once directly as files using QGIS and another time as WMSs using GeoServer, I got white lines/gaps precisely at the border of ever 2 images. I thought the problem is with no data values but I decided to take another approach and merged all the 10,000 files into one huge image and this time I got one perfect image with no lines or gaps. I failed to create overviews for the big image because the process took days or gdaladdo running with no progress. I tested then on smaller images with and without overviews and the ones with no overview came perfect while the one with gdaladdo overviews came with the same problem of lines and gaps. The commands I m using are the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -a_srs EPSG:27700 -input_file_list tiff_list.txt mosaic.vrt gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co PHOTOMETRIC=YCBCR mosaic.vrt mosaic.tif gdaladdo mosaic.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Any ideas, tips or recommendations would be appreciated! Best regards, Ammar _ Sent from http://osgeo-org.1560.x6.nabble.com attachment: jpegCompress.jpegattachment: lzwCompress.jpeg___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about gdaladdo and raster mosaicking
As was suggested, you could try using a mask instead. On Thu, Jan 23, 2014 at 7:52 AM, Ammar ammar8...@yahoo.com wrote: Chaitanya, Thank you very much for your reply and suggestion. I have used LZW with predictor 2 compression and added external overviews compressed in LZW too and the image came perfect. The only downside is the size of each of the images has expanded from approx. 2 GB to 18-20 GB. So now I have to choose between quality and size! Attached are two screen shots showing the difference. Thanks again! Regards, Ammar -- *From:* Chaitanya kumar CH chaitanya...@gmail.com *To:* ammar8...@yahoo.com *Cc:* gdal dev gdal-dev@lists.osgeo.org *Sent:* Tuesday, January 21, 2014 6:27 PM *Subject:* Re: Question about gdaladdo and raster mosaicking Ammar, You are using lossy JPEG compression. I'm guessing that the white lines are are actually pixels with values near but not equal to 255. So, they are not treated as nodata pixels. My suggestion is to use another format with lossless compression for the 21 images or use a mask band if you prefer. Let me know how it goes. -- Best regards, Chaitanya Kumar CH On 21-Jan-2014 5:31 pm, ammar8...@yahoo.com wrote: Hello Chaitanya, I was looking online for solutions to my problem and I cam across some of your posts so I thought you might help me with my problem. I have 10,000+ TIFF files that I want to merge into one big Image and serve using GeoServer. I merged every 500 images at a time creating using gdalbuildvrt and gdal_translate along with JPEG compression creating 21 TIFF files. I added overviews then to each of the new 21 files. When adding the images together, once directly as files using QGIS and another time as WMSs using GeoServer, I got white lines/gaps precisely at the border of ever 2 images. I thought the problem is with no data values but I decided to take another approach and merged all the 10,000 files into one huge image and this time I got one perfect image with no lines or gaps. I failed to create overviews for the big image because the process took days or gdaladdo running with no progress. I tested then on smaller images with and without overviews and the ones with no overview came perfect while the one with gdaladdo overviews came with the same problem of lines and gaps. The commands I m using are the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -a_srs EPSG:27700 -input_file_list tiff_list.txt mosaic.vrt gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co PHOTOMETRIC=YCBCR mosaic.vrt mosaic.tif gdaladdo mosaic.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Any ideas, tips or recommendations would be appreciated! Best regards, Ammar _ Sent from http://osgeo-org.1560.x6.nabble.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about gdaladdo and raster mosaicking
Etienne, I tried the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -addalpha -input_file_list tiff_list.txt mosaic02.vrt gdal_translate -of GTiff -b 1 -b 2 -b 3 -mask 4 -a_srs EPSG:3011 -co TILED=yes -co compress=jpeg -co jpeg_quality=80 -co blockxsize=512 -co blockysize=512 -co photometric=ycbcr --config gdal_tiff_internal_mask yes mosaic02.vrt mosaic02.tif gdaladdo mosaic02.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Did I implement the mask the right way? The results I got were similar to the JPEG compression with no mask, in other words I got white lines too! From: Etienne Tourigny etourigny@gmail.com To: Ammar ammar8...@yahoo.com Cc: Chaitanya kumar CH chaitanya...@gmail.com; gdal dev gdal-dev@lists.osgeo.org Sent: Thursday, January 23, 2014 12:25 PM Subject: Re: [gdal-dev] Question about gdaladdo and raster mosaicking As was suggested, you could try using a mask instead. On Thu, Jan 23, 2014 at 7:52 AM, Ammar ammar8...@yahoo.com wrote: Chaitanya, Thank you very much for your reply and suggestion. I have used LZW with predictor 2 compression and added external overviews compressed in LZW too and the image came perfect. The only downside is the size of each of the images has expanded from approx. 2 GB to 18-20 GB. So now I have to choose between quality and size! Attached are two screen shots showing the difference. Thanks again! Regards, Ammar From: Chaitanya kumar CH chaitanya...@gmail.com To: ammar8...@yahoo.com Cc: gdal dev gdal-dev@lists.osgeo.org Sent: Tuesday, January 21, 2014 6:27 PM Subject: Re: Question about gdaladdo and raster mosaicking Ammar, You are using lossy JPEG compression. I'm guessing that the white lines are are actually pixels with values near but not equal to 255. So, they are not treated as nodata pixels. My suggestion is to use another format with lossless compression for the 21 images or use a mask band if you prefer. Let me know how it goes. -- Best regards, Chaitanya Kumar CH On 21-Jan-2014 5:31 pm, ammar8...@yahoo.com wrote: Hello Chaitanya, I was looking online for solutions to my problem and I cam across some of your posts so I thought you might help me with my problem. I have 10,000+ TIFF files that I want to merge into one big Image and serve using GeoServer. I merged every 500 images at a time creating using gdalbuildvrt and gdal_translate along with JPEG compression creating 21 TIFF files. I added overviews then to each of the new 21 files. When adding the images together, once directly as files using QGIS and another time as WMSs using GeoServer, I got white lines/gaps precisely at the border of ever 2 images. I thought the problem is with no data values but I decided to take another approach and merged all the 10,000 files into one huge image and this time I got one perfect image with no lines or gaps. I failed to create overviews for the big image because the process took days or gdaladdo running with no progress. I tested then on smaller images with and without overviews and the ones with no overview came perfect while the one with gdaladdo overviews came with the same problem of lines and gaps. The commands I m using are the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -a_srs EPSG:27700 -input_file_list tiff_list.txt mosaic.vrt gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co PHOTOMETRIC=YCBCR mosaic.vrt mosaic.tif gdaladdo mosaic.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Any ideas, tips or recommendations would be appreciated! Best regards, Ammar _ Sent from http://osgeo-org.1560.x6.nabble.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] (no subject)
GDALers: I've not had this error before when compiling GDAL for Linux boxes, but I'm getting some sqlite error. This is from: ./configure --prefix=/pathto/wherever --with=python make *** ... chmod a+x gdal-config /bin/sh /projects/oa/shared/jgrn/code/src/gdal-1.10.1/libtool --mode=link g++ gdalinfo.lo commonutils.lo /projects/oa/shared/jgrn/code/src/gdal-1.10.1/libgdal.la -o gdalinfo libtool: link: g++ .libs/gdalinfo.o .libs/commonutils.o -o .libs/gdalinfo /projects/oa/shared/jgrn/code/src/gdal-1.10.1/.libs/libgdal.so -L/usr/apps/oa/lib -L/usr/lib64/hdf -L/usr/apps/oa/lib/lib -L/usr/local/openmpi-1.4-gcc/lib /usr/apps/oa/lib/libgeos_c.so /usr/apps/oa/lib/libgeos.so /usr/apps/oa/lib/libsqlite3.so -lexpat -ljasper -lnetcdf -lhdf5 /usr/apps/oa/lib/libmfhdf.so /usr/apps/oa/lib/libdf.so /usr/apps/oa//lib/libjpeg.so /usr/apps/oa/lib/libpng15.so -lpthread -lrt -lpcre -lcurl /usr/apps/oa/lib/libxml2.so -lm -ldl -lz -Wl,-rpath -Wl,/usr/apps/oa/lib -Wl,-rpath -Wl,/usr/apps/oa//lib /projects/oa/shared/jgrn/code/src/gdal-1.10.1/.libs/libgdal.so: undefined reference to `sqlite3_column_table_name' collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make[1]: Leaving directory `/projects/oa/shared/jgrn/code/src/gdal-1.10.1/apps' make: *** [apps-target] Error 2 *** I do have SQLite properly installed via the sqlite-autoconf-3080200 release, configured via: ./configure --prefix=/pathto/wherever make make install Any ideas? --j -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about gdaladdo and raster mosaicking
Try without internal mask. Duarte _ De: Ammar [mailto:ammar8...@yahoo.com] Enviada: quinta-feira, 23 de Janeiro de 2014 14:28 Para: Etienne Tourigny Cc: gdal dev Assunto: Re: [gdal-dev] Question about gdaladdo and raster mosaicking Etienne, I tried the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -addalpha -input_file_list tiff_list.txt mosaic02.vrt gdal_translate -of GTiff -b 1 -b 2 -b 3 -mask 4 -a_srs EPSG:3011 -co TILED=yes -co compress=jpeg -co jpeg_quality=80 -co blockxsize=512 -co blockysize=512 -co photometric=ycbcr --config gdal_tiff_internal_mask yes mosaic02.vrt mosaic02.tif gdaladdo mosaic02.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Did I implement the mask the right way? The results I got were similar to the JPEG compression with no mask, in other words I got white lines too! From: Etienne Tourigny etourigny@gmail.commailto:etourigny@gmail.com To: Ammar ammar8...@yahoo.commailto:ammar8...@yahoo.com Cc: Chaitanya kumar CH chaitanya...@gmail.commailto:chaitanya...@gmail.com; gdal dev gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org Sent: Thursday, January 23, 2014 12:25 PM Subject: Re: [gdal-dev] Question about gdaladdo and raster mosaicking As was suggested, you could try using a mask instead. On Thu, Jan 23, 2014 at 7:52 AM, Ammar ammar8...@yahoo.commailto:ammar8...@yahoo.com wrote: Chaitanya, Thank you very much for your reply and suggestion. I have used LZW with predictor 2 compression and added external overviews compressed in LZW too and the image came perfect. The only downside is the size of each of the images has expanded from approx. 2 GB to 18-20 GB. So now I have to choose between quality and size! Attached are two screen shots showing the difference. Thanks again! Regards, Ammar From: Chaitanya kumar CH chaitanya...@gmail.commailto:chaitanya...@gmail.com To: ammar8...@yahoo.commailto:ammar8...@yahoo.com Cc: gdal dev gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org Sent: Tuesday, January 21, 2014 6:27 PM Subject: Re: Question about gdaladdo and raster mosaicking Ammar, You are using lossy JPEG compression. I'm guessing that the white lines are are actually pixels with values near but not equal to 255. So, they are not treated as nodata pixels. My suggestion is to use another format with lossless compression for the 21 images or use a mask band if you prefer. Let me know how it goes. -- Best regards, Chaitanya Kumar CH On 21-Jan-2014 5:31 pm, ammar8...@yahoo.commailto:ammar8...@yahoo.com wrote: Hello Chaitanya, I was looking online for solutions to my problem and I cam across some of your posts so I thought you might help me with my problem. I have 10,000+ TIFF files that I want to merge into one big Image and serve using GeoServer. I merged every 500 images at a time creating using gdalbuildvrt and gdal_translate along with JPEG compression creating 21 TIFF files. I added overviews then to each of the new 21 files. When adding the images together, once directly as files using QGIS and another time as WMSs using GeoServer, I got white lines/gaps precisely at the border of ever 2 images. I thought the problem is with no data values but I decided to take another approach and merged all the 10,000 files into one huge image and this time I got one perfect image with no lines or gaps. I failed to create overviews for the big image because the process took days or gdaladdo running with no progress. I tested then on smaller images with and without overviews and the ones with no overview came perfect while the one with gdaladdo overviews came with the same problem of lines and gaps. The commands I m using are the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -a_srs EPSG:27700 -input_file_list tiff_list.txt mosaic.vrt gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co PHOTOMETRIC=YCBCR mosaic.vrt mosaic.tif gdaladdo mosaic.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Any ideas, tips or recommendations would be appreciated! Best regards, Ammar _ Sent from http://osgeo-org.1560.x6.nabble.comhttp://osgeo-org.1560.x6.nabble.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about gdaladdo and raster mosaicking
Ammar you want to turn on internal masks in the shell, gdaladdo will not use them otherwise. also you will need to turn this on if you use mapserver. gdal will need to have this turned on for any further operations. gdaladdo should use the correct image options without specifying them export GDAL_TIFF_INTERNAL_MASK=YES gdalbuildvrt -srcnodata 255 -vrtnodata 255 -addalpha \ -input_file_list tiff_list.txt \ mosaic02.vrt gdal_translate -of GTiff -b 1 -b 2 -b 3 -mask 4 -a_srs EPSG:3011 \ -co TILED=yes -co photometric=ycbcr \ -co compress=jpeg -co jpeg_quality=80 \ -co blockxsize=512 -co blockysize=512 \ -mosaic02.vrt \ -mosaic02.tif gdaladdo mosaic02.tif -r average 2 4 8 16 32 64 128 256 512 and you should end up with a On Thu, 2014-01-23 at 06:28 -0800, Ammar wrote: Etienne, I tried the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -addalpha -input_file_list tiff_list.txt mosaic02.vrt gdal_translate -of GTiff -b 1 -b 2 -b 3 -mask 4 -a_srs EPSG:3011 -co TILED=yes -co compress=jpeg -co jpeg_quality=80 -co blockxsize=512 -co blockysize=512 -co photometric=ycbcr --config gdal_tiff_internal_mask yes mosaic02.vrt mosaic02.tif gdaladdo mosaic02.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Did I implement the mask the right way? The results I got were similar to the JPEG compression with no mask, in other words I got white lines too! __ From: Etienne Tourigny etourigny@gmail.com To: Ammar ammar8...@yahoo.com Cc: Chaitanya kumar CH chaitanya...@gmail.com; gdal dev gdal-dev@lists.osgeo.org Sent: Thursday, January 23, 2014 12:25 PM Subject: Re: [gdal-dev] Question about gdaladdo and raster mosaicking As was suggested, you could try using a mask instead. On Thu, Jan 23, 2014 at 7:52 AM, Ammar ammar8...@yahoo.com wrote: Chaitanya, Thank you very much for your reply and suggestion. I have used LZW with predictor 2 compression and added external overviews compressed in LZW too and the image came perfect. The only downside is the size of each of the images has expanded from approx. 2 GB to 18-20 GB. So now I have to choose between quality and size! Attached are two screen shots showing the difference. Thanks again! Regards, Ammar __ From: Chaitanya kumar CH chaitanya...@gmail.com To: ammar8...@yahoo.com Cc: gdal dev gdal-dev@lists.osgeo.org Sent: Tuesday, January 21, 2014 6:27 PM Subject: Re: Question about gdaladdo and raster mosaicking Ammar, You are using lossy JPEG compression. I'm guessing that the white lines are are actually pixels with values near but not equal to 255. So, they are not treated as nodata pixels. My suggestion is to use another format with lossless compression for the 21 images or use a mask band if you prefer. Let me know how it goes. -- Best regards, Chaitanya Kumar CH On 21-Jan-2014 5:31 pm, ammar8...@yahoo.com wrote: Hello Chaitanya, I was looking online for solutions to my problem and I cam across some of your posts so I thought you might help me with my problem. I have 10,000+ TIFF files that I want to merge into one big Image and serve using GeoServer. I merged every 500 images at a time creating using gdalbuildvrt and gdal_translate along with JPEG compression creating 21 TIFF files. I added overviews then to each of the new 21 files. When adding the images together, once directly as files using QGIS and another time as WMSs using GeoServer, I got white lines/gaps precisely at the border of ever 2 images. I thought the problem is with no data values but I decided to take another approach and merged all the 10,000 files into one huge image and this time I got one perfect image with no lines or gaps. I failed to create overviews for the big image because the process took days or gdaladdo running with no progress. I tested then on smaller images with and without overviews and the ones with no
Re: [gdal-dev] (no subject) [sqlite configuration]
Le jeudi 23 janvier 2014 17:09:41, Jonathan Greenberg a écrit : GDALers: I've not had this error before when compiling GDAL for Linux boxes, but I'm getting some sqlite error. This is from: ./configure --prefix=/pathto/wherever --with=python make *** ... chmod a+x gdal-config /bin/sh /projects/oa/shared/jgrn/code/src/gdal-1.10.1/libtool --mode=link g++ gdalinfo.lo commonutils.lo /projects/oa/shared/jgrn/code/src/gdal-1.10.1/libgdal.la -o gdalinfo libtool: link: g++ .libs/gdalinfo.o .libs/commonutils.o -o .libs/gdalinfo /projects/oa/shared/jgrn/code/src/gdal-1.10.1/.libs/libgdal.so -L/usr/apps/oa/lib -L/usr/lib64/hdf -L/usr/apps/oa/lib/lib -L/usr/local/openmpi-1.4-gcc/lib /usr/apps/oa/lib/libgeos_c.so /usr/apps/oa/lib/libgeos.so /usr/apps/oa/lib/libsqlite3.so -lexpat -ljasper -lnetcdf -lhdf5 /usr/apps/oa/lib/libmfhdf.so /usr/apps/oa/lib/libdf.so /usr/apps/oa//lib/libjpeg.so /usr/apps/oa/lib/libpng15.so -lpthread -lrt -lpcre -lcurl /usr/apps/oa/lib/libxml2.so -lm -ldl -lz -Wl,-rpath -Wl,/usr/apps/oa/lib -Wl,-rpath -Wl,/usr/apps/oa//lib /projects/oa/shared/jgrn/code/src/gdal-1.10.1/.libs/libgdal.so: undefined reference to `sqlite3_column_table_name' collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make[1]: Leaving directory `/projects/oa/shared/jgrn/code/src/gdal-1.10.1/apps' make: *** [apps-target] Error 2 *** I do have SQLite properly installed via the sqlite-autoconf-3080200 release, configured via: ./configure --prefix=/pathto/wherever make make install Any ideas? Jonathan, The GDAL source code tries to use sqlite3_column_table_name only if it is available i the sqlite library. Indeed, not all builds of sqlite3 have sqlite3_column_table_name defined. So you should not get this error theroretically. My hypothesis is that the test in ./configure that detects if sqlite3_column_table_name is available or not must link against another library than the one that GDAL is finally linking against. This is a bit weird however that this happens, but I'd encourage you checking that there are not several libsqlite3.so hanging around. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdaldem slope with -s 111120.0 works only at equator for lat/lon?
Le mercredi 22 janvier 2014 23:14:01, John Abraham a écrit : Please help me with something potentially important. The documentation for gdaldem slope says “If the horizontal unit of the source DEM is degrees (e.g Lat/Long WGS84 projection), you can use scale=20 if the vertical units are meters” but I don’t think this works very far away from the equator. I think the algorithm assumes that the north-south units are the same as the east-west units, whereas obviously away from the equator degrees of longitude become a lot shorter. I’m looking at my attempt at avalanche slope mapping, and seem to see east-west slopes showing up with higher slopes than north-south slopes with identically spaced contour intervals. Am I right? Or am I seeing things? Yes, the -scale 20 only works for approximate visual rendering, not for something life critical. If I’m right, perhaps: 1) Someone should fix the documentation, so that people don’t rely on incorrect slope calculations for something life-critical such as avalanche slope mapping, and If you want to provide an update of the doc, its source is in apps/gdal_utilities.dox ( http://svn.osgeo.org/gdal/trunk/gdal/apps/gdal_utilities.dox ) 2) Someone could tell me a better solution, I think perhaps the best idea is to just resample the grid into a projection based on meters, before applying gdaldem without any scaling factor. Yes that would probably be certainly more appropriate. For example in the UTM zone of your data, or potentially some more fitted grid. Thanks for your help. This has been bugging me for sometime, but I finally decided to speak up. — John Abraham j...@hbaspecto.com -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_translate adding 'dashed' lines to output
I've been trying to use gdal_translate to convert a USGS GeoPDF to a GeoTiff file. It appears to be working correctly except for one issue. During the conversion a number of horizontal lines appear in the output. They appear at a few latitudes in the file - it looks like a dashed line across the image with a lot of space between each dash (but you have to zoom in to see them). When I view the produced GeoTiff file in an image viewer here is what I see (zoomed in and cropped): http://www.graysolutions.com/temp/LenexaLines.png I've circled the improper lines in this image. When I view the GeoPDF in Acrobat these lines do not appear (so I do not believe they are part of the source image). Has anybody seen this problem before or know how to keep it from happening? - Additional Details: For the example above I rendered only the raster orthoimage layer, however when the full contents of the file are rendered I still see the 'dashes' in the output. The source GeoPDF file I'm working with can be downloaded here (~25 MB, downloads as a .zip file): http://ims.er.usgs.gov/gda_services/download?item_id=5689818 I'm using GDAL compiled for Windows from http://www.gisinternals.com/sdk/. I tried using both the 'stable' and 'development' versions and the results were the same (running on Windows 8.1). The command line used: gdal_translate -of GTiff --config GDAL_PDF_LAYERS Images.Orthoimage --config GDAL_PDF_DPI 150 KS_Lenexa_20120905_TM_geo.pdf Lenexa.tif I'm using the DPI setting to scale the image down so the output isn't so large (without this it is a ~950 MB file). I did render one without setting this (rendering at the native resolution) and the dahses were still there. I've also tried this for other GeoPDF files in the same series and experienced similar results. Thanks, John ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_translate adding 'dashed' lines to output
Le jeudi 23 janvier 2014 22:49:33, John Gray a écrit : I've been trying to use gdal_translate to convert a USGS GeoPDF to a GeoTiff file. It appears to be working correctly except for one issue. During the conversion a number of horizontal lines appear in the output. They appear at a few latitudes in the file - it looks like a dashed line across the image with a lot of space between each dash (but you have to zoom in to see them). When I view the produced GeoTiff file in an image viewer here is what I see (zoomed in and cropped): http://www.graysolutions.com/temp/LenexaLines.png I've circled the improper lines in this image. When I view the GeoPDF in Acrobat these lines do not appear (so I do not believe they are part of the source image). Has anybody seen this problem before or know how to keep it from happening? - Additional Details: For the example above I rendered only the raster orthoimage layer, however when the full contents of the file are rendered I still see the 'dashes' in the output. The source GeoPDF file I'm working with can be downloaded here (~25 MB, downloads as a .zip file): http://ims.er.usgs.gov/gda_services/download?item_id=5689818 I'm using GDAL compiled for Windows from http://www.gisinternals.com/sdk/. I tried using both the 'stable' and 'development' versions and the results were the same (running on Windows 8.1). The command line used: gdal_translate -of GTiff --config GDAL_PDF_LAYERS Images.Orthoimage --config GDAL_PDF_DPI 150 KS_Lenexa_20120905_TM_geo.pdf Lenexa.tif I've just tried the above with a recent version of the Poppler library that is used by the PDF driver for the rendering and there are no such artifacts. I've also just tried with the Poppler version used by the builds on gisinternals, which is a bit obsolete now, and I do see the artifacts. So the builds on gisinternals would benefit from an upgrade of the Poppler library. You might want to contact Tamas Szekeres about this. I'm using the DPI setting to scale the image down so the output isn't so large (without this it is a ~950 MB file). I did render one without setting this (rendering at the native resolution) and the dahses were still there. I've also tried this for other GeoPDF files in the same series and experienced similar results. Thanks, John ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
