00:11:00 *** aub has quit (Read error: 110 (Connection timed out))
00:12:23 *** rcoup (n=rcoup@ip-58-28-159-166.static-xdsl.xnet.co.nz) has joined #mapnik
00:16:41 *** D3f0 (n=defo@190.176.201.89) has joined #mapnik
00:24:13 *** D3f0 has quit (Remote closed the connection)
01:19:05 *** weizhuo (n=chatzill@nat/yahoo/x-a8bfc4f8e7b97a3f) has joined #mapnik
02:07:56 *** TomH1 has quit (Read error: 60 (Operation timed out))
03:32:48 *** TomH (n=tom@gate.compton.nu) has joined #mapnik
04:38:03 *** rcoup has quit ()
05:03:16 *** rcoup (n=rcoup@ip-118-90-78-242.xdsl.xnet.co.nz) has joined #mapnik
05:08:13 *** rcoup has quit (Client Quit)
05:08:29 *** ser has quit (kubrick.freenode.net irc.freenode.net)
05:09:00 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik
05:13:07 *** TomH has quit (kubrick.freenode.net irc.freenode.net)
05:13:07 *** jbglaw has quit (kubrick.freenode.net irc.freenode.net)
05:13:07 *** crschmidt has quit (kubrick.freenode.net irc.freenode.net)
05:15:16 *** Mrfo has quit (Read error: 104 (Connection reset by peer))
05:23:25 *** TomH (n=tom@gate.compton.nu) has joined #mapnik
05:23:25 *** jbglaw (n=jbglaw@lug-owl.de) has joined #mapnik
05:23:25 *** crschmidt (i=crschmid@helios.crschmidt.net) has joined #mapnik
05:55:18 *** weizhuo has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.20/2008121709]")
06:13:20 *** rcoup (n=rcoup@ip-118-90-78-242.xdsl.xnet.co.nz) has joined #mapnik
06:28:30 *** D3f0 (n=defo@190.176.201.89) has joined #mapnik
06:59:07 *** D3f0 has quit (Remote closed the connection)
07:26:18 *** rcoup has quit ()
08:04:55 *** xcacou (n=aga@AToulouse-157-1-56-173.w86-207.abo.wanadoo.fr) has joined #mapnik
08:16:15 *** kunitoki (n=kraken@host210-49-dynamic.7-79-r.retail.telecomitalia.it) has joined #mapnik
09:41:52 *** rcoup (n=rcoup@ip-118-90-78-242.xdsl.xnet.co.nz) has joined #mapnik
09:44:23 <ninja_> hey guys had a question about projection forwarding
10:01:40 *** sandGorgon (n=chatzill@122.162.148.210) has joined #mapnik
10:03:18 <sandGorgon> hi guys.. im a newbie to mapnik and am just setting it up on ubuntu - I installed PGSQL and imported some data into it using osm2pgsql. i also installed python-mapnik. How do I start serving it?
10:32:34 <aled> \back
11:12:31 <aled> sandGordon: have a look at the Getting started guide on the wiki: http://trac.mapnik.org/wiki/GettingStarted
11:13:01 <aled> also lots of example code and utilities on mapnik-utils.googlecode.com
11:13:17 <aled> http://code.google.com/p/mapnik-utils/
11:16:19 *** rcoup has quit ()
11:19:59 *** darragh (n=darragh@83.70.173.25) has joined #mapnik
11:23:45 <darragh> Are WMS parameters using to alter the layer query if the layer is using a postgis datasource?
12:04:40 *** kunitoki has quit ("leaving")
12:16:34 *** sandGorgon has quit (Remote closed the connection)
13:42:53 *** ninja_ has quit ()
14:13:21 *** aub (n=aubrey@static-70-107-236-83.ny325.east.verizon.net) has joined #mapnik
15:18:39 <CIA-23> mapnik: artem * r890 /trunk/include/mapnik/image_util.hpp: + fixed typo affecting win32 build
15:23:46 <nikq> Mapnik Trac: Changeset [891]: + add missing header cstdint.hpp | http://trac.mapnik.org/changeset/891
15:39:46 *** D3f0 (n=defo@190.176.201.89) has joined #mapnik
15:50:31 <CIA-23> mapnik: artem * r891 /trunk/include/mapnik/octree.hpp: + add missing header cstdint.hpp
15:54:08 *** darragh has quit (Remote closed the connection)
15:58:18 *** scruggs has quit ("Ex-Chat")
15:58:24 <nikq> Mapnik Trac: Changeset [892]: + boost-qualify type | http://trac.mapnik.org/changeset/892
16:07:15 *** adakkak has quit ("Ex-Chat")
16:08:55 *** scruggs (n=chris@72-161-105-25.dyn.centurytel.net) has joined #mapnik
16:15:49 <CIA-23> mapnik: artem * r892 /trunk/include/mapnik/octree.hpp: + boost-qualify type
16:29:47 <nikq> Mapnik Trac: Changeset [893]: + make compile cleanly with boost >= 1.38.0   (TODO : move to spirit2 in  ... | http://trac.mapnik.org/changeset/893
16:40:50 *** xcacou has quit (Remote closed the connection)
16:43:32 <CIA-23> mapnik: artem * r893 /trunk/ (3 files in 2 dirs):
16:43:32 <CIA-23> mapnik: + make compile cleanly with boost >= 1.38.0
16:43:32 <CIA-23> mapnik:  (TODO : move to spirit2 in milestone 1.0.0)
16:43:32 <nikq> No Milestone for that release number
16:45:20 <nikq> Mapnik Trac: Changeset [894]: + use 'typedef byte' instead of uint_8t | http://trac.mapnik.org/changeset/894
16:51:13 *** TomH has quit ("Coyote finally caught me")
16:56:50 *** scruggs_ (n=chris@72-161-105-25.dyn.centurytel.net) has joined #mapnik
16:57:12 *** TomH (n=tom@gate.compton.nu) has joined #mapnik
16:57:51 <nikq> Mapnik Trac: Changeset [895]: + use 'byte' defined in global.hpp | http://trac.mapnik.org/changeset/895
16:58:35 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
17:09:56 <nikq> Mapnik Trac: Changeset [896]: + add | http://trac.mapnik.org/changeset/896
17:11:49 <CIA-23> mapnik: artem * r894 /trunk/include/mapnik/octree.hpp: + use 'typedef byte' instead of uint_8t
17:11:49 <CIA-23> mapnik: artem * r895 /trunk/include/mapnik/ (image_data.hpp png_io.hpp octree.hpp): + use 'byte' defined in global.hpp
17:11:50 <CIA-23> mapnik: artem * r896 /trunk/include/mapnik/unicode.hpp: + add <string>
17:27:45 *** artem has quit ()
17:36:15 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
17:49:06 <springmeyer> hey artem: curious about pickle support. I was reading on the boost python pickle page and it notes in the 'Practical Advice' section...
17:49:11 <springmeyer> 'In Boost.Python extension modules with many extension classes, providing complete pickle support for all classes would be a significant overhead.'
17:50:03 <springmeyer> artem: do you understand this to mean overhead in terms of the time and effort to write in support or are we talking about a performance hit?
17:50:40 <springmeyer> FYI: http://www.boost.org/doc/libs/1_38_0/libs/python/doc/v2/pickle.html
17:51:59 <artem> springmeyer: good point. maybe we should  provide our own serialisation routines . in fact to/from xml string is a step forward
17:53:31 <springmeyer> well, I think pickling would be really great, I just want to make sure it is __fast__
17:53:56 <springmeyer> are you talking about to/from xml for each object?
17:54:04 <artem> springmeyer : nope
17:54:16 <springmeyer> oh, then explain? :)
17:54:36 <artem> springmeyer : I was thinking about Map object
17:54:58 <springmeyer> oh, what we have - yes it is a great thing
17:55:27 <artem> I don't know what performance penalty we can expect from implementing full pickle support
17:55:33 <artem> lets try and see :)
17:55:39 <artem> BTW, BOOST_VERSION in SConstruct clashes with  one defined in <boost/version.hpp> do we actually need  BOOST_VERSION
17:55:44 <artem> ??
17:55:54 <artem> in SConstruct ?
17:56:17 <springmeyer> ah, interesting
17:56:23 <springmeyer> I'll look...
17:56:32 <springmeyer> my hunch in terms of pickling is that loading a pickled map (with all styles and layers) will be faster than load_map() from xml
17:56:51 <springmeyer> and that the ultimate goal is to be able to 'copy' objects in python
17:57:05 <springmeyer> ie map_copy = deepcopy(m)
17:57:17 <springmeyer> (which required pickling I think)
17:57:17 <artem> well, if speed is an issue, we should implement serialisation in c++
17:57:46 <artem> sptingmeyer : i don't think pickling is reuiqred for copying
17:57:51 <springmeyer> ah, to c++ binary objects? (I would know nothing about that :))
17:58:08 <springmeyer> ya, not copying but for deepcopy (all the nested objects)
17:58:39 <springmeyer> but I could be wrong. I just tried to use deepcopy(m) and boost spit back a pickling not yet supported error...
17:58:44 <artem> sure but even deep copy shouldn't rely on pickling
17:59:07 <artem> hmm ... interesting
17:59:12 <springmeyer> okay. perhaps there is som other boost::python way of copying that we should/could support then.
18:00:46 <springmeyer> any idea how jburgess handles this in the renderd.py? Does he copy map objects or load_map(xml) for each thread?
18:00:57 * springmeyer heads to look at SConstruct...
18:01:19 <jburgess> one map object & load_map call per thread
18:01:52 <jburgess> actually, there can be more than one per thread, if you have multiple rendering layers defined
18:02:11 <springmeyer> ah, okay.
18:02:27 <artem> springmeyer : I'll have a look at pickling support, I think it'll be great feature
18:02:45 <artem> for 1.0.0
18:03:13 <artem> jburgess: are coming to London tomorrow ?
18:03:14 <springmeyer> so jburgess - do you think deepcopy of the map object (with all the xml styles and layers loaded) could be a speed boost?
18:03:42 <springmeyer> yes, artem I've been hacking at pickle support for various objects and am attaching patches to 1.0.0 tickets
18:04:02 <artem> cool
18:04:20 <springmeyer> I'm not pushing this for 0.6.0 at all, just curious how to attack the problem/opportunity
18:04:30 <jburgess> artem: I don't know, I heard / read a little about the launch a few days back but only saw the invite from Steve today. I thought the previous stuff I read suggested it was over-subscribed
18:04:55 <TomH> well he just posted it to talk-gb so I guess not
18:05:02 <TomH> I think nickb said they increased the space
18:05:20 <jburgess> springmeyer: I guess it could be, but it would only save a few seconds of startup time. The map object is created at startup and then held for the lifetime of the whole renderd process
18:05:52 <springmeyer> oh I think I read your response wrong...
18:06:14 <jburgess> well, one is created in each thread at startup and held forever
18:06:14 <springmeyer> so one map per startup, then a load_map() call per thread?
18:06:38 <jburgess> no, one map & load_map call for each layer in each thread
18:07:05 <springmeyer> okay, guess I'll have to look closer at the code :)
18:07:05 <springmeyer> thx
18:07:11 <jburgess> so it ends up with NUM_THREADS * NUM_XML_STYLES of map objects
18:07:26 <jburgess> all created at startup
18:07:44 <springmeyer> oh oh, gocha
18:08:53 <jburgess> as I think you were hinting, creating the map object and loading the style is really quite slow, so you don't want to do it on every request
18:10:12 <jburgess> I figured that sharing a single map object between multiple threads might not be safe, but I have not tested this
18:11:00 <jburgess> in fact, given how the zoom, bbox etc is set, it almost certainly isn't thread safe
18:11:12 <springmeyer> yes, exactly
18:12:39 <springmeyer> and if you already have a map object per thread in memory, then copying/ripping off a base map object per variable # of threads likely would'nt get you much faster
18:13:27 *** aub has quit (Read error: 104 (Connection reset by peer))
18:13:40 <jburgess> it could save some memory, but I have not checked to see how much a map object and the sub-objects takes
18:13:44 * springmeyer is thinking here about improving the OGCServer code which currently throws away and reloads the map object every request
18:14:09 <springmeyer> right, okay
18:14:13 <jburgess> I guess you could implement a cache / pool pretty easily
18:14:50 <springmeyer> how would that work?
18:15:08 <jburgess> when you create the map & call load_map, an object is created
18:15:22 <jburgess> when you release it, it doesn't get destroyed but is held in reserve by the bindings
18:15:43 <jburgess> if you later create a new map & do load_map with the same style then just re-use the previous map object
18:16:51 <jburgess> though that does assume that someone has updated the style.xml between the two calls.
18:17:41 <springmeyer> hmmm
18:18:17 *** aub (n=aubrey@70.107.236.83) has joined #mapnik
18:18:57 <artem> springmeyer: map objects are not thread safe by design
18:19:07 <springmeyer> artem: regarding BOOST_VERSION, yes we can remove it
18:19:20 <artem> ok
18:19:23 <springmeyer> artem: okay
18:20:29 <springmeyer> BOOST_VERSION looks to be used only for figuring out the boost_system_required thing on darwin
18:20:36 <springmeyer> (in SConstruct)
18:20:50 <artem> springmeyer : mapnik compiles with boost 1.38
18:20:51 <springmeyer> which I think we need a better solution for in general
18:20:57 <springmeyer> cool :)
18:21:40 <artem> what Python versions should we support on win32? 2.5 2.6 3.0 ?? all?
18:21:54 <springmeyer> artem: so if map objects are not thread safe by design then I must be mis-thinking how to cleanly cache styles and layers that don't change between requests
18:23:35 <artem> springmeyer :  you can't share Layer objects between threads  , because of Datasouce's
18:24:53 <artem> you could share read-only styles however
18:25:58 <jburgess> there is also a big difference between sharing stuff between concurrent users vs re-using something between uses
18:26:17 <artem> yes
18:26:38 <springmeyer> ah ha
18:27:08 <jburgess> hence why the renderd code creates a map object for each thread & re-uses that map object in that thread only.
18:29:43 * springmeyer is starting to understand why the OGCServer code looks the way it does :)
18:32:31 *** artem has quit ()
19:16:41 <cmarqu> Can I use the ShieldSymbolizer to draw an icon every n pixels along a road? Someone said I could, but when I tried it didn't seem to work.
19:25:02 *** rcoup (n=rcoup@ip-118-90-27-63.xdsl.xnet.co.nz) has joined #mapnik
21:01:42 *** rcoup has quit (Read error: 104 (Connection reset by peer))
21:01:51 *** rcoup (n=rcoup@ip-118-90-27-63.xdsl.xnet.co.nz) has joined #mapnik
21:49:34 *** rcoup_ (n=rcoup@ip-118-90-27-63.xdsl.xnet.co.nz) has joined #mapnik
21:49:35 *** rcoup has quit (Read error: 104 (Connection reset by peer))
21:59:23 *** rcoup (n=rcoup@ip-118-90-27-63.xdsl.xnet.co.nz) has joined #mapnik
22:03:38 *** adakkak (n=adakkak@ppp-70-225-166-147.dsl.chmpil.ameritech.net) has joined #mapnik
22:05:25 *** adakkak has quit (Remote closed the connection)
22:09:06 *** rcoup_ has quit (Read error: 110 (Connection timed out))
22:09:36 *** adakkak (n=adakkak@ppp-70-225-166-147.dsl.chmpil.ameritech.net) has joined #mapnik
22:22:25 *** scruggs has quit (Remote closed the connection)
22:23:23 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
22:30:56 *** jlivni has quit (Read error: 104 (Connection reset by peer))
22:31:03 *** artem has quit ()
22:33:31 <cmarqu> Is the ShieldSymbolizer still subject to collision detection? min_distance doesn't seem to have an effect for me, and I don't understand why.
22:42:05 <CIA-23> mapnik-utils: cmarqu42 * r552 /sandbox/cascadenik/hike_n_bike/img/ (20 files): Add hiking symbols (colored dots).
22:58:36 <nikq> Mapnik Trac: TextSymbolizer edited | http://trac.mapnik.org/wiki/TextSymbolizer?version=13
23:14:30 *** ninja (n=pankur@nat/yahoo/x-8404a3bbfd2218e9) has joined #mapnik
23:36:03 *** phycho (n=phycho@217.151.105.73) has joined #mapnik