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-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
