<div dir="ltr"><div><div><div><div><div><div><br></div>I'm playing with USGS GeoPDF's.  It seems the newer ones - for some reason - have 'unknown' for their GEOGCS value.  <br></div><br></div><div>This is from a file a little over three years old, as output from gdalinfo:<br>
Driver: PDF/Geospatial PDF<br>Files: OH_Lodi_20100809_TM_geo.pdf<br>Size is 13869, 17680<br>Coordinate System is:<br>PROJCS["UTM Zone 17, Northern Hemisphere",<br>    GEOGCS["NAD83",<br>        DATUM["North_American_Datum_1983",<br>
...<br><br></div>This is from a file just a little over a month old, as output from gdalinfo:<br>Driver: PDF/Geospatial PDF<br>Files: PA_Tionesta_20130621_TM_geo.pdf<br>Size is 13652, 17403<br>Coordinate System is:<br>PROJCS["UTM Zone 17, Northern Hemisphere",<br>
    GEOGCS["unknown",<br>        DATUM["North_American_Datum_1983",<br>...<br><br></div>When I do most anything with the later PDF, I receive an error:<br>ERROR 1: Couldn't find group for reference to set OFF<br>
<br></div>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.<br>
<br><br></div>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.<br>
<br>Thanks.<br></div>