Print proxy

 Implementation of a print proxy to deal with time series layers in the current

## Spec

The spec document has to be modified the following way:

- The print template will print a timestamp, if present

   ` {"pages: [{"timestamp": "20111231"}]]}`

- If at least one layer has a time serie, a page will be generated for each "timestamp"

   `{"layers": [{"timstamps": ["20010112", "20021231"]}]}`

- Otherwise print as usual


## Tests


example |               waitress       |          pdf  | remarks
------------|----------------------|---------------------- |-----
zeitreiehen    |   39s             |        580 MB     |  all zeitreiehn + PK base layer
zeitreiehen2    |  41s             |        412MB     |   all zeitreiehen
zeitreiehen3   |   44s         |            390MB  |      all zeitreiehen, scale 1:100'000
luftbild       |  1m38s        |            320MB    |    luftbild s/w + luftbild farbe + PK
luftbild 75dpi   |  28s            |         88MB     |   luftbild s/w + luftbild farbe + PK
combination    |   2m05s         |          782MB    |    all zeitreiehen + luftbild s/w + luftbild farbe

Note 'waitress' is by far more robust than 'apache2' on our dev instance (way too much process on this instance)

## Issues


### Client timeout
  If the server fails to return something within the timeout delay, the browser closes the connection. This timeout is 60 sec on Chrome (tested) and Safari, but much more on Firefox and IE. Additionally, the BIT proxy also cut the connection after 60s.
   Request with response time over 60 seconds will fail. I have tried to cope with this streaming results as soon as some page are available, PDF is not made for this and streaming  big files through the WSGI interface kills the server.

###  Size of generated PDF
  For greater scale, the resulting PDF is in the range 200-400MB, for smaller scale it is often well above 500 MB, if it does not cross the timeout limit.
Reducing the size of the PDF:

*  Generating PDF at 75 DPI instead of 150DPI, discarding layers which are under an opaque one, as for instance the pixelkarte under the 'zeitreihen'.
*  _Ghostscript_ reduce in general the size of the PDF by 2, but it is extremely slow. Example a 300 MB is reduce to 134 MB, but in 2m50 (on 'dev'). Orinal: http://mf-chsdi3.dev.bgdi.ch/~ltmom/timestamps/zeitreihen4.pdf (304MB), ghostscript'ed http://s.geo.admin.ch/6081bb1486f (149MB)
* Animated GIF http://s.geo.admin.ch/6081ba023b (308MB)   


## Alternate approach

### Alternate format

 The fastest way to generate images is through mapproxy or WMS. Generating 100+ images of 1600x1200 (same as in the PDF) and dowloading them takes about 10-15 s (example from the production cluster, obvioulsy layer comparable to _zeitreihen_).
Converting them into a movie, take 30-40s, for a size of 50 MB (the PDF for these data would be 10x larger). Example: http://s.geo.admin.ch/6081bc913c

Generating images through _phantomjs_ is not an option because it is much slower (it hard to know exactly when the tiles are really loaded)

### Asynchronous API

The raw material for an image 1600x1200 is about 0.5GB. Processing and dowloading takes time. Why not send the result to the client when it is ready ?










Regarding logging: do we want all those messages in production? Or maybe reduce the log-level?