[Mapnik-devel] Mapnik BoF at SotM

[Richard Weait]

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 ]