[gdal-dev] Lost error messages

Even Rouault even.rouault at spatialys.com
Wed Jan 31 01:39:41 PST 2024


Ray,
>>
> Thanks. My interest was that TIGER is a supported format in Leveller, 
> so I need to ensure the user experience for error reporting is valid.
And are there really real TIGER users :-)? AFAICS this format is for an 
antiquated version of TIGER datasets that is no longer produced.

>
> Then, when one goes to import a TIGER dataset and there's a read error,
Where exactly? Perhaps something missing to add.
> the TIGER driver returns FALSE w/o calling CPLError, and Leveller 
> calls CPLGetLastError which returns the earlier TIFF warning, which is 
> of course of no help at this point. If the TIFF textures had been 
> okay, then there'd be no error text at all, which would be equally 
> unhelpful.

I don't understand the connection between the GeoTIFF driver and the 
TIGER one. They shouldn't be probed together as one is for raster, and 
the other one vector.

And each time GDALOpenEx() is called it starts with a CPLErrorReset()

>
> From what you explained, it seems like the TIGER (and NTF) dataset 
> open logic tried to solve a problem at the wrong place -- it is nice 
> to have apps that can try different drivers to figure out a dataset 
> format on their own, but the driver shouldn't hide error messages on 
> the app's behalf, and it shouldn't output error messages (to console, 
> e.g.) on its behalf either. The latter can be fixed using the existing 
> hook API, but the message hiding still needs to be addressed. Maybe 
> add a "Hide errors when opening" driver API and default it to true in 
> the TIGER and NTF drivers to preserve the existing behavior?

A new option would be odd. The best probably would be that you come with 
a reproducer, and a PR to address the missing error message

Even



-- 
http://www.spatialys.com
My software is free, but my time generally not.



More information about the gdal-dev mailing list