00:28:28 *** lordelph (n=paul@cpc1-hitc3-0-0-cust120.lutn.cable.ntl.com) has joined #mapnik
00:28:36 *** lordelph has quit (Remote closed the connection)
00:52:44 *** lordelph1 has quit (Read error: 110 (Connection timed out))
01:00:44 *** rcoup_ (n=rcoup@ip-118-90-117-9.xdsl.xnet.co.nz) has joined #mapnik
01:10:50 *** rcoup has quit (Read error: 110 (Connection timed out))
02:00:48 *** sanjiv has quit ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032711]")
04:10:39 <nikq> Mapnik Trac: Ticket #270 (mapnik.ogcserver.configparser: "Change SafeConfigParser behavior to treat  ...) created | http://trac.mapnik.org/ticket/270
04:11:46 <nikq> Mapnik Trac: Ticket #270 (mapnik.ogcserver.configparser: "Change SafeConfigParser behavior to treat  ...) closed | http://trac.mapnik.org/ticket/270#comment:1
04:15:13 <nikq> Mapnik Trac: Changeset [1030]: scons: normalize paths written to 'paths.py' to avoid double '//' | http://trac.mapnik.org/changeset/1030
04:17:05 <nikq> Mapnik Trac: Changeset [1031]: fix scale_denominator to be a method (not property) and shuffle  ... | http://trac.mapnik.org/changeset/1031
04:24:02 <nikq> Mapnik Trac: Changeset [1032]: ogcserver: in relation to load_XML() rename and break apart methods for  ... | http://trac.mapnik.org/changeset/1032
04:25:03 <nikq> Mapnik Trac: Changeset [1033]: ogcserver: add module level docstrings for remaining ogcserver files | http://trac.mapnik.org/changeset/1033
04:27:20 <nikq> Mapnik Trac: Ticket #267 (Add module/file level docstrings to __init__.py and ogcserver module files) updated | http://trac.mapnik.org/ticket/267#comment:1
04:32:24 <nikq> Mapnik Trac: Changeset [1034]: add docstrings to main boost python functions | http://trac.mapnik.org/changeset/1034
04:33:05 <nikq> Mapnik Trac: Ticket #267 (Add module/file level docstrings to __init__.py and ogcserver module files) closed | http://trac.mapnik.org/ticket/267#comment:2
04:33:25 <nikq> Mapnik Trac: Ticket #268 (Add docstrings to top level python functions  ...) closed | http://trac.mapnik.org/ticket/268#comment:1
04:37:31 <nikq> Mapnik Trac: Changeset [1035]: add docstrings to top of file and factory methods in __init__.py and  ... | http://trac.mapnik.org/changeset/1035
04:38:42 <nikq> Mapnik Trac: Ticket #270 (mapnik.ogcserver.configparser: "Change SafeConfigParser behavior to treat  ...) updated | http://trac.mapnik.org/ticket/270#comment:2
04:39:13 <nikq> Mapnik Trac: Ticket #244 (Support interleaved ShieldSymbolizers on a way) updated | http://trac.mapnik.org/ticket/244#comment:2
04:39:57 <nikq> Mapnik Trac: Ticket #227 (Doctrings in __init__.py for Input Plugins) closed | http://trac.mapnik.org/ticket/227#comment:2
04:42:00 <nikq> Mapnik Trac: Ticket #265 (Before 0.6.0 remove the doxygen docs and update the epydocs) updated | http://trac.mapnik.org/ticket/265#comment:1
04:42:16 <nikq> Mapnik Trac: Ticket #269 (Fix the mapnik/__init__.py to use the python style of 4 space indents) updated | http://trac.mapnik.org/ticket/269#comment:1
04:42:36 <nikq> Mapnik Trac: Ticket #269 (Fix the mapnik/__init__.py to use the python style of 4 space indents) closed | http://trac.mapnik.org/ticket/269#comment:2
04:43:11 <nikq> Mapnik Trac: Ticket #266 (Update the OGCServer docs to reflect load_map() functionality) updated | http://trac.mapnik.org/ticket/266#comment:1
04:57:45 *** rcoup (n=rcoup@ip-118-90-117-9.xdsl.xnet.co.nz) has joined #mapnik
04:58:37 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
05:02:21 *** jlivni (n=josh@76.14.74.234) has joined #mapnik
05:10:03 <nikq> Mapnik Trac: Changeset [1036]: add docstring for Datasource wrapper | http://trac.mapnik.org/changeset/1036
05:15:43 *** rcoup_ has quit (Read error: 110 (Connection timed out))
05:16:10 *** rcoup has quit (Read error: 110 (Connection timed out))
05:20:02 <nikq> Mapnik Trac: Changeset [1037]: replaced 'epydocs' folder with 'api_docs/python' using revised api  ... | http://trac.mapnik.org/changeset/1037
05:20:33 <nikq> Mapnik Trac: Ticket #265 (Before 0.6.0 remove the doxygen docs and update the epydocs) updated | http://trac.mapnik.org/ticket/265#comment:2
05:22:55 <nikq> Mapnik Trac: Changeset [1038]: set html mime-type on new python api docs so we can view them at:  ... | http://trac.mapnik.org/changeset/1038
05:23:21 <springmeyer> fyi: http://svn.mapnik.org/trunk/docs/api_docs/python/index.html
05:57:07 *** stamf has quit (Read error: 110 (Connection timed out))
05:57:44 *** weizhuo has quit (Read error: 110 (Connection timed out))
05:58:14 <nikq> Mapnik Trac: Ticket #261 (PREFIX option is ignored) updated | http://trac.mapnik.org/ticket/261#comment:3
06:12:07 <nikq> Mapnik Trac: Ticket #217 (Add ability to set PKG_CONFIG_PATH in SCons) closed | http://trac.mapnik.org/ticket/217#comment:10
06:14:40 <nikq> Mapnik Trac: Changeset [1039]: removed non-usable doxygen files until proper api docs can be rebuilt | http://trac.mapnik.org/changeset/1039
06:29:44 <nikq> Mapnik Trac: Ticket #265 (Before 0.6.0 remove the doxygen docs and update the epydocs) updated | http://trac.mapnik.org/ticket/265#comment:3
06:30:35 *** springmeyer has quit ()
07:11:55 *** huats (n=chris@ubuntu/member/huats) has joined #mapnik
07:15:49 *** rcoup (n=rcoup@ip-118-90-56-192.xdsl.xnet.co.nz) has joined #mapnik
07:43:32 <huats> morning
07:43:40 <huats> I am trying to use mapnik
07:43:44 <huats> and I have some issues :)
07:44:21 <huats> I have some problem using the GetFeatureInfo request
07:44:28 <huats> (the getMap works fine)
07:44:48 <huats> (I am using mapnik in ogcserver)
07:45:11 <huats> I always get the following error : 'tuple' object has no attribute 'key'
07:45:15 <huats> and I have no idea why
07:45:27 <huats> does it sounds familiar with someone ?
07:47:10 *** weizhuo (n=chatzill@220-245-254-27.free.tpgi.com.au) has joined #mapnik
08:14:28 *** __d3f0__ (n=defo@190.177.3.227) has joined #mapnik
08:19:19 *** d3f0 has quit (Read error: 110 (Connection timed out))
08:41:26 *** aga (n=aga@28.54.86-79.rev.gaoland.net) has joined #mapnik
08:41:47 *** aga has quit (Client Quit)
08:43:53 *** weizhuo has quit (Read error: 60 (Operation timed out))
09:56:38 *** __d3f0__ has quit (Remote closed the connection)
10:15:05 *** darragh (n=darragh@83.70.173.25) has joined #mapnik
10:54:25 <nikq> Mapnik Trac: InstallationTroubleshooting edited | http://trac.mapnik.org/wiki/InstallationTroubleshooting?version=29
11:02:21 *** rcoup has quit ()
11:14:14 <huats> still noone to help me with my GetFeatureInfo issue ?
11:24:40 *** synax (n=synax@24.222.57.182) has joined #mapnik
11:25:44 *** aba_ is now known as aba
12:02:23 <synax> can anyone enlighten me as to what the +no_defs option means for the projection definition?
12:54:47 <synax> "no defaults"
12:55:19 <synax> Berteun: are you around?
12:58:13 <Berteun> I'm a bit busy, but I can tell you I don't have a clue.
12:58:33 <Berteun> You should look into the documentation of PROJ.4 probably.
12:59:08 <synax> nah, I answered my own previous question ;) I have another issue now
13:01:24 <synax> Berteun: I've got a sample .prj file to use with my shapefiles which is EPSG:2038... However, when specifying the SRS of the layer I've loaded the shapefile into, nothing is being displayed when I output to PNG. If I omit the srs definition, it outputs just fine...
13:02:30 <synax> If I load the shapefile using GMapCreator though, it reads the .prj correctly and displays the expected output...
13:02:54 <synax> I know I'm being a bit vague and you said you're busy, but I'm at a loss and am taking a shot in the dark ;)
13:03:26 <Berteun> You zoom to the bbox, and the outputted coordinates make sense?
13:03:33 <synax> yes
13:03:34 <Berteun> And you don't use other datasets?
13:03:37 <synax> no
13:03:48 <synax> I can give you a pastie of the code if that helps
13:04:12 <Berteun> I won't have time to look into it now... but anyway, then, I don't know what is going wrong.
13:04:20 <synax> alright
13:04:31 <Berteun> The only thing is... it's very hard to find out sometimes, because it might be that PROJ gives some error.
13:04:37 <Berteun> But you don't see those.
13:04:42 <synax> oh, awesome
13:04:45 <Berteun> And then indeed nothing happens.
13:04:53 <Berteun> Which is terribly confusing.
13:05:08 <synax> there's no way I can debug the PROJ?
13:05:17 <Berteun> Perhaps, but I don't know that.
13:05:20 <synax> heh
13:05:47 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
13:06:03 <synax> hey, maybe Dane can be of some assistance :D
13:08:59 <synax> springmeyer: do you have a few minutes?
13:11:26 * springmeyer yawns
13:11:49 <synax> maybe drink a coffee first?
13:11:51 <synax> http://paste.mootools.net/d4b658072
13:12:17 * springmeyer coffee in hand :)
13:12:51 <synax> I'm having what I guess to be projection issues...
13:13:02 <synax> in the pastie I linked, the highlighted line
13:13:17 <synax> if that is left commented out, the shapefile renders as I'd expect
13:13:23 <springmeyer> ya, okay
13:13:32 <synax> but if I define the projection, nothing renders
13:14:02 <synax> the projection snippet at the bottom is the contents of the .prj file I have
13:14:19 <springmeyer> try adding
13:14:24 <springmeyer> m.srs = "+proj=utm +zone=20 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"
13:15:00 <synax> !
13:15:07 <synax> so far so good :D
13:16:50 <synax> alright, at least now I can generate it properly
13:26:54 <springmeyer> anyone here using the OGC Server?
13:27:45 *** huats has quit (Read error: 113 (No route to host))
13:31:32 *** aub_ (n=aubrey@static-70-107-236-83.ny325.east.verizon.net) has joined #mapnik
13:33:03 *** darragh has quit (Remote closed the connection)
14:00:01 *** sanjiv (n=chatzill@59.180.142.115) has joined #mapnik
14:06:13 *** huats (n=chris@ubuntu/member/huats) has joined #mapnik
14:15:53 <huats> sorry to bother (again)
14:16:14 <huats> but does anyone have been faced with issues related to GetFeatureInfo ?
14:16:19 <huats> I cannot get it work
14:17:03 <springmeyer> huats: ya, the api changed to the Feature interface, so I bet it needs to be updated
14:17:08 <springmeyer> what error are you getting?
14:17:23 <huats> 'tuple' object has no attribute 'key'
14:17:45 <huats> springmeyer: that was my error
14:18:05 <springmeyer> okay, can you file a trac ticket?
14:18:17 <huats> sure
14:18:18 <springmeyer> I assume you are running mapnik trunk?
14:18:34 <huats> springmeyer: I am running the ubuntu package...
14:18:49 <huats> yeah I know it might be a wrong idea..
14:18:55 <springmeyer> okay
14:19:02 <springmeyer> so 0.5.1 then likely
14:19:09 <huats> indeed
14:19:19 <springmeyer> you must have patched the python code then huh?
14:19:32 <huats> just for the getMap
14:19:33 <huats> :)
14:19:53 <springmeyer> there were some other bugs in the ogcserver code that slipped through
14:20:08 <huats> indeed related to ogcserver
14:20:23 <springmeyer> how did you patch getMap?
14:20:40 <huats> I just put a fix you had in trunk
14:20:48 <springmeyer> ah okay :)
14:21:32 <springmeyer> huats: another lurking issue with GetFeatureInfo is unicode stuff, do you happen to be a unicode guy? :)
14:21:48 <huats> springmeyer: hum
14:21:56 <huats> I can have a look :)
14:22:27 <springmeyer> :)
14:22:37 <huats> because indeed all my stuffs in on unicode...
14:23:16 <springmeyer> u'\u3438' <-- that look decodeable or bunk? :)
14:24:52 <springmeyer> or how about this :)
14:24:58 <springmeyer> u'Aak\x07\x00\x00' == Alaska
14:25:36 <huats> LOL
14:29:40 <huats> springmeyer: do you want me to paste my code in the ticket ?
14:30:19 <springmeyer> ya, thanks!
14:31:57 <huats> springmeyer: do you mind if I simply paste my actual code (I am running it inside django...)
14:32:30 <springmeyer> whatever works :) just put it between {{{ <code }}}
14:32:35 <huats> sure :)
14:32:57 <nikq> Mapnik Trac: Ticket #271 (Issue with GetFeatureInfo) created | http://trac.mapnik.org/ticket/271
14:33:52 <nikq> Mapnik Trac: views.py attached to Ticket #271 | http://trac.mapnik.org/attachment/ticket/271/views.py
14:34:05 <springmeyer> hmm, unicode wierdness may be just mac os x...
14:34:35 <huats> ok
14:37:04 <nikq> Mapnik Trac: OL.js attached to Ticket #271 | http://trac.mapnik.org/attachment/ticket/271/OL.js
14:39:18 <huats> springmeyer: please do not hesitate to say ot you need stuffs...
14:39:30 <huats> (I can open you a dev env if it help)
14:39:39 <nikq> Mapnik Trac: Ticket #272 (Mapnik Featureset.properies (Feature::props) returns fishy unicode in  ...) created | http://trac.mapnik.org/ticket/272
14:39:51 * springmeyer looks at #271
14:42:16 <springmeyer> looks good. fun integration with django
14:43:03 <huats> :)
14:43:13 <huats> springmeyer: I need to run
14:43:25 <springmeyer> okay.
14:43:26 <huats> please tell me (on the bug) if you need something...
14:43:31 <huats> it would really help me :)
14:43:34 <springmeyer> looks like an easy fix
14:43:38 <huats> GREAT !
14:43:51 <springmeyer> I'll commit in a few minutes to trunk and you can take a look
14:44:10 <huats> hehe
14:44:13 <huats> great ...
14:44:31 <huats> (I have a plane to catch... so it might be a great thing to play in the flight :))
14:44:37 <huats> thanks !
14:44:48 <springmeyer> np
14:59:49 <nikq> Mapnik Trac: Changeset [1040]: revise handling of featureset returned from GetFeatureInfo  ... | http://trac.mapnik.org/changeset/1040
15:00:23 <nikq> Mapnik Trac: Ticket #271 (Issue with GetFeatureInfo) closed | http://trac.mapnik.org/ticket/271#comment:1
15:02:54 <nikq> Mapnik Trac: Ticket #261 (PREFIX option is ignored) updated | http://trac.mapnik.org/ticket/261#comment:4
15:04:26 <nikq> Mapnik Trac: Ticket #261 (PREFIX option is ignored) updated | http://trac.mapnik.org/ticket/261#comment:5
15:05:57 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
15:06:15 <artem> springmeyer: hey
15:06:15 <nikq> artem: 23 Feb 22:20Z <springmeyer> tell artem 'this is a test'
15:06:18 <nikq> artem: 23 Feb 22:28Z <kunitoki> tell artem 'Ragarding your limit 0 fix in r961 you should have read the XXX comment before doing that: without a row, we cannot iterate over the fields'
15:06:37 <springmeyer> hello :)
15:07:17 <artem> I'm looking at fixing ticket (just a sec :)
15:07:38 <springmeyer> okay, cool
15:07:52 <artem> #45
15:07:53 <nikq> Ticket #45: Names on areas don't seem to be correctly centered in the vertical axis, http://trac.mapnik.org/ticket/45
15:08:27 <springmeyer> nice, I'm peeking at #261
15:08:27 <nikq> Ticket #261: PREFIX option is ignored, http://trac.mapnik.org/ticket/261
15:09:28 <artem> We can change  vertical alignment to  'center' but it might break other cases
15:09:47 <artem> like : Icon + text below
15:11:03 <artem> Should we introduce vertical alignment parameter for text_symbolizer in 0.6.0 ? Obviously it'll need further work later to add horizontal alignment as well ?
15:12:30 <springmeyer> sounds good
15:27:32 <artem> ok, cool I'll work on this tonight , got to run now
15:27:42 <springmeyer> see ya
15:27:47 <artem> bbl here
15:27:54 <springmeyer> okay, great
15:35:48 *** springmeyer has quit ()
15:51:01 *** artem has quit ()
15:52:17 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
16:06:00 *** huats has quit ("Ex-Chat")
16:41:01 *** artem has quit ()
16:47:04 *** D3f0 (n=defo@190.177.3.227) has joined #mapnik
16:52:37 <nikq> Mapnik Trac: Changeset [1041]: scons: make sure to respect options in 'config.py' over defaults stored in  ... | http://trac.mapnik.org/changeset/1041
16:53:28 <nikq> Mapnik Trac: Ticket #261 (PREFIX option is ignored) updated | http://trac.mapnik.org/ticket/261#comment:6
16:55:30 <nikq> Mapnik Trac: Ticket #264 (Scons rebuilds unchanged targets) updated | http://trac.mapnik.org/ticket/264#comment:2
16:58:58 <synax> what unit does LineSymbolizer take to define its stroke width?
17:04:15 <synax> I'm guessing it's relative...but to what?
17:06:19 <Berteun> Pixels.
17:24:35 <synax> pixels?
17:24:48 <synax> 0.02 pixels doesn't make sense
17:27:15 <synax> doesn't look like my LineSymbolizer cares what number I give the stroke anyway...they're always super thin no matter what value I supply
17:29:03 <Berteun> You plot PNG?
17:30:20 <cmarqu> synax: http://trac.mapnik.org/wiki/LineSymbolizer says indeed "pixels" (in the table, all the way to the right)
17:30:47 <synax> ...why can't I find these wiki pages on my own?
17:30:52 <synax> Berteun: yes, output is PNG
17:49:32 <nikq> Mapnik Trac: Ticket #264 (Scons rebuilds unchanged targets) closed | http://trac.mapnik.org/ticket/264#comment:3
17:50:22 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
17:51:13 <synax> a stroke of < 1px still doesn't make sense to me
17:53:17 <cmarqu> synax: It would if you take antialiasing into account. And maybe if you export vectors when you map a pixel unit to some "real" width.
17:54:39 <cmarqu> Not sure if Mapnik does this, but it could in theory.
17:54:42 <synax> IMO it's a misnomer: a pixel is always an integer >= 1 that's an absolute unit of measurement
17:54:53 <synax> in the context of vectors, pixels are (mostly) irrelevant
17:55:47 <cmarqu> I don't disagree, but it's what we have.
17:56:36 <synax> anyhow, my lines not responding to the value I was giving it was not an issue of pixels ;) it was an issue of my own stupidity
17:56:51 <synax> or rather, lack of experience w/ mapnik
17:56:55 <springmeyer> syntax: mapnik does subpixel rendering
17:56:59 <springmeyer> http://en.wikipedia.org/wiki/Subpixel_rendering
17:57:16 <synax> I understand
17:57:22 <springmeyer> fractional widths are a way of directing that
17:58:01 <synax> there are weird edge-cases with that though - if you define a width of 0.02 pixels and the output is viewed on a CRT...what happens?
17:58:10 <springmeyer> check out mapserver if you don't like the look
17:58:41 <springmeyer> .milestone 0.6.0
17:58:48 <springmeyer> milestone 0.6.0
17:58:49 <nikq> 25 open tickets in Milestone 0.6.0: Names on areas don't seem to be correctly centered in the vertical axis, Update Install Document on Mapnik.org by release and trunk, Better exception handling for shape.input, PREFIX option is ignored, Enable dx/dy options for ShieldSymbolizer, Fix 'limit' errors in sqlite.input, "Extend TextSymbolizer ""spacing"" parameter to apply to polygons", Add transfer mo...
17:58:50 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.6.0&order=priority
17:58:51 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.6.0
17:59:54 <synax> alright, I've been trying to figure this problem out all day and am no farther ahead than I was this morning...
18:00:38 <synax> I've loaded a shapefile, zoomed to its bounds and output the corresponding image
18:01:45 <synax> I'm trying to zoom into a specific bounding area within the shape and then output that image...
18:02:04 <synax> but I'm not doing the projection conversion correctly, somehow
18:03:09 <springmeyer> does the map.srs differ from the layer.srs?
18:04:28 <synax> http://paste.mootools.net/d7f5c4739
18:04:32 <synax> no it doesn't
18:04:52 <synax> e ends up looking like Envelope(inf,inf,inf,inf)
18:07:15 <springmeyer> if the layer.srs does not differ from the map.srs then you don't need to mess with Projection forwarding
18:07:28 <springmeyer> what does this give:
18:07:33 <springmeyer> print l.envelope()
18:08:21 <synax> UTM coords... :Envelope(445310.12,4951192.32,448198.52,4954812.56)
18:08:48 <springmeyer> ah, I see what you are doing
18:08:53 <springmeyer> ya, sorry
18:08:58 <synax> if I do the conversion manually, I get the expected output
18:09:09 <synax> forward isn't doing what I think it's supposed to do
18:09:22 * springmeyer looks back
18:09:33 <synax> rather, what I think it's supposed to do is probably wrong
18:09:53 <springmeyer> hmmm, what version of mapnik synax?
18:09:56 <synax> SVN
18:10:00 <springmeyer> okay
18:10:21 <springmeyer> reason I ask is because the 'idea' of forwarding or inversing is hard for me to remember...
18:10:33 <springmeyer> unless it is relative to the geometry in question
18:10:36 <synax> inverse outputs lat/lon AFAIK
18:10:57 <springmeyer> so in trunk I've added those methods off of the Coord and Envelope objects
18:11:23 <springmeyer> so to go from long/lat to UTM
18:11:37 <synax> I noticed it was part of Envelope as well (via pydoc) but I couldn't see it when browsing the source
18:12:10 <springmeyer> right, since the python bindings are coming from c++ its a little odd
18:12:26 <synax> I checked both the .cpp and bindings ;)
18:12:28 <springmeyer> check out the __init__.py file you'l see some funky stuff in there
18:12:32 <synax> ah
18:12:59 <synax> anyway, you were saying? lat/long -> UTM?
18:13:10 <springmeyer> ya, one sec
18:13:42 <synax> ah crap, I was hoping it was an easy answer ;)
18:14:33 <synax> FWIW. ultimately what I'm trying to do is read in a shapefile and output tiles using a modified OSM's generate_tiles.py script
18:15:06 <synax> I've got it outputting the correct tiles, but they're all blank b/c of this conversion issue
18:15:15 <synax> at least that's what I think is wrong
18:17:27 <springmeyer> where is this shapefile data relevant for? ie what place does it depict?
18:18:48 <synax> local properties
18:19:16 <synax> using http://spatialreference.org/ref/epsg/2038
18:20:36 <springmeyer> uh, where is 'local'?
18:20:44 <synax> Bedford, NS, Canada
18:23:42 <springmeyer> try forwarding Envelope(-63.6740,44.7252,-63.6713,44.7272)
18:23:59 <springmeyer> I think you've mixed up your lon/lat's
18:24:31 <springmeyer> http://blog.cleverelephant.ca/2007/12/lets-call-whole-thing-off.html
18:27:32 <synax> that did it
18:28:00 <springmeyer> .e.g the web mapping api's broke with the OpenGIS protocol of ordering long/lat
18:28:20 <springmeyer> anyway, this is how I do forwarding in trunk:
18:28:20 <springmeyer> http://dpaste.com/21241/
18:28:23 <synax> so Coord takes lon/lat?
18:28:31 <springmeyer> yes
18:28:54 <springmeyer> and Envelope takes (lon,lat, lon,lat) as (minx,miny,maxx,maxy)
18:29:25 <synax> wait...I thought x = lat, y = lon
18:29:41 <synax> yeah
18:29:45 <springmeyer> nope
18:29:49 <synax> ...that's had me fucked up all day
18:30:50 <springmeyer> ya, the lack of consenses between the mapping apis and all the rest of the world of gis tools makes for one of the most common walls for new (and experienced) users
18:33:10 <springmeyer> synax: you may benefit from rebuilding mapnik with DEBUG=True
18:33:35 <springmeyer> which will print a bunch of these extents to stderr when the rendering happens
18:33:57 <synax> scons/scons.py --DEBUG=True ?
18:34:06 <springmeyer> so a slick way to get the extents of your shapefile in lon/lat...
18:34:08 <springmeyer> ya
18:34:13 <springmeyer> is to just do
18:34:30 <springmeyer> >>> map.srs = '+init=epsg:4326'
18:34:32 <springmeyer> and also
18:34:40 <springmeyer> >>> map.zoom_all()
18:35:02 <springmeyer> you can see mapnik internally reproject the layer extents to lon/lat in the output
18:35:29 <springmeyer> when you render with changes in the code like that, as an example
18:36:07 <springmeyer> nik2img.py is also another way to get at some of the debug info when in --verbose mode
18:38:02 <synax> springmeyer: this is the hacked up version of generate_tiles.py I
18:38:07 <synax> 'm working on... http://paste.mootools.net/d53da0643
18:38:42 <synax> it's correctly outputting the right file names and directories (and coordinates when it's run) but all my tiles are blank
18:38:45 <nikq> Mapnik Trac: Ticket #265 (Before 0.6.0 remove the doxygen docs and update the epydocs) closed | http://trac.mapnik.org/ticket/265#comment:4
18:39:46 <synax> it's mostly unchanged from the original script, except that bbox is generated by the shapefile's extents instead of being manually supplied
18:42:18 <synax> lines 74 & 75 are probably suspect since that's where I'm reprojecting from the original to lon/lat
18:42:36 <synax> but the following print statement on line 77 is correct
18:42:43 <cmarqu> Does http://trac.mapnik.org/changeset/1027 mean hillshading will be in Mapnik 0.6.0? Awesome.
18:43:19 <springmeyer> cmarqu: yes
18:43:53 <springmeyer> would be awesome if you could test before we release though :)
18:43:58 <cmarqu> Wil have to try it.
18:44:13 *** sanjiv_ (n=chatzill@59.180.154.37) has joined #mapnik
18:44:36 <aba> are there any news on not overlapping parallel ways?
18:45:23 *** sanjiv has quit (Read error: 110 (Connection timed out))
18:45:36 *** sanjiv_ is now known as sanjiv
18:48:21 *** D3f0 has quit (Read error: 104 (Connection reset by peer))
18:52:04 <cmarqu> springmeyer: How about preparing a standalone tutorial for hillshading similar to http://trac.mapnik.org/wiki/ShieldSymbolizerTests?
18:52:39 <cmarqu> I'd want to develop that under version control though, maybe in mapnik-utils/sandbox?
18:53:20 <springmeyer> awesome idea
18:55:50 <cmarqu> Means I can tell you to fix any bugs I'm introducing :)
18:56:23 * springmeyer chuckles :)
18:56:57 <springmeyer> aba: is their a ticket for what you are hinting at?
18:57:35 * springmeyer takes a look at synax's hack... :)
18:57:46 <synax> thanks man, I'm suffering ;)
18:58:13 <aba> springmeyer: not really, but perhaps I should file one ...
18:58:25 <springmeyer> first off, would be cool if you credited the source of the script ;)
18:59:01 <springmeyer> second, makes more sense to me to stick with loading an xml file
18:59:14 <springmeyer> rather than adding your python style stuff inside the script
18:59:39 <springmeyer> you can use save_map(m,'serialized_xml.xml') to save out of a mapfile from your previous script
19:00:28 *** sanjiv has quit ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032711]")
19:01:07 <springmeyer> third, I think the only way to feasibly help would be to have a diff file
19:01:23 <springmeyer> between the original generate_tiles.py and what you've changed
19:01:55 <springmeyer> I can't just dig through your code :)
19:02:31 <synax> springmeyer: things seem to go wrong at lines 105, 106
19:02:44 <springmeyer> but, I do see that you need to make your map.srs match the google projection
19:03:03 <springmeyer> try:
19:03:05 <springmeyer> m.srs = prj.params()
19:03:17 <springmeyer> after line 69
19:03:17 <synax> o_O at which point?
19:03:19 <synax> k
19:04:51 <synax> that didn't change anything, lines 105,106 are still not properly converting
19:07:12 <springmeyer> did you make sure to delete your cache?
19:07:26 <springmeyer> what do you mean by 'not properly converting' ?
19:08:31 <synax> the reprojections are giving me UTM coords that do not fall in the zone I've been working with
19:08:53 <synax> if I replace prj.forward(...) with shp_prj.forward(..) I get the correct coords
19:10:32 <springmeyer> I'd recommend grabbing a test shapefile in wgs84(long/lat) projection that covers your area
19:10:44 <springmeyer> and get your script working with that first
19:10:59 <synax> I've got it working
19:11:58 <synax> whew
19:12:18 <synax> the final projection is still probably not right, since it's not in Google's projection
19:12:24 <synax> but I've at least got tiles now
19:15:24 <synax> actually, this will probably work just right
19:15:43 *** w0lfie_ has quit (brown.freenode.net irc.freenode.net)
19:15:43 *** dodobas has quit (brown.freenode.net irc.freenode.net)
19:15:43 *** CIA-6 has quit (brown.freenode.net irc.freenode.net)
19:15:43 *** ser has quit (brown.freenode.net irc.freenode.net)
19:15:43 *** cmarqu has quit (brown.freenode.net irc.freenode.net)
19:15:43 *** Berteun has quit (brown.freenode.net irc.freenode.net)
19:16:17 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik
19:16:17 *** CIA-6 (n=CIA@208.69.182.149.simpli.biz) has joined #mapnik
19:16:17 *** dodobas (n=dodobas@open.geof.hr) has joined #mapnik
19:16:17 *** w0lfie_ (n=wolf@cpe-67-49-133-78.hawaii.res.rr.com) has joined #mapnik
19:16:17 *** Berteun (i=berteun@berteun.nl) has joined #mapnik
19:16:17 *** cmarqu (i=colin@oemcomputer.oerks.de) has joined #mapnik
19:20:26 <cmarqu> springmeyer: From Envelope(-175694.6612042082,6542691.745898315,-168424.6950525119,6549216.387789081), how do I get the lat/lon (for downloading the SRTM data)?
19:23:32 <springmeyer> cmarqu: is that spher. mercator?
19:24:08 <cmarqu> The XML file has srs="+proj=merc +datum=WGS84 +k=1.0 +units=m +over +no_defs"
19:25:06 <cmarqu> (if that helps?)
19:25:37 <springmeyer> sure
19:25:40 <springmeyer> >>> from mapnik import *>>> env = Envelope(-175694.6612042082,6542691.745898315,-168424.6950525119,6549216.387789081)
19:25:40 <springmeyer> >>> env.inverse(Projection('+proj=merc +datum=WGS84 +k=1.0 +units=m +over +no_defs'))
19:25:40 <springmeyer> Envelope(-1.57829199498,50.7420815096,-1.51298477789,50.7792570692)
19:26:37 <springmeyer> 'inverse' because we are going from a projected system to geographic/platte caree
19:26:56 * springmeyer ducks w0lfie_'s ruler
19:27:02 <dodobas> yello
19:27:15 <dodobas> which book would you recommend ?
19:27:25 <dodobas> or books
19:27:41 <dodobas> about, mapping, gis, spatail data, etc...
19:29:06 <cmarqu> springmeyer: Thanks.
19:31:32 <nikq> Mapnik Trac: Ticket #272 (Mapnik Featureset.properies (Feature::props) returns fishy unicode in  ...) updated | http://trac.mapnik.org/ticket/272#comment:1
19:31:53 <nikq> Mapnik Trac: feature_props_to_eval_tuple.patch attached to Ticket #272 | http://trac.mapnik.org/attachment/ticket/272/feature_props_to_eval_tuple.patch
19:33:27 <springmeyer> dodobas: I like edward tuftes books on visualization
19:34:02 <springmeyer> for data and gis http://www.pragprog.com/titles/sdgis/gis-for-web-developers has been recommended
19:34:35 <springmeyer> I've not seen it yet but I bet that
19:34:36 <springmeyer> http://www.pragprog.com/titles/gsdgis/desktop-gis
19:34:53 <springmeyer> is excellent, knowing gary's past workshops
19:38:59 *** synax has quit ()
19:52:38 <nikq> Mapnik Trac: Ticket #246 (python: add function to test for available plugins) updated | http://trac.mapnik.org/ticket/246#comment:2
19:52:54 <nikq> Mapnik Trac: Ticket #245 (Support reading of datasource paths relative to xml location) updated | http://trac.mapnik.org/ticket/245#comment:1
19:53:28 <nikq> Mapnik Trac: Ticket #203 (Align polygon pattern fills globally) updated | http://trac.mapnik.org/ticket/203#comment:1
19:53:56 <nikq> Mapnik Trac: Ticket #211 (Support min_distance in LinePatternSymbolizer) updated | http://trac.mapnik.org/ticket/211#comment:2
19:54:16 <nikq> Mapnik Trac: Ticket #180 (Parameter for line symbolizer to offset line to one side) updated | http://trac.mapnik.org/ticket/180#comment:2
19:55:07 <nikq> Mapnik Trac: Ticket #131 (Extend TextSymbolizer "spacing" parameter to apply to polygons) updated | http://trac.mapnik.org/ticket/131#comment:3
20:08:04 <dodobas> springmeyer: tnx, i already have the first one on my check list, did not know about the second one
20:12:09 <cmarqu> springmeyer: http://mapnik-utils.googlecode.com/svn/sandbox/hillshading/ - I'm stuck. :)
20:12:20 <dodobas> with that one its 14 books in total, i hope i get 3 of them :D
20:12:26 *** rcoup (n=rcoup@ip-118-90-117-9.xdsl.xnet.co.nz) has joined #mapnik
20:12:39 <cmarqu> springmeyer: Run get_srtm_data.sh first, then render_map.py
20:12:50 <springmeyer> k
20:14:58 <springmeyer> one sec
20:20:01 <nikq> Mapnik Trac: Changeset [1042]: add 'base' path option to sql,gdal, and ogr plugins and touchup handling  ... | http://trac.mapnik.org/changeset/1042
20:20:22 <nikq> Mapnik Trac: Ticket #263 (Support base path option in gdal/org/sqlite plugins (like shapefile  ...) closed | http://trac.mapnik.org/ticket/263#comment:1
20:35:16 <springmeyer> cmarqu: it may be working but the raster is just not detailed enough at that zoom
20:35:35 *** D3f0 (n=defo@190.176.224.228) has joined #mapnik
20:35:53 <cmarqu> springmeyer: But there should be *some* grey in there I guess?
20:35:58 <springmeyer> try svn up && nik2img.py -m hillshading_test2.xml -o test.png
20:36:21 * springmeyer has gotta head off - bbl
20:39:13 <jburgess> cmarqu: I tried running that and just see a black background
20:39:42 <jburgess> I then tried copy-pasting the raster layer into an existing osm.xml file and running that with my C render code. I now get a segv after printing:
20:39:46 <jburgess> ERROR 3: Read of file /usr/share/epsg_csv/unit_of_measure.csv failed.
20:39:51 <cmarqu> jburgess: It works with the new hillshading_test2.xml, it was a projection issue I guess
20:40:04 <CIA-6> mapnik-utils: cmarqu42 * r602 /sandbox/ (9 files in 3 dirs): Non-working example for http://trac.mapnik.org/ticket/259.
20:40:05 <CIA-6> mapnik-utils: dane.springmeyer * r603 /sandbox/hillshading/ (10 files in 2 dirs): add second test with super simple overlay line shapefile
20:40:13 <jburgess> this happens in geotiff reading code
20:40:35 <cmarqu> jburgess: Is this with current SVN?
20:40:44 <jburgess> no, 5 or 10 minutes old :)
20:40:50 <cmarqu> :)
20:41:14 <cmarqu> Interesting, works for me, at least in principle.
20:42:30 <jburgess> how are you running hillshading_test2.xml, just replacing the name in the render_me.py script?
20:42:39 <jburgess> now I just get 2 black tiles
20:42:46 <cmarqu> nik2img.py -v -m hillshading_test2.xml -o test.png
20:44:07 <cmarqu> Indeed, render_map.py just gives black images.
20:44:36 <cmarqu> The Envelope is wrong maybe?
20:45:24 <jburgess> I don't know.
20:45:29 <cmarqu> Right, nik2img reports Envelope(-298300.666958,6446250.25958,-35624.9164577,6621367.42658)
20:45:45 <cmarqu> When setting that, render_map starts to work.
20:45:47 <jburgess> That is why I wanted to put the style into my mod_tile render daemon, then I can zoom around to see if the data shows anywhere
20:46:00 <jburgess> I'm nervous of that proj string for the shapefile.
20:46:24 <jburgess> I think it has one of the bad projections that have caused latitude shifts of a few km before
20:47:28 <nikq> Mapnik Trac: Changeset [1043]: + add support for vertical_alignment (text_symbolizer)   valid values are  ... | http://trac.mapnik.org/changeset/1043
20:48:28 <cmarqu> I guess springmeyer just made sure they were all the same projection. The original line (to gdalwarp) I got from http://wiki.openstreetmap.org/wiki/HikingBikingMaps#Hill_Shading
20:49:22 <jburgess> I'm thinking that the error I saw is a threading issue. The daemon no longer crashes when I run with 1 thread
20:49:32 <cmarqu> I don't really know what I'm doing there.
20:49:34 <jburgess> now the geotiff renders OK too
20:54:14 <nikq> Mapnik Trac: middle.png attached to Ticket #45 | http://trac.mapnik.org/attachment/ticket/45/middle.png
20:54:27 <nikq> Mapnik Trac: top.png attached to Ticket #45 | http://trac.mapnik.org/attachment/ticket/45/top.png
20:54:38 <nikq> Mapnik Trac: bottom.png attached to Ticket #45 | http://trac.mapnik.org/attachment/ticket/45/bottom.png
20:55:02 <jburgess> cmarqu: I get something which looks like: http://tile.openstreetmap.org/hill-shade.png
20:55:48 <jburgess> this is the geotiff added in as another layer in the standard OSM style, between the coast-poly and the rest of the rendering
20:56:03 <cmarqu> jburgess: Not so bad then.
20:56:12 <jburgess> looks good to me
20:56:14 * springmeyer drools
20:56:33 <cmarqu> The areas need transparency etc., but the patch is proven IMO
20:57:38 <cmarqu> jburgess: What does it look like when zoomed into an area which has a steep gradient?
20:58:05 <jburgess> things are quite pixelated when zoomed in, i'll get another screenshot
20:59:15 <cmarqu> So there is some tweaking to do until we get http://mapa.ump.waw.pl/ump-www/?zoom=15&lat=49.30126&lon=19.94725
20:59:30 <jburgess> actually, it looks quite good, but is let down by some bad pixelated artifacts along the coast areas
21:00:05 <cmarqu> Ah, that's in the SRTM data I suppose.
21:00:52 <jburgess> http://tile.openstreetmap.org/hill-shade-spots.png
21:00:57 <cmarqu> Maybe -srcnodata/-dstnodata in the gdalwarp call can be made better.
21:02:40 <jburgess> It isn't a particularly hilly area, but here is one bit with some gradients http://tile.openstreetmap.org/hill-shade-hills.png
21:02:55 <jburgess> look really quite smooth
21:03:33 <nikq> Mapnik Trac: Ticket #45 (Names on areas don't seem to be correctly centered in the vertical axis) closed | http://trac.mapnik.org/ticket/45#comment:6
21:03:35 <cmarqu> Yes. Though there is some color banding to the left of the A338 shield.
21:04:55 <jburgess> that may be the png256 rendering, plus I set it to an indexed palette when I saved the screenshot
21:05:18 <jburgess> I don't think you can really avoid a bit of colour banding  with such subtle gradients
21:05:36 <cmarqu> For flatter areas, it would be good to have some height exaggeration... Need an extra layer with the exaggeration factor :)
21:06:59 <nikq> Mapnik Trac: Ticket #262 (Fix 'limit' errors in sqlite.input) closed | http://trac.mapnik.org/ticket/262#comment:1
21:07:01 <cmarqu> Some strange artifacts in the middle of http://mapa.ump.waw.pl/ump-www/?zoom=14&lat=49.24052&lon=19.80323&layers=B00000T - as if the smoothing didn't happen
21:09:57 <jburgess> steep hills :)
21:10:18 <jburgess> Looks likt those tiles are still 8-bit colormaps so some striping will be due to that
21:12:45 <jburgess> there are some voids in the data in that area too, if you look at the cyclemap http://www.openstreetmap.org/?lat=49.2401&lon=19.8065&zoom=14&layers=00B0FTF
21:12:56 <cmarqu> Hmm. There is a tile border in that one place where the striping starts all of a sudden: http://1.tiles.ump.waw.pl/ump_tiles/14/9092/5609.png is good, http://3.tiles.ump.waw.pl/ump_tiles/14/9093/5609.png is striped
21:14:39 <cmarqu> Maybe Marcin's data is from CGIAR
21:15:30 <cmarqu> Though he claims to use SRTM-3 v2 in https://lists.berlios.de/pipermail/mapnik-users/2009-February/001651.html
21:18:35 <jburgess> I would still put money of the 256 colour palette. Even in that "good" tile, the black spot near the bottom right has clear rings around it
21:19:23 <cmarqu> True
21:55:38 <nikq> Mapnik Trac: Ticket #259 (Hill Shading support) updated | http://trac.mapnik.org/ticket/259#comment:2
21:56:09 <nikq> Mapnik Trac: Changeset [1044]: add boost filesystem checks (for filename existance) to gdal and raster  ... | http://trac.mapnik.org/changeset/1044
21:57:00 <nikq> Mapnik Trac: Ticket #273 (compiler warnings on os x after r1043) created | http://trac.mapnik.org/ticket/273
22:01:08 <springmeyer> I wonder about #54 - currently we've got it in milestone 1.0.0
22:01:09 <nikq> Ticket #54: Support for overviews in gdal input plug-in, http://trac.mapnik.org/ticket/54
22:01:15 <nikq> 51 open tickets in Milestone 1.0.0: Rendering text labels when point size of labels exceeds the width of the line, Add python docstrings to boost:python bindings, Vertical Displacement of line text, Main library gets linked against unnecessary libraries, Improve XML parsing error-reporting, Provide return value policy in doc strings, Error reading shapefile on Mac OS X with G5 processor, Allow for...
22:01:17 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=1.0.0&order=priority
22:01:18 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/1.0.0
22:02:04 <springmeyer> perhaps #54 might become more critical as folks hear about and use the hillshading stuff with big files
22:02:04 <nikq> Ticket #54: Support for overviews in gdal input plug-in, http://trac.mapnik.org/ticket/54
22:03:39 <springmeyer> or maybe based on the way the rastersymbolizer works it won't matter/could conflict - anyone have a sense?
22:03:49 <nikq> Mapnik Trac: Ticket #54 (Support for overviews in gdal input plug-in) updated | http://trac.mapnik.org/ticket/54#comment:5
22:06:44 <cmarqu> I now mentioned the hillshading demo on mapnik-users and asked Marcin for a few more details about his own renderings.
22:09:00 *** huats (n=chris@ubuntu/member/huats) has joined #mapnik
22:09:56 <nikq> Mapnik Trac: Ticket #101 (Experimental mod_python server for Mapnik) updated | http://trac.mapnik.org/ticket/101#comment:12
22:09:58 <nikq> Mapnik Trac: Ticket #101 (Experimental mod_python server for Mapnik) closed | http://trac.mapnik.org/ticket/101#comment:13
22:10:13 <huats> springmeyer: just a quick update
22:10:24 <huats> your fix seems to work !  thanks
22:10:35 <springmeyer> cool
22:10:42 <huats> I only say "seems" since I have another stuff later :(
22:11:09 <huats> "No more features." have you ever seen that ?
22:11:19 <huats> Exception Type:  	StopIteration
22:11:29 <nikq> Mapnik Trac: Ticket #190 (Make symbolizers available/editable via a Style object in python bindings) updated | http://trac.mapnik.org/ticket/190#comment:6
22:11:42 <springmeyer> oh, bogus
22:12:00 <springmeyer> ya, that might be because you are running 0.5.1
22:12:22 <springmeyer> because I was not seeing it
22:12:29 <huats> ok
22:12:58 <springmeyer> so huats either way you should just be able to wrap the next = featureset.next()
22:13:09 <springmeyer> in a try/except:pass
22:14:00 <huats> springmeyer: ok I can do that
22:15:04 <springmeyer> then :) you may get a unicode error...
22:15:19 <huats> lol
22:15:19 <springmeyer> but 0.5.1 has different unicode handling I think so we'll see
22:15:20 <huats> :)
22:15:21 <springmeyer> I get:
22:15:22 <springmeyer> http://dpaste.com/21363/
22:15:55 <springmeyer> ya, huats the OGC server author/maintainer has had health problems so we've not had a maintainer for a while :
22:15:57 <springmeyer> (:(
22:16:09 <huats> springmeyer: ok I understand
22:16:30 <springmeyer> I've been pondering proposing moving the code to its own versioning repository
22:16:47 <springmeyer> so that the community of users could update it easier perhaps
22:17:56 <springmeyer> its just python and does not need to live in the mapnik trunk for any reason other than it would ideally be easier to maintain compatibility with mapnik C++ core when kept with mapnik
22:19:02 <huats> I see your point
22:25:27 <nikq> Mapnik Trac: Ticket #195 (Support reading Projection information within OGR/GDAL input plugins) closed | http://trac.mapnik.org/ticket/195#comment:1
22:25:47 <nikq> Mapnik Trac: Ticket #214 (SConstruct build engine refactoring) updated | http://trac.mapnik.org/ticket/214#comment:3
22:26:29 <nikq> Mapnik Trac: Ticket #125 (Basic Translations of Mapnik tutorials) updated | http://trac.mapnik.org/ticket/125#comment:8
22:27:30 <nikq> Mapnik Trac: Ticket #212 (Add OCCI.input plugin to read all ORACLE (> 10g) supported vector formats) closed | http://trac.mapnik.org/ticket/212#comment:3
22:29:53 <nikq> Mapnik Trac: Ticket #274 (Add factory methods for OCCI plugin (and docstrings)) created | http://trac.mapnik.org/ticket/274
22:30:35 <nikq> Mapnik Trac: Ticket #275 (Add factory methods for OSM plugin (and docstrings)) created | http://trac.mapnik.org/ticket/275
22:36:01 <nikq> Mapnik Trac: Ticket #192 (Memory Datasource support for Line and Polygon Geometries) updated | http://trac.mapnik.org/ticket/192#comment:1
22:39:53 <nikq> Mapnik Trac: Ticket #174 (Better exception handling for shape.input) updated | http://trac.mapnik.org/ticket/174#comment:2
22:40:22 <springmeyer> hey jburgess: if you happen to be around still would be great to get your feedback on the patch for #199
22:40:22 <nikq> Ticket #199: "Shapefile reader should look for file=""name.shp""", http://trac.mapnik.org/ticket/199
22:43:51 <jburgess> springmeyer: the patch looks good to me (assuming it works like should)
22:44:21 <springmeyer> :) cool thanks for looking
22:44:36 <huats> springmeyer: I did the try except stuff and it works like a charm here
22:44:42 <huats> (so far)
22:44:48 <springmeyer> ah good
22:45:42 <springmeyer> jburgess: it does work. :)
22:52:47 <CIA-6> mapnik-utils: cmarqu42 * r604 /sandbox/hillshading/ (6 files): Clean up. Thanks to Dane, it now works out of the box.
23:30:40 <huats> any idea why I cannot get the counter element in the GetFeatureInfo request ?
23:30:42 <huats> lyr_us.datasource = PostGIS(
23:30:42 <huats>             host='localhost',
23:30:42 <huats>             user='postgres',
23:30:42 <huats>             password='postgres',
23:30:42 <huats>             port='5432',
23:30:43 <huats>             dbname='loco-directory',
23:30:45 <huats>             table=("(SELECT '0' as counter, * from us_states_borders) geom"))
23:30:53 <huats> (I have pasted my datasource)
23:32:45 <nikq> Mapnik Trac: Changeset [1045]: scons: remove print statement of PREFIX introduced in r1043 | http://trac.mapnik.org/changeset/1045
23:36:59 *** weizhuo (n=chatzill@nat/yahoo/x-164028eb8c714b4a) has joined #mapnik
23:37:21 <huats> springmeyer: by chance you have an idea ?
23:42:40 <springmeyer> hey
23:42:46 <springmeyer> what do you mean you can't get it?
23:43:09 <springmeyer> it is not showing up in OL?
23:43:17 <jburgess> should that be "... as geom" on the end?
23:47:36 <huats> springmeyer I mean I cannot get it on the GetFeatureInfo :)
23:47:53 <huats> I get all the others param except that one
23:48:00 <huats> jburgess:  testing
23:48:32 <springmeyer> does SELECT '1' as counter, work?
23:49:08 <huats> jburgess: same stuff with as geom
23:49:32 <huats> springmeyer: testing
23:51:52 <huats> springmeyer: it is not better with '1'
23:51:59 <nikq> Mapnik Trac: Changeset [1046]: improve up front error checking of shapefile existence with boost, and  ... | http://trac.mapnik.org/changeset/1046
23:55:22 <nikq> Mapnik Trac: Ticket #174 (Better exception handling for shape.input) updated | http://trac.mapnik.org/ticket/174#comment:3
23:55:32 <nikq> Mapnik Trac: Ticket #174 (Better exception handling for shape.input) closed | http://trac.mapnik.org/ticket/174#comment:4
23:55:42 <nikq> Mapnik Trac: Ticket #199 (Shapefile reader should look for file="name.shp") closed | http://trac.mapnik.org/ticket/199#comment:4
23:56:23 <nikq> Mapnik Trac: Ticket #199 (Shapefile reader should accept files with or without '.shp' extension) updated | http://trac.mapnik.org/ticket/199#comment:5
23:57:17 <springmeyer> should we continue to support boost 1.33.1?