Collaborating in geospatial context since 2000!

Tuesday, May 05, 2009

History of GeoPDF: PDF Map Books, LGIView, and LGIDict

GeoPDF has a history that goes back to the 1990s. Using PDF files for engineering applications was the brainchild of Phil Lee, one of the founders of TerraGo. In 1999, Phil, then vice president of Layton Graphics, bid on a project to deliver maps and engineering drawings to telecommunications maintenance crews. The maps and drawings came from scanned paper maps, AutoCAD and Microstation design files and backed by different database systems maintained by different engineering groups. Phil was an avid Acrobat user -- fanatic may not be too strong a word. He knew more about getting stuff done with Acrobat than anyone I knew then or since. Taking all of these heterogeneous formats and data to PDF and exploiting the features of PDF and Acrobat was obvious to him. The PDF solution was compelling because it was not tied to any CAD or database system, secure, and easy-to-use. The solution was to render all of the engineering data to PDF, add bookmarks and hyperlinks to ease navigation, and organize the resulting map book with an interactive index map. My nominal role in all of this was for the rendering AutoCAD DWG files to PDF, along with extraction and analysis of the data that they contained for creating links and metadata. Alan Stewart headed up the Microstation side of things. Alan had been writing software to manipulate and render DGN files for quite a while. He arrived at Layton Graphics with Michael Bufkin some years before in an acquisition of Michael's company Cad Share. Michael ran Layton Graphics' engineering group. Michael, Alan, and I are all still working together at TerraGo.

The PDF map book project was a big success for Layton Graphics. We delivered the first map book set in the fall of 2000 and last in 2005. We built a custom system that consumed the raw design files and databases and churned out 2500 map book updates quarterly, burned them to CD and delivered them to the different maintenance groups. These map books were popular with the crews, and soon received requests for new features. These features were usually exposed by creating plugins to Acrobat. This was the responsibility of JB Freels. It was increasingly obvious that a combination of software and carefully prepared data was a compelling application that could be used in numerous contexts. It seemed that everyone we showed our map books to wanted them.

One of the first attempts to productize a collection of PDF files specifically configured for engineering applications along with Acrobat plugins was called LGIView. Adobe profiled LGIView as a success story. Patrick Graves was brought on board in 2002 to serve as chief software architect and run the software development group. One of the LGIView features was a coordinate finder. Engineering design coordinate systems are almost invariably Cartesian, but they are sometimes aligned with some mapping coordinate system like UTM or a State Plane system. Since the working coordinates were Cartesian, it was a simple matter to embed a rotation, scale, and translation that mapped the engineering coordinate system to that of the PDF. This metadata was encoded in the PDF file as a PDF dictionary called LGIDict. My notes indicate that Alan came up with the LGIDict version 1 schema. I Ling Xu initially documented the schema and I gave its name: LGIDict -- LGI Geospatial Information Dictionary. At the time, I didn't know about Acrobat developer's prefixes, and JB didn't bust me on it.

Even as LGIDict version 1 was being drafted in 2002 -- we had deadlines and product to ship! -- the limitations were obvious. In 2003 I started working on a second version with provisions to drive a coordinate transformation engine. The LGIDict version 2 was cut in November of 2003.


Anonymous Anonymous said...

This comment has been removed by a blog administrator.

7:32 AM EDT

Anonymous Anonymous said...

Do you know if there is any information about the Version 1 LGIDict somewhere ?

10:39 AM EST

Blogger George Demmy said...

It was never published and very few V1 "geo"PDF files made it into the wild. It was superseded by Adobe's measurement dictionary that came out with (IIRC) PDF 1.6/Acrobat 7.

1:45 PM EST

Anonymous Anonymous said...

They do does exist for NACO/FAA digital procedures charts.. Just wondering if its possible to geo-reference these charts ?

One example here:
wget -q '' -O 05722L17.PDF


6:32 PM EST

Blogger George Demmy said...

Very interesting! That's worth digging into in general. To your question: can these charts be geo-referenced. In general, yes. Can they be converted to GeoPDF, yes, but these are not answers to the same question. In the first case, they may *already* be georeferenced if the design coordinate system is coincident with a geographic coordinate reference system. If the coordinates, by applying a linear transformation, can be mapped onto a projected coordinate system supported by the TerraGo Toolbar, then the file can be turned into a GeoPDF compatible with the same.

10:29 PM EST

Anonymous Anonymous said...

Well, if you look in the file there is a Bounds tag that seems interesting, however I'm not sure what coordinate system they might be specified in ?


<< /Bounds [ (-2508.0000000000) (-4236.0000000000) (-2508.0000000000) (3937.0000000000) (2624.0000000000) (3937.0000000000) (2624.0000000000) (-4236.0000000000) ] /PDFBounds [ 0 0 369.504000 588.456000 ] /Parameters << /Source (DGN) >> /Projection (LINEAR) /Rotation (0.000000) /Scale (0.0720000000) /Type /LGIDict /Version 1 >>

1:19 AM EST

Blogger George Demmy said...

Naturally, I *did* look into the file, and with emacs no less... to see that it was indeed a file containing an LGIDict. In the PDF object parlance, the LGIDict is a page-level dictionary and that's what you've copied out of the file. That file was created by a program called DGN2PDF created by Alan Stewart while working at Layton Graphics. Alan wrote the version one LGIDict specification. The value of the Bounds key is an array of numbers. In this case, the units are in that of the design file used for input to DGN2PDF. This is indicated by the DGN value for the Source key.

Version 1 LGIDict didn't have any notion of encoding arbitrary geographic spatial reference systems. Many Microstation users set their design units to coincide with globally-referenced CRSs like a particular state plane CS or UTM. As I indicated in the previous note, if you knew that was the case, it would be a matter of doing some arithmetic calculation to come up with LGIDict version 2 registration points and mapping the CRS definition to the proper projection parameters for OGC best practice encoding. There is a little more to do in the case of the Adobe style encoding, but it can be done as well, since the two methods are almost entirely equivalent in the information they encode.

Also, the dates on the map are recent which makes DGN2PDF a pretty long-running application (it does make very pretty PDF files and has a nifty pen-table processing capability) and there may be more LGIDict V1 files in the wild than one might have guessed! Thanks for the heads up!

6:50 AM EST

Anonymous Anonymous said...

Unfortunately I have no idea what was used, I was hoping you would know! ;)

But I'll do something drastic, I'll ask the FAA if they know..

Thanks for your help!

10:39 AM EST

Blogger George Demmy said...

From the looks of it, it's most likely a unreferenced design coordinate system. The values for the Bounds entry range in the ± thousands, and not many practical mapping systems use negative values or even get so "close" to zero. This is not uncommon for CAD systems that don't traditionally word in terms of global referencing by default.

10:51 AM EST


Post a Comment

<< Home