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