[gdal-dev] issue with gdal.Open() on new USGS GeoPDF

[Even Rouault]

Le jeudi 15 août 2013 16:30:48, Reaves, Timothy a écrit :
> I'm playing with USGS GeoPDF's.  It seems the newer ones - for some reason
> - have 'unknown' for their GEOGCS value.
> 
> This is from a file a little over three years old, as output from gdalinfo:
> Driver: PDF/Geospatial PDF
> Files: OH_Lodi_20100809_TM_geo.pdf
> Size is 13869, 17680
> Coordinate System is:
> PROJCS["UTM Zone 17, Northern Hemisphere",
>     GEOGCS["NAD83",
>         DATUM["North_American_Datum_1983",
> ...
> 
> This is from a file just a little over a month old, as output from
> gdalinfo: Driver: PDF/Geospatial PDF
> Files: PA_Tionesta_20130621_TM_geo.pdf
> Size is 13652, 17403
> Coordinate System is:
> PROJCS["UTM Zone 17, Northern Hemisphere",
>     GEOGCS["unknown",
>         DATUM["North_American_Datum_1983",
> ...
> 
> When I do most anything with the later PDF, I receive an error:
> ERROR 1: Couldn't find group for reference to set OFF
> 
> For most things, the operation continues successfully.  However, I have a
> Python script I am using that will pull out the NEATLINE for cropping
> purposes.  It does exist in the metadata, but, the call to gdal.Open()
> returns None, so my program fails on these newer PDF's.
> 
> 
> I'm sure there is an issue on the USGS side, but, I wouldn't know where to
> report it.  However, I think there is an issue here with gdal as well; gdal
> correctly converts these files from the command line, so gdal is in fact
> pulling out the correct information.  This would seem to me then that the
> call to gdal.Open() should not fail.  It may have 'unknown' as the value
> for the metadata key GEOGCS, but, the rest of the metadata should be
> available.

Could you point me to a URL of such a file so I can inspect ?

> 
> Thanks.

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html