[gdal-dev] Re: GDAL encounters problem with very small files
Hi Frank, Thanks for your response. I made the error of mixing one gdal_utility question and a Python-GDAL binding question. The problem I am encountering with gdal_translate and gdalinfo with these very little files only happens when I am working on very small images. Else, it is working well. And I use these utilities from the shell, so it should have nothing to do with Python. But as I told you, I have only the version 1.4.2 installed here... On the other hand I have problems with the Python piece of code I have copied, so I just wanted to know if I forgot something in these simple data copying code. I will look for that, thanks. So for the first problem, I will try it again on other configurations, with GDAL 1.5.3 or 1.6 beta and maybe with different libtiff versions... If you still have other ideas, tell me ;) Best regards, Matthieu On Thursday 13 November 2008 18:13:17 you wrote: Matthieu Rigal wrote: Hi all, hi Frank, I am encountering problem with gdal_translate and gdalinfo with very little images. I have for example a 9*16 pixels image, georeferenced, 16bits and 8bits, that I have tested in 2 formats : .pix PCIDSK and .tif GTiff. And both times, I get errors : gdal_translate: symbol lookup error: gdal_translate: undefined symbol: GDALValidateCreationOptions gdalinfo: symbol lookup error: gdalinfo: undefined symbol: GDALGetFileList I have attached both tif files in 8bits and 16 bits, with the hope it will help. Notice that these images can be open by software like QGis or PCI Geomatica... If you have any ideas or if it is a known bug... let me know ! Matthieu, I tried gdalinfo on the files and it worked fine. Your Python looked fine. The error messages seem to indicate an inappropriate mixture of versions. Presumably recent Python bindings that are trying to pick up an older version of GDAL lacking some modern entry points. Does the same configuration work fine with larger TIFF files? Best regards, RapidEye AG Molkenmarkt 30 14776 Brandenburg an der Havel Germany Head Office/Sitz der Gesellschaft: Brandenburg an der Havel Management Board/Vorstand: Wolfgang G. Biedermann Chairman of Supervisory Board/Vorsitzender des Aufsichtsrates: Axel Schmalz Commercial Register/Handelsregister Potsdam HRB 17 796 Tax Number/Steuernummer: 048/100/00053 VAT-Ident-Number/Ust.-ID: DE 199331235 DIN EN ISO 9001 certified * Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. The information in this e-mail is intended for the named recipients only. It may contain privileged and confidential information. If you have received this communication in error, any use, copying or dissemination of its contents is strictly prohibited. Please erase all copies of the message along with any included attachments and notify RapidEye AG or the sender immediately by telephone at the number indicated on this page. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR WFS driver
Hello, Some informations about our driver : - It uses existing OGR GML driver to parse WFS server message and knows only gml 1.0 answer, so you must specified answer in gml 1.0 in your requests to the server. It should not be difficult to add zipped gml, but for another format (such as shape) it will be a more complex thing to do. - A specific request is done to get capabilities of a wfs server and a xerces parser is used to scan the answer - curl is directly used, no call to cpl_http.h, sorry. - It does not understand WFS style tag. - In fact, it is used to do geometric request on layers and parse the answer to produce ogr data. Next week, I will try to build it directly in ogr (for gdal 1.5.3 release) and look into cpl_http.h. As for being a commiter, I'm sorry but I can't do that during my working time. Regards, Johan. -- Johan Nouvel, RD Engineer http://www.archivideo.com tel : +33 (0)2 99 86 30 20 ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Gdal Bug? was: Re: [gdal-dev] JP2MRSID Issues
Stephen Woodbridge wrote: Frank, If someone can generate a patch the prints this stuff out, I'll have our guys build a version with the patch and I'll run it against one of the cases that fails. There wouldn't happen to be a hidden debug option that might already print this out? Thank you Michael for any assistance from your end also. Steve, Skimming through mrsiddataset.cpp, it appears there are already quite extensive debug statements. Try enabling debug output when running the failed operation. For GDAL commandline apps adding --debug on to the commandline (without the quotes) should do the trick. The debug output all goes to stderr. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Gdal Bug? was: Re: JP2MRSID Issues
Jukka Rahkonen wrote: Stephen Woodbridge woodbri at swoodbridge.com writes: PPS. I don't understand your point where you seem to suggest that converting to tiff first is slower than other mechanisms. Are you suggesting it takes 2-3 hours to convert a 500MB jpeg2000 image to GeoTIFF? Perhaps you need to up your GDAL block cache size? Yes, this is exactly my problem it is taking 2-3 hours to run: GDAL_SKIP=JPEG2000 gdal_translate my.jp2 -b 1 -b 2 -b 3 my.tif Hi, There is absolutely something basically wrong. For that little files conversion to GeoTIFF should take perhaps 5 minutes. Try skipping more drivers and see how Kakadu driver performs. If you want to know how fast it can be, download Kakadu win32 executables from www.kakadusoftware.com and measure how long it takes to expand your images to GeoTIFFs with kdu_expand. Hi Jukka, Thank you for that pointer. I grabbed the linux version and kdu_expand is really fast!!! 2 mins if the source file is not cached and 55 sec if it is cached by the file system. But is only is expanding the first band, do you know how I can get it to expand bands 1,2,3 into the tiff as r,g,b? If I can do that then I could just use that as an interim step to expand the jp2 into a tif and then do the gdalwarp based on that. -Steve ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[Gdal-dev] problems warping a netcdf file
Hello, I'm fairly new to reprojection and my experience with gdal is limited, so I'll do my best to keep up. I have tried searching through a number of messages without finding anything quite like my problem. I've been completely unsuccessful trying to reproject a netcdf file for some time now and I'm becoming fairly desperate for some help. I'm going for changing Lambert Conformal with a perfect sphere geoid with earth radius=6370km centered at 40N, 97W with standard latitudes at 33N, 45N to geographic lat, long (flat) projection. First, a little gdal info on one particular subdataset for the netcdf file: Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute Driver: netCDF/Network Common Data Format Size is 148, 112 Coordinate System is `' ... ad then coordinates, cdate, ctime, xcent, ycent, etc. etc. I was wondering if NC_Global or the coordinate system being `' might cause a problem. and then, running the command (going to mercator just to get a successful reprojection, I'll deal with lat/lon later): gdalwarp -s_srs +proj=lcc -t_srs +proj=merc NETCDF:test_0910.nc:PM25 NETCDF:test_out.nc:PM25 gives me: Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for NETCDF:test_0910.nc:PM25. There is no affine transformation and no GCPs. I'm fairly stuck. If anyone has any ideas at all, I'd really appreciate it. Thanks! -Ed -- View this message in context: http://www.nabble.com/problems-warping-a-netcdf-file-tp20504569p20504569.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
Re: [Gdal-dev] problems warping a netcdf file
On Fri, Nov 14, 2008 at 6:06 PM, edfialk [EMAIL PROTECTED] wrote: Hello, I'm fairly new to reprojection and my experience with gdal is limited, so I'll do my best to keep up. I have tried searching through a number of messages without finding anything quite like my problem. I've been completely unsuccessful trying to reproject a netcdf file for some time now and I'm becoming fairly desperate for some help. I'm going for changing Lambert Conformal with a perfect sphere geoid with earth radius=6370km centered at 40N, 97W with standard latitudes at 33N, 45N to geographic lat, long (flat) projection. First, a little gdal info on one particular subdataset for the netcdf file: Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute Driver: netCDF/Network Common Data Format Size is 148, 112 Coordinate System is `' ... ad then coordinates, cdate, ctime, xcent, ycent, etc. etc. I was wondering if NC_Global or the coordinate system being `' might cause a problem. This has been recently fixed in SVN-trunk, but... and then, running the command (going to mercator just to get a successful reprojection, I'll deal with lat/lon later): ... gdalwarp still fails. See http://trac.osgeo.org/gdal/ticket/2584 Somewhere the coordinates get lost, see last two entries in the trac report. best, Markus ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Gdal Bug? was: Re: [gdal-dev] JP2MRSID Issues
Frank Warmerdam wrote: Stephen Woodbridge wrote: Frank, If someone can generate a patch the prints this stuff out, I'll have our guys build a version with the patch and I'll run it against one of the cases that fails. There wouldn't happen to be a hidden debug option that might already print this out? Thank you Michael for any assistance from your end also. Steve, Skimming through mrsiddataset.cpp, it appears there are already quite extensive debug statements. Try enabling debug output when running the failed operation. For GDAL commandline apps adding --debug on to the commandline (without the quotes) should do the trick. The debug output all goes to stderr. Best regards, Frank, Here is what I get from the debug output. I'm a little surprised it is trying to extract from zoom 1 instead of zoom 0. I didn't think I was scaling this but maybe some rounding is causing that. Thanks, -Steve [EMAIL PROTECTED] ~]$ cd tif-test/ [EMAIL PROTECTED] tif-test]$ GDAL_SKIP=JPEG2000 gdal_translate -of VRT /var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.jp2 -b 1 -b 2 -b 3 tmp.vrt Input file size is 36010, 49447 [EMAIL PROTECTED] tif-test]$ GDAL_SKIP=JPEG2000 gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:26915 -t_srs EPSG:4326 -te -93.5 43.8125 -93.4375 43.875 -rb -wm 250 --config GDAL_ONE_BIG_READ ON -co TILED=YES tmp.vrt out.tif Creating output file that is 6029P x 6029L. Processing input file tmp.vrt. gdalwarp: ../compressed/compressed.cpp:1724: bool kd_tile::read_tile_part_header(): Assertion `tpart_body_length = 0' failed. Aborted [EMAIL PROTECTED] tif-test]$ GDAL_SKIP=JPEG2000 gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:26915 -t_srs EPSG:4326 -te -93.5 43.8125 -93.4375 43.875 -rb -wm 250 --config GDAL_ONE_BIG_READ ON -co TILED=YES --debug on tmp.vrt out.tif MrSID: Opened zoom level 1 with size 18005x24724. MrSID: Opened zoom level 2 with size 9003x12362. MrSID: Opened zoom level 3 with size 4502x6181. MrSID: Opened zoom level 4 with size 2251x3091. MrSID: Opened zoom level 5 with size 1126x1546. MrSID: Opened zoom level 6 with size 563x773. MrSID: Opened zoom level 7 with size 282x387. MrSID: Opened zoom level 8 with size 141x194. MrSID: Opened zoom level 9 with size 71x97. MrSID: Opened zoom level 10 with size 36x49. MrSID: Opened zoom level 0 with size 36010x49447. MrSID: Opened image: width 36010, height 49447, bands 4 GDAL: GDALOpen(/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.aux) succeeds as HFA. GDAL: GDALClose(/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.aux) GDAL: GDALOpen(/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.jp2) succeeds as JP2MrSID. GDAL: GDALOpen(tmp.vrt) succeeds as VRT. OGRCT: Source: +proj=utm +zone=15 +ellps=GRS80 +datum=NAD83 +units=m +no_defs OGRCT: Target: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs OGRCT: Source: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs OGRCT: Target: +proj=utm +zone=15 +ellps=GRS80 +datum=NAD83 +units=m +no_defs GDAL: GDALClose(tmp.vrt) GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose() GDAL: GDALClose(/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.jp2) GDAL: QuietDelete(out.tif) invoking Delete() ERROR 4: `out.tif' not recognised as a supported file format. GDAL: GDALDriver::Create(GTiff,out.tif,6029,6029,3,Byte,0x86d1bc0) MrSID: Opened zoom level 1 with size 18005x24724. MrSID: Opened zoom level 2 with size 9003x12362. MrSID: Opened zoom level 3 with size 4502x6181. MrSID: Opened zoom level 4 with size 2251x3091. MrSID: Opened zoom level 5 with size 1126x1546. MrSID: Opened zoom level 6 with size 563x773. MrSID: Opened zoom level 7 with size 282x387. MrSID: Opened zoom level 8 with size 141x194. MrSID: Opened zoom level 9 with size 71x97. MrSID: Opened zoom level 10 with size 36x49. MrSID: Opened zoom level 0 with size 36010x49447. MrSID: Opened image: width 36010, height 49447, bands 4 GDAL: GDALOpen(/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.aux) succeeds as HFA. GDAL: GDALClose(/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.aux) GDAL: GDALOpen(/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.jp2) succeeds as JP2MrSID. GDAL: GDALOpen(tmp.vrt) succeeds as VRT. OGRCT: Source: +proj=utm +zone=15 +ellps=GRS80 +datum=NAD83 +units=m +no_defs OGRCT: Target: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs OGRCT: Source: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs OGRCT: Target: +proj=utm +zone=15 +ellps=GRS80 +datum=NAD83 +units=m +no_defs MrSID: RasterIO() - using optimized dataset level IO. MrSID: Dataset:IRasterIO(25432,42149 5066x6973 - 5066x6973 - 5066x6973, zoom=1) gdalwarp: ../compressed/compressed.cpp:1724: bool kd_tile::read_tile_part_header(): Assertion `tpart_body_length = 0' failed. Creating output file that is 6029P x
Re: [gdal-dev] OBus error when writing GeoTiffs
Even, I compiled the beta and now it works. Thanks! For the record, I'm using the GNU tools. Chris On Fri, Nov 14, 2008 at 1:25 PM, Even Rouault [EMAIL PROTECTED]wrote: Chris, I'd bet too that you are hitting a problem with unaligned access on Sparc architecture when dereferencing some pointers that is present in the TIFFWriteDirectorySec function of the internal libtiff in GDAL 1.5.X (I don't think that the compiler used would make any difference.) This problem was reported and fixed as http://bugzilla.maptools.org/show_bug.cgi?id=1892 Current internal libtiff in GDAL 1.6.0beta has the above fix and should hopefully work. Le Friday 14 November 2008 20:26:24 Frank Warmerdam, vous avez écrit : Chris Garrard wrote: Hi, I've compiled GDAL 1.5.3 on Solaris 10, using internal support for tiff and gtiff. When I try to create a new GTiff using gdal_translate, it fails with OBus Error. That's all the information I get. The problem is only with writing GTiffs, not reading them. I can convert a tiff to another format, get information about them with gdalinfo, and am using them with MapServer built with GDAL support. I can write to other formats without a problem. Chris, Any chance of running things in gdb or dbx and getting a traceback? I assume this is Solaris on Sparc? Often problems on this architecture are byte order or double alignment issues. Is this a 32bit or 64 bit build? Are you using the GNU or Sun tool chains? Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] WMS-C ?
What possibilities exist for WMS-C support in GDAL? Specifically, we're looking for a mechanism to consume WMS-C via MapServer using PHP/MapScript. Any ideas at all? -- Gregor Mosheh / Greg AllensworthBS, A+, Network+, Security+, Server+ System Administrator, Lead Programmer HostGIS development hosting services, http://www.HostGIS.com/ Remember that no one cares if you can back up, only if you can restore. - AMANDA ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
