Support Staff2 Posted by Dane on 02 Sep, 2011 01:11 AM
TileMill is certainly of the tribe of tools that target a single
projection intentionally to try to make things simpler for a larger
audience of non-specialist map makers.
That said, the underlying renderer, mapnik, is projection (and
tile system) agnostic, so once you design your map in TileMill you
can simply export out the Mapnik XML, setting the srs
to your desired projection, and render your maps from there (of
course scale denominators may need to be adjusted).
I think the larger issue is community standards around tiling
schemes for projections. If it there were a clearer path to this I
think there could be a discussion of TileMill supporting more
projections, but I'm not seeing that at this point.
Community standards around tiling schemes for projections is a
great idea. Maybe you should start such an initiative! ;-)
As far as I understand, Mapnik renders images/grids and not
tilesets. I've previously used TileCache together with Mapnik. Do
you know of a tile script that supports multiple reference systems
and the new grid renderer in Mapnik2?
The grid_renderer API in mapnik is very experimental at this
point via the python API, but TileStache is planning support
and I think TileStache supports both 900913 and 4326 - so that is
at least one more projection than TileMill :). The other option
might be MapProxy.
Unfortunately, I'm not able to attend the FOSS4G conference this
year (it look like it's going to be a great event!), but I hope
you'll raise the issue at the breakout sessions.
Maybe it don't have to be that complicated for the map maker. I
think you can standardize on 256x256px tiles and that each zoom
level is dividing every tile into four - like you do with web
mercator. You already have a nice interface for specifying map
extent and zoom levels. It's everything you need to create tiles in
a different projection. If the map maker use the same extent (and
max resolution, which you can calculate on the fly) in OpenLayers
or other capable map clients, the tiles should line up
It's a bit more complicated if the user want to mix projected
tiles from different providers - as they should follow the same
gridset pattern - but I'm sure you can make a nice interface for
this task as well.
I think the json grids are a great contribution to the web
mapping evolution (+ css-like styling and the beautiful Mapnik
rendering), and I would love to use it for my thematic world maps
and country maps. Mercator is a really bad choice, especially for a
country far north like Norway. While waiting for projection support
in TileMill, I'll have look at the tools your suggesting.
Support Staff6 Posted by Dane on 02 Sep, 2011 07:39 PM
Thanks, glad you like the css and json advances. We do too:) The
css styling and the json grids can be also used fully outside of
tilemill - there is nothing specific about these to mercator. To
leverage css you would use the carto toolkit (or wait
for native carto support in mapnik: http://trac.mapnik.org/milestone/GSOC%20Carto%20C%2B%2B).
And to leverage the json grids, as we've discussed, you would just
And yes, I think it could be doable for a mapping client, like
OpenLayers, to support any projection, but we've move quite far
from this in TileMIll specifically. We moved to using ModestMaps,
which only talks in mercator, because we only planned support for
mercator and ModestMaps is much smaller than OpenLayers.
So, I guess my summary is that I recognize the critical
importance of using the right projection for a given map. My
feeling is that TileMill, at least right now given the set of tools
at hand, will benefit more users if we stick to one projection. But
one projection for the map design stage only - TileMill obviously
tries to help prepare you for the next stages (and guides you based
on mercator) but this is not the only way and TileMill should not
prevent more creative and custom uses.
Generally we need a system that does the following:
Presents projections in such a way that clients can
auto-configure and display maps without having to be configured
manually in that projection
Fails softly when a projection besides spherical mercator is
attempted in a client that has no support (Google Maps, Modest
Maps, Leaflet, route-me, Locus - all of the APIs we support).
Plays nicely with the styling language so that 'zoom levels'
have a standard meaning across projections, and this meaning can
also be percolated into #1 for autodetection
Communicates the concept of projections to users of the map
framework, styling language, and map styling environment and
manages expectations that maps in odd projections will be
incompatible with all other maps, especially those that users know
well, like Google.
Creating an interface for combining tilesets of different
projections is a nonissue, since underlying goal is impossible
without eliminating IE support or adding an expensive reprojection
operation in the middle.
There are plenty of possibilities for solutions here, but
nothing seems viable yet. In the middle-term, it seems possible to
do static exports of specific projections so that the problem area
is reduced tremendously. We're certainly open to good ideas, but
it's important to understand that we're building for all users, not
just advanced users, and we want the level of expectations that
we've set - that MBTiles will just work, that maps can be
autoconfigured and combined - to continue.
Closing this here: the general goal of projection support is
agreed-upon, but it's only as good as its underlying architecture,
which still needs creation.