02:57:31 *** mapniklog (n=mapniklo@li21-121.members.linode.com) has joined #mapnik 02:57:31 <calvino.freenode.net> Topic for #mapnik is: Mapnik - C++/Python Toolkit | Mapnik 0.7.0 released 02:57:31 <calvino.freenode.net> Users on #mapnik: mapniklog ajturner @springmeyer jctull chad_burt rcoup mperry dodobas cmarqu mishok13 twain47 Primer crust tomhughes mapnikbuild Simon- racicot CIA-21 avar nikq dukeku hobu ser 03:11:38 <nikq> Mapnik Trac: Ticket #499 (Graceful recovery if postgres connection is lost) created | http://trac.mapnik.org/ticket/499 03:29:13 <nikq> Mapnik Trac: Ticket #477 (semitransparency support for png256) updated | http://trac.mapnik.org/ticket/477#comment:9 03:32:16 <nikq> Mapnik Trac: Changeset [1587]: my first ever commit to a tag - fixup spelling of 0.7.0 release CHANGELOG | http://trac.mapnik.org/changeset/1587 03:36:50 <nikq> Mapnik Trac: Release0.7.0 edited | http://trac.mapnik.org/wiki/Release0.7.0?version=3 03:38:42 <nikq> Mapnik Trac: Ticket #492 (hanging and/or MemoryError thrown if png icon is not found) closed | http://trac.mapnik.org/ticket/492#comment:1 03:40:23 <nikq> Mapnik Trac: Ticket #428 (Polygons and "the problem of adjacent edges") updated | http://trac.mapnik.org/ticket/428#comment:6 03:56:28 <nikq> Mapnik Trac: Ticket #414 (Use Find_SRID in postgis driver) updated | http://trac.mapnik.org/ticket/414#comment:3 03:57:29 *** chad_burt has quit (Client Quit) 03:58:50 <nikq> Mapnik Trac: Ticket #456 (Expose an option to allow for the PostGIS extent to be calculated upon ...) updated | http://trac.mapnik.org/ticket/456#comment:4 03:59:00 <nikq> Mapnik Trac: Ticket #260 (Improve flexibility and reliability of PostGIS SQL/Query handling) updated | http://trac.mapnik.org/ticket/260#comment:19 03:59:10 <nikq> Mapnik Trac: Ticket #428 (Polygons and "the problem of adjacent edges") updated | http://trac.mapnik.org/ticket/428#comment:7 03:59:40 <nikq> Mapnik Trac: Ticket #433 (PostGIS connection is not released when datasource is deleted) updated | http://trac.mapnik.org/ticket/433#comment:4 04:00:01 <nikq> Mapnik Trac: Ticket #466 (Catch up on Changelog before 0.7.0 release) updated | http://trac.mapnik.org/ticket/466#comment:5 04:00:11 <nikq> Mapnik Trac: Ticket #485 (TextSymbolizer vertical_align should have varying default) updated | http://trac.mapnik.org/ticket/485#comment:3 04:22:15 *** ajturner has quit () 04:23:02 *** ajturner (n=ajturner@pool-72-66-109-70.washdc.fios.verizon.net) has joined #mapnik 04:54:58 *** ajturner has quit () 05:01:30 <nikq> Mapnik Trac: Changeset [1588]: fixup CHANGELOG in trunk | http://trac.mapnik.org/changeset/1588 05:03:11 <nikq> Mapnik Trac: Ticket #489 (Sync CHANGELOG in trunk after tagging 0.7.0) closed | http://trac.mapnik.org/ticket/489#comment:2 05:05:08 <springmeyer> fyi all: 05:05:11 <springmeyer> https://lists.berlios.de/pipermail/mapnik-users/2010-January/002856.html 05:07:54 *** springmeyer has quit () 05:34:28 *** cgs_bob (n=bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 05:57:27 *** HounD (n=HounD@unics1.grfc.ru) has joined #mapnik 06:11:45 *** tcarobruce (n=tim@c-98-210-194-147.hsd1.ca.comcast.net) has joined #mapnik 06:24:51 *** dodobas has quit (Read error: 110 (Connection timed out)) 06:34:16 *** dodobas (n=dodobas@open.geof.hr) has joined #mapnik 06:48:13 *** springmeyer (n=springme@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 07:48:18 *** Phurl (n=mdupont@ip-81-210-245-60.unitymediagroup.de) has joined #mapnik 09:40:50 *** myselfhimself (n=chatzill@91.199.6.245) has joined #mapnik 09:40:52 <myselfhimself> hi !! 09:41:01 *** tcarobruce has parted #mapnik () 09:45:22 *** rcoup has quit () 10:25:19 <dodobas> yello 10:27:30 <myselfhimself> hi !! 10:53:44 *** friism (n=friism@81.19.246.10) has joined #mapnik 11:48:45 *** friism has quit (Remote closed the connection) 11:53:44 *** friism (n=friism@81.19.246.10) has joined #mapnik 11:58:45 *** friism_ (n=friism@81.19.246.10) has joined #mapnik 12:02:41 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik 12:05:29 *** Ldp__ has quit (Client Quit) 12:09:23 *** friism__ (n=friism@80.63.59.51) has joined #mapnik 12:13:22 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik 12:17:03 *** friism_ has quit (Read error: 110 (Connection timed out)) 12:17:46 *** friism has quit (Read error: 110 (Connection timed out)) 12:48:17 *** friism__ has quit (Read error: 110 (Connection timed out)) 12:58:29 *** Dominic244 (n=Dominic@dialbs-213-023-220-018.static.arcor-ip.net) has joined #mapnik 12:58:35 <Dominic244> hey guys" 12:59:15 <Dominic244> someone here who has exoerience wit installing mod_tile 13:01:24 <twain47> maybe. Seems to be the theme of the moment... 13:01:46 <twain47> Dominic244: What's the problem? 13:14:47 *** friism (n=friism@80.63.59.51) has joined #mapnik 13:43:52 *** avar has quit (calvino.freenode.net irc.freenode.net) 13:56:54 *** willwhite (n=diggersf@c-69-136-229-112.hsd1.dc.comcast.net) has joined #mapnik 13:59:47 *** friism has quit (Read error: 110 (Connection timed out)) 13:59:54 *** friism (n=friism@80.63.59.51) has joined #mapnik 14:12:47 *** avar (i=avar@wikipedia/avar) has joined #mapnik 14:33:08 *** myselfhimself_ (n=chatzill@ppp-216.net-62-100-141.static.magiconline.fr) has joined #mapnik 14:34:29 <myselfhimself_> can you kick "myselfhimself" ? 14:34:43 <myselfhimself_> anyway it'll get disconnected 14:34:52 <myselfhimself_> it's a remainder from my ethernet connection 14:35:30 <myselfhimself_> ok anyway 14:37:05 *** friism has quit (Read error: 60 (Operation timed out)) 14:38:08 *** myselfhimself has quit (Read error: 110 (Connection timed out)) 14:38:17 *** myselfhimself_ is now known as myselfhimself 15:05:42 *** HounD has parted #mapnik () 15:51:39 *** myselfhimself_ (n=chatzill@ppp-216.net-62-100-141.static.magiconline.fr) has joined #mapnik 15:51:47 *** myselfhimself has quit (Read error: 110 (Connection timed out)) 15:51:48 *** myselfhimself_ is now known as myselfhimself 16:06:18 <myselfhimself> hey 16:20:50 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik 16:23:33 *** Dominic244 has quit ("http://irc2go.com/") 16:40:05 *** chad_burt (n=chad_bur@mm-01.msi.ucsb.edu) has joined #mapnik 16:53:04 *** myselfhimself has quit (Remote closed the connection) 16:57:20 *** myselfhimself (n=chatzill@ppp-216.net-62-100-141.static.magiconline.fr) has joined #mapnik 16:59:39 *** drewby (n=dfaubion@128-8-138-156.umd.edu) has joined #mapnik 17:00:01 <drewby> I am in need of the ability to draw offset lines. I hear there's a patch floating around for that. 17:00:49 <Ldp__> #180 17:00:50 <nikq> Ticket #180: Parameter for line symbolizer to offset line to one side, http://trac.mapnik.org/ticket/180 17:01:26 <drewby> oh haha, I was looking at that, I didn't see tha patch that was attached at the top 17:01:39 <springmeyer> it needs work to be updated to trunk as I did not have the time to work on it's including in 0.7.0 release 17:01:46 <drewby> I continue to make a fool of myself in this chat, either way thanks 17:01:52 <Ldp__> query springmeyer for the current status. I don't know if the patch cleanly applies anymore 17:02:29 <springmeyer> ya, certainly will not apply cleanly to anything recent 17:02:58 <drewby> I'll see if I can do anything 17:03:00 <springmeyer> and I have an additional one that refactors it and added partial support to the LinePatternSymbolizer that I've yet to share 17:03:16 <Ldp__> springmeyer: is it still on track for 0.8 ? 17:03:22 <myselfhimself> How do I render a Mapnik's bbox around a postgres request, into png tiles which have an alpha channel set to opacity=0 for pixels not filled by any layer ? 17:03:26 <springmeyer> certainly Ldp__ 17:04:42 <Ldp__> myselfhimself: <Map background="transparent"> for the last part of your question 17:12:31 <myselfhimself> Ldp__: ok thanks 17:13:11 <myselfhimself> Ldp__: being able to obtain a bbox/extent of a pgsql query in a Layer's datasource is a feature from 0.7 I think 17:13:18 *** jctull has quit () 17:13:18 <myselfhimself> like !bbox! 17:13:21 <myselfhimself> I'll find that 17:13:34 <Ldp__> the bbox is always applied to the query, even in earlier versions 17:13:36 <myselfhimself> is this !bbox! feature also already in mapnik 0.8 ? 17:13:39 <myselfhimself> Ldp__: ok 17:13:58 <Ldp__> myselfhimself: see the 2nd box on http://trac.mapnik.org/wiki/OptimizeRenderingWithPostGIS 17:20:04 <springmeyer> myselfhimself: you will not need to care about using !bbox!, that is only for custom placement if very unique queries 17:20:10 <springmeyer> if/in 17:20:29 <myselfhimself> springmeyer: ok 17:20:40 <myselfhimself> Ldp__: ok I've just read the full page thanks 17:20:44 <myselfhimself> springmeyer: thanks 17:21:12 <Ldp__> there are some new tricks, like the !bbox! you mentioned, that would deserve a spot on that page 17:21:55 <myselfhimself> ok 17:22:44 *** tcb_ (n=tcarobru@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik 17:26:16 <myselfhimself> with mapnik's cpp library (I mean from mod_tile), is that possibly to 1) open an osm.xml file, 2) disable "online" some layers and enable others, 3) run a tile rendering for a specific tile/small bbox ? 17:27:40 <Ldp__> didn't you ask 2) yesterday already, or was that someone else? 17:28:02 <myselfhimself> Ldp__: maybe that was Micka 17:28:04 <Ldp__> if it's not possible, you can open an enhancement ticket 17:28:08 <myselfhimself> ok 17:28:12 <myselfhimself> I have to read the api.. 17:28:17 <myselfhimself> api reference 17:28:23 <myselfhimself> Micka is another team member 17:28:38 <myselfhimself> I've been asking questions around this topic anyway today 17:28:39 <Ldp__> 3) you always have to tell mapnik which bbox you want to render 17:29:07 <Ldp__> 1) of course 17:30:08 <myselfhimself> for 2) instead of enabling disabling/layers, I would want instead to rewrite a layer (eg. name="LayerToGetAParticularLevelChangeMyPGSQL")'s pgsql code to filter a specific level 17:30:39 <myselfhimself> that's better for me than generating osmlevel1.xml, osmlevel2.xml etc... 17:30:59 <Ldp__> level=zoom? 17:31:07 <Ldp__> or building level? 17:31:09 <myselfhimself> no level is a floor 17:31:11 <myselfhimself> yes building level 17:31:48 <myselfhimself> for floor / level, the objects to render are different and are filtered by tag level=N, where N is a determined integer 17:31:53 <Ldp__> if you have a level column in your postgis input, what's the problem? 17:32:38 <myselfhimself> there's no problem... 17:32:44 <Ldp__> you're not mapping the Petronas Towers or Burj al-Dubai yet, I presume. How many levels will you handle 17:32:46 <myselfhimself> I can do the pgsql filtering correctly 17:32:59 <myselfhimself> 2 levels (for a prototype for next thursday/friday) 17:33:20 <myselfhimself> I'll have to hack mod_tile... 17:33:22 <Ldp__> so have 2 sets of rules, and filter on level 17:33:30 <myselfhimself> yes 17:33:52 <myselfhimself> 2 sets of rules... or one DataSource code that gets customized online ? 17:34:00 <Ldp__> either way 17:34:23 <Ldp__> I think you can load an XML through the API, and then add more styles/rules/layers on top of that 17:34:34 <Ldp__> but I'm no API expert, springmeyer is 17:34:54 <myselfhimself> yes 17:35:05 <myselfhimself> I'll make an effort and read that api 17:35:06 <Ldp__> so have a base XML, and add the custom stuff at runtime 17:35:15 <myselfhimself> yes that's what's best 17:35:47 <myselfhimself> then I have to design something, an interface between mod_tile and mapnik 17:36:34 <Ldp__> you can talk directly to renderd from your own code, too 17:36:48 <Ldp__> but yeah, renderd will have loaded an XML already 17:36:49 <nikq> Mapnik Trac: LinuxInstallation edited | http://trac.mapnik.org/wiki/LinuxInstallation?version=10 17:37:30 <Ldp__> don't know why you don't write your own code. Seems very hard to do in mod_tile, without extensive customizations 17:38:31 * springmeyer agrees 17:38:38 * myselfhimself : ) 17:38:54 <springmeyer> likes like a web application that should be written on top of mapnik python api 17:38:58 <myselfhimself> or I can hack tilecache or tilelite 17:39:07 <springmeyer> no 17:39:18 <springmeyer> both has very specific ideas of request handling 17:39:34 <springmeyer> and intentionally don't look for arbitrary styles to be applied 17:39:57 <springmeyer> because that is much easier handled by your own code to do request handling 17:40:14 <myselfhimself> ok but I want to do caching as well 17:40:19 <myselfhimself> this would spare me that 17:40:39 <springmeyer> caching is pretty simple 17:40:47 <springmeyer> worry about that later 17:42:36 <myselfhimself> at least I'll need style caching, so that I'm not generating level1's style again before rendering upon each level1/somepng.png request 17:43:33 <Ldp__> seems like you're thinking of different branches in the styles, which is an interesting concept 17:46:28 <myselfhimself> the postgresql queries could have dynamic variables like select * from tables where value=[variableIcanSetAsAparameterByMapnikComplementedAPI] 17:49:06 <myselfhimself> and I could style = mapnik.openStyle("osm.xml), level1Style=mapnik.customizeStyle(style,{"variableIcanSetAs...":1})... then myTileLevel1 = mapnik.render(level1Style,bbox) 17:49:41 <myselfhimself> this could be a stupid as C #define doing full find & replace 17:50:45 <drewby> springmeyer, the offset code works like a charm 17:50:55 <drewby> now if only all my roads were pointing in the same direction 17:51:17 <springmeyer> drewby: that is charming, which svn r did you apply to? 17:51:21 <myselfhimself> mapnik uses sax so the api I'm imagining is not easy to implement and should have another form 17:51:43 <drewby> springmeyer: 7.0 release 17:52:01 <springmeyer> ah, well that is a miracle, great 17:52:28 <drewby> springmeyer: I just went through the patch and applied it by hand, it took all of 10 minutes 17:52:35 <springmeyer> the funding for that project kind of ran out abruptly, so glad it works for you 17:52:37 <springmeyer> ah, I see 17:53:08 <Ldp__> may I suggest making a new diff and attaching it to #180? :) 17:53:08 <nikq> Ticket #180: Parameter for line symbolizer to offset line to one side, http://trac.mapnik.org/ticket/180 18:18:12 *** drewby has quit ("Leaving.") 18:25:40 *** drewby (n=dfaubion@128-8-138-156.umd.edu) has joined #mapnik 18:29:50 <drewby> I can't figure out how to do a diff to send you guys the patch ^^. 18:41:37 <drewby> how to keep it from exploding on sharp angles 18:41:44 <drewby> my postgis function did that too 18:42:41 <springmeyer> hey drewby 18:42:47 <drewby> yeah 18:42:53 <springmeyer> I gather you did not check out from svn? 18:43:10 <drewby> I did 18:43:15 <springmeyer> if not, you can download a fresh 0.7.0 copy.. 18:43:16 <springmeyer> oh 18:43:20 <springmeyer> $ svn diff 18:43:20 <springmeyer> ? 18:43:33 <springmeyer> svn diff > your.patch 18:44:30 <drewby> and then attach it to the ticket in trac? 18:44:39 <springmeyer> yes, exactly 18:44:56 <springmeyer> ideally do that command from the base source directory, not a subdirectory 18:46:14 <drewby> I don't think I have the power to comment on tickets 18:46:31 <springmeyer> you should, just have to be logged in 18:46:56 <drewby> oh. needed to refresh 18:46:59 <springmeyer> if its a hassle for you just http://dpaste.com the patch 18:47:01 <springmeyer> ah 18:47:55 <springmeyer> re: "exploding on sharp angles" yes it does not make an attempt to handle blown out offsets 18:48:23 <nikq> Mapnik Trac: offset-0.7.0.patch attached to Ticket #180 | http://trac.mapnik.org/attachment/ticket/180/offset-0.7.0.patch 18:48:29 <springmeyer> I tested the offset functionality in ArcGIS and it also suffered from that problem 18:48:31 <springmeyer> so I figured that could be a later phase item 18:50:02 <drewby> my indenting is screwy or something 18:50:23 <springmeyer> no worries 18:50:50 <drewby> I'm gonna work on the exploding issue 18:50:55 <springmeyer> could be a tabs vs. spaces issue 18:51:01 <springmeyer> drewby: thats awesome 18:51:38 *** jctull (n=jctull@adsl-75-0-10-64.dsl.renocs.sbcglobal.net) has joined #mapnik 18:52:21 <springmeyer> hey jctull 18:52:34 <jctull> springmeyer: hi 18:53:00 <springmeyer> I recall your noticing issues in QGIS with display over overlapping dashed lines 18:53:25 <jctull> yes 18:54:22 <springmeyer> not sure if you've tried this.... painting a thin line underneath in the same color as the map background? 18:54:34 <springmeyer> solid thin that is, below the dashed lines 18:55:04 <springmeyer> I did some quick testing and it seems to work decently in Mapnik 18:55:05 <jctull> usually my maps have enough complexity in the base layers that that probably would not work too well 18:55:19 <jctull> I often use topo maps as base information 18:55:20 <springmeyer> ah, good point 18:55:23 <jctull> and hillshades 18:56:13 <jctull> it's a complex problem, I guess, b/c the renderer would have to check for common polygon boundaries in multipolygons and only render those once 18:56:19 <springmeyer> so for that case you'd really need to enforce that the dashed line is only drawn once, or have it be an "erasing stroke" effect 18:56:23 <springmeyer> yep 18:56:40 <springmeyer> or the datatype would have to be topological 18:56:48 <springmeyer> so the renderer truly would only draw one line 18:56:58 <springmeyer> would would be ideal for performance too 18:57:50 <springmeyer> well, my fiddling with the simple use case (which won't work for you) is now in Quantumnik 0.3.1.... 18:58:35 <springmeyer> I added it at the same time as adding a fix for keeping the seamless look between polygons 18:58:46 <springmeyer> which was the original issue that got us chatting about this I think 18:59:00 <springmeyer> when it turned out we were thinking about different things :) 18:59:03 <jctull> that's progress, right? 18:59:47 <springmeyer> ya, for sharp/crisp looking stylistic maps with intentionally non-complex colors and lines 18:59:56 <springmeyer> it solves the problem 19:00:03 <jctull> that's good 19:03:32 <springmeyer> although, in my testing I screwed up once and painted a solid color line underneath a dash line that was different that the background of the map 19:03:44 *** rcoup (n=rcoup@131.203.102.171) has joined #mapnik 19:04:14 <springmeyer> and it actually can bring out the dashes nicely, but at that point its in the eye of the beholder of course... 19:04:41 <jctull> So, if you have a common boundary issue, how will this help? 19:05:06 <jctull> The common boundary will be rendered on top of the line beneath, so it will still overdraw itself, right?> 19:05:38 <jctull> I will have to mess around with it and see what it looks like 19:06:30 <springmeyer> not in Mapnik (and I assume in Symbology-ng)... 19:06:55 <springmeyer> it works because the line drawing order goes.... 19:07:27 <springmeyer> draw feature (draw solid line, draw dashed line), draw next features (draw solid line... 19:12:37 <springmeyer> jctull: http://dbsgeo.com/tmp/dash_underlay_approach.png 19:13:31 <springmeyer> there is some slight distortion on strait lines but overall its close to the mark i think. 19:13:46 <jctull> I see, using symbology ng with multiple patterns/lines, not duplicate map layers 19:13:55 <springmeyer> exactly 19:14:01 <jctull> hey, you even got my state in the middle ;) 19:14:18 <springmeyer> I centered on burning man 19:14:19 <jctull> I will play with that approach. It would still be a big improvement! 19:14:23 <springmeyer> jk 19:14:24 <jctull> good thinking 19:14:32 <jctull> heh 19:14:47 <jctull> you need to go a little north and west, but you're close 19:15:04 <springmeyer> lets just say that your state looks a like nicer that say the border of Idaho 19:15:31 <springmeyer> for that to look good dashed we'd ne on-the-fly line bezier smoothing 19:16:45 <jctull> get to work ;) 19:17:43 <springmeyer> ha, its already implemented, just needs testing :) 19:17:47 <springmeyer> #332 19:17:47 <nikq> Ticket #332: Rendering curved paths, http://trac.mapnik.org/ticket/332 19:19:21 *** ajturner has quit () 19:22:37 <jctull> nice 19:25:13 *** rcoup has quit () 19:48:07 *** drewby has quit ("Leaving.") 19:49:16 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik 20:04:46 *** tomhughes has quit ("Coyote finally caught me") 20:07:56 *** tomhughes (n=tom@gate.compton.nu) has joined #mapnik 20:09:58 *** drewby (n=dfaubion@128-8-138-156.umd.edu) has joined #mapnik 20:10:09 <drewby> hahaha, the mapserver sources are ummm.... 20:10:34 <drewby> interesting 20:10:35 <springmeyer> huh? 20:10:46 <springmeyer> wrong window? ;) 20:11:14 <drewby> actually I'm'a see how mapserver does offsets cause it works pretty well in mapserver 20:11:22 <drewby> I just can't keep writing mapfiles 20:11:36 <drewby> they get to be thousands of lines of 90% duplicate code 20:11:47 <springmeyer> ah, thats why you are looking, gocha 20:13:29 * springmeyer didn't think mapserver supported anything but simple x,y coordinate offsets... 20:13:36 <springmeyer> eg. shifts 20:13:57 <drewby> no, they have along-line offset 20:14:37 <springmeyer> nice 20:15:30 * springmeyer did search around before starting to code that initial patch and found literally nothing out there 20:15:51 <springmeyer> guess I didn't look hard 20:15:54 *** drewby has quit (Read error: 54 (Connection reset by peer)) 20:16:07 *** drewby (n=dfaubion@128-8-138-156.umd.edu) has joined #mapnik 20:16:26 <drewby> it's poorly documented but if you set the why offset to -99 it swtiches to following along the line 20:16:41 <springmeyer> lol 20:17:08 *** Phurl has quit (Read error: 110 (Connection timed out)) 20:17:32 <springmeyer> by that you mean beside the line? 20:17:52 *** Phurl (n=mdupont@ip-81-210-245-60.unitymediagroup.de) has joined #mapnik 20:19:25 <drewby> yeah 20:19:45 <drewby> and I mean y offset not the why offset, darn autocorrect 20:20:20 <springmeyer> :) 20:20:44 <springmeyer> maybe in mapnik we should use that keyword why=1, ex=-1 :) 20:20:52 <springmeyer> secret feature! 20:22:09 <drewby> hahaha 21:02:58 <myselfhimself> see you thanks for all 21:03:00 *** myselfhimself has parted #mapnik () 21:18:42 <springmeyer> cmarqu: have you ever noticed that microsoft's map's have very soft, glowing text halos? 21:19:07 <springmeyer> curious if you've ever gotten/tried that amount of glow with mapnik... 21:20:28 <springmeyer> http://ecn.t7.tiles.virtualearth.net/tiles/r02123002133.png?g=401&mkt=en-us&shading=hill&n=z 21:20:30 <nikq> Mapnik Trac: Ticket #500 (Fix PostGIS datasource's schema support) created | http://trac.mapnik.org/ticket/500 21:21:21 <nikq> Mapnik Trac: mapnik-postgis.patch attached to Ticket #500 | http://trac.mapnik.org/attachment/ticket/500/mapnik-postgis.patch 21:21:56 *** drewby has quit ("Leaving.") 21:22:38 *** drewby (n=dfaubion@128-8-138-156.umd.edu) has joined #mapnik 21:38:31 <nikq> Mapnik Trac: Ticket #500 (Fix PostGIS datasource's schema support) updated | http://trac.mapnik.org/ticket/500#comment:1 21:48:09 <nikq> Mapnik Trac: Ticket #500 (Fix PostGIS datasource's schema support) updated | http://trac.mapnik.org/ticket/500#comment:2 21:50:00 <nikq> Mapnik Trac: Ticket #500 (Fix PostGIS datasource's schema support) updated | http://trac.mapnik.org/ticket/500#comment:3 21:54:51 *** drewby is now known as tclmetk 21:55:08 *** tclmetk is now known as tcl_me_tk 22:15:32 *** rcoup (n=rcoup@64.136.LCA2010.fx.net.nz) has joined #mapnik 22:18:34 *** rcoup has quit (Client Quit) 22:23:18 <nikq> Mapnik Trac: Ticket #500 (Fix PostGIS datasource's schema support) updated | http://trac.mapnik.org/ticket/500#comment:4 23:26:10 *** friism (n=friism@81.19.246.10) has joined #mapnik 23:33:03 *** rcoup (n=rcoup@64.136.LCA2010.fx.net.nz) has joined #mapnik 23:38:10 *** springmeyer_ (n=springme@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 23:39:05 *** springmeyer has quit (Read error: 113 (No route to host)) 23:39:38 *** springmeyer_ is now known as springmeyer 23:48:53 *** willwhite has quit ("Leaving") 23:53:16 *** tcl_me_tk has quit ("Leaving.")