Il problema di Mapnik su MacOS è che mancava l'inputplugin osm, che è necessario per il funzionamento del tutto.

Per quanto riguarda il dump preso da JOSM, posso confermare per l'area che hai provato -- dev'esserci qualcosa di diverso nei dati, ma non capisco cosa

Grazie del commento!

Oops, yes, I should've chosen a better name instead of map.

Regarding the bbox: I chose to use a string because it's used elsewhere like that: JOSM's download box, osm.org when drawing an area, and other related software. Sure, a more complete version would support something like "--south nnn --west nnn --east nnn --north nnn".

Segnalo che usando mapnik per mac os non si riesce a renderizzare la mappa e che facendo il dump scaricando il .osm da Josm non il render non è completo Grazie per l'interessante tutorial

'map' is a built-in function and should not be overwritten.

map = mapnik.Map(width, height)

using a capital M could help; or just a different name:

mymap = mapnik.Map(width, height)

bbox = '12.58664,37.65759,12.5945,37.66325'

###
# Don't touch below!
###
bbox = bbox.split(',')

could be replaced by:

bbox = [ 12.58664, 37.65759, 12.5945, 37.66325 ]

Posting a reply by Alexander via e-mail:

The lxml way to conserve memory while using iterparse is documented at
http://codespeak.net/lxml/parsing.html#modifying-the-tree . It consists
in removing children and previous siblings of the element. It does work,
but cElementTree is faster, according to my benchmark (cElementTree:
1m5s, lxml: 1m51s).

Uhm, I should really setup threaded comments.

@Alexander: reading this page about ElementTree compatibility of lxml, I see:

The iterparse() function in lxml is implemented based on the libxml2 parser
and tree generator. This means that modifications of the document root or the
ancestors of the current element during parsing can irritate the parser and
even segfault. While this is not a problem in the Python object structure used
by ElementTree, the C tree underlying lxml suffers from it. The golden rule
for iterparse() on lxml therefore is: do not touch anything that will have to
be touched again by the parser later on. See the lxml parser documentation on
this.

I suspect this is the reason why it doesn't work with lxml's ElementTree implementation.

@Marius: apart from my previous reply by e-mail (i.e. I'll try to write some code using lxml with a SAX approach), please also note Alexander's comment -- that same code won't work with lxml, just because of implementation differences.

However, I still want to optimize my particular code, so, if I ever find anything faster or lighter, I'll surely post it here

I'll paste the comment that I originally sent via email:

You may also want to look at lxml, which is the Pythonic binding of libxml2, or use libxml2's native bindings, which aren't as nice as lxml, but maybe a bit faster? As far as I understand, Vala uses libxml2 too; this way you'd end up comparing apples with apples.

In your python example, you retrieve the root node at start and clear it after processing each element. I tried to use this technique on dmoz rdf data files (about 2 GB in size). It does work with the xml.etree.cElementTree implementation of ElementTree. However, this is not the only implementation of ElementTree, and with lxml.etree, this approach fails (the error is "Namespace default prefix was not found, line 1029, column 21", and it doesn't appear if I don't clear the root).

So I wonder whether it is a bug in their implementation, or your script relies on undefined behavior by clearing the root node.