[gdal-dev] Neatline for USGS PDF maps

Eli Adam eadam at co.lincoln.or.us
Fri Jan 18 18:38:16 PST 2013

Checking over some USGS topo PDFs, the neatline reported appears too
large.  Has anyone else check this or noticed anything similar?
Specific details below.

> I did the same thing and got the same result.  If you make a shapefile
> out of the neatline and view it, you will see that it matches to the
> black.  So it is a correct result but not intended.  So we need
> different values for the neatline.  Here are values that I just
> estimated off of QGIS:
> "Record_Id","wkb_Polygon"
> "1","POLYGON ((420793 4955647,420689 4941858,410784 4942004,410971 4955792))"
> Using this gives expected results.
> Does this pdf file have incorrect neatline information?  I'll look at
> some others to see if they work better.

It looks to me that the USGS topo pdf from
http://ims.er.usgs.gov/gda_services/download?item_id=5365522 reports a
neatline that covers most of the pdf, NEATLINE=POLYGON
4956417.675689895637333)) but should cover much less area as estimated
out of QGIS above.

Is this an error within the file or an error in what gdalinfo reports
or something else?  If it is an error in the file, I can contact the
USGS liaison for the Pacific Northwest to see if it can be fixed (at
least for Oregon).

I checked other USGS Topos in OR, CO, MI and found the same problem.
I tried some in ND and IA and the neatline seemed correct.
Specifically, http://ims.er.usgs.gov/gda_services/download?item_id=5154397&quad=Granger&state=IA&grid=7.5X7.5&series=TNM%20GeoPDF
and http://ims.er.usgs.gov/gda_services/download?item_id=5251428&quad=Nelson%20Lake&state=ND&grid=7.5X7.5&series=TNM%20GeoPDF

It is great to have the pdf driver to make more data accessible.
GDAL/OGR always makes me smile when I encounter data in some new to me
format and it is already supported (in the last few months, SEG-Y).

Best Regards, Eli

More information about the gdal-dev mailing list