[gdal-dev] Some info about geospatial PDF and TerraGo Toolbar

Even Rouault even.rouault at mines-paris.org
Fri Mar 2 16:02:29 EST 2012


Le vendredi 02 mars 2012 21:22:10, George Demmy a écrit :
> Here's some info that might help the development effort for PDF and
> use of PDF created or georegistered by GDAL.
> 
> Something that is confusing is TerraGo Toolbar's behavior with PDF
> files not created by TerraGo software. The company policy was to not
> support files with the Toolbar, the reason being the company could not
> afford to support debugging of files created by other software
> systems, etc., with a free product. This policy was imperfectly
> implemented in Toolbar code: sometimes it can be tricked into
> believing a PDF was created by TerraGo even when it wasn't.

Well, sorry for trolling a bit, but I can't resist ;-) I'm not surprised such 
attempt wasn't reliable (and having even tried to do so is quite chocking from 
my point of view !). How would that be doable with an opened spec ? Unless 
there are some secret sauce not exposed in the spec, such as strict order of 
keys in the dictionary...

> Some of
> the "works sometimes, other times not" behavior can be attributed to
> this, especially when it comes to ISO encodings which have been
> supported since 2008.

Hum, actually, I've never see any public sample with the ISO encoding (but to 
be honest, I couldn't find many of them) that is recognized by the toolbar 
(well, the SRS and geotransform are recognized, but none of the tools are 
available, not even coordinate display)

> Fortunately, this policy has been abandoned and
> the next release of the Toolbar will attempt to read any and provide
> display of coordinates, measurement, etc. Toolbar is due to ship later
> this month. That will have some rudimentary introspection tools to
> help figure out why a PDF doesn't seem to work.

Good to know. If ISO encoding is fully supported, then it will save the effort 
of mapping all the various projection methods, which is a tedious effort. 
Currently, only a few of them are written by the driver (geographic, UTM, 
Transverse Mercator, LCC 2SP).

> 
> Some of the issues reported in an earlier thread may be related to the
> Toolbar "refusing" to display the coordinates and might not any
> indication that the encoding has been bunged, strings not properly
> formed, etc. As was noted in the earlier thread and as I've confirmed
> with some prerelease Toolbar code, the encodings are correct for both
> samples cited, so good job Even!
> 
> With the OGC encoding, it's safer to always write the numbers as
> strings .16g.

That's what the driver does, unless it detects its an int value, in that case 
it is written as a standard PDF numeric value. Saves a few bytes ;-)

> However, the ISO method does not permit this. The ISO
> method is less sensitive to the limitations of the PDF real number
> object type, so the only concern there is precision (PDF reals are ~ 5
> significant digits in the fractional part (cf. ISO32000)), which
> cannot be addressed without modifying the encoding specification and
> everything that implies.

Actually, the driver will try to output up to 16 decimals. I'm not sure if it 
will cause issues to readers. I guess that, at worst, they will discard the 
extra digits.

> 
> When did gdal_translate pick up the cool macho supremo ability to
> georegister a PDF? The googles did not help me...

Just a few days ago. And for the record, MapServer can also now output 
geospatial PDF, through its Cairo/PDF backend, when it leverages the GDAL PDF 
driver.

> 
> I fell off this list a while back, but am back on. LMK if there are
> other questions.
> 
> HTH and cheers!
> 
> George Demmy
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


More information about the gdal-dev mailing list