[Xastir] GeoPDF

[Lee Bengston]

Just realized my reply didn't go to the list.

On Mon, Sep 5, 2011 at 10:05 PM, Lee Bengston <lee.bengston at gmail.com> wrote:
> On Mon, Sep 5, 2011 at 4:03 PM, Tom Russo <russo at bogodyn.org> wrote:
>> On Mon, Sep 05, 2011 at 01:53:15PM -0600, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
>>> On Mon, Sep 05, 2011 at 02:13:35PM -0400, we recorded a bogon-computron collision of the <lee.bengston at gmail.com> flavor, containing:
>>> >
>>> > Great - thanks for the new creation!  I've got to check and see if my
>>> > gdal was built with python support, and it figures the maps I
>>> > downloaded are mostly the ones that most likely don't have the correct
>>> > neatline specifiers.  I'll have to give things a try later - too tied
>>> > up in other stuff now.
>>>
>>> If you hold off a little bit longer (less than a half hour) I will have
>>> a second cut --- this version has an option that allows you to "fudge"
>>> a neatline.  It finds the nearest 7.5' quad boundaries that enclose the
>>> map and uses that as neatline instead of what is in the GeoPDF.  This definitely
>>> works on the couple I've tested so far, and should work on 15' quads (because
>>> I'm doing it by finding left, right, top and bottom boundaries just inside
>>> the full image that round off to even 7.5' numbers).
>>>
>>> That'll allow you to use the newer GeoPDFs with bad neatlines.
>>
>> Committed.  Requires not only GDAL 1.8.1 with python support, but also
>> the Perl module "Getopt::Long."  This module is installed by the "perl-base"
>> package on my Ubuntu machines, but needed to be installed separately
>> as devel/p5-Getopt-Long on my BSD machine.  You may well already have it
>> if you're using Linux (try man Getopt::Long to verify).
>>
>> To run, use:
>>
>>  geopdf2gtiff --fixneatline foo.pdf
>>
>> or
>>
>>  geopdf2gtiff -f foo.pdf
>>
>> and it'll find the closest 7.5' left, right, top and bottom boundaries that
>> lie inside your geopdf, and clip to those.  Should work for any USGS product,
>> but should not be needed unless you verify that the neatline stored in the
>> GeoPDF is unusable.
>>
>> This is better than just generating an FGD for the thing, because it'll mean
>> less work (and therefore faster map loads) for Xastir every time you display
>> it.
>
> I did make a quick attempt to use the first version of the script
> before the 'hold off" message came in - and that was enough to make me
> realize that somehow my proj.4 packages had been removed.  Then Mr.
> Mom duties kept me away for several hours.  I added back the proj
> stuff, but I actually forgot to check for the Getopt::Long module.  It
> must already be there because the new script is working.  Thanks!
>
> After seeing the news about the messed up neatline data it did cross
> my mind that cropping like this might be doable given the files are
> supposed to contain geo data, but I was thinking in terms of
> auto-creating the FGD file (or even having the script use GDAL to
> convert to PNG or JPG, crop, and create a geo file).  The current
> script works great, though, and I certainly didn't think that if this
> auto-magic was doable that it would actually be done today.  Bravo.
>
> I think these topos - especially the ones with the arial photography -
> make pretty cool offline maps.  They load pretty fast, too.  I'm sjure
> knocking them down to 8-bit helped that.  It's great that we have a
> way to make use of the GeoPDF's now.
>
> Thanks again,
> Lee - K5DAT
>