The GeoPDF format seems to be gaining traction these days. I have to admit, when I first heard of this technology I had the same reaction as James Fee - "What's it good for"? But I'm coming round... A live map with rich information content and a true geospatial coordinate system - what's not to like?
My excuse for such scepticism is my finely-honed technical bullsh*t reflex, which uses the logic of "If this is such a good, obvious, simple idea then why hasn't it been implemented ages ago?".
To be fair, there have been lots of SVG mapping demos, which fill the same use case and provide equivalent functionality. Sadly that concept hasn't really caught fire, though (perhaps due to the ongoing SVG "always a bridesmaid, never a bride" conundrum).
Of course, an idea this good is really too important to be bottled up in the murky world of proprietary technology. It seems like this area is ripe for an open standard. SVG is the obvious candidate for the spatial content (sorry, GeoJSON). What it needs is some standards around modelling geospatial coordinate systems and encoding layers of features. It seems like this should be quite doable. The goal would be to standardize the document format so that viewers could easily be developed (either stand-alone, as modules of existing viewers, or as browser-hosted apps). Also, the feature data should be easy to extract from the data file, for use in other applications.
Perhaps there's already an initiative like this out there - if so, I'd love to hear about it.
Monday, 23 June 2008
Subscribe to:
Post Comments (Atom)
13 comments:
"Standardize the document format so viewers can be developed..."
Like GML did? There is a reason the PDF chicken is laying the GeoPDF egg, and that's Acrobat Reader. Anyhow, now that Adobe is baking geo directly into PDF, I think we will see a lot more of this stuff, sans the proprietary GeoPDF software.
Er - what tool do I use to visualize an arbitrary GML document?
I think KML would be a closer approximation... and perhaps that is the answer. But it needs some extensions to be able to render nicely onto a flat coordSys, I think. It also needs some extra map-surround formatting (which is one of the cool things that PDF can provide). Once you start throwing those kinds of requirements into the mix, you don't really have KML anymore.
Anyway, I agree about the benefit of Adobe supplying geo capabilities directly. And they claim that their format is wide open. So maybe what's needed is a nice geoPDF generator API.
Although I still prefer the idea of a format built on truly open, modern standards...
WTF does any of this have to do with JSON (a format good for web services and APIs, not a competitor to PDF)?
PDF is great for getting published maps to end users who use Reader - the file format is designed to allow consuming applications to faithfully render what the author intended the user to see.
In addition to the faithful rendering, the PDF spec also allows content to be "marked" so that consuming apps can associate data with the drawing instructions. Adobe has supported layer separation since Acrobat 6.0 and feature identification since Acrobat 7.0. And now Acrobat 9.0 is supporting georegistration as part of the soon to be published spec.
Given the differences between drawing instructions and feature geometries, I wouldn't expect to see an explosion of tools parsing content streams to try to make spatial sense out of data in a georegistered PDF. The data in a PDF is just not always the same as the original source data. It's a generalization of the data appropriate for the map, a cartographic representation. Subtle difference, but just think railroad tracks.
The content in a PDF a bunch of drawing instructions - set color, move to, line to, pop/push graphic state, place text here and place raster there sort of stuff. Hardly the same stuff you'd expect to see in an OGC WMS or WFS.
Should not be a problem anyway because if I wanted to share my data with another GIS analyst, I can always send them a shape file and let them create their own map
Woohoo! I figured this post would be "poular"...
@Sean: I'm not surprised you're confused - the connection to GeoJSON is a bit obscure. Here's my thinking:
What I'm proposing is an open format for describing maps for rendering, viewing, and querying in a limited way. Likely the rendering agent will be a browser. An obvious format to use is SVG, but it's not the only option. JSON was developed to circumvent limitations of XML for encoding data - and those same limitations might apply here. It might be more effective to supply the data in a more "pure" form such as GeoJSON, and use JS to render the data into the DOM. One benefit would be to support agents which do not handle SVG. The data might also be more amenable to querying and other forms of manipulation.
Just an idea..
@jpg:
Good point. The idea that GeoPDF (or equivalent) might be used to actually communicate data is probably the least compelling argument for using such a format. But some sort of data has to be encoded in the format, and it should be somewhat easy to get at by external clients, so they can add functionality.
With an open format encoded as HTML/SVG/JS I can imagine it being the basis for "mashups" which added JS-based widgets and further rendering on top of the base data and symbology supplied in the original map. This is a good reason for ensuring that the data supports any desired precision, and is straightforward to access.
To elaborate on the thinking behind this post:
I see PDF as sort of the "gorgeous but dumb" sister of HTML. PDF looks great, but is proprietary and more limited in it's ability to be generated and read (in the sense of parsing.
So we have the equation:
PDF:HTML::GeoPDF:x
Since GeoPDF seems to have an audience, it's interesting to speculate on what "x" might be.
Perhaps a better name would be "GeoHTML". Although I'm hopeful that it could have the same visual quality as GeoPDF - but still be smart.
Did you heard about SVG MAP Consortium[1]?
It's a consortium of japanese companies who have developed a standard for SVG MAPS and a viewer for internet explorer.
They also developed tools for converting SHP and DXF to SVG MAP and they host a very big vectorial map online for demo purposes.
http://blog.svg-map.com/
@dr jts: In some ways PDF is and Reader is akin to HTML and the web - but disconnected. Reader supports interactive features such as hyperlinks and javascript. You can't run ajax, but, you can make web service calls. The big splash Adobe is making about Reader 9 is not the geospatial part, but Flash. I've messed around with the Acrobat 9.0 prerelease and it's pretty cool.
Bringing JSON into this discussion is indeed a bit misleading -- it's an apple among the oranges.
@Dr.JTS
I too have seen what is now possible with Flash in Acrobat 9.0 and I can see a lot more development being done with GeoPDFs in this environment...especially on the web. I would encourage everyone to check out Adobe AIR to see what is possible. There is a free SDK and you can also compile your swf's for free using the FLEX SDK. All very cool stuff!
We have been continuing various activities concerning web mapping platform that uses SVG (and the ancestor) for about 12 years.
One was standardization of SVG1.1 in 2003. The result was to have made the Hyper-Layering technology the public value only for SVG.
However, the open and interoperable Web map platform might still have been premature..
Implementation excluding us was not accompanied.
We are advancing the activity with three points now.
The first is cooperation with the administrative body of Japan that is the greater part of land record data holders in Japan. It may push the delivery of the Japanese map of the administrative body by SVG.
The second is lowering the cost of the map service by upgrading the standard specifications on the viewer side.
These specifications makes dynamic mechanisms such as DBMS, CGI, and Servlet needless on typical map servers. It can achieve the map service that can be freely scrolled only by delivering SVG map files divided into mosaic tegular with mere web server.
SVG Map Profiles (Japanese) If you want an English version, please use translation services etc.
* PURL for geospatial coordinate reference system for metadata of SVG Map
* Viewer requirements for tiled svg map data rendering
* Geospatial metadata for SVG Map
See also ESW Wiki GeoMetadataOverSvg (English)
The third is speed-up of the Vector Graphics(SVG) viewer.
We were considering that the vector graphics drawing solution on past Web had not reached a necessary performance yet.
We thought that it was necessary to display the vector map graphics data of about 10MB with ordinary PC at a comfortable speed. This was difficult in an interpreter processing system such as javascript. SVG Map Toolkit that SVG Map Consortium offers may fill it.
I created english translation of SVG Map Profile 1.0
Post a Comment