[gdal-dev] Is it possible to hide some ERROR messages?
Hi list, Is it somehow possible to customize/hide some GDAL error messages? I know error messages are really useful to fix/understand problems. Anyway, let me expose my use case: I simply need to check if I can obtain a Dataset for a file and return a boolean. If I get a Dataset, great! Otherwise... no problem. :) The user won't see messages like this ERROR 4: `c:\mydataformat.frmt' not recognised as a supported file format (although by this way he will never know why no Dataset has ben acquired). Is there some setConfigOption(xxx,) to hide (some) error messages? Thank you. Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Is it possible to hide some ERROR messages?
Hi Daniele, were to you get those error message? Since GDAL is a library it shouldn't come up with thing like this - at least not errors which are shown to the user automatically (like message boxes or std::out prints (I guess). So if your application gets no dataset for a file it will get NULL returned, you can then do with this information what you want - either inform the user about it or not. Bye, Tom Daniele Romagnoli schrieb: Hi list, Is it somehow possible to customize/hide some GDAL error messages? I know error messages are really useful to fix/understand problems. Anyway, let me expose my use case: I simply need to check if I can obtain a Dataset for a file and return a boolean. If I get a Dataset, great! Otherwise... no problem. :) The user won't see messages like this ERROR 4: `c:\mydataformat.frmt' not recognised as a supported file format (although by this way he will never know why no Dataset has ben acquired). Is there some setConfigOption(xxx,) to hide (some) error messages? Thank you. Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ 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] Is it possible to hide some ERROR messages?
Daniele, this thread should give you some hints: http://lists.osgeo.org/pipermail/gdal-dev/2003-March/000323.html Regards, Vincent. Tom Kazimiers wrote: Hi Daniele, were to you get those error message? Since GDAL is a library it shouldn't come up with thing like this - at least not errors which are shown to the user automatically (like message boxes or std::out prints (I guess). So if your application gets no dataset for a file it will get NULL returned, you can then do with this information what you want - either inform the user about it or not. Bye, Tom Daniele Romagnoli schrieb: Hi list, Is it somehow possible to customize/hide some GDAL error messages? I know error messages are really useful to fix/understand problems. Anyway, let me expose my use case: I simply need to check if I can obtain a Dataset for a file and return a boolean. If I get a Dataset, great! Otherwise... no problem. :) The user won't see messages like this ERROR 4: `c:\mydataformat.frmt' not recognised as a supported file format (although by this way he will never know why no Dataset has ben acquired). Is there some setConfigOption(xxx,) to hide (some) error messages? Thank you. Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Is it possible to hide some ERROR messages?
Hi Tom, Vincent, I'm using GDAL via Java by means of the SWIG bindings. The error message automatically appears on the console when I call the gdal.Open(name, accessType) method and GDAL is unable to open the dataset. Anyway, I have just taken a look on the thread suggested by Vincent and now I can quiet the errors. Thank you. Regards, Daniele On Fri, Oct 24, 2008 at 1:44 PM, Vincent Schut [EMAIL PROTECTED] wrote: Daniele, this thread should give you some hints: http://lists.osgeo.org/pipermail/gdal-dev/2003-March/000323.html Regards, Vincent. Tom Kazimiers wrote: Hi Daniele, were to you get those error message? Since GDAL is a library it shouldn't come up with thing like this - at least not errors which are shown to the user automatically (like message boxes or std::out prints (I guess). So if your application gets no dataset for a file it will get NULL returned, you can then do with this information what you want - either inform the user about it or not. Bye, Tom Daniele Romagnoli schrieb: Hi list, Is it somehow possible to customize/hide some GDAL error messages? I know error messages are really useful to fix/understand problems. Anyway, let me expose my use case: I simply need to check if I can obtain a Dataset for a file and return a boolean. If I get a Dataset, great! Otherwise... no problem. :) The user won't see messages like this ERROR 4: `c:\mydataformat.frmt' not recognised as a supported file format (although by this way he will never know why no Dataset has ben acquired). Is there some setConfigOption(xxx,) to hide (some) error messages? Thank you. Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_merge.py outputs bad geotiff?
Hello When I use gdal_merge.py to merge two files and write a geotiff it creates a file which PhotoshopCS3 cannot read. Yet the result of passing that tiff through gdal_translate produces a different tiff (of a completely different size) which *is* readable. % gdal_merge.py -v -o merged1.tif -of gtiff tl10dtm/w001001.adf tl67dtm/w001001.adf The Photoshop error is Could not complete your request because of a problem parsing the TIFF file % gdal_translate -of gtiff merged1.tif merged2.tif Input file size is 1200, 1600 0...10...20...30...40...50...60...70...80...90...100 - done. I don't understand the size of the first one given that there's no compression: % ls -l merged1.tif merged2.tif 981186 merged1.tif 3854344 merged2.tif However the tiffinfo output and the gdalinfo output are identical for both files (except for the TIFF directory offsets, see below. Andrew tiffinfo TIFF Directory at offset 0xee622 (976418) Image Width: 1200 Image Length: 1600 Bits/Sample: 16 Sample Format: unsigned integer Compression Scheme: None Photometric Interpretation: min-is-black Samples/Pixel: 1 Rows/Strip: 3 Planar Configuration: single image plane Tag 33550: 50.00,50.00,0.00 Tag 33922: 0.00,0.00,0.00,51.00,28.00,0.00 Tag 34735: 1,1,0,15,1024,0,1,1,1025,0,1,1,1026,34737,8,0,2048,0,1,4001,2049,34 737,49,8,2054,0,1,9102,3072,0,1,32767,3074,0,1,32767,3075,0,1,1,3076,0,1,9001,30 80,34736,1,1,3081,34736,1,0,3082,34736,1,3,3083,34736,1,4,3092,34736,1,2 Tag 34736: 49.00,-2.00,0.999601,40.00,-10.00 Tag 34737: unnamed|Unknown datum based upon the Airy 1830 ellipsoid| gdalinfo Driver: GTiff/GeoTIFF Size is 1200, 1600 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the Airy 1830 ellipsoid, DATUM[Not_specified_based_on_Airy_1830_ellipsoid, SPHEROID[Airy 1830,6377563.396,299.324964643, AUTHORITY[EPSG,7001]], AUTHORITY[EPSG,6001]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4001]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,49], PARAMETER[central_meridian,-2], PARAMETER[scale_factor,0.999601272], PARAMETER[false_easting,40], PARAMETER[false_northing,-10], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (51.000,28.000) Pixel Size = (50.000,-50.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 51.000, 28.000) ( 0d22'58.02W, 52d24'23.61N) Lower Left ( 51.000, 20.000) ( 0d24'30.74W, 51d41'15.02N) Upper Right ( 57.000, 28.000) ( 0d29'54.91E, 52d23'28.35N) Lower Right ( 57.000, 20.000) ( 0d27'31.76E, 51d40'21.17N) Center ( 54.000, 24.000) ( 0d 2'29.21E, 52d 2'25.00N) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_merge.py outputs bad geotiff?
Andrew, my guess is that your merged1.tif TIFF has areas which are not initialized (black/transparent areas). gdal_merge.py probably doesn't write any data in them, thus leading to missing blocks in the file. GDAL support them in reading, but those kind of tiff files are maybe not supported by PhotoshopCS3 (they are known not to be widely supported by some readers) But when you gdal_translate it, those missing blocks will be finally written as empty blocks (filled with zero). That accounts for the difference in size. Le Friday 24 October 2008 18:46:26 Andrew Brooks, vous avez écrit : Hello When I use gdal_merge.py to merge two files and write a geotiff it creates a file which PhotoshopCS3 cannot read. Yet the result of passing that tiff through gdal_translate produces a different tiff (of a completely different size) which *is* readable. % gdal_merge.py -v -o merged1.tif -of gtiff tl10dtm/w001001.adf tl67dtm/w001001.adf The Photoshop error is Could not complete your request because of a problem parsing the TIFF file % gdal_translate -of gtiff merged1.tif merged2.tif Input file size is 1200, 1600 0...10...20...30...40...50...60...70...80...90...100 - done. I don't understand the size of the first one given that there's no compression: % ls -l merged1.tif merged2.tif 981186 merged1.tif 3854344 merged2.tif However the tiffinfo output and the gdalinfo output are identical for both files (except for the TIFF directory offsets, see below. Andrew tiffinfo TIFF Directory at offset 0xee622 (976418) Image Width: 1200 Image Length: 1600 Bits/Sample: 16 Sample Format: unsigned integer Compression Scheme: None Photometric Interpretation: min-is-black Samples/Pixel: 1 Rows/Strip: 3 Planar Configuration: single image plane Tag 33550: 50.00,50.00,0.00 Tag 33922: 0.00,0.00,0.00,51.00,28.00,0.00 Tag 34735: 1,1,0,15,1024,0,1,1,1025,0,1,1,1026,34737,8,0,2048,0,1,4001,2049,34 737,49,8,2054,0,1,9102,3072,0,1,32767,3074,0,1,32767,3075,0,1,1,3076,0,1,90 01,30 80,34736,1,1,3081,34736,1,0,3082,34736,1,3,3083,34736,1,4,3092,34736,1,2 Tag 34736: 49.00,-2.00,0.999601,40.00,-10.00 Tag 34737: unnamed|Unknown datum based upon the Airy 1830 ellipsoid| gdalinfo Driver: GTiff/GeoTIFF Size is 1200, 1600 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the Airy 1830 ellipsoid, DATUM[Not_specified_based_on_Airy_1830_ellipsoid, SPHEROID[Airy 1830,6377563.396,299.324964643, AUTHORITY[EPSG,7001]], AUTHORITY[EPSG,6001]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4001]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,49], PARAMETER[central_meridian,-2], PARAMETER[scale_factor,0.999601272], PARAMETER[false_easting,40], PARAMETER[false_northing,-10], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (51.000,28.000) Pixel Size = (50.000,-50.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 51.000, 28.000) ( 0d22'58.02W, 52d24'23.61N) Lower Left ( 51.000, 20.000) ( 0d24'30.74W, 51d41'15.02N) Upper Right ( 57.000, 28.000) ( 0d29'54.91E, 52d23'28.35N) Lower Right ( 57.000, 20.000) ( 0d27'31.76E, 51d40'21.17N) Center ( 54.000, 24.000) ( 0d 2'29.21E, 52d 2'25.00N) ___ 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] Re: Going between gdal nodata and GMT NaN
Hmm, let me ask this a different way. Does the GMT driver implemented in gmtdataset.cpp support the creation of Nan values when writing to an output dataset? Thanks, Roger -- On Wed, Oct 22, 2008 at 4:38 PM, Roger André [EMAIL PROTECTED] wrote: Sooo... apparently nodata values are not converted to NaN when doing something like a gdal_translate from GeoTiff to GMT format. Is there a way that anyone knows to do this? Thanks, Roger -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Desktop App Map Server?
Hi Folks, Sorry if this is a newbie question, but I've looked all over and can't find any good information. I have a desktop app (wxGTK / C++ / OpenGL) on which I want to display all manner of geo-images, in all manner of projections, etc. I have coded the ability to display simple NITF, etc. using GDAL, but I am constantly finding image formats or projection systems which I haven't supported. I really want to have a data store with an API which looks something like: getMapLayers( area, layers, resolution ) o It looks like OGDI is built to solve this problem, but I can't find a 'howto'. o PostGIS + GDAL? o MapServer et al.? - look good, but are more web focused. Can anyone give me a good starting point? Thanks much for your help, Brian ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Desktop App Map Server?
Brian Hone wrote: Hi Folks, Sorry if this is a newbie question, but I've looked all over and can't find any good information. I have a desktop app (wxGTK / C++ / OpenGL) on which I want to display all manner of geo-images, in all manner of projections, etc. I have coded the ability to display simple NITF, etc. using GDAL, but I am constantly finding image formats or projection systems which I haven't supported. I really want to have a data store with an API which looks something like: getMapLayers( area, layers, resolution ) o It looks like OGDI is built to solve this problem, but I can't find a 'howto'. o PostGIS + GDAL? o MapServer et al.? - look good, but are more web focused. Can anyone give me a good starting point? Brian, I am not clear on what you are looking for that GDAL doesn't already do. In your getMapLayers() function above, are you suggesting that it is returning the area, layers and resolution? Are you wanting it to work for feature datasources as well as raster data sources? If you support NITF via GDAL - is there some reason you don't automatically support the rest of the GDAL raster formats? What are you using for projections? Normally GDAL+PROJ.4 allows you to support a wide set of coordinate systems without having to do anything special for particular projections. I guess I'm not getting the dilemma. 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: Going between gdal nodata and GMT NaN
Roger André wrote: Hmm, let me ask this a different way. Does the GMT driver implemented in gmtdataset.cpp support the creation of Nan values when writing to an output dataset? Roger, I see no support for handling NaN on read or write in gmtdataset.cpp. So, no. 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
[gdal-dev] Compiler warnings for dgnhelp.cpp ogrgeometryfactory.cpp ogrspatialreference.cpp
Gdal-dev, I just had occasion to rebuild gdal from SVN trunk on Mac OS 10.5, which worked great. I thought perhaps recording a few of the warnings might be useful. Pasted below. Dane [...snip...] libtool: compile: g++ -g -O2 -Wall -I.. -I../.. -I/Users/spring/src/ gdal/port -I/Users/spring/src/gdal/gcore -I/Users/spring/src/gdal/alg - I/Users/spring/src/gdal/ogr -I/Users/spring/src/gdal/ogr/ogrsf_frmts - DOGR_ENABLED -D_REENTRANT -I/Users/spring/src/gdal/port -c dgnhelp.cpp -fno-common -DPIC -o ../o/.libs/dgnhelp.o dgnhelp.cpp: In function 'void DGNDumpElement(void*, DGNElemCore*, FILE*)': dgnhelp.cpp:1052: warning: too many arguments for format [...snip...] libtool: compile: g++ -DHAVE_MITAB -g -O2 -Wall -Iogrsf_frmts -I. -I/ Users/spring/src/gdal/port -I/Users/spring/src/gdal/gcore -I/Users/ spring/src/gdal/alg -I/Users/spring/src/gdal/ogr -I/Users/spring/src/ gdal/ogr/ogrsf_frmts -DPROJ_STATIC -DHAVE_GEOS=1 -I/usr/local/include - DOGR_ENABLED -D_REENTRANT -I/Users/spring/src/gdal/port -c ogrgeometryfactory.cpp -fno-common -DPIC -o .libs/ogrgeometryfactory.o ogrgeometryfactory.cpp: In static member function 'static OGRErr OGRGeometryFactory::createFromFgf(unsigned char*, OGRSpatialReference*, OGRGeometry**, int, int*)': ogrgeometryfactory.cpp:1583: warning: 'poGC' may be used uninitialized in this function [...snip...] libtool: compile: g++ -DHAVE_MITAB -g -O2 -Wall -Iogrsf_frmts -I. -I/ Users/spring/src/gdal/port -I/Users/spring/src/gdal/gcore -I/Users/ spring/src/gdal/alg -I/Users/spring/src/gdal/ogr -I/Users/spring/src/ gdal/ogr/ogrsf_frmts -DPROJ_STATIC -DHAVE_GEOS=1 -I/usr/local/include - DOGR_ENABLED -D_REENTRANT -I/Users/spring/src/gdal/port -c ogrspatialreference.cpp -fno-common -DPIC -o .libs/ ogrspatialreference.o ogrspatialreference.cpp: In member function 'const char* OGRSpatialReference::GetAxis(const char*, int, OGRAxisOrientation*)': ogrspatialreference.cpp:5654: warning: 'poAxis' may be used uninitialized in this function ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
