PHOTOGRAMMETRIC ENGINEERING & REMOTE SENSING
November 2016
841
SECTOR
INSIGHT:
.
com
E
ducation
and
P
rofessional
D
evelopment
in
the
G
eospatial
I
nformation
S
cience
and
T
echnology
C
ommunity
A
ll modern commercial geospatial software depends
on open source libraries which are ultimately
maintained by the community which uses that
software. That community stands to gain as we
support and train within this common infrastructure.
A Real-Life Example
A few years ago, my team was tasked with a project that add-
ed “Geospatial PDF” support to a high-performance geospa-
tial image server. “Geospatial PDF, Cool,” we said. Then,
“what’s that?” For our purposes, this meant a PDF file of
a single map that could be rasterized, geo-referenced and
served alongside all the other geo-referenced images on the
server. The details, of course, turned out to be less concise.
It turns out that the PDF file format is an international stan-
dard. The specification is 800+ pages long and describes the
format in implementation-level detail: how the document is
built up from containers, where fonts are and so on. Howev-
er, it says nothing about geo-referencing.
For that, we needed to look at a different document: Exten-
sion Level 3. It is 140 pages long and discusses a lot of topics,
including the ability to provide the geo-referencing for a cer-
tain region of the PDF page. The particulars we cared about
are on page 49, Chapter 8 “Interactive Features,” Subsection 8
“Measurement Properties,” in subsection 8.1.1 titled “Geospa-
tial Features.”Bear with me; I am not just being pedantic here.
In a minute, I will share a defect-resolution story that comes
back to these long documents that almost no one has read.
Now that I know exactly what a geospatial PDF file is, how
can I make it available to my application-- the high-performance
image server? My brief perusal of the nearly 1000 pages of spec-
ification suggests writing our own reader/writer is not a feasible
option. It would need to address minutiae like font rendering
and substitution, which the company has neither expertise nor
interest. We need someone else to do this for us. Happily, there
are several vendors who make exactly such a software develop-
ment kit (SDK). We evaluated four of them: Adobe, TerraGo,
PDFLib and Geospatial Data Abstraction Library (GDAL).
Picking a Geospatial PDF SDK
Adobe is the gold standard of course. In practice, PDF means
“Opens in Acrobat Reader” and this is the library that powers
By
Michael Rosen
Open Source Software in a Commercial Software Environment
Reader. In terms of proven street-cred, TerraGo is up next.
This is the company that is most closely associated with the
PDFLib Programming library, the new geospatial extension
for PDF, they are and distribute “GeoPDF”. PDFLib was rel-
atively new at the time; but seemed well-regarded. GDAL
was the only open source option we considered and had the
significant virtue of being free. Furthermore we have already
integrated it for other reasons and it had a newly contributed
driver that claimed geospatial PDF support. However, a new
driver that claims to support those 1000 pages of specification
seemed like a risky prospect.
We evaluated the libraries across four dimensions:
y
y
Community/Responsiveness. If there are questions about
the SDK, is it easy to find someone to ask? If something is
not working right, can someone help me understand why?
If we decide the library needs to be extended or fixed, is
there a fast and reliable mechanism to support that? All
of the libraries had active forums for peer support; expect-
ed responsiveness to fix requests was harder to gauge.
y
y
Integration Effort. Software has data and processing
models and when we use different libraries together, we
need to integrate the two. If the new models are sim-
ple or are already in use, then the integration effort is
minimized. In our case, we were already using GDAL
for much of our raster format support; this dramatically
reduced the risk of using the new driver.
y
y
Quality / Robustness. At the end of the day, the new li-
brary needs to work right for a wide variety of documents
and the best estimate of the risk here is past experience:
if other people have used it and it worked for them, then
probably it will work for us too. If it is a “version 1.0”
then, it is risky to assume it will “just work.” This ar-
gued strongly for the Adobe followed by TerraGO.
y
y
Cost. We were quoted SDK licensing fees from $0
(GDAL) to significantly more than that.
Photogrammetric Engineering & Remote Sensing
Vol. 82, No. 11, November 2016, pp. 841–842.
0099-1112/16/841–842
© 2016 American Society for Photogrammetry
and Remote Sensing
doi: 10.14358/PERS.82.11.842
