This code snippet, modifed from Mpanik's rundemo.cpp (r727, license LGPL), 
renders the State of California using USGS state boundaries data.

Here's a play-by-play (via https://lists.berlios.de/pipermail/mapnik-devel/2008-August/000679.html)

rundemo.cpp renders a map of Ontario/Quebec, and instead I wanted to draw a
map of California and its surrounding states.

I grabbed the data from the USGS in the form of "statesp020" (google it, or
browse through nationalatlas.gov) and first wanted to modify rundemo.py
instead. Alas, this is uncharted territory, as the Python binding does not
yet support the mapnik::query object (see the near empty
mapnik/bindings/python/mapnik/mapnik_query.cpp). Instead, I modified 
demo/c++/rundemo.cpp)

It took some time to get up to speed on Mapnik internals -- the code is
sparsely commented and there doesn't seem to be a canonical Doxygen dump
online (although one can be generated manually from the source). The Mapnik
wiki has some details, and I started to fill in some small gaps there, but
important bits such as what the "res" (second) parameter to the
mapnik::query ctor isn't documented anywhere (elsewhere, some feature
to_string() method seems to return "TODO").

The basic Mapnik data model which isn't directly documented is something
like this. A mapnik Map has Layers, a Layer has a mapnik::datasource_ptr,
and a datasource has features. One queries a Map's Layer's datasource by
asking it for the features given a mapnik::query, specifying the
axis-aligned bounding box (Envelope).

Mapnik relies heavily on boost shared_ptr and similar classes, with the
convention that _ptr denotes such a pointer.

You can follow along here -- http://gist.github.com/5009#LID76

Note the call to (mapnik::query) q.add_property_name('STATE') on Line 80 --
without these, no properties will be returned! Figured this out by reading
feature_style_processor.hpp.
Line 81 has the feature query call. It would probably be nice to use a
filter_featureset<> object instead, but the filter<> objects don't seem to
expose public typedefs to facilitate declaring the filter_featureset<>
object?

So, we asked the Map's Layer's datasource for a featureset_ptr, and then
iterate through the linked list of features, checking to see which features
pass the previously constructed filter. Unfortunately, the "nil" extent,
that is, a default constructed Envelope<double> isn't really a nil extent,
but rather an Envelope with negative width and negative height. That's okay
but you shouldn't tell such an Envelope to expand_to_include() another
Envelope, as it will do the Wrong Thing.

I was hoping that it would work the other way, but there may or may not be
reasons to design the library this way (code simplicity).

Overall, even though the library is as-of-yet sparsely documented, it seems
to work pretty well even though my XCode compiles crash whereas gcc compiles
don't (ostensibly with the same include, compile, and linking options). The
Python binding has some rough edges, and there are cases where appropriate
public typedefs (in the "traits" spirit) would make figuring out how to type
things somewhat simpler.

~L