Mapproxy-util serve-develop mapproxy.yaml Mapproxy-util create -t base-config mymapproxy This basic difference in geometry is reflected in every zoom level.)Ĭreate a generic configuration, to validate the platform, before making any adjustments: At zoom level 0, a map in Mercator / 900913 is made up of 4 tiles - two rows of tiles in two columns At the same zoom level, a map in Platte Carre / Global Geodetic / EPSG:4326 is made of two tiles in one row. (The reason tile indexing changes with projection is that the aspect ratio of the map can change. MapProxy's tile indexing works without having to fiddle with arrays of resolution at each zoom level, adopting odd tile sizes, or hacking the Javascript library, regardless of whether your map is in Mercator or Global Geodetic projections.
When you add a mapnik source, cache, and any layer(s) to the mapproxy.yaml file, a link appears in the demo HTML / Javascript that gets created for you. It appears to work well with 2.2.1 given use_mapnik2: true.įrom that point forward, it all moves very quickly. Second, you must assign a value of true or false to a configuration variable: "use_mapnik2". People on shared servers may not have this luxury, so look at virtualenvwrapper.
I chose to start-over and install MapProxy without a virtual environment. This may be prudent, but unless you also install virtualenvwrapper and use "toggleglobalsitepackages", you probably won't be able to import mapnik (assuming Mapnik was already installed before instantiating your virtual environment). Has anyone succeeded in serving tiles from a local host in EPSG:4326?įirst, MapProxy documentation suggests that it be installed in a Python virtual environment. TileMill and friends look elegant, but the documentation is clear that any self-respecting map should be square, to match its pixels.Įscaped me that trying to avoid Spherical Mercator is like trying toĪvoid oxygen, but Platte Carre was specified in the requirements that I
I'd apply that patch in a second, if I had any sense that it TirexĬould count rows in the 2:1 aspect ratio of EPSG:4326. To be a patch needed for it to work with the current release of Mapnik. I was about to try Tirex, but there appears Works with EPSG:4326 with renderd, mod_tile, javascript, et al? I consider making changes to generate_tiles.py or leaflet-src.js, am I missing something obvious? Wms.cpp:361:67: error: 'out' was not declared in this scope Wms.cpp:361:47: error: 'ImageData8' is not a member of 'mapnik' Wms.cpp:361:16: error: 'ImageData32' is not a member of 'mapnik' Wms.cpp:361:36: error: variable or field 'reduce_8' declared void Wms.cpp:63:44: error: 'class mapnik::Map' has no member named 'setAspectFixMode' But when I went toĬompile mod_mapnik_wms, it complained about the version of Mapnik I'm
WMS layer works properly, at least in Leaflet. Leaflet also allows me to use EPSG:4326, but expects more rows than a Platte Carre map should have. Render_list will store tiles in the rows and columns that I'd need for a map that was half as tall as its width.
The crs I specify in the map file, but neither generate_tiles.py nor Of tiles in Google Spherical Mercator (900913) projection, and that while specifyingĮPSG:4326 in OpenLayers changes aspect ratio of the map, the tile server stillĮxpects the "extra" rows of tiles that 900913 uses. I'm slowly coming to the realization that no matter what I specify, the OpenLayers / mod_tile / Mapnik stack expects the x and y coordinates
(See attached samples.) I can see why this is happening, but not how to get around this. The data sources are in EPSG:4326, and the mapfile specifies this CRS properly.īut the maps have extra rows of tiles were I don't need them, and missing rows of tiles where I do. I need to serve tiles for maps in Platte Carre CRS.