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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev