[gdal-dev] gdal2tiles.py generating dark tiles
Hi all, Dark tiles are generated when I run gdal2tiles.py on a .IMG file(a scanned and georeferenced topographical map). A sample png of the tiles generated is found here https://sites.google.com/site/lumtegis/files/519.png. Even when i translate to tiff, the output is still the same. Why does gdal2tiles.py give this result ? The gdalinfo output is as below: Driver: HFA/Erdas Imagine Images (.img) Files: ALOI.IMG ALOI.IMG.aux.xml Size is 3830, 2552 Coordinate System is: GEOGCS[GCS_WGS_1984, DATUM[WGS_1984, SPHEROID[WGS_1984,6378137.0,298.257223563]], PRIMEM[Greenwich,0.0], UNIT[Degree,0.017453292519943295]] Origin = (32.999437318839924,3.000470692247897) Pixel Size = (0.000392066994127,-0.000392066994127) Metadata: DataType=Generic Corner Coordinates: Upper Left ( 32.9994373, 3.0004707) ( 32d59'57.97E, 3d 0'1.69N) Lower Left ( 32.9994373, 1.157) ( 32d59'57.97E, 1d59'59.70N) Upper Right ( 34.5010539, 3.0004707) ( 34d30'3.79E, 3d 0'1.69N) Lower Right ( 34.5010539, 1.157) ( 34d30'3.79E, 1d59'59.70N) Center ( 33.7502456, 2.5001932) ( 33d45'0.88E, 2d30'0.70N) Band 1 Block=64x64 Type=UInt16, ColorInterp=Undefined Description = Layer_1 Min=0.000 Max=255.000 Minimum=0.000, Maximum=255.000, Mean=225.572, StdDev=31.338 NoData Value=256 Overviews: 1915x1276, 958x638, 479x319, 240x160 Metadata: STATISTICS_COVARIANCES=982.046346716112,845.521289084631,710.510646703791 STATISTICS_MINIMUM=0 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=225.57242379015 STATISTICS_MEDIAN=0 STATISTICS_MODE=0 STATISTICS_STDDEV=31.337618714831 STATISTICS_SKIPFACTORX=1 STATISTICS_SKIPFACTORY=1 STATISTICS_EXCLUDEDVALUES= LAYER_TYPE=athematic Image Structure Metadata: COMPRESSION=RLE Band 2 Block=64x64 Type=UInt16, ColorInterp=Undefined Description = Layer_2 Min=4.000 Max=255.000 Minimum=4.000, Maximum=255.000, Mean=226.079, StdDev=29.739 NoData Value=256 Overviews: 1915x1276, 958x638, 479x319, 240x160 Metadata: STATISTICS_COVARIANCES=845.521289084631,884.412989496947,765.062067015664 STATISTICS_MINIMUM=4 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=226.07921779459 STATISTICS_MEDIAN=0 STATISTICS_MODE=0 STATISTICS_STDDEV=29.739081853631 STATISTICS_SKIPFACTORX=1 STATISTICS_SKIPFACTORY=1 STATISTICS_EXCLUDEDVALUES= LAYER_TYPE=athematic Image Structure Metadata: COMPRESSION=RLE Band 3 Block=64x64 Type=UInt16, ColorInterp=Undefined Description = Layer_3 Min=0.000 Max=255.000 Minimum=0.000, Maximum=255.000, Mean=172.929, StdDev=27.135 NoData Value=256 Overviews: 1915x1276, 958x638, 479x319, 240x160 Metadata: STATISTICS_COVARIANCES=710.510646703791,765.062067015664,736.335138826829 STATISTICS_MINIMUM=0 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=172.92884721066 STATISTICS_MEDIAN=0 STATISTICS_MODE=0 STATISTICS_STDDEV=27.135495920046 STATISTICS_SKIPFACTORX=1 STATISTICS_SKIPFACTORY=1 STATISTICS_EXCLUDEDVALUES= LAYER_TYPE=athematic Image Structure Metadata: COMPRESSION=RLE Thanks, Allan. -- Allan Oware Cell: +254 727 365820 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] warp taking time
Adiba, I noticed that your source and target projections are same. Why not use gdalbuildvrt and gdal_translate and skip the warping process? You create a virtual mosaic (and assign the projection if needed) with buildvrt. You can create a tiff file from the vrt file using gdal_translate. On Mon, Jul 14, 2014 at 11:12 AM, adiba nizami adiba.niz...@gmail.com wrote: Sorry for the late reply. Here is the command i gave : gdalwarp --config GDAL_CACHEMAX 512 -s_srs +proj=aea +lat_1=28 +lat_2=12 +lat_0=20 +lon_0=87 +x_0=200 +y_0=200 +ellps=WGS84 +datum=WGS84 +units=m +no_defs -t_srs +proj=aea +lat_1=28 +lat_2=12 +lat_0=20 +lon_0=87 +x_0=200 +y_0=200 +ellps=WGS84 +datum=WGS84 +units=m +no_defs -te -138559.10 571316.50 3010515.63 4012751.95 -tr 18 18 -wm 512 -co BIGTIFF=YES -srcnodata 255 -dstnodata 255 file1.tif file2.tif . file28.tif output.tif On Thu, Jul 10, 2014 at 7:23 PM, Thornton, Michele M. thornto...@ornl.gov wrote: Hello, I’m interested in this thread. One comment I can add about gdal_merge.py is that it does not properly handle nodata values from the full (padded) extent of the input files. gdalwarp, which can be VERY slow, does handle the nodata values correctly. Michele Thornton *From:* gdal-dev-boun...@lists.osgeo.org [mailto: gdal-dev-boun...@lists.osgeo.org] *On Behalf Of *bas smit *Sent:* Thursday, July 10, 2014 7:52 AM *To:* Chaitanya kumar CH *Cc:* gdal dev *Subject:* Re: [gdal-dev] warp taking time I am wondering why you are using gdalwarp for mosaicing images having same projection instead of gdal_merge.py? Bas Smit On Thu, Jul 10, 2014 at 7:14 PM, Chaitanya kumar CH chaitanya...@gmail.com wrote: garfy, Please provide the gdalwarp command you used. Did you modify GDAL_CACHEMAX? On Thu, Jul 10, 2014 at 3:26 PM, garfy adiba.niz...@gmail.com wrote: Dear All, I am trying to generate mosaic of 28 input images using *gdalwarp*. All are in same projection. It has taken 5 days to generate the final output. Please find the gdalinfo of input and output attached. The input files are passed to warp in the order in which the gdalinfo is present in the attachement. Any input on improving the time would be really helpful. Thanks input_files_gdalinfo.txt http://osgeo-org.1560.x6.nabble.com/file/n5150453/input_files_gdalinfo.txt final_output_gdalinfo.txt http://osgeo-org.1560.x6.nabble.com/file/n5150453/final_output_gdalinfo.txt -- View this message in context: http://osgeo-org.1560.x6.nabble.com/warp-taking-time-tp5150453.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ 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 -- Regards, Adiba Khan -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] RE : Re: Reading shapefile PRJ failing
Envoyé depuis un mobile Samsung Message d'origine De : Even Rouault (par Internet, dépôt gdal-dev-boun...@lists.osgeo.org) even.roua...@mines-paris.org Date : 12/07/2014 9:29 PM (GMT+01:00) A : Brian McCormick mcc...@cox.net Cc : gdal-dev@lists.osgeo.org Objet : Re: [gdal-dev] Reading shapefile PRJ failing Brian, I've added support in GDAL trunk for those files. I could see that at least another GIS software supported them, so... Even Even, I am not sure what generated it. It seems as though I have run across a lot of files that have a BOM that have thrown me in recent years. Most seem to have some relation to using Microsoft .net framework tools that have Unicode support built in from the ground up. But I am really not sure and that is just a guess. Some text editors seem to do it also. I just know that it has caused me all sorts of grief over the years with all sorts of software I have both used and written. Here is what I have used in the past for the BOM list although the EF BB BF is by far the most common I have seen... http://en.wikipedia.org/wiki/Byte_order_mark Anyway I have attached a shapefile that has a bom marker in the prj file. Not sure yet about the other files...if they have any similar anomalies or exactly what was used to gen the shapefile. I haven't looked at the shp, shx or dbf file yet... Thanks, Brian S. McCormick mcc...@cox.net 918-749-5453 -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Saturday, July 12, 2014 12:32 PM To: mccorb Subject: Re: [gdal-dev] Reading shapefile PRJ failing Le samedi 12 juillet 2014 18:45:24, vous avez écrit : So I have tracked this down to the fact that the PRJ files that I have been given to use have a BOM of 0xEF 0xBB 0xBF for the first three bytes of the file. When I use the shapefiles that have these byte order markers the Layer class method getSpatialRef() (java JNI bindings) returns null. I am guessing that the PRJ file is being opened in binary mode instead of text mode possibly? Regardless, is there any setting I can make to coerce the file opener/reader into ignoring the BOM when grabbing the WKT from the PRJ file? Not really. GDAL should be enhanced to support such a file. Do you have a sample of such a .prj ? Do you know which software has generated it ? That's the first time I hear about .prj with BOM marker. thanks -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Reading-shapefile-PRJ-failing-tp51 5077 8.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ 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 -- 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal2tiles.py generating dark tiles
After digging around and comparing other images, I realised that the .IMG lacks color interpretation since the ColorInterp parameter in gdalinfo output is undefined for the 3 bands. When I attempt to gdal_translate to Gtiff with -expand rgb option, the error output was: band 1 has no color table. Any hint on how to properly define color interpretation for a .IMG ? I have qgis, grass and gdal in an ubuntu setup. Thanks, Allan. On Mon, Jul 14, 2014 at 10:02 AM, Allan Oware allanow...@gmail.com wrote: Hi all, Dark tiles are generated when I run gdal2tiles.py on a .IMG file(a scanned and georeferenced topographical map). A sample png of the tiles generated is found here https://sites.google.com/site/lumtegis/files/519.png. Even when i translate to tiff, the output is still the same. Why does gdal2tiles.py give this result ? The gdalinfo output is as below: Driver: HFA/Erdas Imagine Images (.img) Files: ALOI.IMG ALOI.IMG.aux.xml Size is 3830, 2552 Coordinate System is: GEOGCS[GCS_WGS_1984, DATUM[WGS_1984, SPHEROID[WGS_1984,6378137.0,298.257223563]], PRIMEM[Greenwich,0.0], UNIT[Degree,0.017453292519943295]] Origin = (32.999437318839924,3.000470692247897) Pixel Size = (0.000392066994127,-0.000392066994127) Metadata: DataType=Generic Corner Coordinates: Upper Left ( 32.9994373, 3.0004707) ( 32d59'57.97E, 3d 0'1.69N) Lower Left ( 32.9994373, 1.157) ( 32d59'57.97E, 1d59'59.70N) Upper Right ( 34.5010539, 3.0004707) ( 34d30'3.79E, 3d 0'1.69N) Lower Right ( 34.5010539, 1.157) ( 34d30'3.79E, 1d59'59.70N) Center ( 33.7502456, 2.5001932) ( 33d45'0.88E, 2d30'0.70N) Band 1 Block=64x64 Type=UInt16, ColorInterp=Undefined Description = Layer_1 Min=0.000 Max=255.000 Minimum=0.000, Maximum=255.000, Mean=225.572, StdDev=31.338 NoData Value=256 Overviews: 1915x1276, 958x638, 479x319, 240x160 Metadata: STATISTICS_COVARIANCES=982.046346716112,845.521289084631,710.510646703791 STATISTICS_MINIMUM=0 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=225.57242379015 STATISTICS_MEDIAN=0 STATISTICS_MODE=0 STATISTICS_STDDEV=31.337618714831 STATISTICS_SKIPFACTORX=1 STATISTICS_SKIPFACTORY=1 STATISTICS_EXCLUDEDVALUES= LAYER_TYPE=athematic Image Structure Metadata: COMPRESSION=RLE Band 2 Block=64x64 Type=UInt16, ColorInterp=Undefined Description = Layer_2 Min=4.000 Max=255.000 Minimum=4.000, Maximum=255.000, Mean=226.079, StdDev=29.739 NoData Value=256 Overviews: 1915x1276, 958x638, 479x319, 240x160 Metadata: STATISTICS_COVARIANCES=845.521289084631,884.412989496947,765.062067015664 STATISTICS_MINIMUM=4 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=226.07921779459 STATISTICS_MEDIAN=0 STATISTICS_MODE=0 STATISTICS_STDDEV=29.739081853631 STATISTICS_SKIPFACTORX=1 STATISTICS_SKIPFACTORY=1 STATISTICS_EXCLUDEDVALUES= LAYER_TYPE=athematic Image Structure Metadata: COMPRESSION=RLE Band 3 Block=64x64 Type=UInt16, ColorInterp=Undefined Description = Layer_3 Min=0.000 Max=255.000 Minimum=0.000, Maximum=255.000, Mean=172.929, StdDev=27.135 NoData Value=256 Overviews: 1915x1276, 958x638, 479x319, 240x160 Metadata: STATISTICS_COVARIANCES=710.510646703791,765.062067015664,736.335138826829 STATISTICS_MINIMUM=0 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=172.92884721066 STATISTICS_MEDIAN=0 STATISTICS_MODE=0 STATISTICS_STDDEV=27.135495920046 STATISTICS_SKIPFACTORX=1 STATISTICS_SKIPFACTORY=1 STATISTICS_EXCLUDEDVALUES= LAYER_TYPE=athematic Image Structure Metadata: COMPRESSION=RLE Thanks, Allan. -- Allan Oware Cell: +254 727 365820 -- Allan Oware Cell: +254 727 365820 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal installation, geopdf not recognized
Hello, I have been trying to install GDAL to convert USGS GeoPdf. Googling gave me a couple of links for quick installation for windows. http://trac.osgeo.org/osgeo4w/wiki · http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal (GDAL‑1.11.0.win32‑py2.7.exejavascript:;) I have 32 bit machine, windows 7 and python 2.7. There was a side-by-side configuration error, so I had to get that .dll, and I tried a couple of times. The installation seemed successful, however, I got error when reading a geopdf: ERROR 4: `C:\TestFolder\WI_Madison_West_20100723_TM_geo.pdf' not recognized as a supported file format. Even though pdf is listed with gdalinfo –formats: PDF (rw): Geospatial PDF Anybody could point me to a solution to this? It’s much appreciated. (I saw a previous post about cleaning before a new installation. That could be my problem too. But not sure how to do this with windows. Any clue would be helpful, thanks!) Regards, Jian ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal installation, geopdf not recognized
Hi Jian, On Mon, Jul 14, 2014 at 7:52 AM, Liu, Jian j...@eris.ca wrote: Hello, I have been trying to install GDAL to convert USGS GeoPdf. Googling gave me a couple of links for quick installation for windows. http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries lists some additional options. I often use http://www.gisinternals.com/sdk/ from Tamas. http://trac.osgeo.org/osgeo4w/wiki · http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal (GDAL‑1.11.0.win32‑py2.7.exe) I have 32 bit machine, windows 7 and python 2.7. There was a side-by-side configuration error, so I had to get that .dll, and I tried a couple of times. The installation seemed successful, however, I got error when reading a geopdf: ERROR 4: `C:\TestFolder\WI_Madison_West_20100723_TM_geo.pdf' not recognized as a supported file format. I got this error from OSGeo4W too. The last two lines of this page, http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and ticket tracker. You can ask or report this error there. Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 If you list a link to the file, it is easier for people to test. I found, this, ims.er.usgs.gov/gda_services/download?item_id=5954807 for testing. I tested with about a four month old download from http://www.gisinternals.com/sdk/ and it worked showing this, gdalinfo WI_Madison_West_20130722_TM_geo.pdf Driver: PDF/Geospatial PDF Files: WI_Madison_West_20130722_TM_geo.pdf Size is 13656, 17407 Coordinate System is: PROJCS[UTM Zone 16, Northern Hemisphere, ... ... Corner Coordinates: Upper Left ( 294830.111, 4779306.587) ( 89d31'22.05W, 43d 8'19.31N) Lower Left ( 294317.106, 4761635.933) ( 89d31'21.23W, 42d58'46.52N) Upper Right ( 308692.951, 4778904.128) ( 89d21' 8.42W, 43d 8'19.34N) Lower Right ( 308179.946, 4761233.474) ( 89d21' 9.19W, 42d58'46.51N) Center ( 301505.029, 4770270.031) ( 89d26'15.22W, 43d 3'33.04N) Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=1024x1024 Type=Byte, ColorInterp=Alpha So the file is fine but something appears to be wrong with the OSGeo4W geopdf support. The binaries at http://www.gisinternals.com/sdk/ from Tamas seem to properly support geopdf. Best Regards, Eli Even though pdf is listed with gdalinfo –formats: PDF (rw): Geospatial PDF Anybody could point me to a solution to this? It’s much appreciated. (I saw a previous post about cleaning before a new installation. That could be my problem too. But not sure how to do this with windows. Any clue would be helpful, thanks!) Regards, Jian ___ 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] gdal installation, geopdf not recognized
Hi Eli, On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote: I got this error from OSGeo4W too. The last two lines of this page, http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and ticket tracker. You can ask or report this error there. Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 I can't reproduce that. WI_Madison_West_20130722_TM_geo.pdf works fine with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2). Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal installation, geopdf not recognized
On Mon, Jul 14, 2014 at 11:17 AM, Jürgen E. j...@norbit.de wrote: Hi Eli, On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote: I got this error from OSGeo4W too. The last two lines of this page, http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and ticket tracker. You can ask or report this error there. Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 I can't reproduce that. WI_Madison_West_20130722_TM_geo.pdf works fine with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2). I tried gdalinfo --debug on but that did not provide additional information. gdalinfo --version reports GDAL 1.11.0, released 2014/04/16 Before I try updating OSGeo4W and seeing if anything changes, is there anything else to try to find the source of the error? My install is the result of an advanced install about three months ago and probably updated about a month or two ago. Thanks, Eli Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ 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] gdal installation, geopdf not recognized
Hi Eli, On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote: Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 I can't reproduce that. WI_Madison_West_20130722_TM_geo.pdf works fine with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2). Before I try updating OSGeo4W and seeing if anything changes, is there anything else to try to find the source of the error? My install is the result of an advanced install about three months ago and probably updated about a month or two ago. Ok, that's explains it. #408 tries to explain that 1.11.0-2 is from 9 days ago and introduces pdf read support - earlier didn't have it. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal installation, geopdf not recognized
Thanks Eli and Jürgen. Eli, The link you gave solved my problem. Thank you very much! I was trying to use GDAL with python bindings. So I keep the installation from http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal (GDAL‑1.11.0.win32‑py2.7.exe) and manually replaced and added some files using those from the link you gave. Not sure which one(s) did the fix, and not sure if that is a proper way, but I am glad it's working now. Thank you so much! Best regards, Jian -Original Message- From: Eli Adam [mailto:ea...@co.lincoln.or.us] Sent: Mon, July 14, 2014 1:40 PM To: Liu, Jian Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdal installation, geopdf not recognized Hi Jian, On Mon, Jul 14, 2014 at 7:52 AM, Liu, Jian j...@eris.ca wrote: Hello, I have been trying to install GDAL to convert USGS GeoPdf. Googling gave me a couple of links for quick installation for windows. http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries lists some additional options. I often use http://www.gisinternals.com/sdk/ from Tamas. http://trac.osgeo.org/osgeo4w/wiki · http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal (GDAL‑1.11.0.win32‑py2.7.exe) I have 32 bit machine, windows 7 and python 2.7. There was a side-by-side configuration error, so I had to get that .dll, and I tried a couple of times. The installation seemed successful, however, I got error when reading a geopdf: ERROR 4: `C:\TestFolder\WI_Madison_West_20100723_TM_geo.pdf' not recognized as a supported file format. I got this error from OSGeo4W too. The last two lines of this page, http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and ticket tracker. You can ask or report this error there. Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 If you list a link to the file, it is easier for people to test. I found, this, ims.er.usgs.gov/gda_services/download?item_id=5954807 for testing. I tested with about a four month old download from http://www.gisinternals.com/sdk/ and it worked showing this, gdalinfo WI_Madison_West_20130722_TM_geo.pdf Driver: PDF/Geospatial PDF Files: WI_Madison_West_20130722_TM_geo.pdf Size is 13656, 17407 Coordinate System is: PROJCS[UTM Zone 16, Northern Hemisphere, ... ... Corner Coordinates: Upper Left ( 294830.111, 4779306.587) ( 89d31'22.05W, 43d 8'19.31N) Lower Left ( 294317.106, 4761635.933) ( 89d31'21.23W, 42d58'46.52N) Upper Right ( 308692.951, 4778904.128) ( 89d21' 8.42W, 43d 8'19.34N) Lower Right ( 308179.946, 4761233.474) ( 89d21' 9.19W, 42d58'46.51N) Center ( 301505.029, 4770270.031) ( 89d26'15.22W, 43d 3'33.04N) Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=1024x1024 Type=Byte, ColorInterp=Alpha So the file is fine but something appears to be wrong with the OSGeo4W geopdf support. The binaries at http://www.gisinternals.com/sdk/ from Tamas seem to properly support geopdf. Best Regards, Eli Even though pdf is listed with gdalinfo –formats: PDF (rw): Geospatial PDF Anybody could point me to a solution to this? It’s much appreciated. (I saw a previous post about cleaning before a new installation. That could be my problem too. But not sure how to do this with windows. Any clue would be helpful, thanks!) Regards, Jian ___ 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] gdal installation, geopdf not recognized
On Mon, Jul 14, 2014 at 12:35 PM, Jürgen E. j...@norbit.de wrote: Hi Eli, On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote: Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 I can't reproduce that. WI_Madison_West_20130722_TM_geo.pdf works fine with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2). Before I try updating OSGeo4W and seeing if anything changes, is there anything else to try to find the source of the error? My install is the result of an advanced install about three months ago and probably updated about a month or two ago. Ok, that's explains it. #408 tries to explain that 1.11.0-2 is from 9 days ago and introduces pdf read support - earlier didn't have it. More carefully reading, I now see that the fix was 9 days ago. I updated and as expected OSGeo4W reads geopdf fine. Thanks, Eli Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ 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] [BULK] Re: Dissolve shapefile using GDAL/OGR
Hello all, Does anybody have suggestions on this issue? I am just interested on dissolving polygons, if there is another way around, too. thanks On Jul 11, 2014 9:21 AM, kalu671 kalu...@gmail.com wrote: Hello Dan, I tried to use the syntax and I am getting the error: The filename, directory name, or volume label syntax is incorrect. my syntax is as below: inFile = D:\Dir1\Polygons.shp outFile = D:\Dir2\Dissolved_polygons.shp dissolve = 'C:\OSGeo4W64\apps\saga\saga_cmd shapes_polygons Polygon Dissolve -POLYGONS = ' + inFile + ' -DISSOLVED = ' + outFile + ' -FIELD_1= Value -DISSOLVE= 0' subprocess.call(dissolve, shell=True) Would you please suggest what did I do wrong? Thanks -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Dissolve-shapefile-using-GDAL-OGR-tp5036930p5150675.html Sent from the GDAL - Dev mailing list archive at 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] [BULK] Re: Dissolve shapefile using GDAL/OGR
The path strings are not escaped, so dissolve[13] is '\a' or '\x07' and not 'a', which makes the path invalid. For Windows paths, the best practice is to either use forward slashes (like unix), or use raw escape with r as a string prefix, e.g. dissolve = r'C:\OSGeo4W64\apps...' On 12 July 2014 02:21, kalu671 kalu...@gmail.com wrote: Hello Dan, I tried to use the syntax and I am getting the error: The filename, directory name, or volume label syntax is incorrect. my syntax is as below: inFile = D:\Dir1\Polygons.shp outFile = D:\Dir2\Dissolved_polygons.shp dissolve = 'C:\OSGeo4W64\apps\saga\saga_cmd shapes_polygons Polygon Dissolve -POLYGONS = ' + inFile + ' -DISSOLVED = ' + outFile + ' -FIELD_1= Value -DISSOLVE= 0' subprocess.call(dissolve, shell=True) Would you please suggest what did I do wrong? Thanks ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
