Hi Ken,
I wasn't aware that there were extensionless file that were required
to be supported. The method that is catching and rejecting these
files exists to help VPB better handle source directories that contain
more than just source data, such as text files etc. We could add an
option to disable this, but my preference would be to better detect
this problem files as being supported.
The code that manages the filtering of source files can be found in
the vpb::System class, with the methods of interest being:
inline bool isFileTypeSupported(const std::string& filename,
int acceptedTypeMask) const
{
return
isExtensionSupported(osgDB::getFileExtension(filename),
acceptedTypeMask);
}
inline bool isExtensionSupported(const std::string& ext, int
acceptedTypeMask) const
{
SupportedExtensions::const_iterator itr =
_supportedExtensions.find(ext);
if (itr != _supportedExtensions.end()) return
(itr->second.acceptedTypeMask & acceptedTypeMask)!=0;
else return false;
}
The _supportedExtensions data structure is populated by
System::System() constructor that queries GDAL for what extension are
supported. Reviewing the code now there is check again an empty
extension string, so perhaps this could be relaxed to all empty
extension strings. The relevant code in System::System is:
GDALDriverManager* driverManager = GetGDALDriverManager();
if (driverManager)
{
for(unsigned int i=0; i<driverManager->GetDriverCount(); ++i)
{
GDALDriver* driver = driverManager->GetDriver(i);
if (driver)
{
const char* ext = driver->GetMetadataItem("DMD_EXTENSION");
if (ext && strlen(ext)!=0)
{
addSupportedExtension(ext,
Source::IMAGE | Source::HEIGHT_FIELD,
driver->GetMetadataItem( GDAL_DMD_LONGNAME ));
}
}
}
}
The other possibility would be to manually do an
addSupportedExtension("",SOURCE::IMAGE | SOURCE::HEIGHTFIELD,"") entry
to hack support in for extensionless files. This would mean that the
filtering wouldn't be so effective though.
The other route would be to add a fallback in the
System::isFileTypeSupported() that calls GDAL to see if it can handle
the file format. This is relatively expensive to do though, as VPB
can process ten or even hundreds of thousands of source files.
Robert.
On Mon, Feb 23, 2009 at 9:36 PM, Sewell, Kenneth R Civ USAF AFMC
AFRL/RYZW <[email protected]> wrote:
> A lot of the imagery data we use is in ENVI's native format. GDAL does
> support it and it has worked in previous versions of Virtual Planet
> Builder. It now fails with the current SVN head (953) because the data
> doesn't use a filename extension. Typically the ENVI format is composed
> of two files (sample.hdr and sample, for example). One file has the
> projection and image info, the other is just the raw data. All the gdal
> commands want the file without the extension as the argument.
> Previously, this was not an issue with VPB, but the new method of
> checking filename extensions on input files is causing problems. Since
> there is no extension to add to VPB's list, may I suggest a flag for VPB
> to tell it not to do the filename extensions checking?
>
> Ken.
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
