00:04:26 *** D3f0 has quit (Remote closed the connection) 00:17:06 *** ninja_ (n=pankur@nat/yahoo/x-73f65b072567ea43) has joined #mapnik 00:22:13 *** cmarqu (i=colin@oemcomputer.oerks.de) has joined #mapnik 01:06:46 <dukeku> does trac have support for talk pages? 01:27:50 *** kunitoki has quit ("Lost terminal") 01:28:56 <springmeyer> dukeku: you mean like media wiki? 01:29:08 <springmeyer> I'm not sure but if you find anything I can try to install 01:33:39 <dukeku> nah, don't sweat it 01:34:17 <dukeku> i did a mapnik install on a fresh copy of ubuntu and found a bunch of libs that were listed were unneeded as they were implied by deps 01:34:29 <dukeku> didn't want to edit anything out, as it's better to be verbose 01:34:31 <springmeyer> trac.mapnik.org/wiki/DukekuTalks :) 01:35:10 <springmeyer> ah, well I went with the verbose route in trac once 01:35:22 <dukeku> just spent a few hours on getting a new ubuntu install going on my main computer 01:35:24 <springmeyer> ... trying to get a handle on things as i learned about apt 01:35:31 <springmeyer> thats great 01:35:32 <dukeku> because my gis box died apparently...but after 2 restarts it's ok again 01:35:38 <springmeyer> thats not 01:35:50 <dukeku> and my wireless signal strength in ubuntu is about 1/5th of what it is in windows 01:36:01 <dukeku> springmeyer: most definitely, it died when i _really_ needed it 01:36:02 <springmeyer> so dukeku: please edit to be less verbose I'd say 01:36:05 <dukeku> can do 01:36:12 <dukeku> i saved a list of what wasn't needed 01:36:26 <springmeyer> cool cool 01:36:31 <dukeku> at work i noticed the postgres includes don't work anymore, i'll edit those in once i'm back in ubuntu 01:36:46 <springmeyer> ya, so you building with mapnik trunnk? 01:36:55 <dukeku> yeah, with pq 01:40:35 <dukeku> i have a feeling NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl isn't supported by proj4 01:42:08 <crschmidt> dukeku: http://spatialreference.org/ref/esri/102326/proj4/ 01:42:22 <dukeku> heh, was just searching for that 01:42:23 <dukeku> thanks :)\ 01:42:30 <crschmidt> EPSG:2913 01:42:51 <crschmidt> sorry, 102326 isn't right 01:42:55 <crschmidt> that's in meters, not fet 01:43:07 *** D3f0 (n=defo@190.176.194.209) has joined #mapnik 01:43:18 <crschmidt> 2913 is right though 01:44:11 <dukeku> muchos gracias 01:45:03 <springmeyer> k, ya I've been seriously mucking with the Scons build scripts so a few things have changed 01:45:03 <springmeyer> please let me know if you run into any problems 01:45:03 <springmeyer> ninja_: you get your '%'/ regex stuff figured out with mapnik trunk? 01:45:03 <springmeyer> if not please file a ticket 01:45:03 * springmeyer saw nick ask on the mailing list about something that sounded similar 01:45:08 <springmeyer> I'd ask in #gdal sometime about that 01:45:25 <ninja_> hey springmeyer ! nah i tried still couldnt get it to work 01:45:34 <ninja_> the funny thing is no one else seems to have this problem 01:45:55 <dukeku> springmeyer: can do 01:46:02 <ninja_> and it was working when i checked out code and build mapnik libs sometime last year 01:46:26 <dukeku> heh, i got some data from the city of portland, kind of wish i had asked for more 01:46:38 <dukeku> was free because i'm a student - but i don't wanna turn around and ask for a ton more 01:46:46 <dukeku> only took up 20mb on the CD they gave me :) 01:47:37 <springmeyer> ninja_: do you know others using regex? 01:48:51 <ninja_> ah i think i know why thats happening did you just say ask #gdal ? which would mean that regex stuff has a dependency on gdal ? 01:49:10 <ninja_> i was under the impression its implemented using boost.regex 01:49:27 <springmeyer> no, that was directed at dukeku re his proj4 question 01:50:01 * springmeyer has not used regex with mapnik filters, so is fairly clueless there... :( 01:50:01 <ninja_> aha *confused* sorry my bad 01:51:04 <ninja_> will file a ticket 02:01:54 <dukeku> anyone have an idea what these types would be? not sure if there's a set standard or anything...getting them from street data 02:01:57 <dukeku> type 02:01:57 <dukeku> ------ 02:01:57 <dukeku> 1110 02:01:57 <dukeku> 1121 02:01:59 <dukeku> 1122 02:02:02 <dukeku> kand so on 02:02:04 <dukeku> s/kand/and/ 02:05:26 <crschmidt> Those types are likely to be specific to your data type 02:05:31 <dukeku> that's what i figured 02:05:38 <crschmidt> I would search for documentation from the provider. 02:13:27 <dukeku> heh, i can't get mapnik to render anything using the 2913 srs 02:24:30 *** aub_ has quit () 02:49:55 *** aub (n=aubrey@static-70-107-236-83.ny325.east.verizon.net) has joined #mapnik 03:26:41 <dukeku> springmeyer: around? 03:28:11 <dukeku> nevermind, figured it out 03:28:26 <dukeku> every time i start to ask a question i figure it out a lot quicker than if i'd just started looking anyways 03:32:26 <springmeyer> dukeku: what did you figure out? :) 03:33:42 <dukeku> filters in python :P always done them in xml 03:34:20 <dukeku> speaking of filters, is there any way to do the equivalent of >=? 03:40:42 <springmeyer> dukeku: yes... http://trac.mapnik.org/wiki/Filter 03:44:54 <dukeku> bleh, missed that the first time around 04:22:27 *** rcoup has quit () 05:45:25 *** dukeku_ (i=dukeku@adhd.irule.net) has joined #mapnik 05:45:52 *** dukeku_ has quit (Client Quit) 07:01:58 *** weizhuo has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.20/2008121709]") 07:41:49 *** xcacou (n=aga@AToulouse-157-1-165-31.w83-193.abo.wanadoo.fr) has joined #mapnik 08:30:24 *** kunitoki (n=kraken@host210-49-dynamic.7-79-r.retail.telecomitalia.it) has joined #mapnik 08:52:40 *** __d3f0__ (n=defo@190.176.202.95) has joined #mapnik 08:57:32 *** D3f0 has quit (Read error: 60 (Operation timed out)) 09:01:24 *** d3f0 (n=defo@190.176.201.121) has joined #mapnik 09:06:26 *** __d3f0__ has quit (Read error: 60 (Operation timed out)) 09:14:12 *** __d3f0__ (n=defo@190.176.201.89) has joined #mapnik 09:19:39 *** d3f0 has quit (Read error: 60 (Operation timed out)) 09:52:33 *** __d3f0__ has quit (Remote closed the connection) 10:57:15 <kunitoki> the roads.shp in mapnik/demo/data... which SRID it have ? 11:14:58 *** Quelbs (n=Quelbs@146.107.217.191) has joined #mapnik 11:19:24 *** Quelbs has quit () 11:27:01 <kunitoki> jburgess: have you got the chance to try the latest sqlite input plugin 11:27:04 <kunitoki> ? 11:27:29 <kunitoki> i mean, with the changes about the r*tree index usage added by artem 11:28:09 <kunitoki> i tried loading a shapefile and index it with spatialite r*tree but the indexed mbr is wrong 11:28:18 <kunitoki> ymax is always 0.0 11:28:25 <kunitoki> so i think is a problem of spatialite 11:30:09 <nikq> Mapnik Trac: PluginArchitecture edited | http://trac.mapnik.org/wiki/PluginArchitecture?version=8 12:03:26 <nikq> Mapnik Trac: SQLite created | http://trac.mapnik.org/wiki/SQLite?version=1 13:13:36 <nikq> Mapnik Trac: SQLite edited | http://trac.mapnik.org/wiki/SQLite?version=2 13:25:05 <nikq> Mapnik Trac: SQLite edited | http://trac.mapnik.org/wiki/SQLite?version=3 13:42:20 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 13:43:27 *** TomH1 (n=tom@gate.compton.nu) has joined #mapnik 13:47:43 <kunitoki> artem: got a chance to test your stuff 13:47:57 <kunitoki> but now i'm unable to visualize any data 13:48:21 <kunitoki> i think r*tree in idx_table_geometry tables generate wrong mbr (spatialite problem) 13:48:39 <artem> are you on 2.3 ? 13:48:52 <kunitoki> yeah 13:49:01 <artem> I had problems with Mbr on 2.2 13:49:16 <kunitoki> if i loadshp roads from demo (mapnik/demo/data/roads.shp) 13:49:21 <artem> but 2.3 works fine. Also, what version of GEOS are you using? 13:49:45 <kunitoki> it loads a spatial index witn maxy = 0.0 13:50:07 <kunitoki> (geos 3.0.0) 13:50:16 <kunitoki> anyway now i tried with my data 13:50:16 <artem> yep, this is what I had on 2.2 - but I suspect GEOS :) 13:50:35 <artem> try using geos 3.0.3 + spatialite 2.3 13:50:47 <kunitoki> ok 13:51:07 <kunitoki> anyway last patches i sent to you was working perfectly here with the demo data 13:51:33 <kunitoki> now i always see bloank maps,but my features gets picked up ! 13:53:01 <kunitoki> i patched a little more your patches ;) 13:53:13 <artem> sure :) 13:53:43 <kunitoki> reading the spatialite docs, to make full use of the spatial index the spatial wuery to the index should be done in a sub-query not a join 13:55:02 <kunitoki> i changed that... also i refactorized from_wkb, now it takes a enum wkbFormat { wkbGeneric=1, wkbAutodetect=2, wkbSQLite=3 }; 13:55:20 <artem> yep, this will help with constructing final SQL (sub-query) 13:55:29 <artem> good stuff 13:55:52 <kunitoki> anyway wkbAutodetect is not supported but planned :) 13:57:18 <kunitoki> if only i can speedup the scons.... 13:57:36 <artem> yes, scons can be a pain 13:57:43 <kunitoki> most of my coding time is spent waiting scons to finish compile ONE file 13:57:58 <kunitoki> which is unacceptable 13:58:26 * kunitoki knows why he loves plain Makefiles even in 2009 14:01:24 <ninja_> hey guys . 14:01:28 <artem> kunitoki: I think scons doesn't cache config params in latest trunk. 14:01:58 <ninja_> i had a question , asked in the morning its about the regex filters 14:01:59 <artem> springmeyer: Does caching config (scons) works for you ? 14:02:19 <artem> ninja_: sure ? 14:02:54 <kunitoki> artem: well, most of the scons time is not in the configure step, but the time between "scons: Building targets ..." and the start of the compilation step... seconds 14:02:57 <ninja_> haha i spoke to springmeyer this morning , checked out the source from svn and suddenly my mod operator '%' in the xml gets an error 14:03:17 <ninja_> we couldnt figure it out was wondering artem if you have any insights into this 14:04:09 <ninja_> Configuration error: Failed to parse filter expression: 14:04:10 <ninja_> [POLYGON_ID] % 6 = 1 14:04:29 <ninja_> and this works on the older mapnik libraries i had built , 14:04:46 <ninja_> (older as in 0.5.1 ) but source checked out last year 14:05:41 <artem> libxml2 is a default xml parser and it doesn't like un-escaped chars ?? Ha, I don't remember implementing mod op ... let me check 14:05:53 <ninja_> yep i tried rebuilding with tinyxml 14:06:10 <ninja_> and % doesnt need to be escaped right ? 14:06:34 <ninja_> sure 14:07:48 <artem> I can't see how '%' worked in 0.5.1 as it's not referenced in filter parser ??? 14:07:54 <ninja_> hey kunitoki: scons -H i think you can make it use the cache config , springmeyer mentioned something about this yesterday 14:08:29 <ninja_> huh strange ! i could swear i have maps that have different colours for settlements due to the mod operator 14:14:15 <ninja_> http://tinypic.com/view.php?pic=2eb6fdf&s=5 14:14:36 <ninja_> see that all those colours for different neighborhoods 14:14:43 <ninja_> come from the mod operator 14:15:11 <ninja_> so the suburbs have a different colour to each other 14:22:41 <nikq> Mapnik Trac: wkb-format.patch attached to Ticket #223 | http://trac.mapnik.org/attachment/ticket/223/wkb-format.patch 14:23:25 <TomH1> ninja_: does http://pastebin.com/m76d9abb1 do the trick as far as implementing a % operator goes? 14:25:51 <ninja_> TomH1: let me rebuild etc will let you know how i go 14:25:54 <ninja_> thanks for that :) 14:26:31 <kunitoki> artem: spatialite-2.3 + geos-3.0.3 = the spatial index now works 14:27:18 <artem> great 14:32:33 <kunitoki> i don't see any clear difference, but my dataset for now is pretty small 14:45:19 <kunitoki> artem: any chance to get the write in the repository ? 14:45:25 <kunitoki> sorry write bit 14:45:31 <kunitoki> :D 14:45:51 <artem> kunitoki: sure, just send me your public key 14:45:59 <kunitoki> where ? 14:46:07 <artem> email 14:46:22 <kunitoki> ok 14:46:57 <kunitoki> mmmh what's your email 14:52:03 <artem> artem@mapnik.org 14:53:59 <kunitoki> artem: got mail 14:54:36 <artem> not yet 14:55:57 <artem> kunitoki: I'm going out for a couple hours, will add yourself then 14:56:05 <kunitoki> hey with demo data: using spatial index (real0m3.341s) - without index (real0m9.182s) 14:56:28 <kunitoki> that's pretty cool 14:56:38 <kunitoki> artem_ ok thanx 14:56:50 *** artem has quit ("no probs") 15:10:37 <nikq> Mapnik Trac: SQLite edited | http://trac.mapnik.org/wiki/SQLite?version=4 15:12:19 <nikq> Mapnik Trac: SQLite edited | http://trac.mapnik.org/wiki/SQLite?version=5 15:23:48 <ninja_> hey TomH1: that worked! 15:24:04 <ninja_> thanks a lot for that :) 15:24:33 <ninja_> was there any reason why this was removed? 15:30:00 <nikq> Mapnik Trac: SQLite edited | http://trac.mapnik.org/wiki/SQLite?version=6 15:32:02 <nikq> Mapnik Trac: SQLite edited | http://trac.mapnik.org/wiki/SQLite?version=7 15:39:29 <TomH1> ninja_: well artem doesn't seem to think it was ever there 15:39:43 <ninja_> hmm but it was right? 15:39:53 <ninja_> okay i am confused 15:40:18 <TomH1> what version do you think had it? 15:41:04 <ninja_> okay i just found the src for the library 15:41:12 <ninja_> the one that i used last year 15:41:21 <ninja_> i dint check it out from svn so not sure 15:41:26 <ninja_> but i can see mod in here 15:41:38 <ninja_> basically the stuff that you just asked me to do 15:42:04 <TomH1> so if you didn't get it from svn where did it come from? a released version? 15:42:08 <ninja_> yeah 15:42:14 <TomH1> which one? 15:42:17 <ninja_> 0.5.1 15:42:22 <ninja_> and 0.5.0 15:42:25 <ninja_> it was there in both 15:42:34 <ninja_> last year around feb /march 15:43:17 <TomH1> I've just downloaded 0.5.1 and I can't see it 15:43:48 <ninja_> hmm i am not sure whats changed but this is a back up i had from last year 15:44:02 <ninja_> yeah i downloaded 0.5.1 and i noticed its not there either 15:44:14 <ninja_> anyways let me know if you guys think it should be in there 15:44:40 <TomH1> doesn't seem to be in the official 0.5.0 or 0.5.1 releases so I don't know where you got that code from... 15:45:31 <ninja_> i have no clue .. i am super confident that i downloaded it off the site .. but i guess no one seems to have seen this before 15:45:45 <ninja_> so must've been from somewhere else 15:46:24 <ninja_> anyways its bed time here thanks again for your help TomH1 15:46:56 <nikq> Mapnik Trac: Changeset [883]: Add a modulus operator to the filter language. | http://trac.mapnik.org/changeset/883 15:49:17 <ninja_> okay this seems pretty old since it has only two developers in the AUTHORS list 15:49:24 <ninja_> as compared to the huge list there is today 15:49:38 <ninja_> i am sorry i am trying to find out some date, etc , in the source 15:49:43 <ninja_> cant seem to find anything 15:50:17 *** aled (n=chatzill@socksgw1.ncl.ac.uk) has joined #mapnik 15:51:04 <ninja_> anyways off to bed now 15:51:08 *** ninja_ has parted #mapnik () 15:52:01 <aled> hi, has anyone had mapnikserv or similar CGI scrips working on windows/IIS? 15:53:12 *** ninja__ (n=pankur@cm211.psi132.maxonline.com.sg) has joined #mapnik 15:53:37 <aled> I'm (still) getting garbled images even with simple maps, and have replicated on my other win machine 16:13:22 <CIA-23> mapnik: tom * r883 /trunk/include/mapnik/ (math_expr.hpp value.hpp filter_parser.hpp): Add a modulus operator to the filter language. 16:21:08 <nikq> Mapnik Trac: OCCI created | http://trac.mapnik.org/wiki/OCCI?version=1 16:23:58 <springmeyer> ninja__: that is really odd, but I'm relieved that TomH1 could help out! 16:24:32 <springmeyer> ninja__: regarding the AUTHORS list, yes I've updated it in trunk to reflect the community of committers and patch providers 16:25:16 <TomH1> we should probably adjust that list to reflect the fact that Dave Stubbs and Randomjunk are one and the same person ;-) 16:25:53 <springmeyer> ah! :) 16:26:28 * springmeyer has wondered who all the dave's were :) 16:26:37 *** D3f0 (n=defo@190.176.201.89) has joined #mapnik 16:26:47 * springmeyer will fix that now... 16:28:12 *** xcacou_ (n=aga@AToulouse-157-1-56-173.w86-207.abo.wanadoo.fr) has joined #mapnik 16:28:14 *** xcacou has quit (Read error: 110 (Connection timed out)) 16:32:32 <springmeyer> all: regarding SCons caching of dependencies, yes setting SCONS_CACHE=True will speed up the configure stage a bit, but kunitoki is experiencing slow builds 16:33:03 <springmeyer> I'm not aware of any changes affecting compile speeds, but I'll look into it. 16:33:19 *** ninja__ has quit () 16:34:38 <springmeyer> aled: I've never seen the garbled images you describe. Can you post a ticket with examples of how you are setting up the cgi scripts and what the images look like? 16:35:15 <springmeyer> aled: btw in trunk a method has been added for reading a mapfile from a string, which will be useful for your cgi work 16:46:35 *** xcacou_ has quit (Remote closed the connection) 16:47:25 <aled> cheers, writing one up now. that method'll be handy 16:48:18 *** TomH1 has quit ("Coyote finally caught me") 16:48:23 *** TomH (n=tom@gate.compton.nu) has joined #mapnik 16:48:58 <springmeyer> aled: cool 16:49:01 <springmeyer> aled: have you tried within apache on windows? 16:50:43 <aled> no, but agree that seems the next logical step in troubleshooting 16:51:59 <springmeyer> you could also run your script using a local httpserver in pure python - that would rule out the ill stuff too 16:52:54 <CIA-23> mapnik: dane * r884 /trunk/AUTHORS: Authors: Remove duplicate listing for Dave Stubbs 16:58:34 <kunitoki> springmeyer: here it is the fastest compile/link time ever seen (for single line change in 1 file of 3.5KB): http://pastebin.com/d24c1249a 16:59:08 <kunitoki> springmeyer: is there a way to compile a specific plugin only and not the complete trunk ? 16:59:59 <springmeyer> :) 17:00:01 <kunitoki> springmeyer: i will get a white beard before i can test my bugfixes to the code :) 17:00:01 <springmeyer> no, but I think it would be as easy as only running the SConstript for that plugin 17:00:12 <springmeyer> no! 17:01:00 <kunitoki> 40 seconds for a single line change is worse than have to wait the code to be checked in a subversion repository :) 17:01:24 <springmeyer> oh geez, I hear you. 17:01:36 <TomH> the problem is that scons doesn't separate the configure and build steps so you wind up having to reconfigure every time you build 17:01:49 <kunitoki> yeah that is a real drawback of using scons 17:02:32 <kunitoki> but most of the time... it hangs from 20 to 25 seconds here "scons: Building targets ... " 17:02:33 <springmeyer> and I've read through a variety of discussions on the SCons lists about people patching to make them more separate, but it seems it goes against the grain.. 17:03:36 <kunitoki> can we consider plan a build-framework change for 1.0.0 ? 17:05:06 <springmeyer> fine by me, but I'm still interested to find ways to speed up what we have 17:05:18 <kunitoki> take in consideration CMake for example ? scons can't even build a project for a IDE 17:05:57 <kunitoki> other build-frameworks doesn't build themselves, they are geared to output specific ide-projects/makefiles for the platforms 17:06:08 <TomH> If we're going to change it we should just use automake like everybody else.... I don't need to learn yet another obscure build system (scons was quite enough...) 17:06:20 <kunitoki> you started from the worse 17:06:29 <kunitoki> other build systems are far better from this 17:06:37 <kunitoki> from=than 17:07:06 <kunitoki> autotools practically are unmaintainable code in the long run 17:07:33 <kunitoki> i like them... but why write them by hand where another build system can do it simple and easy 17:07:35 <TomH> I'm sure they are all technically better, but they create barriers to entry - far more people know autotools than any of the other things and if use the full autotools stack then most of the horror of old style configure scripts is hidden 17:08:20 <kunitoki> sure i agree with you... would you like to maintain by yourself the autotools stack for mapnik ? 17:08:31 <kunitoki> i wouldn't for sure 17:09:04 <kunitoki> and i'm not lazy, i just don't want to hammer my head on the wall more than what it's worth 17:21:59 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 17:25:14 <kunitoki> artem: thanx 17:25:34 <artem> no probs 17:25:49 <kunitoki> artem: There are any guidelines for commits ? (especially regarding svn comments in order to link with trac tickets, revisions, changesets, patches) 17:26:33 <artem> kunitoki: not really, but feel free to follow practice etc :) 17:26:43 <artem> good practice 17:27:16 <kunitoki> ok, yeah i know that. i thought trac have special tags for linking messages to tickets or patches directly 17:27:16 <artem> kunitoki: all committed stuff should at least compile :) 17:27:25 <kunitoki> yeah of course :P 17:28:18 <artem> kunitoki: I think you can use things like r884 or #100 17:28:19 <nikq> Ticket #100: mapnik/font_set.hpp file missing, http://trac.mapnik.org/ticket/100 17:28:20 <nikq> http://trac.mapnik.org/changeset/884, at , by dane: Authors: Remove duplicate listing for Dave Stubbs 17:28:47 <artem> nikq understands them 17:29:00 <kunitoki> ok 17:29:14 <artem> m 0.6.0 17:29:24 <artem> milestone 0.6.0 17:29:26 <nikq> 31 open tickets in Milestone 0.6.0: Names on areas don't seem to be correctly centered in the vertical axis, Stroke border, Ability to set label value manually in TextSymbolizer (rather than have them read from datasource field), Support MAPNIK_VERSION, Crashing with TextSymbolizer and line placement., Update Install Document on Mapnik.org by release and trunk, Path env variable behaving strangely... 17:29:27 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.6.0&order=priority 17:29:28 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.6.0 17:30:49 <springmeyer> yes: bot code is here: http://mapnik-utils.googlecode.com/svn/sandbox/irc_tools/mapniktrac.py 17:31:38 <springmeyer> nikq is phenny with that 'mapniktrac' plugin so phenny also accepts a variety of other commands 17:31:53 <springmeyer> like google searches or google counts 17:31:58 <springmeyer> .g phenny 17:31:59 <nikq> springmeyer: http://inamidst.com/phenny/ 17:32:05 <springmeyer> .gc mapnik 17:32:05 <nikq> mapnik: 108,000 17:32:13 <springmeyer> .w mapnik 17:32:22 <springmeyer> .wik mapnik 17:32:23 <nikq> "This page has been deleted." - http://en.wikipedia.org/wiki/Mapnik 17:32:44 <artem> yep, we need to write wiki sometime 17:36:52 <kunitoki> springmeyer: now most of the plugins won't compile by default 17:37:09 <kunitoki> what i have to do to add them 17:37:15 <springmeyer> right 17:37:22 <kunitoki> config.py ? 17:37:33 <springmeyer> add which ones you want on the command line... 17:37:42 <springmeyer> then it will be saved in the 'config.py' 17:37:56 <kunitoki> scons DEBUG=Y LIBS='occi,sqlite' 17:38:00 <kunitoki> something like this ? 17:38:04 <springmeyer> ie INPUT_PLUGINS=postgis,sqlite 17:38:07 <springmeyer> yes 17:38:11 <kunitoki> ok 17:38:12 <kunitoki> thanx 17:38:33 <springmeyer> maybe should just be PLUGINS ? 17:38:37 <nikq> Mapnik Trac: Ticket #224 (Mapnik produces garbled images from CGIs running on Windows XP/IIS 5.1) created | http://trac.mapnik.org/ticket/224 17:38:42 <springmeyer> kunitoki: regarding build times... 17:39:08 <nikq> Mapnik Trac: mapnikserv.py.jpeg attached to Ticket #224 | http://trac.mapnik.org/attachment/ticket/224/mapnikserv.py.jpeg 17:39:24 <springmeyer> yes I just played around and noticed that even if I don't change anything SCons will take about 40 seconds to configure, check deps, and check targets 17:39:39 <nikq> Mapnik Trac: Screenshot.png attached to Ticket #224 | http://trac.mapnik.org/attachment/ticket/224/Screenshot.png 17:39:51 <kunitoki> springmeyer: ok thanx... later 17:39:56 *** kunitoki has quit ("leaving") 17:40:34 <springmeyer> ack, but then i was able to get it down to ~ 6 seconds :) 17:41:16 <springmeyer> nikq: tell kunitoki to use --implicit-deps-unchanged 17:41:17 <nikq> springmeyer: I'll pass that on when kunitoki is around. 17:59:57 <nikq> Mapnik Trac: Changeset [885]: scons: Use implicit caching of deps if SCONS_CACHE is requested which ... | http://trac.mapnik.org/changeset/885 18:01:13 <springmeyer> nikq: tell kunitoki to check out r885 18:01:13 <nikq> springmeyer: I'll pass that on when kunitoki is around. 18:01:17 <nikq> http://trac.mapnik.org/changeset/885, at , by dane: scons: Use implicit caching of deps if SCONS_CACHE is requested which should double or triple the speed at which the 'scons: Building targets ...' step will run. Hint: use the --implicit-deps-unchange 18:07:20 <CIA-23> mapnik: dane * r885 /trunk/SConstruct: 18:07:20 <CIA-23> mapnik: scons: Use implicit caching of deps if SCONS_CACHE is requested which should 18:07:20 <CIA-23> mapnik: double or triple the speed at which the 'scons: Building targets ...' step will 18:07:20 <CIA-23> mapnik: run. Hint: use the --implicit-deps-unchanged flag for even quicker target 18:07:20 <CIA-23> mapnik: checking 18:10:06 <nikq> Mapnik Trac: Ticket #224 (Mapnik produces garbled images from CGIs running on Windows XP/IIS 5.1) updated | http://trac.mapnik.org/ticket/224#comment:1 18:10:16 <nikq> Mapnik Trac: Ticket #224 (Mapnik produces garbled images from CGIs running on Windows XP/IIS 5.1) updated | http://trac.mapnik.org/ticket/224#comment:2 18:10:31 <springmeyer> aled: can you try what I propose on that ticket? 18:11:29 *** artem has quit () 18:18:03 *** D3f0 has quit (Remote closed the connection) 18:20:04 <nikq> Mapnik Trac: Ticket #214 (SConstruct build engine refactoring) updated | http://trac.mapnik.org/ticket/214#comment:1 18:21:26 <nikq> Mapnik Trac: Ticket #224 (Mapnik produces garbled images from CGIs running on Windows XP/IIS 5.1) updated | http://trac.mapnik.org/ticket/224#comment:3 18:21:35 *** TomH has quit ("Coyote finally caught me") 18:21:56 <nikq> Mapnik Trac: out.jpeg attached to Ticket #224 | http://trac.mapnik.org/attachment/ticket/224/out.jpeg 18:25:07 *** TomH (n=tom@gate.compton.nu) has joined #mapnik 18:27:00 <aled> have done. jpeg is garbled, while png is unreadable 18:27:11 <springmeyer> aled: okay interesting 18:27:47 <springmeyer> aled: so that helps identify the problem as related to the to_string() method because you've confirmed that render_to_file works fine, right? 18:28:04 <springmeyer> aled: can you try changing the line in nik2img here: http://code.google.com/p/mapnik-utils/source/browse/trunk/nik2img/nik2img.py#1024 18:28:24 <springmeyer> from 'im.tostring(self.format)' to 'im.tostring()' 18:30:02 <springmeyer> my usage in nik2img and mapnikserv are the same there... ie the both encode the image string to a certain format, I'm curious what you get if you don't encode the image? 18:32:27 <aled> yes, r_t_f and im.save() have both worked 18:32:45 <aled> changing that line gives an unviewable image 18:34:16 <aled> InfranView says 'Can't read file header' 18:38:10 <nikq> Mapnik Trac: Ticket #224 (Mapnik produces garbled images from CGIs running on Windows XP/IIS 5.1) updated | http://trac.mapnik.org/ticket/224#comment:4 18:38:37 <springmeyer> hmmmm. okay commented again there... 18:39:00 <springmeyer> essentially over my head then if it is a win32 specific problem with writing the binary image data to a string... 18:39:11 <springmeyer> hopefully others can comment 18:39:17 *** rcoup (n=rcoup@ip-58-28-159-166.static-xdsl.xnet.co.nz) has joined #mapnik 18:39:28 <crschmidt> wait 18:39:34 <crschmidt> are we writing binary data to cgi on win32? 18:39:34 <springmeyer> yes.... :) 18:39:44 <crschmidt> (And why aren't we using tilecache, kids?) 18:39:57 <springmeyer> yes, but it also borked when piping to a file 18:40:01 <crschmidt> see binary_print at the bottom of: 18:40:01 <crschmidt> http://svn.tilecache.org/trunk/tilecache/TileCache/Service.py 18:40:22 <crschmidt> well, if you're piping to a file via f.write(), was the file opened in "wb" mode? 18:40:33 <springmeyer> very nice Dad! 18:40:56 *** TomH` (n=tom@gate.compton.nu) has joined #mapnik 18:41:32 *** TomH` is now known as TomH1 18:41:38 <springmeyer> crschmidt: I had aled try to redirect output to a file with '>' like shp2img which now feel suspect :) 18:41:42 <springmeyer> so, no 18:41:54 <crschmidt> redirect from what though? 18:41:59 <crschmidt> if he was using 'print', then that wouldn't work 18:42:17 *** TomH1 is now known as Tom1 18:42:18 *** Tom1 is now known as TomH1 18:42:19 <springmeyer> nik2img.py (my python hack equivalent to shp2img) 18:42:34 <springmeyer> which it was, yes using 'print' 18:42:59 <springmeyer> so, this is surely the problem. 18:43:29 <crschmidt> Yeah 18:43:39 <crschmidt> you might want to score the tilecache binary_print for nik2img while you're at it 18:43:55 * springmeyer in process! :) thx 18:45:17 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 18:47:28 <aled> yes, thanks 18:55:23 <springmeyer> aled: can you svn up with nik2img and try again for me? 18:57:53 <nikq> Mapnik Trac: Ticket #224 (Mapnik produces garbled images from CGIs running on Windows XP/IIS 5.1) closed | http://trac.mapnik.org/ticket/224#comment:5 18:59:33 *** artem has quit () 19:00:17 *** D3f0 (n=defo@190.176.218.99) has joined #mapnik 19:03:25 *** kunitoki (n=kraken@host210-49-dynamic.7-79-r.retail.telecomitalia.it) has joined #mapnik 19:03:55 *** TomH has quit (Read error: 110 (Connection timed out)) 19:04:00 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 19:06:52 <springmeyer> kunitoki: can you see if your SCons builds run faster now? with r885 19:06:52 <nikq> http://trac.mapnik.org/changeset/885, at , by dane: scons: Use implicit caching of deps if SCONS_CACHE is requested which should double or triple the speed at which the 'scons: Building targets ...' step will run. Hint: use the --implicit-deps-unchange 19:07:52 *** artem has quit (Client Quit) 19:09:22 <nikq> Mapnik Trac: Changeset [886]: Following #223: + improvements to the wkb converter + improved sqlite ... | http://trac.mapnik.org/changeset/886 19:09:55 <kunitoki> springmeyer: sure 19:09:55 <nikq> kunitoki: 17:41Z <springmeyer> tell kunitoki to use --implicit-deps-unchanged 19:09:56 <nikq> kunitoki: 18:01Z <springmeyer> tell kunitoki to check out r885 19:10:14 <kunitoki> springmeyer: p.s. my first commit ! 19:10:21 <springmeyer> nice! 19:11:06 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 19:11:40 <kunitoki> springmeyer: whau that --implicit-wtf speed up things ! 19:11:58 <kunitoki> finally ! 19:12:16 <springmeyer> shhh! don't let anyone else know about --implicit-wtf (that one is different) ;) 19:13:01 <kunitoki> i think we should add some of those funky flags somehwere in the code... :) ehehe 19:13:11 <springmeyer> kunitoki: apparently --implicit-deps-unchanged is even faster, but cannot be set in the SConstruct and must be specified on the command line 19:13:13 <springmeyer> lol 19:13:47 <kunitoki> well can i put it in config.py ? 19:14:06 <springmeyer> no :( 19:14:39 <springmeyer> i mean you could but config.py is only sensitive to 'opts' specified in the SConstruct 19:15:16 <springmeyer> I bet with a bit more digging we could figure out how to hack in '--implicit-deps-unchanged' as a default.... 19:16:00 <kunitoki> well from 12 seconds to 6 seconds for building an unchanged project 19:16:20 <kunitoki> that's nice ! 19:16:22 <springmeyer> good, that's progress at least :) 19:16:25 <springmeyer> thx 19:16:33 <kunitoki> thanx to you.. i've done nothing ! 19:16:43 <kunitoki> (besides testing) 19:16:55 <springmeyer> okay, thx for testing :) 19:17:50 <kunitoki> artem: applyed new stuff for sqlite 19:18:33 <artem> kunitoki: cheers 19:18:36 <kunitoki> artem: i have prepared a sqlite database with all the demo data (roads.shp, boundaries.shp)... shoul i upload it with a proper rundemo 19:19:28 <kunitoki> so you can test it straight away after checking out 19:20:13 <kunitoki> artem: pssss.. my first commit here :) 19:20:23 <artem> kunitoki: I don't mind. I have some *.sqlite around 19:20:28 <kunitoki> thanx for letting me in 19:20:40 <artem> kunitoki: congrats on first commit :) 19:21:15 <CIA-23> mapnik: kunitoki * r886 /trunk/ (7 files in 3 dirs): 19:21:15 <CIA-23> mapnik: Following #223: 19:21:15 <CIA-23> mapnik: + improvements to the wkb converter 19:21:15 <CIA-23> mapnik: + improved sqlite index usage 19:21:15 <CIA-23> mapnik: + added more parameters to sqlite datasource 19:22:07 <kunitoki> artem: i spoke with spatialite creator, about adding table mbr in geometry_columns 19:22:11 <artem> kunitoki : latest trunk works fine with my local *.sqlite 19:22:22 <artem> kunitoki: and ? 19:22:27 <nikq> Mapnik Trac: Changeset [886]: Following #223: + improvements to the wkb converter + improved sqlite ... | http://trac.mapnik.org/changeset/886 19:22:29 <nikq> Mapnik Trac: Changeset [887]: Add Lucio Asnaghi to committers list and alphabetize list for clarity | http://trac.mapnik.org/changeset/887 19:22:38 <kunitoki> artem: probably they will put in the next release 19:22:53 <artem> ok, good 19:23:51 <springmeyer> aled: so are things working now? 19:24:33 <artem> kunitoki: can latest sqlite.input handle 'select' statements ? 19:24:41 <springmeyer> TomH1: did you fix for '%' operator address Nick W's question on the mailing list? 19:24:47 <springmeyer> you/your 19:24:48 <kunitoki> artem: select statements ? 19:25:34 <artem> postgis.input can accept tablename or something like (select geom, length(name),name from roads) as roads 19:25:47 <TomH1> springmeyer: should do, yes 19:26:06 <artem> this is useful for filtering at data source level etc 19:26:16 <kunitoki> artem: you mean 'select' statements as tablename ? 19:26:17 <artem> TomH1: thanks for % impl! 19:26:23 <artem> yes 19:26:24 <kunitoki> yes it should 19:26:37 <kunitoki> i haven't tried so far but should be ok 19:27:12 <artem> I'll give it a go. I'm using OSM dataset imported into SQLite 19:27:22 <kunitoki> interesting 19:27:28 <artem> osm.xml has lots of SQL magic .. 19:28:49 <jburgess> most of it isn't too bad. The obvious things are: using filters to avoid fetching more data than necessary & ordering the returned results to help render road and areas in the best sequence 19:29:03 <jburgess> both those could be dropped for an initial test 19:29:25 *** ser has quit (kubrick.freenode.net irc.freenode.net) 19:29:27 <kunitoki> artem: cool i really need a good .xml for learning 19:29:33 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik 19:29:57 <kunitoki> artem: my first maps rendering are a bit dirty and ugly :) 19:29:58 <jburgess> best not start with the osm.xml, unless you want to spend a few hours getting familiar with it! 19:30:27 <kunitoki> but i'm getting familiar... 19:30:56 <artem> kunitoki: the most comprehensive *.xml out there: http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml 19:30:56 <jburgess> 6544 lines, even I struggle with finding what I need sometimes 19:31:42 <CIA-23> mapnik-utils: dane.springmeyer * r549 /trunk/nik2img/ (CHANGELOG.txt nik2img.py): Added workaround for binary printing on win32 19:31:43 <CIA-23> mapnik-utils: dane.springmeyer * r550 /trunk/mapnikserv/mapnikserv.py: port binaryprint fix from nik2img (thanks crschmidt) 19:31:53 <crschmidt> np 19:38:01 *** artem has quit () 19:53:12 <CIA-23> mapnik: dane * r887 /trunk/AUTHORS: Add Lucio Asnaghi to committers list and alphabetize list for clarity 20:17:09 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 20:24:27 <nikq> Mapnik Trac: Changeset [888]: osm plugin: Fix up test xml samples | http://trac.mapnik.org/changeset/888 20:25:38 <nikq> Mapnik Trac: Changeset [889]: + Add SCons build script for osm plugin | http://trac.mapnik.org/changeset/889 20:42:55 <nikq> Mapnik Trac: Ticket #72 (Support MAPNIK_VERSION) updated | http://trac.mapnik.org/ticket/72#comment:7 20:43:37 <springmeyer> artem: if you can comment on how to approach #72 that would be awesome 20:43:38 <nikq> Ticket #72: Support MAPNIK_VERSION, http://trac.mapnik.org/ticket/72 20:44:05 <artem> springmeyer: sure, let me have a look 20:45:08 * springmeyer would love to be able to fetch the mapnik version via the python bindings to be able to support trunk easier in nik2img.py, etc 20:46:10 <artem> sptingmeyer: I'm planing to add mapnik/version.hpp (similar to boost/version.hpp) we can then export version to Python. Any example for version() in some python pkgs? 20:46:31 <springmeyer> ah cool. 20:46:50 <springmeyer> good question, I'll think about a good example... 20:47:50 <artem> ok, I can see your last comment on http://trac.mapnik.org/ticket/72 sounds reasonble 20:49:09 <springmeyer> well, what ever you have planned sounds good :) 20:49:45 <CIA-23> mapnik: dane * r888 /trunk/plugins/input/osm/ (test2.xml test3.xml test.xml): osm plugin: Fix up test xml samples 20:49:46 <CIA-23> mapnik: dane * r889 /trunk/ (plugins/input/osm/SConscript SConstruct): + Add SCons build script for osm plugin 20:49:47 <springmeyer> the only extra thought I have it that is would be cool to detect svn builds and r numbers 20:50:36 <springmeyer> that could be done in python during the SCons build I guess, but is less important than first implementing mapnik/version.hpp 20:51:06 <springmeyer> artem: pycairo seems to have a descent, intuative interface... 20:51:10 <springmeyer> >>> import cairo 20:51:34 <springmeyer> cairo.cairo_version();cairo.cairo_version_string() 20:52:16 <springmeyer> heh, other than for me cairo_version_string() returns '1.8.0' while the 'version' property returns '1.6.4' 20:52:42 <artem> :) >>> import cairo 20:52:43 <artem> >>> cairo.cairo_version();cairo.cairo_version_string() 20:52:43 <artem> 10604 20:52:43 <artem> '1.6.4' 20:52:59 <springmeyer> cool :) 20:53:12 <springmeyer> ya, I have seriously messed up cairo installs on my machine 20:54:02 <springmeyer> anyway, mapnik.mapnik_version() and mapnik.mapnik_version_string() would be cool 21:16:15 <CIA-23> mapnik-utils: dane.springmeyer * r551 /trunk/nik2img/nik2img.py: Catch Mapnik exception when searching for non-existent style, and only do 'layers_in_extent' validation if verbose is requested 21:36:16 <springmeyer> artem: the current render_to_tile(), save(), etc methods seem to only allow writing to directories that exist 21:36:53 <springmeyer> if the path to write the image to does not exist mapnik fails silently... 21:37:21 <springmeyer> do you think mapnik should be able to write all nested directories needed to save an image? 22:26:04 <artem> springmeyer: should we be raising an exception ? 22:28:23 <springmeyer> artem: I'm not sure. do you think it is possible/wise to allow mapnik to create the directories? 22:28:36 <springmeyer> if not perhaps we should raise an exception 22:29:59 <artem> I'm not sure about creating dirs in library, this kind of things can be implemented on client side 22:30:38 <springmeyer> ya, good call 22:34:35 *** jlivni (n=josh@76.14.74.234) has joined #mapnik 22:41:44 *** kunitoki has quit ("leaving") 22:58:56 *** ninja_ (n=pankur@nat/yahoo/x-03d75bcef57d5dd2) has joined #mapnik 23:01:48 *** artem has quit () 23:22:00 *** D3f0 has quit (Remote closed the connection) 23:22:18 *** rcoup has quit ()