srs representations and a small optimization

[springmeyer]

For the style in this we moved to using the +init syntax to ensure that srs strings match exactly what is passed in from the url request.

But, if we did the translation between +init=epsg:3857 and the exact mercator proj4 literal (that we choose to use in the style) in the server this would avoid proj4 (inside of mapnik's proj_transform) having to hit its /usr/share/proj/epsg file to get the proj4 definition. This lookup only should happen a couple of times max per request, so it may not be a measurable i/o burden, but could still be avoided as a small optimization.

[springmeyer]

a cleaner solution could be to work on http://trac.mapnik.org/ticket/839, but at this point I don't think this is as critical as other issues.

[kkaefer]

That ticket only solves part of the problem. The problem in the style was that we had slightly different proj4 strings which resulted in proj4 being called and it essentially did a null transform. Mapnik should "normalize" proj4 strings to make sure we're only ever using one single proj4 string for all descriptions of a projection.

[springmeyer]

yes, totally, the main problem was non matching. But given that we are now matching, this could be a future todo - though lets not worry about this right now... (mostly created this ticket for @ajashton to know the backlog)

[springmeyer]

Fixed upstream in Mapnik now by implement 4326 and 3857 natively.