[Xastir] GeoPDF

[Derrick Brashear]

On Mon, Sep 5, 2011 at 6:18 PM, Derrick Brashear <shadow at gmail.com> wrote:
> On Mon, Sep 5, 2011 at 5:49 PM, Tom Russo <russo at bogodyn.org> wrote:
>> On Mon, Sep 05, 2011 at 05:43:50PM -0400, we recorded a bogon-computron collision of the <shadow at gmail.com> flavor, containing:
>>> On Mon, Sep 5, 2011 at 1:42 PM, Tom Russo <russo at bogodyn.org> wrote:
>>> > On Mon, Sep 05, 2011 at 09:08:10AM -0600, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
>>> >>
>>> >> I'm not going to hack Xastir to handle 24-bit, but I've been working on a
>>> >> script to deal with this process (and an extension of it) and hope to release
>>> >> it this afternoon.
>>> >
>>> > Or this morning. ?Please do a cvs update and look for the "geopdf2gtiff.pl"
>>> > script in the scripts directory. ?It installs to /usr/local/lib/xastir, too.
>>> >
>>> > geopdf2gtiff.pl foobar.pdf
>>> >
>>> > will collar strip, warp, format change to Geotiff and dither to 8-bit color.
>>> > The output will be foobar.tif.
>>> >
>>> > Unfortunately, I've found that some geopdfs contain INCORRECT specifications
>>> > of their own neatlines --- these GeoPDFs say that the neatline is the same
>>> > as the entire image, rather than the boundary of the map data itself. ?There's
>>> > nothing to be done about that other than to hand-craft an FGD file with the
>>> > lat/lon of the north, south, east, and west neatlines. ?But many GeoPDFs
>>> > have correct specifiers, and the output of geopdf2gtiff.pl will be precisely
>>> > a geotiff that can be used in Xastir with a minimum of fuss.
>>>
>>> there's a script which will make up an fgd for a grid-named (e.g.
>>> o40080a1) geotiff
>>> and certainly if you have any georeferencing you can guess that, so it
>>> shouldn't be that
>>> hard.
>>
>> No, it isn't difficult.  Hence my most recent script update.  It guesses the
>> boundaries as best it can if you tell it to ignore the stored neatline.  The
>> mapfgd.pl script isn't much help, because it computes the neatlines from the
>> file name directly.  But it wasn't hard to come up with a scheme that worked.
>>
>> Using "zip" to compress the geotiff file isn't what I meant --- there's image
>> compression available in the tiff library,
>
> yup. and tiff "deflate" is zip. (libzip)
>
> that's what i was describing. -c zip:1 versus -c zip:2 in gdal_translate :)

er. geotifcp, not gdal_translate.

> --
> Derrick
>



-- 
Derrick