Joaquim,
Interesting! As Peter pointed out, the LPTS tag is the transformation matrix
to go from projected coords to page coords, and is created by forming the
UTM->page coordinates tranformation (from the information in the CTM tag below)
and inverting it (there's a brief mention near the end of
http://geopdf.blogspot.com/2009/02/georegistration-worked-example.html)
Since the TerraGo way has been superceded by the Adobe/ISO way (thank
goodness!), it makes it easier to identify the reference system definition in
GDAL, so there may be some hope for GDAL and GeoPDF.
Now I need to think about my requirements for reading and writing GeoPDFs.
Write a Postscript driver for GDAL? Figure out how to write the equivalent
info into a PDF using Mapserver/Cairo? Yikes!
Thanks,
Brent
Joaquim Luis wrote:
Brent,
I was also digging a bit on this matter. It's true that the blogger only
opens
our appetite as there is no more details on how to do it generally. I
mean, for
UTM maps it has become fairly obvious how one can do it. The relevant
part in the
PS file is
[ {ThisPage} <<
/LGIDict <<
/Description Title
/CTM [(35.28267) (0) (0) (35.28267) (205188.64) (3207094.8)]
/Projection <<
/Description (WGS 84 UTM 16N)
/ProjectionType (TC)
/Datum (WGE)
/CentralMeridian (-87.0)
/OriginLatitude (0.0)
/FalseEasting (500000.0)
/FalseNorthing (0.0)
/ScaleFactor (0.999600)
/Type /Projection
>>
/Type /LGIDict
/Version (2.1)
>
> /PUT pdfmark
However, there is no more info on how to program in this "TerraGo way"
A next post shads a bit more lite on the matter.
http://geopdf.blogspot.com/2009/02/geopdf-and-geops-with-adobe-style.html
As you can see in the quada.ps file there is an alternative "Adobe way",
which encodes the referencing as
% embed georegistation info
[ {ThisPage} <<
/VP [ <<
/Type /Viewport
/BBox[0 0 dh dv]
/Name Title
/Measure <<
/Type /Measure
/Subtype /GEO
/Bounds[0 0 0 1 1 1 1 0]
/GPTS[29.0 -90.0 30.0 -90.0 30.0 -89.0 29.0 -89.0]
/LPTS[0.024324 0.039461 0.051689 0.978774 0.975675 0.961136
0.957432 0.022122]
/GCS <<
/Type /PROJCS
/WKT
(PROJCS["WGS_1984_UTM_Zone_16N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-87],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]])
>>
>>
>>]
> /PUT pdfmark
Now this is more familiar, except for the
/LPTS[0.024324 0.039461 0.051689 0.978774 0.975675 0.961136 0.957432
0.022122]
part that, contrary to the promise has not been explained where it comes
from.
I think I could implement the first encoding type in GMT's ps2raster (if
I knew all the specs)
Second type would be even easier ... if we had a way to translate the
GMT projection syntax into
WKT, which we don't.
Joaquim
Joaquim,
Doing the format conversion from .ps to pdf is one thing (and there
are several ways to do it), but embedding the georeferencing in the
PDF to make it a GeoPDF is the interesting bit. I haven't found any
open source project capable of do that. Or even capable of writing
the PDF elements (e.g. Frames) necessary for writing the GeoPDF
information. But I remain hopeful...
Brent
Joaquim Luis wrote:
Brent Fraser wrote:
I see the example calculation of the transformation matrix, and a
statement "I created a GeoPDF by running the Postscript file through
Ghostscript to create a Postscript file that looks like this"
But I don't see where the georeferencing is written into PDF to make
it a GeoPDF. Is it a Ghostscript command line?
Brent,
One only has to convert it to pdf using ghostscript.
I did it with GMT's ps2raster, like that
ps2raster quad.ps -Tf -A
Joaquim Luis
Brent
Klokan Petr Přidal wrote:
Hi,
There is a great blog post (and the linked "worked example" post
with details):
http://geopdf.blogspot.com/2009/02/geopdf-map-for-worked-example.html
It shows you how to create geopdf via GhostScript - so there is
already a practical open-source example how to encode the georeference
into the PDF/PS according the OGC standard - for use in Acrobat
Reader. To add support for such tag in MapServer, which generates pdf
dynamicaly via pdflib, should not be totally problematic.
Decoding is not as hard either, there are nice libraries like poppler
(http://poppler.freedesktop.org/), which allows you to parse vectors
(and convert them to SVG for example) or rasterize the PDF files (into
TIFF,...) via Cairo.
The work is in assigning correct geographic coordinates to the
coordinate system internally used in PDF files and especially write
the bridge to the outside world (with GDAL/OGR).
I am afraid that authors of the GeoPDF standard would not like this,
as it seems that the idea of GeoPDF is "see it in the Acrobat, print
it, but that's all". At least I think so, because they discontinued
their Geopdf2geotiff product and all the conversion tools are just one
way - into GeoPDF. Please correct me...
Anyway, in this moment you can quite easily use utility like
"pdfimages" to extract full quality image tiles from any GeoPDF (like
those from USGS) and merge it based on their location in PDF into one
GDAL file via VRT (gdalbuildvrt) with a bit of hacking. This is what I
did for my favorite USGS DRG of Grand Canyon ;-).
Look at: http://klokan.mzk.cz/~klokan/geopdf/ - soon I will update the
MapTiler.org overlay examples...
Unfortunately all PDF parsing libraries I know are GPL, and that means
we can't use them for the gdal driver - because of the license issues.
But to create a GPL utility for converting GeoPDF to anything what
GDAL/OGR supports should be OK. Poppler can be the best base of such
GDAL-based utility for reading/rasterizing of the GeoPDF files.
Now just find a sponsor and time to make it ;-).
Best,
Klokan Petr Pridal
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
