Staticmap for CMS

[GoogleCodeExporter]

Staticmap was written very specifically for MPAs and arrays. Major overhaul is 
needed to display features.

We'll likely want to leverage djmapnik to bridge the django layers with mapnik 
layers. 

Ideally, service should take arbitrary feature uids and map them on top of a 
mapnik xml-based basemap. 

Sharing permissions should be accounted for. 

Styling will be difficult and we'll likely need to have a feature instance 
property/method to determine it's mapnik style.

Initial testing reveals threading problems running djmapnik under apache/wsgi. 
This will need to be resolved to close the ticket.

Original issue reported on code.google.com by perrygeo...@gmail.com on 14 Feb 2011 at 8:23

[GoogleCodeExporter]

refactored staticmap to work with feature uids and djmapnik.

Still need:
* account for sharing permissions
* styling
* wsgi threading errors: 

To expand on the threading issue, the service runs fine on the django test 
server but under mod_wsgi and apache2 (the stock ubuntu setup), we get a 500 
after a long wait with this message in the apache error logs:

[Mon Feb 14 20:09:50 2011] [error] Exception KeyError: 
KeyError(139916416284480,) in <module 'threading' from 
'/usr/lib/python2.6/threading.pyc'> ignored
[Mon Feb 14 20:10:16 2011] [error] [client 76.25.16.198] Premature end of 
script headers: test_wsgi.py

Original comment by perrygeo...@gmail.com on 14 Feb 2011 at 8:27

[GoogleCodeExporter]

Original comment by perrygeo...@gmail.com on 14 Feb 2011 at 8:50

[GoogleCodeExporter]

After some epic debugging, I think I've traced the problem to a threading issue 
at the C++ level in mapnik ... the load_map function is not fully 
thread-safe(?). Luckily there is a workaround: load the mapfile into a string 
and load the xml string directly. Unfortunately this borks the relative paths 
in your mapfile. The practical implication is that the mapfile must contain 
full paths to each data source so it'll have to be tweaked for every 
installation. but we'll have to live with it until we fix mapnik itself. 

Sharing permissions are in place. Because a user could technically request a 
mixed bag of features, some of which were accessible but some of which they 
lacked permissions, I decided to just silently ignore the inaccessible ones 
rather than error out the entire request. May want to change this to more 
strict behavior?

Styling is going to be tricky. There's no robust way to translate a feature's 
kml_style into a mapnik style object so I am leaning towards another feature 
property, mapnik_style, which returns a mapnik style object (which may be risky 
passing around mapnik objs given the threading difficulties). We'll see..   

Original comment by perrygeo...@gmail.com on 15 Feb 2011 at 4:23

• Added labels: PercentComplete-50

[GoogleCodeExporter]

http://lists.berlios.de/pipermail/mapnik-devel/2007-September/000289.html ?

Original comment by underbluewaters on 15 Feb 2011 at 5:16

[GoogleCodeExporter]

Yeah I haven't tried recompiling mapnik. To be honest, I think it's probably 
more user-friendly to just assume the default mapnik installation and change 
the absolute paths in the mapfile vs. writing python code that assumes certain 
compile flags in the underlying c++ lib. 

Original comment by perrygeo...@gmail.com on 15 Feb 2011 at 6:11

[GoogleCodeExporter]

Added mapnik_style classmethod to spatial features to allow styling control. 
the classmethod must return a mapnik style object (appears threadsafe for now)

 For better or worse this is completely seperate from the kml_style property so you'll have to style each representation seperately

Original comment by perrygeo...@gmail.com on 17 Feb 2011 at 4:09

• Changed state: Fixed