Dear All, I took some notes at the Mapnik Birds of a Feather at State of the Map 2010 in Girona, Spain last Friday. I hope that other attendees will add their notes and recollections in this thread and then we can move them to a more-permanent home.
Attendees (Apologies to later arrivals, please add yourselves) Andy Allan Robert Coup Aubrey Holland Andrii Mishkovskyi Dane Springmeyer Jochen Topf Richard Weait Discussion Starter: What does Mapnik need? - Documentation - Tests - Packaging / Releases - Performance - Metrics - Debugging - Simplify styles - Multithreading Documentation We talked a lot about documentation. There was consensus that more and better documentation would lead to more and happier newcomers joining the mapnik community. Some points from the discussion included: - Rename the rendering styles on OSM. ;-) - Add a "What is Mapnik" to the web page. - Rendering the OSM default style from the complete OSM toolchain isn't really for everybody. Let's find make some simpler tutorials for those with modest goals. - Failure shouldn't have "import planet.osm for a week" as a prerequisite. Let's provide other ways to install and test mapnik. (Same for success) - Developer references (eg symbolizer parameters) are good. Let's make illustrated examples that go further and tell folks when to use which parameter and how typical parameter combinations interact. - For the raster symbolizer, show examples of color theory options so "average" users can select dodge vs burn with fewer missteps. - More demonstrations with working code. - Test for working installation earlier, from .osm files and or pgsql dumps. - Consider wider documentation audiences, including new mappers. - Find and document the simplest path from interest through installation to pixels on the screen. - Make docs refer to code versions. Keep 'em up to date. Can tests flag docs that need revision at a minimum? - Clear out old / dead demos and docs. - Aim for demos and tutorials that are "not too trivial" real examples with clear path to success. Packaging and Releases We talked a bit about Packaging and Releases at various times. Consensus was that this was a good idea as we have little of this right now. Having a recent and stable mapnik available in every distro for instant sudo $command install mapnik might be a lofty goal but we can move towards it. - At least build deb and rpm packages locally. Perhaps nightly, perhaps per commit. - Do more builds for FreeBSD/Mac/Win/ - Do more to make Debian / redhat releases dead-simple for Debian / redhat to include in official repositories. - Find and make connections through distro channels. - Stay on top of distro release schedules. - Do more with releases and show a connection between release numbers and svn commit numbers. Testing Brief discussion suggested more tests and testing around builds. - Test all data sources, PostGIS, .osm, shapefile, etc. - Test projections. - Test with documentation and tutorials, (fix 'em? mark them as stale at version#) Performance and Metrics There is a build option to show the time required for each layer. What other metrics can we add to the code to make evaluation our installation and style better? - Style sheet profiling. - What else? Multithreading [ please help fill in these notes ] _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
