00:19:06 *** jctull has quit ()
00:44:27 *** chad_burt has quit ("Leaving...")
01:00:18 *** ajturner (n=ajturner@pool-72-66-109-70.washdc.fios.verizon.net) has joined #mapnik
01:07:52 *** avar has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** aub has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** nikq has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** hobu has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** Komzpa has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** CIA-13 has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** tcb has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** ajturner has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** perry_ has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** crust has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** mak has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** cgs_bob has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** Ldp__ has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** dukeku has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** Simon- has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** racicot has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** cmarqu has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** mapnikbuild has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** dodobas has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** tomhughes has quit (pratchett.freenode.net irc.freenode.net)
01:07:52 *** ser has quit (pratchett.freenode.net irc.freenode.net)
01:16:00 *** avar (i=avar@wikipedia/avar) has joined #mapnik
01:16:00 *** CIA-13 (n=CIA@208.69.182.149) has joined #mapnik
01:16:04 *** CIA-13 has quit (Killed by sagan.freenode.net (Nick collision))
01:16:05 *** aub (n=aubrey@h-64-236-128-41.nat.aol.com) has joined #mapnik
01:16:05 *** nikq (n=nikq@li21-121.members.linode.com) has joined #mapnik
01:16:05 *** hobu (n=hobu@osgeo/member/hobu) has joined #mapnik
01:16:05 *** Komzpa (n=kom@mm-71-245-57-86.leased.line.mgts.by) has joined #mapnik
01:16:40 *** CIA-16 (n=CIA@208.69.182.149) has joined #mapnik
01:16:40 *** ajturner (n=ajturner@pool-72-66-109-70.washdc.fios.verizon.net) has joined #mapnik
01:16:40 *** racicot (n=chatzill@dsl-209-166-85-189.whidbey.net) has joined #mapnik
01:16:40 *** cgs_bob (n=bobm@239.sub-70-210-221.myvzw.com) has joined #mapnik
01:16:40 *** perry_ (n=perry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
01:16:40 *** tcb (n=tcb@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
01:16:40 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik
01:16:40 *** crust (n=russ@vobster.nepharia.org) has joined #mapnik
01:16:40 *** mak (n=mak@vobster.nepharia.org) has joined #mapnik
01:16:40 *** dukeku (i=dukeku@66.81.0.197) has joined #mapnik
01:16:40 *** tomhughes (n=tom@gate.compton.nu) has joined #mapnik
01:16:40 *** mapnikbuild (n=mapnikbu@miranda.nwcr.net) has joined #mapnik
01:16:40 *** cmarqu (i=colin@oemcomputer.oerks.de) has joined #mapnik
01:16:40 *** Simon- (i=simon@2001:8b0:ffea:0:205:b4ff:fe12:530) has joined #mapnik
01:16:40 *** dodobas (n=dodobas@161.53.248.113) has joined #mapnik
01:16:40 *** ser (n=ser@82.208.9.201) has joined #mapnik
01:28:30 *** jctull (n=jctull@adsl-75-14-205-49.dsl.renocs.sbcglobal.net) has joined #mapnik
01:45:32 *** cgs_bob has quit (Read error: 110 (Connection timed out))
02:05:17 *** ajturner has quit ()
02:39:43 *** tcb has quit ()
02:42:15 *** cgs_bob (n=bobm@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik
02:47:47 *** jctull has quit ()
02:57:26 *** Ldp__ has quit (Read error: 110 (Connection timed out))
03:33:49 <nikq> Mapnik Trac: Ticket #477 (semitransparency support for png256) updated | http://trac.mapnik.org/ticket/477#comment:4
05:54:20 *** j03lar50n (n=Administ@66-215-49-100.dhcp.snlo.ca.charter.com) has joined #mapnik
08:16:55 *** j03lar50n has quit (Read error: 54 (Connection reset by peer))
08:25:40 *** cgs_bob has quit (Remote closed the connection)
08:26:21 <nikq> Mapnik Trac: Ticket #477 (semitransparency support for png256) updated | http://trac.mapnik.org/ticket/477#comment:5
09:21:23 *** cgs_bob (n=bobm@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik
11:00:26 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik
11:00:27 *** Ldp__ is now known as Ldp
13:05:16 *** Ldp has quit (Nick collision from services.)
13:05:43 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik
13:53:57 *** springmeyer (n=springme@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
15:12:14 *** chad_burt (n=chad_bur@mm-01.msi.ucsb.edu) has joined #mapnik
15:15:09 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
15:39:16 *** ajashton (n=aj@c-68-33-227-150.hsd1.md.comcast.net) has joined #mapnik
15:42:12 <nikq> Mapnik Trac: Changeset [1509]: apply fix from Marcin for semitransparency of png256 - closes #477 and  ... | http://trac.mapnik.org/changeset/1509
15:48:48 <nikq> Mapnik Trac: Ticket #477 (semitransparency support for png256) closed | http://trac.mapnik.org/ticket/477#comment:6
15:54:35 <nikq> Mapnik Trac: Changeset [1510]: apply fix from Marcin for semitransparency of png256 - closes #477 and  ... | http://trac.mapnik.org/changeset/1510
15:55:26 <nikq> Mapnik Trac: Ticket #294 (thread unsafe gdal layer initialization (libgeotiff)) updated | http://trac.mapnik.org/ticket/294#comment:1
15:56:47 <nikq> Mapnik Trac: Ticket #296 (Ability to specify different geometry field) updated | http://trac.mapnik.org/ticket/296#comment:4
15:57:07 <nikq> Mapnik Trac: Ticket #443 (Support for random styles) updated | http://trac.mapnik.org/ticket/443#comment:2
15:57:48 <nikq> Mapnik Trac: Ticket #454 (rendering Image palaeontological_site) closed | http://trac.mapnik.org/ticket/454#comment:1
15:57:58 <nikq> Mapnik Trac: Ticket #472 (OGR driver support for OGR SQL) updated | http://trac.mapnik.org/ticket/472#comment:2
15:58:19 <nikq> Mapnik Trac: Ticket #475 (Rendring raster border bug) updated | http://trac.mapnik.org/ticket/475#comment:2
16:02:32 <Ldp__> springmeyer: that paleontological_site person already created the right ticket on OSM trac, but he's slightly impatient :D
16:02:59 <springmeyer> :)
16:03:07 <springmeyer> I think he was even on irc
16:03:18 * springmeyer just found those tickets that had not milestone....
16:03:22 <springmeyer> not/no
16:03:50 <Ldp__> 0.7 still in ~2 weeks ?
16:07:50 <springmeyer> yes, that is my hope, lots to do before then though :)
16:13:03 <nikq> Mapnik Trac: Mapnik2 edited | http://trac.mapnik.org/wiki/Mapnik2?version=8
16:16:36 <nikq> Mapnik Trac: Changeset [1511]: fix class names botched in r1509 merge from 0.7 branch | http://trac.mapnik.org/changeset/1511
16:27:37 <nikq> Mapnik Trac: Ticket #359 (Using datas from database into CSS stylesheet parameters) updated | http://trac.mapnik.org/ticket/359#comment:5
16:27:57 <nikq> Mapnik Trac: Ticket #352 (Allow Shield Symbolizer to build an image filename from k:v pairs) updated | http://trac.mapnik.org/ticket/352#comment:7
16:31:20 <nikq> Mapnik Trac: Ticket #70 (Ability to set label value manually in TextSymbolizer (rather than have  ...) closed | http://trac.mapnik.org/ticket/70#comment:8
16:32:45 *** aj_ashton (n=aj@c-68-33-227-150.hsd1.md.comcast.net) has joined #mapnik
16:33:21 <Ldp__> one thing I don't like about trac wiki is its insistence on making every word with more than 2 capitals a link
16:34:26 <Ldp__> there's also something in the current trunk build that causes my server to be at load 30+ for a few minutes, somewhere midway through the compile
16:34:50 <Ldp__> I'll have to pinpoint the exact file sometime
16:38:16 *** ajturner has quit ()
16:38:33 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
16:40:11 <springmeyer> Ldp__: yes the CamelCase can be both annoying and useful
16:40:40 <springmeyer> Ldp__: we should likely switch the buildbot to 0.7 for now. I'll need to check with Beau about that
16:41:35 <springmeyer> but I bet it is the boost_python stuff. we need to ratchet down the -ftemplate-depth-200. I think it only needs to be >100 for compiling libmapnik.dylib
16:41:40 <springmeyer> need to check with artem on that
16:42:34 <springmeyer> mapnik_style and mapnik_rule are the ones that I've noticed take the most time
16:44:05 <Ldp__> I'll check with the buildbot log next time, as the machine itself is totally unresponsive during those minutes
16:44:13 <Ldp__> which is a bit annoying since it's also my squid box
16:45:40 <springmeyer> oh, thats no good
16:46:20 <springmeyer> I need to look at the scons docs to see if there is a way to limit memory usage
16:47:53 *** ajashton has quit (Read error: 110 (Connection timed out))
16:48:20 *** perry_ has quit ()
16:48:58 *** jctull (n=jctull@adsl-75-14-205-49.dsl.renocs.sbcglobal.net) has joined #mapnik
16:49:12 <springmeyer> nice job aj_ashton :)
16:49:18 <springmeyer> http://developmentseed.org/blog/2010/jan/05/adding-pie-charts-map-tiles-using-svg-inkscape-and-tilecache
16:49:56 <springmeyer> in mapnik2/trunk we are considering adding the ability to load a url in symbolizers
16:50:28 <springmeyer> so that combined with the ability to use expressions might offer another route if you were using something like google charts
16:50:42 <springmeyer> but the inkscape stuff looks sharp :)
16:53:06 <springmeyer> so you could do something like:
16:53:27 <springmeyer> <PointSymbolizer url="http://chart.apis.google.com/chart?chs=50x50&chd=t:[SOME DATABASE FIELD],[ANOTHER FIELD]&cht=p3" type="png">
16:53:50 <aj_ashton> springmeyer: interesting, I had no idea about Google charts
16:53:58 <aj_ashton> that could be very cool
16:54:09 * springmeyer first need to get cascadenik understanding how to pass values...
16:57:17 <springmeyer> anyway, rockin job. will be great to review when we put though to making this easier to do in mapnik
16:58:06 <springmeyer> both legends and pie charts are pretty key features that we should support in core, just are going to take some work (as you can imagine :) )
17:03:11 <Ldp__> "I added perl-like alias operators to avoid escaping in XML." hmm, really? :-D
17:03:48 <Ldp__> ah, he's talking about the word variants (/me is reading artem's blog, finally)
17:04:50 <Ldp__> springmeyer: path expressions are very cool, but only work well when you're not forced to give the png dimensions in the symbolizer
17:05:50 <springmeyer> Ldp__: dimensions are now auto-read, so no longer needed (in trunk)
17:06:01 <Ldp__> and in the 0.7 branch?
17:06:16 <springmeyer> but we've talked about adding them back (as optional params) to allow for scaling, but needs more thought
17:06:23 <springmeyer> no, still required in 0.7
17:06:40 <springmeyer> Ldp__: I should probably port to 0.7....
17:06:42 <Ldp__> is that easy to backport?
17:06:45 <springmeyer> likely
17:07:07 <springmeyer> that feature and the symbol caching are the two things I am considering porting
17:07:22 <Ldp__> it will not bring much in the way of style/rule reduction in osm.xml with 0.7, but we could shave off some bytes by dropping explicit dimensions
17:07:47 <springmeyer> and its a usability thing, annoying to have to add them
17:07:55 <Ldp__> very much so
17:08:14 <Ldp__> but having them explicit to enable scaling sounds fine by me. I think that was talked about long ago
17:08:19 <springmeyer> Ldp__: regarding shaving bytes :) I also noticed the osm styles seem to alwasy declare the line-join/line-cap....
17:08:42 <springmeyer> should we change the default for any reason?
17:08:48 <Ldp__> springmeyer: never looked into the defaults before. Do we have a list of the defaults?
17:09:05 <springmeyer> no
17:09:09 <Ldp__> well, osm.xml works with rounded endcaps almost exclusively
17:09:30 <springmeyer> okay
17:09:31 <Ldp__> and joins too. I think only administrative boundary lines don't use them
17:09:54 <springmeyer> okay
17:10:07 <Ldp__> and I think rounded joins/caps are a reasonable default to have, since these make the most sense where lines meet at variable angles
17:10:31 <Ldp__> ie. in maps
17:11:14 <springmeyer> BUTT_CAP and MITRE_JOIN are defaults currently: http://trac.mapnik.org/browser/trunk/src/stroke.cpp#L56
17:11:21 <Ldp__> but changing the default in 0.7 could spell trouble
17:11:40 <springmeyer> right, this would be a 0.8 thing
17:11:51 <Ldp__> it's less of an issue with mapnik2, since the stylesheet needs to be adapted anyway
17:12:20 <springmeyer> my thinking is 0.7 series will have NO backwards incompatible changes while trunk is currently an opportunity to add them all at once
17:12:23 <springmeyer> yes
17:12:28 <Ldp__> although, just shooting from the hip here, being able to set global defaults in the stylesheet may also work?
17:12:47 <springmeyer> interesting thought surely
17:12:47 <Ldp__> that could be interesting to have in 0.8+
17:12:56 <springmeyer> we don't have a ticket for that :)
17:13:07 <springmeyer> but I recommend cascadenik for that anyway...
17:13:52 <Ldp__> cascadenik is a double-edged sword. It's great for development, but does require more tools for the end-user, and does require an extra compile after svn up.
17:14:09 <nikq> Mapnik Trac: Ticket #481 (Consider round defaults for line-join/line-cap) created | http://trac.mapnik.org/ticket/481
17:14:28 <Ldp__> be back later, dinner time
17:14:37 <springmeyer> same here, later
17:16:21 <nikq> Mapnik Trac: Ticket #481 (Consider round defaults for line-join/line-cap) updated | http://trac.mapnik.org/ticket/481#comment:1
17:38:39 *** tcb (n=tcb@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
18:16:31 *** rweait (n=nerd@weait.tor.istop.com) has joined #mapnik
18:30:09 *** perry_ (n=perry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
20:33:58 <nikq> Mapnik Trac: Ticket #13 (Rendering text labels when point size of labels exceeds the width of the  ...) updated | http://trac.mapnik.org/ticket/13#comment:12
20:42:27 <nikq> Mapnik Trac: Ticket #13 (Rendering text labels when point size of labels exceeds the length of the  ...) updated | http://trac.mapnik.org/ticket/13#comment:13
20:48:18 <springmeyer> thanks Ldp__ - I never noticed the botched title :)
20:49:21 <Ldp__> I noticed that many months ago, but didn't know if I was missing something
21:00:59 *** artem (n=artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
21:03:34 <artem> happy new year!
21:03:50 <Ldp__> springmeyer, artem: http://lists.openstreetmap.org/pipermail/dev/2010-January/018191.html
21:03:58 <Ldp__> I replied with #320
21:03:59 <nikq> Ticket #320: SVG-Based Symbolizers, http://trac.mapnik.org/ticket/320
21:04:11 <Ldp__> happy new year, artem!
21:04:20 <springmeyer> hello artem! cheers!
21:04:27 <artem> and you!
21:04:37 <springmeyer> arr, arr
21:04:59 * artem likes using cairo directly, avoiding pycairo
21:05:40 <springmeyer> cool, great
21:06:05 <springmeyer> me too, tho pycairo support is great
21:07:21 <nikq> Mapnik Trac: Ticket #381 (Expose cairo functionality without needing pycairo) updated | http://trac.mapnik.org/ticket/381#comment:5
21:08:40 <artem> can we have pycairo as an optional feature? disabled by default ?
21:09:52 <springmeyer> yes, good idea
21:10:11 <springmeyer> right now it is build if pycairo is found
21:10:14 <springmeyer> build/built
21:10:30 <artem> sound good
21:10:33 <artem> sounds
21:11:28 <artem> #308
21:11:30 <nikq> Ticket #308: Doesn't display feature if another (possibly invalid) feature is present, http://trac.mapnik.org/ticket/308
21:12:01 <artem> not sure what to do about this one...
21:12:52 <springmeyer> no?
21:13:03 <artem> I guess we need to clip every geometry to valid projection extent
21:13:39 <springmeyer> I had the same idea. could we clip just if the proj_transform fails?
21:15:15 <artem> I think (at least in agg renderer) geometry clipped against layer bbox already, we can just intersect that box with valid proj extent.
21:15:38 * artem checking
21:16:49 <springmeyer> cool
21:18:16 *** artem has quit ()
21:25:11 *** xreal (n=mweber@mailgw.FB12.Uni-Dortmund.DE) has joined #mapnik
21:25:26 <xreal> Is it possible to draw a symbole along the line? self repeating?
21:29:22 *** chad_burt has quit ("Leaving...")
21:30:33 <nikq> Mapnik Trac: Changeset [1512]: remove unneeded header | http://trac.mapnik.org/changeset/1512
21:31:10 <springmeyer> `LinePatternSymbolizer
21:31:11 <nikq> http://trac.mapnik.org/wiki/LinePatternSymbolizer
21:31:15 <xreal> thanks!
21:31:30 *** chad_burt (n=chad_bur@mm-01.msi.ucsb.edu) has joined #mapnik
21:39:08 <springmeyer> does anyone use Mapnik's jpeg output?
21:39:18 <Ldp__> the OSM exporter
21:39:56 * springmeyer looks
21:40:37 <springmeyer> yes, okay
21:41:00 <springmeyer> I am thinking about making it an optional compile-time thing
21:41:13 <springmeyer> but on by default
21:43:22 <Ldp__> what would it entail? only a smaller binary or an unexpected speedup somewhere?
21:45:17 *** CIA-16 has quit (Read error: 60 (Operation timed out))
21:45:45 <springmeyer> not much, just a slighly smaller binary and one less dependency for those compiling from source
21:47:41 <springmeyer> might not be worth the effort
21:59:14 <xreal> Is it possible to change the distance using LinePatternSymbolizer?
21:59:56 *** artem (n=artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
22:03:53 *** CIA-28 (n=CIA@208.69.182.149) has joined #mapnik
22:17:54 <springmeyer> xreal: I don't think so, just by changing the shape of the graphic
22:18:05 <xreal> Okay ;-(
22:18:10 <xreal> add to mapnik2 please ;-)
22:18:18 <xreal> It's a common feature in Cartography
22:19:47 <springmeyer> xreal: use the ShielSymbolizer if you need spacing
22:48:24 *** xreal has quit (Read error: 110 (Connection timed out))
23:21:30 <Ldp__> springmeyer: the ShieldSymbolizer doesn't align the graphic to the line
23:22:18 <springmeyer> does it not respect line placement?
23:22:41 <Ldp__> the graphic image itself is always straight up
23:23:11 <springmeyer> ah, okay
23:23:20 <springmeyer> makes sense
23:23:37 <springmeyer> should it be rotatable?
23:23:39 <Ldp__> but xreal should be able to make a png with an extra swath of transparent pixels to one side
23:24:07 <Ldp__> we have a ticket in OSM for a mountain pass symbol, which I've been thinking on how to solve
23:24:32 <Ldp__> but it's hard, of course, since you don't know from the point it's applied to what the connecting line geometry is
23:25:09 <springmeyer> can you give a link to the ticket?
23:25:41 <Ldp__> http://trac.openstreetmap.org/ticket/2140
23:25:57 <Ldp__> PS: I just read on osm-dev that Peter Körner, the one that wrote the svg symbolizer patch in #320 gave up on that
23:25:58 <nikq> Ticket #320: SVG-Based Symbolizers, http://trac.mapnik.org/ticket/320
23:27:16 <nikq> Mapnik Trac: Changeset [1513]: scons: make sure help is displayed if -h or --help is supplied even if we  ... | http://trac.mapnik.org/changeset/1513
23:28:17 <springmeyer> well all peter did was update a few things he did not write it
23:28:26 <Ldp__> ok
23:28:50 <springmeyer> so him "giving up" has no bearing on status, although I appreciate his updating the patch
23:29:11 <Ldp__> I haven't followed too closely, but those were his words on osm-dev
23:29:19 <springmeyer> right, I just read
23:29:49 <springmeyer> the patch falling behind trunk is certainly an issue, but the main issue holding it up is whether we can accept the added depedencies
23:30:42 <springmeyer> if we were comfortable with the dependencies it could likely be added any day as the code is pretty solid
23:31:16 <Ldp__> I know the maposmatic guys would be ecstatic, as would any other person making print copies of maps
23:31:29 <springmeyer> yes, I am one of them :)
23:31:43 <springmeyer> the huge list of dependencies is one thing that got me started working on Mac OS X binaries
23:31:57 <Ldp__> could you make it configurable like you wanted to do with jpeg, and only need the dependency when you enable SVG ?
23:32:07 <springmeyer> if we could build and distribute solid binaries for mac and windows I would be much more comfortable with adding the deps
23:32:19 <Ldp__> gotcha
23:32:24 <springmeyer> Ldp__: yes, the patch actually already works that way
23:33:09 <Ldp__> I'm willing to build Windows svn builds now and again, but would need a solid guide to get started. Don't want to reinvent the wheel, takes too much time.
23:33:29 <springmeyer> but last I looked it interweaved cairo dependence into the agg stuff too heavily
23:33:50 <springmeyer> Ldp__: hear you there
23:34:50 <springmeyer> I could be swayed either way though. I defer to artem on this one...
23:37:25 <Ldp__> ok
23:39:30 <artem> Ldp__: I'll be looking into this asap. Either way svg icons is a must have in 2010
23:39:42 <Ldp__> the year is young
23:39:57 <artem> :)
23:43:00 <springmeyer> cool artem
23:43:01 <Ldp__> I was thinking of finding out the direction of a mountain pass svg symbol by taking the point, retrieving the line it is part of, taking only a few dozen meters each side of the point, simplifying that to hell, and end up with a short straight-ish line section that indicates the direction of the mountain pass.
23:43:06 <springmeyer> if anyone could test and give feedback on r1513 that would be great
23:43:07 <Ldp__> That still won't help in rotating an SVG icon, but I could trick it with a few LineSymbolizers.
23:43:12 <nikq> http://trac.mapnik.org/changeset/1513, at , by dane: scons: make sure help is displayed if -h or --help is supplied even if we are not able to configure successfully and add more user friendly output for dependencies that are not found
23:43:23 <Ldp__> Still, a lot of work :/
23:43:30 <springmeyer> interesting Ldp__
23:43:57 <Ldp__> yeah, but would only work with postgis, and it's extra processing during rendering
23:44:29 <Ldp__> and the length of the generated section of road would vary with latitude?
23:45:12 <Ldp__> I have the same issue with turning circles, when I want to find out which type of road they're part of, so I can stylize them depending on that. :)
23:45:41 <springmeyer> I have basic image rotation code in the line offsets patch...
23:45:42 <Ldp__> mapnik can't solve that... have to do it in postgis
23:45:51 <artem> Ldp__: sounds like mapnik2 feature, needs thinking though
23:45:57 <springmeyer> gah, glad the year is young!
23:46:11 <Ldp__> image rotation is nice, but we'd be working with a point. A point has no direction.
23:46:32 <artem> but it can have an attribute ?
23:46:55 <Ldp__> now, if I could tell mapnik "put a symbol at this point, and have it rotated so it would point at this other geom"... then we'd be on to something great
23:47:26 <Ldp__> sure it can have an attribute, but how would be calculate the attribute?
23:47:32 <springmeyer> oh, forgot it was not on a line
23:48:36 <Ldp__> osmarender has an option (used with turning circles) where it can relate the node to the way it is in
23:49:21 <Ldp__> but it has access to the bare .osm. We have to work with the postgis schema, so I'll have to solve it in SQL
23:50:44 *** j03lar50n (n=SLU_GIS@68-189-119-178.static.wscr.ca.charter.com) has joined #mapnik
23:51:11 <nikq> Mapnik Trac: Changeset [1514]: scons: make sure help is displayed if -h or --help is supplied even if we  ... | http://trac.mapnik.org/changeset/1514
23:51:25 <Ldp__> springmeyer: do you know if qGIS makes use of shapeindex generated indexes?
23:51:54 <springmeyer> you mean QGIS or the Quantumnik plugin?
23:52:00 <Ldp__> qgis itself
23:52:08 <springmeyer> QGIS likely builds indexes for OGR to use
23:52:20 <springmeyer> as I think QGIS loads all vectors through OGR
23:52:29 *** perry_ has quit ()
23:52:38 <springmeyer> and would not use anything generated by mapnik's shapeindex program
23:52:45 *** aj_ashton has quit (Remote closed the connection)
23:52:56 <Ldp__> ok, thought maybe it was part of a generalized way of indexing shapefiles
23:53:06 <artem> springmeyer: r1514 works for me
23:53:07 <nikq> http://trac.mapnik.org/changeset/1514, at , by dane: scons: make sure help is displayed if -h or --help is supplied even if we are not able to configure successfully and add more user friendly output for dependencies that are not found
23:53:13 <springmeyer> no, I think artem cooked it up?
23:53:17 <springmeyer> artem: great
23:54:17 <springmeyer> 1513/1514 fixes the first problem that bugged me about Mapnik, that I could not get any help until SCons found all dependencies
23:54:20 <springmeyer> embarrassing that somehow I introduced that bug again :)
23:54:53 * springmeyer back before he know what C++ was....
23:58:50 <artem> Ldp__:  shapeindex is inspired by mapserver index which is probably the same as ogr index, not sure. But data stored in each tree node is slightly different