[gdal-dev] GeoPDF

[Frank Broniewski]

Hello George,

wow, thank you for your very helpful answer! I must admit I am more of a 
trial-and-error person and when I saw all the docs and the sheer amount 
of content I just went ahead and tried something. But obviously there's 
a lot more to learn about on how to make a GeoPDF. I'll go through your 
email step by step and see what I can do about your mentioned problems 
in the PDF.

Thanks a lot, again!
Frank

Am 16.06.2016 um 17:34 schrieb 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

-- 
Waldhölzbacher Str. 51
66679 Losheim am See

(+49) 0177 30 21 791