[gdal-dev] Selecting OGR Driver Based on File Name

Joel Odom joelodom at gmail.com
Wed Oct 6 09:15:33 EDT 2010


Thanks, Frank.

I understand the purist argument against this, though I think that 90% of
the time you can look at a connection string for a data source and determine
what the output driver should be.  I'd like to see this feature in the
future, but I understand that it would need a caveat that it may not always
work or return the expected result.  Maybe a "GuessOutputDriver(...)"
function would be the appropriate way to name it.




On Wed, Oct 6, 2010 at 8:47 AM, Frank Warmerdam <warmerdam at pobox.com> wrote:

> Joel Odom wrote:
>
>> Is there a canonical way to pick an OGR driver based on a file name or on
>> a generalized connect string?  (For example, if the file name ends in
>> ".shp", it would select the Shapefile driver.)  Thanks.
>>
>
> Joel,
>
> No.
>
> I really wanted to send this out with just that one word answer, but I
> can't help myself but elaborate.
>
> First, I think file format identification based on filename extension is
> a terrible idea, and I curse those operating systems that try to build it
> into the graphical shell.   Likewise a pox on applications that carry on
> this tradition.
>
> Second, there are a number of OGR file formats that have no dependency on
> extension.  For example GML, DGN, DXF, PCIDSK.  For these formats any
> extension is fine and only letting people pick a file if it has some
> particular is offensive to me.
>
> Third, there are lots of database connection formats that aren't extension
> based.  Typically these can be identified based on a prefix string like
> MYSQL: though not always.
>
> Despite my feelings on this matter, on the GDAL side of the house we
> actually
> provide a metadata item on drivers allowing specification of a preferred
> extension which applications can use.  We also have an "identify" mechanism
> that will try to efficiently identify what format a file or dataset name
> string is without necessarily actually opening it.
>
> Unfortunately, the OGR world is less sophisticated in this regard and lacks
> these two mechanisms.  This is one reason I'd like to have a "grand
> unification" of GDAL and OGR one day.
>
> Best regards,
> --
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>


-- 
http://www.operationliberate.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20101006/e20b076c/attachment.html


More information about the gdal-dev mailing list