I’ve been enamored with the GeoExt interface for grabbing MapFish based print services since I first saw it. It’s a slick little interface, and can even been extended for multi-page print layouts pretty easily, ala http://tinyurl.com/mapfishmultipageprint. But as I’ve started to give thought not to what an organization full of professionals needs but what a public interface should looks (and probably those interfaces for professional organizations as well, only they tend to be more tolerant of poor design…), I’ve begun to realize that there are some clever ways we can bypass the GeoExt interface for generating the print documents at all. The actual request for a document is a simple post with a JSON object that has certain properties. We can construct this object all sorts of ways.
So, in the interest of making the snake eat its tail, my objective over the next few posts is to create an entry in a PostGIS database that has a view that automatically parses the “best” multi-page print for the geometry, feeds that back like a good API to the client script, which then requests a pdf print based on those criteria through the GeoServer Mapfish extension. Are we clear as a computer program, usually running over the Internet, that allows multiple users to participate in virtual-reality role-playing games? Good.
5 thoughts on “Ditching GeoExt– building simple clients for MapFish”
Excited about this! I create map books on occasion. It would be neat to see a way to better enable users with multi-page capability – in the GeoServer extension(-framework?)…I’d like to see it make it’s way to GeoNode 🙂
I think some sort of portable map document (pdf) capabilities would be great to see augment GeoNode.
I think the critical part of integration into something like GeoNode with many users would be to enable piping it through GeoWebCache to keep it from overwhelming the server, but that’s not hard.