I sent the message below to mapnik-users, it should probably have gone here.
-mike. Begin forwarded message: > Hello, > > I've been working on a major update to Cascadenik, on a branch: > > http://code.google.com/p/mapnik-utils/source/browse/branches/cascadenik-xmlbad > > There shouldn't be any external changes in behavior, but I've been > slowly modifying the library from one that transforms one kind of XML > into another kind of XML, to a library that operates directly on a > mapnik.Map object via the Python bindings. In particular, I was happy > to find out that it's possible to serialize a mapnik.Map object to XML > directly using save_map(), so that's how the cascadenik-compile.py > script now works. All of my tests are being performed against a two- > month-old trunk build, which I *think* means they should be compatible > with 0.5 installations out in the wild. > > Most of the actual edits were in compile.py, but the most relevant > code is here: > > http://code.google.com/p/mapnik-utils/source/browse/branches/cascadenik-xmlbad/cascadenik/output.py > > See especially the to_mapnik() methods - they take a cascadenik- > specific brew of Layer, Style, Rule and Symbolizer classes and use > them to drive mapnik's own bindings. Having had a chance to work with > the bindings a bunch, I have some ideas on how they could be improved. > The contents of that output.py file are where I think mapnik's > bindings should be. A few thoughts: > > 1. Less C++, more native python. Currently the bindings seems to > mostly be direct interfaces to the compiled library, which makes it > more difficult to look inside and see what's going on, and enforces a > shortlist of accepted method signatures. It would be good for many of > the classes here to be pure python: > > http://svn.mapnik.org/tags/release-0.6.0/docs/api_docs/python/mapnik._mapnik-module.html > > 2. Heavier use of keyword args in constructors. I've put all possible > symbolizer parameters for the few that I've made into the > constructors, which removes the situation in the wiki GettingStarted > page where it's necessary to instantiate an object and then perform > further changes to it to get it all working. In particular, it should > be possible to populate a mapnik.Map object with style and layer > information in an entirely declarative fashion, as shown in this test > from cascadenik: > > http://code.google.com/p/mapnik-utils/source/browse/branches/cascadenik-xmlbad/test.py#1519 > > 3. Real lists. The python bindings make heavy use of append() methods > that give the impression of regular python list objects under the > hood. Generally, appending a layer or style to a mapnik.Map actually > makes a deeper change, and subsequent attempts to reorder the list or > remove items fail. I think it would be interesting for mapnik.Map to > be a fully-editable and introspectable python object, with plain old > lists and dictionaries where possible, instead of a mystery Boost > thing. The to_mapnik methods I wrote above are a fairly clumsy > implementation of late compilation > > 4. Explicit defaults in serialized XML. I was confused when outputting > XML, when LineSymbolizer CssParameters for black colors or one pixel > widths were not being output. I understand that this is because black > + one pixel is the assumed default in mapnik, but I can imagine a > situation where that might change, and it'd be useful for output XML > that might span multiple mapnik releases to include these things. > > Anyway, that's all. The branch is about 90% done, I still need to deal > with datasources and all the symbolizers that use images. > > -mike. ---------------------------------------------------------------- michal migurski- [email protected] 415.558.1610 _______________________________________________ Mapnik-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-devel
