00:41:33 <nikq> Mapnik Trac: Ticket #215 (g++ (Ubuntu 4.3.2-1ubuntu11) compiler warnings) updated | http://trac.mapnik.org/ticket/215#comment:1
01:06:41 <springmeyer> cool, thanks jburgess
01:06:54 <springmeyer> I'll close as invalid then
01:07:25 <springmeyer> hey jburgess: do you have any ticket you think we should push off of the 0.6.0 milestone --> to 1.0 ?
01:07:26 <nikq> No Milestone for that release number
01:07:34 <springmeyer> milestone 0.6.0
01:07:34 <nikq> 33 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...
01:07:36 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.6.0&order=priority
01:07:37 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.6.0
01:08:00 <springmeyer> maybe #51 should be pushed off?
01:08:00 <nikq> Ticket #51: Stroke border, http://trac.mapnik.org/ticket/51
01:40:56 *** springmeyer has quit ()
01:57:37 *** D3f0 (n=defo@190.176.193.117) has joined #mapnik
02:58:13 *** rcoup (n=rcoup@ip-118-90-78-242.xdsl.xnet.co.nz) has joined #mapnik
03:35:27 *** D3f0 has quit ("Konversation terminated!")
03:44:16 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
03:47:01 <springmeyer> is HardDisk_WP a bot?
03:47:03 <springmeyer> Mrfo: any promising adventures with Mod_tile?
03:57:11 *** ninja (n=pankur@nat/yahoo/x-4c44ebea5da70388) has joined #mapnik
03:57:56 <ninja> hello all
04:24:35 *** rcoup has quit ()
04:39:07 <springmeyer> hey ninja! long time no see
04:39:14 <springmeyer> doing good?
04:40:57 <springmeyer> I did a bit of Portfile hacking the other day. I think after #209 it should be a bit easier to use the Portfile with trunk, but I've yet to test since it landed
04:40:57 <nikq> Ticket #209: SCons python install usability improvments, http://trac.mapnik.org/ticket/209
04:41:22 <stamf> howdy people
04:41:32 <ninja> hey springmeyer, yes been busy with work :)
04:41:41 <springmeyer> cool
04:41:45 <springmeyer> hey stamf
04:41:51 <ninja> first i cant get my head around something need help springmeyer
04:42:06 <springmeyer> sure, what with?
04:42:11 <ninja> just got the latest source from svn
04:42:14 <ninja> compiled it
04:42:25 <ninja> regex filter parsing is disabled?
04:42:34 <springmeyer> huh, shouldn't be
04:42:40 <ninja> its not recognizing my '%' in the style xml
04:42:46 <springmeyer> ah, I know...
04:42:50 <ninja> ### Configuration error: Failed to parse filter expression:
04:42:50 <ninja> [POLYGON_ID] % 6 = 0
04:43:09 <ninja> yes springmeyer do share
04:43:30 <springmeyer> ya, so we've switched the default XMLPARSER to libxml2 which expects escaped characters
04:43:33 <ninja> ah
04:43:34 <ninja> yes
04:43:49 <springmeyer> so rebuilt with XMLPARSER=tinyxml
04:44:06 <springmeyer> or escape that % (not sure what that would be of the top of my head)
04:44:19 <ninja> aha
04:44:24 <ninja> springmeyer you rock
04:44:29 <ninja> will give that a try now
04:44:39 <ninja> this was driving me insane
04:44:48 <springmeyer> well, no I don't rock
04:45:00 <springmeyer> I have been getting more into dev and have fallend behind on this:
04:45:01 <springmeyer> http://trac.mapnik.org/browser/trunk/CHANGELOG
04:45:16 <springmeyer> which should be a quick reference for crap like that!
04:45:32 <ninja> yeah true
04:45:49 <stamf> you are atleast "the man"
04:46:01 * springmeyer will create a 0.6.0 milestone release page soon so it is easy to trac stuff there too
04:46:02 <nikq> No Milestone for that release number
04:46:02 <stamf> as in, you the man
04:46:14 <springmeyer> ha!
04:46:28 <springmeyer> lots happening in trunk right now
04:46:41 <ninja> btw stamf and i have been working on this together :)
04:46:42 <springmeyer> especially with the SCons build scripts
04:46:48 <springmeyer> ah, cool
04:47:29 <springmeyer> so ninja: sounds like other than that hiccup the build went well?
04:47:52 <ninja> yep the build went well maybe cause i have built this like a lot of times
04:47:59 <ninja> though i dont particularly like scons
04:48:11 <springmeyer> ya, please share actually
04:48:31 <springmeyer> i've been whittling away as the aspects of our use of SCOns that have troubled me most...
04:48:39 <ninja> it has this aggresive caching of libraries
04:48:43 <springmeyer> but I'd like to know what I've missed
04:48:55 <springmeyer> ah, that is off now by default
04:49:01 <stamf> yay :P
04:49:12 <ninja> thats it then
04:49:25 <springmeyer> see http://trac.mapnik.org/browser/trunk/SConstruct#L111
04:49:41 <springmeyer> new option to turn if back on if you 'need speed'
04:49:46 <springmeyer> next... ?
04:49:58 <ninja> i dont have a next i realise
04:50:49 <springmeyer> cool :)
04:51:07 <ninja> do you use mapnik python bindings ? or have you tried c++ as well ?
04:51:17 <springmeyer> well, peek at all the new (perhaps too many :) ) options with $ python scons/scons.py -h
04:51:40 <springmeyer> only python
04:51:57 <springmeyer> other than playing around with C++ wms server that Fredrik wrote
04:52:52 <ninja> aha .. stamf and i have been looking at the c++ api i was wondering if anyone has insights on if its faster / by how much(should be faster)
04:53:15 <springmeyer> hey ninja and stamf: if you run into any other hiccups with SCons, log them here: #214
04:53:15 <nikq> Ticket #214: SConstruct build engine refactoring, http://trac.mapnik.org/ticket/214
04:53:29 <ninja> will do springmeyer
04:53:36 <springmeyer> cool
04:53:49 <springmeyer> well, that depends of course on what you are doing....
04:54:18 <springmeyer> for example I think we need a C++ implementation of a WMS server, because that is a lot of logic to be done in python
04:54:44 <ninja> the reason why i ask is , c++ bends itself better to be used in multicore environments
04:55:06 <springmeyer> but for doing pure rendering, of say a tileset of static tiles the python bindings are just making C++ calls through boost so I don't suspect much overhead
04:55:13 <springmeyer> ah, interesting
04:55:21 <springmeyer> so for beefy hardware, cool
04:55:47 <ninja> yep .. actually even for normal hardware my suspicion is c++ should be way faster i might be wrong though
04:56:00 <springmeyer> ninja: ya, I've not seen a good comparison.
04:56:37 <springmeyer> the rundemo.py has a c++ counter script, so compiling that and hitting those scripts might be an easy place to start
04:56:40 <ninja> yeah thats what i have been trying to write like a straight translation of my python render script to a c++ version
04:56:45 <ninja> yeah actually true
04:56:53 <ninja> i will give that a shot
04:56:58 <springmeyer> cool.
04:57:16 <springmeyer> I've got an outstanding patch to try to get the thing to compile that kunitoki gave me...
04:57:40 <ninja> yeah i compiled it alright
04:57:45 <ninja> just a huge a g++ command
04:57:47 <ninja> :)
04:57:58 <springmeyer> if it gives you any hassles maybe comment on #197
04:57:59 <nikq> Ticket #197: Fix compilation of C++ rundemo, http://trac.mapnik.org/ticket/197
04:58:08 <springmeyer> cool
04:58:23 <springmeyer> maybe you could post a SConscript ?
04:58:38 <springmeyer> or at least a patch against the readme...
04:59:03 * springmeyer runs to check the oven...
04:59:07 <ninja> yep i will try cause i tried my quick and dirty g++ blah and  a lot of includes and links against the library
04:59:09 *** jburgess has quit (Read error: 54 (Connection reset by peer))
04:59:18 <ninja> but sconscript is a good idea
04:59:42 <ninja> any reason why we dont use autoconf for all of this ?
05:01:40 <ninja> then again keeping a standard across makes more sense
05:02:03 <ninja> so scons it is but that question was out of curiosity
05:11:50 <springmeyer> I don't know 'why' SCons but while playing with the scripts recently I've grown to see the ease of writing them
05:12:10 <ninja> okay cool .. i am going to give it a shot
05:12:25 <springmeyer> and I've run into a number of top notch projects that use Scons.
05:12:47 <springmeyer> awesome, thanks
05:13:11 <ninja> btw springmeyer tinyxml dint help
05:13:19 <springmeyer> ah dear
05:13:21 <ninja> maybe i will try esaping the characters
05:13:45 <ninja> escape*
05:15:19 <springmeyer> ninja and stamf: another big change in Scons is that instead of the 'hidden' caching it uses a local file called 'config.py'
05:15:34 <ninja> yeah i saw where it sets all the variables
05:15:37 <springmeyer> that will be written out after a succesful configure stage
05:15:39 <springmeyer> okay
05:15:50 <ninja> yep i like the new and improved version
05:15:57 <ninja> its easier to understand :)
05:16:10 <ninja> .dblite files are obscure
05:17:03 <springmeyer> cool, ya that should also avoid the need to ever specify command line variables when you do $ python scons/scons.py install
05:18:08 <ninja> nice one
05:30:10 <springmeyer> hmmm r848 and r850 seem like the only recent changesets even vaguely related to filter parsing, but unlikely are causing regex problem I would guess...
05:30:11 <nikq> http://trac.mapnik.org/changeset/850, at , by artem: + remove unused header
05:30:15 <springmeyer> r848
05:30:16 <nikq> http://trac.mapnik.org/changeset/848, at , by jburgess777: Filter parsing: Allow numbers in the filter field name. This allows for shapefiles with columns like '1970'.
05:41:22 <nikq> Mapnik Trac: Ticket #216 (Document the new SCons behavior in trunk for the 0.6.0) created | http://trac.mapnik.org/ticket/216
05:41:45 <nikq> Mapnik Trac: Ticket #216 (Document the new SCons behavior in trunk for the 0.6.0 release) updated | http://trac.mapnik.org/ticket/216#comment:2
05:42:21 <ninja> yeah i dont think so too .. this is the same thing i was getting when using the mapnik port on bsd
05:42:37 <ninja> i just assumed that it was due to that old bug being carried into the port
05:43:05 <ninja> anyways tomorrow is going to be a new day i am going to try escaping the character and will let you know what happens
06:26:42 <springmeyer> okay :)
06:27:09 <springmeyer> bed time here. catch you later ninja
06:29:04 <ninja> see ya springmeyer
06:35:01 <nikq> Mapnik Trac: Ticket #217 (Add ability to set PKG_CONFIG_PATH in SCons) created | http://trac.mapnik.org/ticket/217
07:31:43 *** rcoup (n=rcoup@ip-118-90-78-242.xdsl.xnet.co.nz) has joined #mapnik
07:36:37 *** rcoup has quit (Client Quit)
08:23:27 *** xcacou (n=aga@AToulouse-157-1-165-31.w83-193.abo.wanadoo.fr) has joined #mapnik
08:33:28 *** racicot has quit (Read error: 60 (Operation timed out))
08:38:38 *** racicot (n=chatzill@209.166.85.189) has joined #mapnik
09:07:43 *** kunitoki (n=kraken@host210-49-dynamic.7-79-r.retail.telecomitalia.it) has joined #mapnik
09:12:00 *** racicot has quit (Read error: 110 (Connection timed out))
09:40:56 *** racicot (n=chatzill@dsl-209-166-85-189.whidbey.net) has joined #mapnik
10:15:51 <kunitoki> springmeyer: don't forget to apply http://trac.mapnik.org/attachment/ticket/212/occi-input-plugin-3.patch
11:12:02 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
11:13:59 <artem> kunitoki:  did you give oracle plug-in a try ? does it work well?
11:28:31 *** D3f0 (n=defo@190.176.193.117) has joined #mapnik
11:35:19 <CIA-23> mapnik: artem * r867 /trunk/plugins/input/occi/ (6 files): + occi-input-plugin-3.patch (kunitoki)
11:46:25 *** ChanServ has quit (shutting down)
11:47:50 *** ChanServ (ChanServ@services.) has joined #mapnik
11:54:10 <nikq> Mapnik Trac: Changeset [869]: + more property goodness on the TextSymbolizer from Python (springmeyer) | http://trac.mapnik.org/changeset/869
11:54:37 <nikq> Mapnik Trac: Ticket #161 (More property goodness on the TextSymbolizer from Python) closed | http://trac.mapnik.org/ticket/161#comment:2
12:02:29 <CIA-23> mapnik: tom * r868 /trunk/plugins/input/postgis/postgis.cpp: Include boost/algorithm/string.hpp to get access to string algorithms.
12:02:30 <CIA-23> mapnik: artem * r869 /trunk/ (3 files in 3 dirs): + more property goodness on the TextSymbolizer from Python (springmeyer)
12:17:44 <nikq> Mapnik Trac: Ticket #172 (Add ability of save_map() to overwrite outputs) updated | http://trac.mapnik.org/ticket/172#comment:2
13:06:54 *** artem has quit ()
13:12:44 *** adakkak has quit ("Ex-Chat")
13:21:51 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
13:24:19 *** artem has quit (Client Quit)
15:27:53 *** ninja has quit ()
15:33:39 *** Jon___ (n=Jon@93-97-6-206.zone5.bethere.co.uk) has joined #mapnik
16:02:48 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
16:15:14 <nikq> Mapnik Trac: Ticket #217 (Add ability to set PKG_CONFIG_PATH in SCons) updated | http://trac.mapnik.org/ticket/217#comment:2
16:16:02 <springmeyer> cool thanks for fixing up the TextSymbolizer patch artem
16:16:27 <springmeyer> i mean artem_ :)
16:16:51 <artem_> no probs
16:23:42 <nikq> Mapnik Trac: Ticket #217 (Add ability to set PKG_CONFIG_PATH in SCons) updated | http://trac.mapnik.org/ticket/217#comment:3
16:33:32 <nikq> Mapnik Trac: occi-input-plugin-4.patch attached to Ticket #212 | http://trac.mapnik.org/attachment/ticket/212/occi-input-plugin-4.patch
16:34:13 <nikq> Mapnik Trac: Ticket #217 (Add ability to set PKG_CONFIG_PATH in SCons) updated | http://trac.mapnik.org/ticket/217#comment:4
16:34:23 <nikq> Mapnik Trac: ogr_5th_revision.patch attached to Ticket #170 | http://trac.mapnik.org/attachment/ticket/170/ogr_5th_revision.patch
16:35:18 <kunitoki> artem_: yeah oracle support is working well in my cases. only compound geometry is not tested. but i doubt people use them, even if can be
16:35:51 <artem_> kunitoki: thanks, someone was asking me about oracle plug-in already
16:36:07 <kunitoki> i will do more complete tests on monday when i get back to work and have access to full consistent dataset
16:36:26 <kunitoki> artem_: he can even try to compile oracle support in OGR and use it with that
16:36:42 <kunitoki> artem_: you have 2 choices :)
16:36:51 <artem_> cool :)
16:36:59 <springmeyer> kunitoki rocks
16:37:37 <kunitoki> ogr support is quite perfect, only little things can be done well, code cleanup, more usage of boost stuff
16:38:06 <kunitoki> springmeyer: thanx ;)
16:38:52 <kunitoki> artem_: byw you need to apply the latest patches from me to make things work seamlessly
16:39:14 <artem_> ogr patches ?
16:40:01 <kunitoki> no this http://trac.mapnik.org/attachment/ticket/170/ogr_5th_revision.patch
16:40:20 <kunitoki> i fixed what you asked last time you looked at my code
16:40:45 <kunitoki> suspicious uncached (ogr documentation is skipping on that) call
16:40:48 <artem_> great! I'll apply your patch straight away
16:41:38 <kunitoki> artem_: may i ask who is calling for oracle support ?
16:41:58 <artem_> some guy from russia
16:41:59 <kunitoki> artem_: i hope he is not italian and he is not from Venice like me (competitors)
16:42:21 <artem_> :) nope
16:42:35 <kunitoki> cause we are in war wth another company that work for the government too, and they just copy our ideas with different name
16:42:55 <kunitoki> they don't even write new documents, they rename ours
16:43:05 <kunitoki> so they bought oracle as we done
16:43:16 <kunitoki> and they are using similar stuff to ours
16:43:26 <artem_> very naughty
16:43:38 <kunitoki> now as i'm moving to mapnik, OSM... they moved to OSM too
16:43:49 <kunitoki> eh yeah
16:43:51 <artem_> why don't you use postgresql btw ?
16:44:08 <artem_> i mean oracle is mice but it is $$$
16:44:11 <artem_> nuce
16:44:13 <springmeyer> hey, at least they are smarte enough to follow the __leader__ :)
16:44:13 <artem_> nice
16:44:24 <artem_> lol :D
16:44:33 <artem_> exactly !
16:44:49 <kunitoki> because when we done the test (years ago), postgis was crashing with geomtry datasets > 100.000 records
16:44:59 <artem_> kunitoki: there is no way they can catch up with you
16:45:16 <kunitoki> we evauated a lot of options... and 4 years ago oracle was the most mature
16:45:18 * springmeyer can't even keep up with your patches....
16:46:44 <kunitoki> and for some internal stuff we need things like LRS and topology mainly
16:46:53 <kunitoki> springmeyer: what... they are fucked up ?
16:46:56 *** xcacou has quit (Remote closed the connection)
16:47:11 <nikq> Mapnik Trac: Changeset [870]: + ogr_5th_revision.patch (kunitoki rocks!) | http://trac.mapnik.org/changeset/870
16:47:20 <springmeyer> lol
16:49:33 <artem_> kunitoki : yes, it's better now (postgresql) - it can certainly store lots of geometries. OSM > 20,000,000 linestrings UK MasterMap ~ 500,000,000 (i think)
16:49:54 <kunitoki> whau cool
16:50:19 <kunitoki> you can do linear referencing systems too ?
16:50:25 <kunitoki> and graphs ?
16:50:45 <kunitoki> weighted graphs
16:50:47 <artem_> nope, no topology
16:51:03 <kunitoki> ok
16:51:11 <kunitoki> grid interpolation ?
16:51:33 <artem_> :)
16:51:52 <artem_> can be done though
16:51:59 <kunitoki> yeah with external stuff
16:56:53 <CIA-23> mapnik: artem * r870 /trunk/plugins/input/ogr/ (ogr_featureset.cpp ogr_datasource.cpp ogr_featureset.hpp): + ogr_5th_revision.patch (kunitoki rocks!)
17:06:00 <kunitoki> nikq ?
17:06:08 <kunitoki> http://trac.mapnik.org/attachment/ticket/170/demo.png
17:06:16 <kunitoki> geometries are perfect
17:06:43 <kunitoki> the only thing i would like to fix is the utf-8 / latin1 encoding problem
17:07:59 <kunitoki> which is strange, as i handled like any other input plugin
17:08:38 <kunitoki> with UnicodeString ustr = tr_->transcode((*feat)->GetFieldAsString (i));
17:08:53 <kunitoki> probably i have to do a fix here
17:12:55 *** jlivni_ (n=josh@c-24-4-60-236.hsd1.ca.comcast.net) has joined #mapnik
17:13:56 *** jlivni has quit (Read error: 113 (No route to host))
17:19:22 <kunitoki> aha found !
17:19:31 <kunitoki> we have:
17:19:36 <kunitoki> desc_(*params.get<std::string>("type"), *params.get<std::string>("encoding","utf-8"))
17:19:42 <kunitoki> in shape.input
17:19:46 <kunitoki> and
17:19:57 <kunitoki> desc_(*params.get<std::string>("type"),"utf-8"),
17:20:03 <kunitoki> in postigs.input
17:20:27 <kunitoki> and i copied the line from postgis so ogr was not reading the encoding parameter
17:21:11 <kunitoki> me dumb :)
17:22:25 <nikq> Mapnik Trac: demo.png attached to Ticket #170 | http://trac.mapnik.org/attachment/ticket/170/demo.png
17:25:32 <kunitoki> springmeyer: another patch
17:25:51 <springmeyer> :) awesome, I'll grab it
17:26:00 <nikq> Mapnik Trac: ogr_6th_revision.patch attached to Ticket #170 | http://trac.mapnik.org/attachment/ticket/170/ogr_6th_revision.patch
17:26:25 <kunitoki> see also the demo.png attached... slick ah ?
17:26:42 <kunitoki> same as the shape plugin :)
17:26:44 <springmeyer> ya, looks great
17:26:58 <springmeyer> any speed differences you notice?
17:27:27 <kunitoki> well, for me it seems slower with ogr, but it is only sensation
17:27:43 <kunitoki> i'll need to execute both with time
17:28:19 <kunitoki> OGR: real 0m12.605s
17:29:20 <kunitoki> SHAPE: real 0m7.682s
17:29:30 <kunitoki> it is sensibly faster !
17:29:48 <kunitoki> 5 seconds is A'LLOT !
17:30:02 <springmeyer> :), good to know.
17:30:13 <kunitoki> maybe because of the internal shape_index ?
17:30:38 *** jlivni_ has quit (Read error: 113 (No route to host))
17:31:12 <springmeyer> well, hmm, mapnik uses a custom built .index file but those demo files don't have it. not sure about usage of an internal index...
17:31:32 <kunitoki> ok so it is OGR which is slow as hell
17:32:09 <nikq> Mapnik Trac: Changeset [871]: + apply ogr_6th_revision.patch to allow unicode support | http://trac.mapnik.org/changeset/871
17:32:10 <kunitoki> i should run that with a profiler
17:32:50 <kunitoki> well 6th revision will add support for "encoding" parameter in dataset only... unicode support is still there :)
17:33:01 <CIA-23> mapnik: dane * r871 /trunk/plugins/input/ogr/ogr_datasource.cpp: + apply ogr_6th_revision.patch to allow unicode support
17:33:33 <springmeyer> ah, sorry
17:33:34 <kunitoki> ogr is in a good shape now
17:33:39 <kunitoki> ogr.input i mean
17:33:56 <kunitoki> it sure can be included in the 0.6.0 release
17:33:59 <springmeyer> yes, cool
17:34:20 <springmeyer> will be great news to many in the 0.6.0 release
17:34:34 <kunitoki> i still want to dig the sqlite path
17:35:10 <kunitoki> like what we spoke with artem.... directly putting mapnik geometries binary in sqlite (or any other database) blob
17:35:18 <kunitoki> springmeyer: i hope so
17:36:12 <kunitoki> i think sqlite is in a form it can be used for some production environment
17:37:20 <kunitoki> ok, going out
17:37:29 <kunitoki> keep up the good work with it !
17:37:35 <springmeyer> see ya!
17:38:22 <kunitoki> byez
17:39:08 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:15
17:41:49 *** artem_ has quit ()
17:41:49 <nikq> Mapnik Trac: Changeset [872]: + apply PostgisImprovements.diff (rcoup) for record_limit and cursur_size  ... | http://trac.mapnik.org/changeset/872
17:42:09 <nikq> Mapnik Trac: Ticket #140 (postgis: ability to handle large resultsets) closed | http://trac.mapnik.org/ticket/140#comment:2
17:43:56 <springmeyer> nikq: tell rcoup when he returns that I've applied his postgis resultset patch, and thank you.
17:43:56 <nikq> springmeyer: I'll pass that on when rcoup is around.
17:44:33 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
17:45:43 <nikq> Mapnik Trac: Ticket #207 (view_transform returns Envelope instead of CoordTransform) updated | http://trac.mapnik.org/ticket/207#comment:4
17:46:14 *** artem_ has quit (Client Quit)
17:48:56 <nikq> Mapnik Trac: Ticket #215 (g++ (Ubuntu 4.3.2-1ubuntu11) compiler warnings) closed | http://trac.mapnik.org/ticket/215#comment:2
17:59:30 <CIA-23> mapnik: dane * r872 /trunk/plugins/input/postgis/ (6 files): + apply PostgisImprovements.diff (rcoup) for record_limit and cursur_size support (#140)
18:01:37 <nikq> Mapnik Trac: MacPythonUpgradeIssues edited | http://trac.mapnik.org/wiki/MacPythonUpgradeIssues?version=4
18:09:15 <nikq> Mapnik Trac: Changeset [873]: + apply show_page.patch (thanks Berteun) (closes #201) | http://trac.mapnik.org/changeset/873
18:09:34 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) updated | http://trac.mapnik.org/ticket/201#comment:3
18:09:45 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) closed | http://trac.mapnik.org/ticket/201#comment:4
18:14:38 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) updated | http://trac.mapnik.org/ticket/201#comment:5
18:21:10 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
18:21:32 *** artem_ has quit (Client Quit)
18:27:09 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) updated | http://trac.mapnik.org/ticket/201#comment:6
18:29:21 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) updated | http://trac.mapnik.org/ticket/201#comment:7
18:30:37 <CIA-23> mapnik: dane * r873 /trunk/ (3 files in 3 dirs): + apply show_page.patch (thanks Berteun) (closes #201)
18:32:32 *** adakkak (n=adakkak@gres116.lis.illinois.edu) has joined #mapnik
18:44:35 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) updated | http://trac.mapnik.org/ticket/201#comment:8
19:06:04 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) updated | http://trac.mapnik.org/ticket/201#comment:9
19:13:03 *** jburgess (n=jburgess@bb-87-80-234-70.ukonline.co.uk) has joined #mapnik
21:36:36 *** kunitoki has quit ("Lost terminal")
22:22:41 *** HardDisk_WP has quit ("Caught sigterm, terminating...")
22:48:24 *** Jon___ has quit ()
23:08:33 *** Jon___ (n=Jon@93-97-6-206.zone5.bethere.co.uk) has joined #mapnik
23:10:30 *** Jon___ has quit (Client Quit)
23:30:29 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
23:39:04 *** artem has quit ()