[gdal-dev] gdaltranslate and gdalwarp rotating and resizing image without being asked to, why?

[Jesse McGraw]

Even,
  Thank you for the response!

I'm actually rasterizing the PDF to PNG via pdftoppm before doing anything
with gdal*, that's why the rotating and resizing surprises me.

When do the pixelSkew parameters get used vs. swapping the axes?  The
swapping works in this case is because the rotation is 90 degrees but what
would happen with an arbitrary rotation (eg 37 degrees).

The reason I'm curious about all this is that I'm wanting to use only the
initially generated PNG for my final georeferenced image and not have to
generate an additional one that is rotated by gdal with the skew parameters
set to 0 and also resized.

If I can provide any more detail on my process or what I'm trying to
accomplish please let me know.

Here's the general flow for Airport Diagrams:

Source PDF -> create PNG, create list of GCPs from the PDF mapped to that
PNG -> gdal_translate PNG to intermediate VRT -> gdal_warp intermediate VRT
to final VRT

The final VRT displays properly in QGIS so the process is working correctly
but I was hoping to be able to extract from it all of the parameters of the
affine transformation necessary to properly display the PNG as a
geoferenced image (origin, extents, pixel sizes and pixel skew) in a
separate Android application.  (This bitmap is to be used in a separate
moving map application to display an airplane's real world position on the
image)

-Jesse


On Sat, Jun 28, 2014 at 12:01 PM, Even Rouault <even.rouault at mines-paris.org
> wrote:

> Jesse,
>
> I'm not completely sure to really understand the axis swapping issue
> without
> reproducing what you do.
> The PDF driver should take into account the PDF rotation parameter when
> rasterizing it (so that it outputs something that is visually identical
> with
> what other PDF viewers do).
>
> To answer your questions:
>
> 1) When not providing an existing target image, gdalwarp will indeed
> rectify
> images that have an arbitrary transform with skew/rotation terms, or GCPs,
> to
> an affine transform with squared pixels, which is generally the desired
> behaviour. If you prepare yourself the target dataset with the geotransform
> you whish, you should be able run gdalwarp on it. You can alternatively try
> the -ts option of gdalwarp to force the target dimensions.
>
> 2) The resizing is a consequence of the output geotransform being different
> that the source geotransform.
>
> 3) You could likely merge your step 1 and 2, i.e. directly generate a .png
> with the SRS and GCP set. However I'd recommand generating a tiled TIFF
> instead to make gdalwarp faster.
>
> Best regards,
>
> Even
>
> Le vendredi 27 juin 2014 19:49:35, Jesse McGraw a écrit :
> > Gdal gurus,
> >
> > I'm writing a utility to automatically georeference Instrument Approach
> > Procedures and Airport Diagrams from the FAA (github.com/jlmcgraw, if
> > you're curious) and I'm hoping for some insight from the experts here as
> to
> > why I'm seeing the following behavior with Airport Diagrams
> >
> > Most of the Airport Diagrams diagrams are portrait orientation (True
> North
> > up), however some of them are actually laid out in landscape orientation
> > (True North to the left or right) though the source PDF is still in
> > portrait
> >
> > If I georeference these landscape oriented using GCPs then gdalwarp will
> > swap X and Y axes and also resize the resulting bitmap (it also resizes
> > portrait oriented ones too, though without swapping axes)
> >
> > My questions:
> > 1) Why is gdalwarp swapping the axes rather than using the X and Y
> > pixel-skew parameters of the affine transformation (seems to be always
> 0)?
> > 2) Why is it re-sizing the bitmap?
> > 3) Do I have to do both of these steps separately (translate and then
> warp)
> > or can I simplify somehow?
> >
> > Steps in the process:
> >
> > 1) Generate a list of Ground Control Points from the PDF, rasterize the
> PDF
> > to a 300dpi PNG
> >
> > 2) gdal_translate .PNG to an intermediate .VRT
> > ("gdal_translate -q -of VRT -strict -a_srs EPSG:4326 $gcpstring
> > '$targetpng'  '$targetvrt'")
> >
> > 3) gdalwarp intermediate .VRT to get the final georeferenced output .VRT
> >  ("gdalwarp -q -of VRT -t_srs EPSG:4326 -order 1 -overwrite
> ''$targetvrt''
> > '$targetvrt2'")
> >
> >
> >
> >
> > *example from a landscape diagram*
> >
> > (snippet of step 2 output from gdal_translate'd .vrt)
> > CA-SFO-00375AD-PDF-AIRPORT-DIAGRAM.vrt:
> > *<VRTDataset rasterXSize="1613" rasterYSize="2475">*
> >
> > (snippet of step 3 output from gdalwarp'd .vrt)
> > warpedCA-SFO-00375AD.PDF-AIRPORT\ DIAGRAM.vrt:
> > *<VRTDataset rasterXSize="2623" rasterYSize="1359"
> > subClass="VRTWarpedDataset">*
> > *<GeoTransform> -1.2242081739746585e+02,  2.9114844968978991e-05,
> > 0.0000000000000000e+00,  3.7641622693302779e+01,  0.0000000000000000e+00,
> > -2.9114844968978991e-05</GeoTransform>*
> >
> >
> > *example from a portrait diagram*
> >           (snippet of step 2 output from gdal_translate'd .vrt)
> > *VA-RIC-00347AD-PDF-AIRPORT-*
> > *DIAGRAM.vrt*
> > *<VRTDataset rasterXSize="1613" rasterYSize="2475">*
> >
> > (snippet of step 3 output from gdalwarp'd .vrt)
> > *warpedVA-RIC-00347AD.PDF-*
> > *AIRPORT\ DIAGRAM.vrt*
> >
> >
> >
> > *<VRTDataset rasterXSize="1870" rasterYSize="2287"
> > subClass="VRTWarpedDataset"><GeoTransform> -7.7341103107298423e+01,
> > 2.1580033523515700e-05,  0.0000000000000000e+00,  3.7529840835409082e+01,
> > 0.0000000000000000e+00, -2.1580033523515700e-05</GeoTransform>*
> > Thanks!
> > -Jesse McGraw
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140630/46a10970/attachment.html>