[gdal-dev] GeoPDF

[George Demmy]

On Thu, Jun 16, 2016 at 7:27 AM, Frank Broniewski
<frank.broniewski at gmail.com> wrote:
> Ok, finally l found some time to investigate into making GeoPDF files from
> QGIS map composer PDFs. I've created a small python script to aid me in the
> creation of the GeoPDF (https://github.com/frankbroniewski/GeoPDF). It
> basically takes parameters from QGIS (map position in the page, map extent)
> and writes them to the PDF. There are 2 screenshots in the git which show
> the current data values for my test.pdf test subject. The map-composer.png
> shows the map in the QGIS map composer with the important values for
> georeferencing at the right side. layer-in-qgis.png shows the (unfortunately
> misaligned) GeoPDF in the QGIS main window.
> My gdal_edit call is as follows:
>
> gdal_edit.bat -mo "NEATLINE=POLYGON((30 30, 30 170, 220 170, 220 30, 30
> 30))" -a_srs "EPSG:31466" -a_ullr 2549800.000 5491000.000 2555800.000
> 5486600.000 test.pdf
>
> From reading the docs (the OGC ones) I thought creating a neatline and
> adding coordinates to it would be more or less sufficient. Looking at
> layer-in-qgis.png shows that gdal_edit did not (as what I expected at first)
> write the coordinates to the neatline but to the whole page area.
>
> Is there a way to add the coordinates to the neatline instead of the whole
> PDF page? I could calculate the page's extent and use these values, but
> maybe there's a more clever approach?
>
> I've also noticed that Adobe Acrobat Reader does not display any coordinates
> when using the measurement tool. Any ideas why this is not working?
>
> The python script (polygon.py - the name's somewhat stupid) is atm only used
> to assemble the gdal_edit call while taking the map extent and map frame aka
> neatline position along with an epsg code. I'm on windows (osgeo4w64) and
> using subprocess.call on gdal_edit causes an error with the -a_ullr switch.
> Probably some parsing errors or whatnot. Anyway, copy&paste is as good for
> the moment.
>
> So, any comments on how to proceed with the neatline are greatly
> appreciated.  I will continue to do my own research and report back on any
> successful steps achieved.
>
> Frank

Hi Frank

Forgive me if I don't have any answers for you, but perhaps I've got
some clues. The reason your PDF won't display coordinates in Reader is
because the georegistration metadata has some nonsensical values. The
utility is writing the georegistration metadata in using the ISO-style
encoding, which is fine, but the OGC docs won't help much there. ISO
georegistration is documented here:

http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/adobe_supplement_iso32000.pdf

One of the pieces of metadata in the ISO specification is the BBOX,
which describes the portion of the PDF page which is georegistered.
The BBOX is specified in PDF points. A point is 1/72 of an inch, and
your PDF is 842 points wide and 595 points high. However, the BBOX
entry is (I've truncated some of the trailing digits for clarity):

[ -357783.72 -742183.28 -357757.06 -742164.34 ]

Those could be eastings and northings, I suppose, but usually
projections are set up to keep those values positive, so even if they
are, they're probably based on bogus longitudes and latitudes. For the
portion of the page containing the map, the BBOX values should look
something more like this:

[ 86 86 620 511 ]

These numbers are just approximate, but they are close.

The next clue is the GPTS entry, which contain latitude-longitude
pairs that correspond to the LPTS entry, which is in relative
coordinates for the bounding box. The LPTS entry is:

[ 0 1 0 0 1 0 1 1 ]

Which says the GPTS will correspond to the upper left, lower left,
lower right, and upper right corners respectively. Here's the GPTS
entry:

[ 0.0014258201441901 -15.902408231200148
  0.0002516153195675 -15.902408224328752
  0.0002516181359381 -15.900825314290767
  0.0014258361036234 -15.900825321161765 ]

Those values are in the middle of the Atlantic near the equator, which
is surely not your intent. The Gauss–Krüger zone 2 you've specified is
centered on 6 degrees East longitude, so, somehow something is getting
lost in translation. Taking the values you entered in the command as
GK zone 2 easting/northings, the GPTS should look something closer to:

[ 49.6 5.3
  49.5 5.3
  49.5 5.4
  49.6 5.4 ]

Again, this is just illustrative, those aren't what the actual values
should be (there would be lots more trailing digits and they'd be
"closer together"), but they're ballpark and show the proper
orientation. I hand edited your PDF with these values to show that the
georegistration is otherwise OK and is compatible with Adobe Acrobat
Reader. It's available at:

https://www.dropbox.com/s/5n297s4l0r2d1wz/epsg-31466.pdf?dl=0

Perhaps this information can help give some of the GDAL command-line
ninjas some ideas for pointers for you from the toolset side.

Please let me know if you have any further questions about the
georegistration metadata or PDF -- that's the stuff I know.

Kindest regards,

George