00:00:41 *** wonderchook has quit (Remote host closed the connection) 00:15:47 *** tcarobruce has quit (Quit: tcarobruce) 00:32:32 *** cgs_bob has quit (Ping timeout: 246 seconds) 00:36:15 *** luneff has quit (Quit: Leaving) 01:11:16 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 01:56:16 *** haoyu (~bhy@cm144.delta24.maxonline.com.sg) has joined #mapnik 02:06:15 *** jctull has quit (Quit: jctull) 03:04:33 *** jctull (~jctull@adsl-75-0-29-113.dsl.renocs.sbcglobal.net) has joined #mapnik 03:05:37 *** springmeyer (~springmey@209.133.114.31) has joined #mapnik 03:11:59 <hesco> The map I generated last night with with some patient assistance from springmeyer has whetted my appetite. Now I'd like to apply what I've learned so far and add cairo to the mix. My sample code is here: http://dpaste.com/177959/. But it is throwing errors reported here: http://dpaste.com/177960/. Can anyone here offer some guidance for a python newbie about how to untangle that and make this work, please? I'm guessing I have the wro 03:11:59 <hesco> arguments here, but this seems a faithful adaptation of what I've read at: http://trac.mapnik.org/wiki/MapnikRenderers What might be missing, please? 03:13:37 <springmeyer> hesco: you need to re-compile mapnik with support for pycairo 03:14:09 <hesco> I installed from apt-get, are you saying I should build this from source, instead, then? 03:14:27 <springmeyer> installed mapnik from apt-get or cairo? 03:14:37 <hesco> both, I am pretty sure. 03:14:50 <springmeyer> what debian/ubuntu version? 03:14:57 <springmeyer> also server or desktop? 03:16:35 <hesco> Lenny 5.0, on a RSC xen instance, server. 03:19:03 <hesco> RSC = Rack Space Cloud 03:20:11 <springmeyer> sudo apt-get install python-cairo 03:20:20 <springmeyer> ah, nm, sorry 03:20:43 <springmeyer> ya, the mapnik package must not have been compiled with python-cairo support 03:21:03 <springmeyer> Lenny 5.0 I would guess only has mapnik 0.5.1 03:21:04 <hesco> ok, should I start over and install from source then? 03:21:09 <springmeyer> yes 03:21:20 <hesco> pursuing that next. Thanks. 03:22:13 <springmeyer> http://trac.mapnik.org/wiki/DebianInstallation 03:23:15 <nikq> Mapnik Trac: DebianInstallation edited | http://trac.mapnik.org/wiki/DebianInstallation?version=9 03:39:03 *** c_lopez (~ccaarloos@189.169.37.202) has joined #mapnik 03:46:06 *** springmeyer has quit (Quit: springmeyer) 04:00:03 <hesco> know you are gone for the moment, but thanks springmeyer. That did the trick. compiling took forever, but it worked. 04:04:04 <hesco> I'm closing in on this now. my next step is to sort out which layers I should apply in what order. It would be nice to see the street names labeled, for instance. http://dpaste.com/177959/ shows my script in progress. Is there some guide to understanding the TIGET shape files, and what order they ought to be applied in? 04:04:43 *** waldemarq (~waldemarq@189.169.37.202) has joined #mapnik 04:23:50 *** mperry has quit (Quit: mperry) 04:27:44 *** c_lopez has quit (Ping timeout: 246 seconds) 04:29:58 *** springmeyer (~springmey@209.133.114.31) has joined #mapnik 04:34:32 *** springmeyer has quit (Client Quit) 04:43:03 *** c_lopez (~ccaarloos@189.169.37.202) has joined #mapnik 07:26:47 *** luneff (~yury@154.53.117.87.donpac.ru) has joined #mapnik 09:33:07 *** gavinf has quit (Read error: Connection reset by peer) 09:46:14 *** c_lopez has parted #mapnik (None) 09:46:28 *** c_lopez (~ccaarloos@189.169.37.202) has joined #mapnik 09:47:07 *** c_lopez has parted #mapnik (None) 09:49:04 *** waldemarq has quit (Ping timeout: 258 seconds) 11:08:25 *** StormTide has quit (Ping timeout: 248 seconds) 11:10:15 *** StormTide (~StormTide@2002:186c:64c0:0:21d:60ff:fe5e:cf66) has joined #mapnik 11:31:03 *** gavinf (~gavinf@196.211.119.210) has joined #mapnik 11:42:56 *** Genscher (~Richard@dslb-188-099-085-047.pools.arcor-ip.net) has joined #mapnik 12:08:34 *** gavinf has quit (Quit: gavinf) 12:09:00 *** gavinf (~gavinf@196.211.2.133) has joined #mapnik 12:37:39 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 12:47:18 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 13:08:02 <dkb> artem: could I ask question about hillshading as outlined in http://trac.mapnik.org/ticket/259 ? 13:08:18 <artem> sure, you can 13:09:18 <dkb> am I correct that you created different tif files for different zoom levels to avoid Mapnik from doing the scaling itself? 13:10:06 <artem> dkb: it was Marcin behind #259 13:10:07 <nikq> Ticket #259: Hill Shading support, http://trac.mapnik.org/ticket/259 13:11:07 <dkb> yes, sorry see that.. is that what it sounds like to you? 13:11:16 <artem> dkb: scaling shouldn't be a problem, the easiest way would be to create tiffs with overviews and access them with gdal.input 13:12:31 <dkb> I have not used gdal.input before, is there some reference material on that? 13:15:01 <artem> there is some http://trac.mapnik.org/wiki/GDAL 13:15:40 <artem> but consult gdal site on how to convert SRTM into TIFFs 13:16:46 <dkb> I have sample SRTM/hgt file converted to projection mapnik uses already 13:17:56 <dkb> How does the new overview support in mapnik 0.7.0 fit into this? 13:17:57 <artem> but you might want to merge multiple SRTM files into bigger tiff, right ? 13:18:32 <dkb> yes, I need to merge multiple files but haven't gotten there yet. I wasn't sure how to handle that when I wanted to cover the entire US. 13:18:45 <artem> overviewes (which is gdal specific feature) allows for fast rendering of large rasters by having a pyramid internally 13:19:13 <artem> dkb: gdal_merge should do the trick 13:19:39 <artem> alternatively have a look at VRT datasets -> gdal.org 13:20:25 <dkb> is that reasonable to merge all the tifs for the entire US? 13:20:50 <artem> also, for very big tiffs ensure that libtiff has "BigTIFF" support ! 13:21:04 <artem> yes 13:21:42 <artem> dkb: or you can split US into dozen or so tiles 13:23:23 <dkb> and I will use the RasterSymbolizer to specify the tif that is created. 13:29:26 <dkb> I'm using Dane's Mapnik framework on Mac OS X and i 13:29:41 <dkb> ts telling me 'gdal' in c.plugin_names() is false 13:34:29 <artem> dkb: better ask Dane, I'd expect gdal.input in os x installer. 13:35:06 <artem> have you tried 0.7.1 ? 13:35:26 <dkb> His ReadMe states it is supported and simply requires the GDAL framework from kyngchaos which I have as well so I will investigate further. 13:35:39 <dkb> Yes, I have 0.7.1 on OS X and a ubuntu 9.10 server 13:35:55 <artem> it might be the order you installed them ?? 13:36:59 <dkb> ah, I bet I didn't add the path to the gdal framework in my bash profile 13:37:41 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 13:40:22 <dkb> still doesn't work, have to look at it later.. thanks 14:24:11 *** luneff has quit (Quit: Leaving) 14:42:13 *** Noeve (~Quentin@87-194-112-220.bethere.co.uk) has joined #mapnik 14:43:22 *** wonderchook (~wondercho@streamline116.sjccnet.com) has joined #mapnik 14:44:01 <Noeve> Hey everyone. I have a question regarding the correct terminology for two different map projections. I don't have a background in the area, and would love some help. My first projection takes a plane and projects it onto a hemisphere, with my projection point at infinity - is this an orthographic projection ? My second starts from the hemisphere and projects back onto the plane, this time with viewpoint a finite distance away, such that proje 14:44:01 <Noeve> ction lines ( if I may call them that ) are only normal to the plane in the centre of the hemisphere, and not elsewhere. Is this an example of an azimuthal projection ? 15:24:57 <nikq> Mapnik Trac: Ideas/Compositing edited | http://trac.mapnik.org/wiki/Ideas/Compositing?version=2 15:32:04 *** xreal (~mweber@mailgw.FB12.Uni-Dortmund.DE) has joined #mapnik 15:32:22 <xreal> Another question to OSM support: Do I still need "easy_mapnik" or can Mapnik read osm-files directly like a shapefile? 15:34:59 <artem> Noeve: http://en.wikipedia.org/wiki/Map_projection 15:35:17 <Noeve> artem, thanks, I've read that several times. 15:36:15 <artem> xreal: mapnik can read *.osm file directly using osm.input but it might be not suitable for you - depends on your requirements 15:37:22 <dkb> artem: download page for latest source references 0.7.0 http://mapnik.org/download/ 15:37:28 <xreal> artem: I want to render from it like from a shapefile ;-) 15:37:58 <artem> dkb: thanks, I'll fix that 15:38:19 *** wonderchook has quit (Remote host closed the connection) 15:39:23 <artem> dkb: done\ 15:40:24 <artem> xreal: depending on complicated your map styles are, it might be solution for you. 15:40:32 <artem> on how complicated 15:40:59 * artem really has to run now , bbl 15:41:40 <dkb> xreal: I read a while ago you were doing benchmarks on osm2pgsql, did you post that info anywhere? 15:45:04 *** artem has quit (Quit: artem) 15:45:12 <xreal> artem: Okay, I'll try it on Linux, since there is no input.osm on Windows. Oh, he's gone ;-( 15:45:33 <xreal> dkb: Yes, but we switched to hstore, this is MUCH better. I'll post these results soon. 15:45:52 <xreal> I just tried hstore on Windows - it works. 15:45:54 <xreal> jburgess, are you here? 15:46:05 <dkb> If you want there is a page you can list it at: http://wiki.openstreetmap.org/wiki/Osm2pgsql_benchmarks 15:46:35 <xreal> Ah, very nice. I'll do that after Eastern. 15:46:51 <dkb> xreal: was the import time longer with hstore? 15:52:53 <xreal> dkb: There's a small bug in the code. It crashed when importing the planet. 15:53:06 <xreal> Some kind of hardcored values, which will be fixed in the next days. 15:53:16 <xreal> After that, I'll be doing benchmarks. 15:53:23 <xreal> it works on Windows, I need to inform jburgess about that. 15:53:47 <xreal> I hope, input.osm will work on Windows someday. That would be a timesafer for many osm-users. 15:53:54 <xreal> timesaver* 16:06:18 <xreal> dkb: Since hstore is importing all the data, it's hard to do a comparism. 16:06:43 <xreal> But I could create a default.style which imports the same tags for the old scheme. 16:07:30 *** tcarobruce (~tim@209.133.114.31) has joined #mapnik 16:09:37 <dkb> xreal: question might be more along the lines if someone was using unmodified default.style and decided to use hstore instead 16:10:11 *** jctull has quit (Quit: jctull) 16:10:47 <xreal> dkb: You need a new default.style for it, but it's pretty simple. It was developed to contain ALL the data. Since you only need one DB then and no osmosis-scheme. 16:11:17 <xreal> As soon as it's running stable, it would be easy to change it, I think. 16:11:34 <xreal> Let me import something bigger, I could give you first results then. 16:11:58 <dkb> It was 50 hours for me to do planet with default.style 16:12:10 *** wonderchook (~wondercho@209.133.114.31) has joined #mapnik 16:12:18 <xreal> dkb: On non-hstore? 16:12:23 <dkb> correct 16:13:11 <xreal> I could try this on my system over the holidays ;-) 16:14:45 *** cgs_bob has quit (Ping timeout: 265 seconds) 16:19:40 <dkb> does someone know if the Mapnik build system is responsible for building the input plugins for Mapnik? 16:19:54 *** tcarobruce has parted #mapnik (None) 16:24:36 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik 16:30:06 *** springmeyer (~springmey@209.133.114.31) has joined #mapnik 16:35:46 <dkb> springmeyer: suggestion for Mapnik Framework installer ReadMe for OS X; the kyngchaos frameworks need to be installed before the Mapnik framework is installed otherwise it doesn't install the input plugins such as gdal. 16:35:51 *** jctull (~jctull@75.0.4.106) has joined #mapnik 16:36:43 <springmeyer> dkb: does anyone read readmes? 16:37:42 <dkb> I did :p and it mentions the support for the kyngchaos frameworks but doesn't mention the importance of order of installation 16:43:12 * springmeyer adds to Quickstart section.... 16:43:13 <springmeyer> ⢠First install the Kyngchaos Frameworks 16:43:13 <springmeyer> - Proj4 is required 16:43:14 <springmeyer> - GDAL, SQLite are required for plugins 16:44:10 * springmeyer changes the "Optional" section title to.... 16:44:14 <springmeyer> Datasource Plugin Requirements 16:44:18 <springmeyer> that make sense? 16:45:01 <dkb> yes, hopefully that will save time for someone else in the future :D 16:45:11 <dkb> Thanks 16:45:21 <springmeyer> np 16:45:35 <springmeyer> likely the best solution is to actually provide the plugins as separate installers 16:45:50 <springmeyer> that have a specific check for deps with message,etc 16:46:00 <springmeyer> thats what I'm planning in the future anyway 16:46:14 *** haoyu has quit (Ping timeout: 240 seconds) 16:46:23 <springmeyer> just was easiest to have the plugins in the same installer for now (they just get disabled if deps are not found) 16:46:38 <springmeyer> and the pro of that is that plugins are less likely to get out of sync 16:47:06 <dkb> I resorted to using Pacifist to look what was in the Mapnik package and saw the plugins there so thought it must have been checking for the dependency and not installing otherwise 16:47:36 <springmeyer> dkb: yes that is what it does 16:47:44 <springmeyer> if you go back to the installer and re-install 16:47:52 <springmeyer> you would see that the GDAL plugin is listed 16:48:03 <springmeyer> and will be greyed out if GDAL framework is not found 16:48:15 <springmeyer> and clicking on the grayed out item will give more info 16:48:30 <dkb> that sounds like a good plan 16:48:37 <dkb> there is no issue with using GDAL 1.7 and the input plugin included with mapnik, correct? 16:48:43 <springmeyer> well, thats the way it alwasy worked 16:49:03 <springmeyer> Mapnik 0.7.0 installer requires GDAL 1.6 16:49:09 <springmeyer> Mapnik 0.7.1 installer requires GDAL 1.7 16:50:36 <dkb> I did not notice the greyed out gdal plugin when installing mapnik initially, but obviously must have missed it or not realized I would need to reinstall mapnik if I needed the gdal plugin in the future 16:52:37 <springmeyer> gocha 16:58:13 <xreal> Hey, anyone interested in first results? 16:58:26 <xreal> I've imported a small area of Germany. 16:58:43 <xreal> I've run it three times. 16:58:49 <xreal> hstore (with all tags) => 3 minutes 16:58:56 <xreal> standard scheme => 3,5 minutes 16:59:00 *** ajturner has quit (Quit: Zaijian!) 16:59:04 *** Noeve has parted #mapnik ("Leaving") 16:59:13 <xreal> hstore is much faster here and contains all tags. 16:59:21 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik 17:02:21 *** ajturner has quit (Client Quit) 17:02:41 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik 17:04:41 <dkb> xreal: what was the db size difference? 17:05:10 *** ajturner has quit (Client Quit) 17:05:47 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik 17:07:22 <xreal> dkb: It's way bigger, of course. 17:07:32 <xreal> But you can blacklist tags in default.style. 17:07:44 <xreal> I would like to whitelist them, I've already written to the programmer. 17:07:55 <xreal> I am currently writing a blacklist script, which does this automatically. 17:14:19 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 17:15:59 *** springmeyer has quit (Quit: springmeyer) 17:25:40 *** wonderchook has quit (Remote host closed the connection) 17:26:13 *** ajturner has quit (Quit: Zaijian!) 17:37:22 <xreal> Gnaaaaaaar. tag-length in default.style are limited to 24 chars. 17:38:55 *** springmeyer (~springmey@209.133.114.31) has joined #mapnik 17:42:35 <xreal> Also escaping is not supported. 17:50:42 <xreal> Script is done. 17:56:20 *** tcarobruce (~tim@209.133.114.31) has joined #mapnik 18:01:17 <xreal> Benchmarking is done! 18:02:31 <xreal> time for normal import ("old" osm2pgsql scheme): 00:03:29 18:02:32 <xreal> time without blacklist (hstore with all tags): 00:03:02 18:02:32 <xreal> time with a blacklist (hstore with blacklist): 00:03:03 18:02:32 <xreal> entries and blacklist: 375 (I left out everything, not in standard 18:02:32 <xreal> default.style) 18:02:43 <xreal> hstore is faster. 18:02:49 <xreal> Even with string comparism. 18:11:27 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik 18:24:26 *** Genscher has quit (Quit: Leaving) 18:42:57 *** msimard (~msimard@69-165-173-111.dsl.teksavvy.com) has joined #mapnik 18:43:20 *** wonderchook (~wondercho@209.133.114.31) has joined #mapnik 18:45:03 <msimard> I have an issue with tilecache using mapnik and a simple shapefile. All polygons show up at zoom level 0...but when I zoom in the result becomes chaotic...There are missing polygons at a level where there was plenty just a zoom level before... 18:45:26 <msimard> Anybody here got issues that looked alike? 18:56:13 *** wonderchook has quit (Remote host closed the connection) 18:58:03 <springmeyer> msimard: you likely need to clip your shapefile to valid extents 18:58:25 <springmeyer> as that can happen when the data has invalid coordinates for your target projection - common with web mercator 18:58:51 <springmeyer> msimard: do you have gdal/ogr utilities installed? 19:01:42 <msimard> But, by actual shape does not exceed the upper limit of mercator. I've experienced that kind of problems in the past. Now, it's just unrelated to anything I've seen before. The shape show properly...until I zoom in... 19:02:07 <msimard> I mean, it does not seem related to the mercator upper bound problem 19:09:21 *** Genscher (~Richard@dslb-188-099-085-047.pools.arcor-ip.net) has joined #mapnik 19:11:30 *** cgs_bob has quit (Remote host closed the connection) 19:11:55 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 19:17:13 <msimard> springmeyer, Could it be related to the fact that I try to convert just in time a shapefile in NAD83 to mercator? 19:18:15 <springmeyer> msimard: yes 19:18:35 <springmeyer> it is the failure of proj_transform when invalid coordinates problems show up 19:18:51 <springmeyer> otherwise invalid coordinates don't matter much 19:19:24 <springmeyer> so, msimard try reprojecting from NAD83 to mercator ahead of time using ogr2ogr 19:19:32 <springmeyer> and see if ogr2ogr throws warnings 19:19:55 <msimard> springmeyer, ok I'll try that! Thanks for the help! 19:26:35 *** waldemarq (~waldemarq@189.161.104.92) has joined #mapnik 19:29:31 *** springmeyer has quit (Quit: springmeyer) 19:29:57 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik 19:29:58 *** Ldp__ is now known as Ldp 19:42:39 *** springmeyer (~springmey@209.133.114.31) has joined #mapnik 19:48:57 <nikq> Mapnik Trac: OutputFormats edited | http://trac.mapnik.org/wiki/OutputFormats?version=7 19:58:04 *** ajturner has quit (Quit: ajturner) 20:00:04 *** tcarobruce has quit (Quit: tcarobruce) 20:01:15 <msimard> springmeyer, well I reprojected to mercator using ogr2ogr (ogr2ogr -t_srs EPSG:900913 -s_srs EPSG:4269 test.shp MRC_BDAT_100K_2010.shp)...But still I get shapes that don't get displayed at all zoom levels 20:03:50 *** luneff (~yury@209.61.117.87.donpac.ru) has joined #mapnik 20:04:43 <msimard> springmeyer, And I just tested it works in tilelite :p 20:17:46 <msimard> I guess I'm going to adapt tilelite to render multiple distinct shapefiles since tilecache fails to produce any usable results... 20:20:54 <hesco> I'm closing in on this now. my next step is to sort out which layers I should apply in what order. It would be nice to see the street names labeled, for instance. http://dpaste.com/177959/ shows my script in progress. Is there some guide to understanding the TIGER shape files, and what order they ought to be applied in? 20:22:55 *** springmeyer has quit (Quit: springmeyer) 20:39:56 <xreal> Seems like osm2pgsql can't handle 1700 lines in default.style ;-( 20:41:00 <Ldp> are you stress testing it? 20:42:57 <xreal> Nope, I'm testing hstore performance. It only has a blacklist, not a whitelist. 20:43:06 <xreal> hstore is _much_ faster even in inserting. 20:43:15 <xreal> at* 20:44:34 <xreal> It cannot handle tags longer than 24 chars (seems to be hardcoded) 20:44:39 <xreal> and quoting doesn't work when spaces are inside 20:44:46 <xreal> "medical area" 'medical area' 20:45:51 <Ldp> better open some tickets for those issues 20:46:13 <Ldp> especially the 24 char limit. People have run into that before 20:46:52 <xreal> 1200 lines is working 20:50:26 *** jburgess has quit (Ping timeout: 276 seconds) 20:55:09 <xreal> gnar ... lines seem to be hardcoded to 1000 ............ 20:58:45 *** tcarobruce (~tim@209.133.114.31) has joined #mapnik 20:59:46 *** msimard has quit (Ping timeout: 260 seconds) 21:06:16 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik 21:23:10 <xreal> bye 21:23:14 *** xreal has quit () 21:32:18 *** bitterman (~yury@93.178.95.97) has joined #mapnik 21:35:59 *** luneff has quit (Ping timeout: 276 seconds) 21:45:07 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 21:46:32 *** ojw (~ojw@78-86-37-93.zone2.bethere.co.uk) has joined #mapnik 21:56:19 <dkb> Would anyone happen to know why when I use <CssParameter name="fill-opacity">0.2</CssParameter> 21:56:19 <dkb> for a PolygonSymbolizer rule of the "world" style name all land areas turns into a checkerboard pattern instead of the fill color? 21:56:40 *** waldemarq has quit (Quit: ããããªã) 21:59:10 <Ldp> dkb: that *is* the fill colour 21:59:39 <Ldp> the land mass in the shapefile (assuming the regular OSM shapefiles) is built up of overlapping rectangles 22:00:28 <dkb> ahh, right.. that makes sense 22:00:31 *** darth_bitterman (~yury@93.178.95.97) has joined #mapnik 22:02:17 <dkb> is it mixing the Map bgcolor and world style? 22:02:54 <dkb> (when I had the opacity not 1 for world style) 22:03:52 *** bitterman has quit (Ping timeout: 258 seconds) 22:03:58 <Ldp> when opacity != 1, of course it's mixing colours 22:05:10 *** Genscher has quit (Quit: Leaving) 22:09:58 <dkb> Along those lines, is using Cascadenik more maintainable with complex styles then the standard osm.xml and entities? 22:12:36 <Ldp> I don't know. cmarqu might be able to answer that one 22:16:02 <dkb> Thanks for the assistance in any case. 22:25:25 *** ajturner has quit (Quit: ajturner) 22:27:45 *** ojw has quit (Remote host closed the connection) 22:33:54 *** artem has quit (Quit: artem) 22:39:08 *** tcarobruce has quit (Quit: tcarobruce) 22:44:44 *** Ldp has quit () 23:16:17 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik 23:16:21 *** spone (~5d017f58@gateway/web/freenode/x-tdywcxuyefjffxhx) has joined #mapnik 23:16:24 <spone> hi 23:17:08 <spone> I try to generate a png using a fresh mapnik/cascadenik install 23:17:30 <spone> and I get the following error message : "No module named cascadenik" 23:17:37 <spone> anyone have a clue? 23:22:10 <darth_bitterman> python path? 23:32:10 <spone> should I add the cascadenik path to PYTHONPATH also? 23:33:24 *** spone has quit (Quit: Page closed) 23:40:06 *** Spone (~5d017f58@gateway/web/freenode/x-blnjjhdtfdjcvutw) has joined #mapnik 23:40:16 <Spone> I just added the cascadenik path 23:40:20 <Spone> same problem 23:40:44 <Spone> mmm, to "install" cascadenik, I just need to download and unzip it 23:40:56 <Spone> or are there some operations before use? 23:46:29 *** tcarobruce (~tim@209.133.114.31) has joined #mapnik 23:47:10 <Spone> darth_bitterman? 23:47:30 <darth_bitterman> just a moment 23:48:41 <darth_bitterman> actually, i don't know what cascadenik is. all i can say is you need to have "python\version\site-packages" in your PYTHONPATH 23:49:10 <Spone> mmm ok 23:50:21 <darth_bitterman> hm 23:50:30 <darth_bitterman> http://wiki.openstreetmap.org/wiki/Cascadenik says that everything is simple 23:56:28 *** darth_bitterman has quit (Quit: Leaving)