Mapnik 3.0.0 Release Candidate 2

We are on the final hurdles for a 3.0.0 release! We have officially released and tagged a 3.0.0-rc2 build and are in a feature freeze. We expect the current C++ API not to change and could really use help testing our release candidate.

You can download the release canidate or checkout out the tag from our github repository.

You are welcome to follow all our conversations up to this release on github.


Posted by Blake Thompson on 21 May 2015.

Simple Mapnik Python Installs

I have been hard at work the past couple weeks trying to do something that has been asked for many times from people in the python community. A simple way for Python Mapnik to be installed via pip or easy_install. While we already had a way for a pypi package to be installed in mapnik2 which is on pypi it took some time to configure everything properly.

I am proud to say it should now be as easy as:

pip install mapnik

This now works for OSX 10.8+ and some Linux systems through the magic of python wheels. This requires zero compiling and includes all the binaries necessary for mapnik to work!

Python Bindings Moved

In order to get this all to work properly we took a series of steps. The first was that we spent a great deal of time working on a way to package and distribute binaries easily. The result of this has been mason. This allowed us to make and distribute consistent prebuilt binaries to speed up development and make it easier for developers to configure a new environment.

Once this was accomplished we were able to more easily seperate the C++ mapnik core and establish a new repository for python.

Expect Changes in Python API

While not much has changed yet about the Python mapnik API itself in this move, we do plan on making some changes to the bindings as we head towards a 1.0 release of the Mapnik Python. The goal of these changes will be to include many of the features already in Node Mapnik such as vector tiles. Ideally we would like to have the APIs between the bindings be as similar as possible to make documentation and examples easier to write.

Our Lack of Documentation

I know that currently we do not have great documentation for the python bindings, but we are determined to make this change at some point in the future. The wiki on the mapnik repository is very out of date. We know that users need better examples and a good API documentation. This is on our roadmap and constantly on our minds. Expect some more movement on this once we have an official Mapnik Core 3.0 Release.

Please Post Issues

If you play around with the new Mapnik Python bindings or want to let us know what you think post an issues on the Github issues page.

Posted by Blake Thompson on 06 May 2015.

Approaching 3.0 Release

It has been a long time since we have made a post, but work on Mapnik has not stopped! We are very close to a Mapnik 3.0 release! This has been a major milestone we have been working on for several years. Stay tuned for more details as we get closer to the release!

Posted by Blake Thompson on 05 May 2015.

Release 2.2.0

The Mapnik team is pleased to announce the Mapnik 2.2.0 release. This time around we’ve been focusing primarily on stability and performance, but there are some new cool features too. It’s fun this release coincides with this weekend’s SOTMUS in San Francisco and we hope to see you there!

release 2.2

Summary and Changelog

For more details on 2.2 features and fixes see the Summary and the Changelog.

Everyone is recommended to upgrade!


Get it from downloads page.

Thanks to everyone involved!

Posted by Artem Pavlenko on 04 June 2013.

WKT geometry parsing benchmark

In addition to beautiful rendering capabilities Mapnik also offers a fast C++ and Python API for working with raw geo features. You can create them on the fly from a variety of formats including wkt, wkb, and geojson. This feature allows creative programers to use Mapnik like you would OGR to read or create data and output it to other formats.

Geometry parsing for datasources and tests

The WKT and GeoJSON geometry parsing support in Mapnik core makes it easy to support for these formats in datasource plugins like the Mapnik CSV plugin. And because the CSV plugin supports inline WKT strings you can write simple, standalone test cases for Mapnik bugs as easily as ticket #1484 demonstrates.

Geometry parsing performance

As more people find the Mapnik CSV plugin they start throwing more and more data at it. We need to ensure that our parsing is as fast as possible. So today I started on some benchmarks to figure out baselines for performance. The questions I’m interested in are:

  • If parsing WKT across many threads does performance decline or improve? (We’ve found in the past that std::locale locking can kill threaded performance when parsing XML strings)

  • Does performance differ depending on the C++ library used? (the emergence of clang++ and libc++ on OS X make this an easy and relevant test)

  • How does Mapnik WKT parsing compare to other common libraries that people use for parsing WKT geometries?

First look at benchmarking results

Today I created a first pass at a C++ benchmark. The code is on github. Please see the README for details on how to set it up and run the tests.

There are two tests of Mapnik and GEOS that parse a set of very simple WKT geometries 100 thousand times, one serially and the other broken into 10 threads of work that each parse 10 thousand times.

The results on my system (OS X 10.8 / clang++) were:

mapnik compiled against libc++, using -std=c++11

$ ./run
1) threaded -> mapnik: 640 milliseconds
2) threaded -> geos: 2470 milliseconds
3) mapnik: 2800 milliseconds
4) geos: 9150 milliseconds

CAVEAT: Geos is not linked against libc++ in this test

mapnik compiled against libstdc++, using -ansi

$ ./run
1) threaded -> mapnik: 880 milliseconds
2) threaded -> geos: 2520 milliseconds
3) mapnik: 3440 milliseconds
4) geos: 9200 milliseconds

NOTE: smaller numbers are better and indicate that the tests finished faster.

The results seem to indicate:

  • High concurrency, as you would hope and expect, does not hurt performance but rather helps. This is great, but not always the case in C++ when parsing strings. If your parsing code triggers mutex locks then concurrency like this can hurt.

  • Mapnik is more than 2x faster than GEOS for these simple test cases. So, the next step here is to 1) figure out if Mapnik continues to perform well on larger WKT strings and 2) make sure we are using the GEOS API correctly.

  • Mapnik is slightly faster when compiled against libc++ and built in C++11 mode (than if compiled against libstdc++ in -ansi mode. This is great - will be interesting to learn why. My guess is that boost::spirit, which mapnik uses internally to parse WKT is benefiting from c++11 features. Or libc++ is providing faster implementations of key functionality than the standard gnu libstdc++. Or both :)

Please feel free to check out the benchmarks, run them yourself, and suggest other caveats or improvements. File issues here to provide comments.

Posted by Dane Springmeyer on 19 April 2013.