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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to