Printing
From Map Kibera
- A3 Poster Print
- Atlas with map/text/photos on a number of thematics (wash, religion, education, business)
- Distribute throughout Kibera to schools, public buildings
- Hold PPGIS type workshops with prints
Tech
Foresee this being a multi-step process. First, configuring a map style for the poster, and each of the atlas pages. Second, take that map style and use mapnik to generate the image in the proper resolution/size. Finally, combine that image with other graphic elements, index, photos, etc, to produce the final print image.
To start, suggest familiarization with the following tools.
- Quantumnik: QGIS is an open source desktop GIS. Quantumnik is a plugin to generate Mapnik map styles. This is a powerful tool, which might take some work to get up and running, but worth it for the flexibility. (Mikel can help with this)
- CloudMade Map Style Editor: A browser based tool for styling and producing tiles from OSM data. Very nice interface, no installation BUT we can not reuse the style or tiles for the print. So, this is only for demonstrating the concepts for the Prints.
- Mapsomatic: Generates PDF of city maps and index. Again very nice, but perhaps not flexible enough for our use.
- MapBox: A suite of tools for generating tiles on Amazon EC2. This suite includes Quantunmik to generate map styles, but then handles all of the map tile generation. Depending on our needs later on, this could be helpful.
- TileDrawer: Another take on generating tiles on Amazon EC2. Haven't evaluated either of these in detail.
- Contours totally necessary for Wongonyi at least.
Notes from Dane on QGIS
Connecting to osm data imported into postgis is ideal since that is faster and more akin to what you'll ultimately likely be moving stylesheets into.
But, .osm files imported into QGIS using QGIS's built-in OpenStreetMap plugin can also be handled by the latest Quantumnik, but in a special way. Mapnik can read .osm files directly, but this plugin is not yet available for windows. So, instead Quantumnik tries to use the SQLite3 database that the OpenStreetMap QGIS plugin pushes a .osm file into when opened within QGIS. If that is confusing, I understand - I'm just starting to wrap my mind about how best to handle raw .osm files, and having the Mapnik windows binaries missing that support is tricky. More background on this one here: http://www.cartotalk.com/index.php?showtopic=5310&pid=29684&mode=threaded&start=#entry29684
The big gocha with this direct .osm/sqlite approach is that I've yet to add support for getting a the styles that QGIS has for .osm data, which pretty much negates the value of using QGIS to try to author the Mapnik XML in the first place - but I'll hopefully get to adding this soon.
In summary, osm2pgsql and using osm data inside PostGIS is ideal. :)
Of Note, either way there is one key trick to being able to open osm data in postgis, since it is likely in EPSG:900913.
ISSUE: QGIS will not auto-recognize the 900913 projection of the postgis tables and will default to assuming epsg:4326.
SOLUTION:
1) Make sure to change the default setting in SETTINGS > OPTIONS > CRS > DEFAULT COORDINATE SYSTEM == 'prompt for CRS'
2) Add a custom projection for spherical mercator (SETTINGS > CUSTOM CRS)
3) Assign that custom projection to the osm data when opened in QGIS and prompted for a projection.
> For the Mapnik stylesheet, can I just take the standard OSM one? (guess that requires the postgis connection of course)
>
So, Quantumnik is really only useful (at this point) for two main things:
1) opening arbitrary data in QGIS and doing a quick and dirty styling/symbolization of it inside the QGIS GUI interface, then being able to export out the result into Mapnik XML to tweak further by hand.
or
2) as a viewer for a native Mapnik XML/MML. The idea here is through the plugin you can open Mapnik XML in a read only mode, and use QGIS as a live preview (ctrl-r will refresh) while hand editing the XML in an external text editor.
So, you cannot yet open something like the official Mapnik OSM styles in a read/write way.
