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 are welcome to follow all our conversations up to this release on github.
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
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.
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.
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!
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!
Summary and Changelog
Everyone is recommended to upgrade!
Get it from downloads page.
Thanks to everyone involved!
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
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
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 /
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
-ansimode. 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.