00:07:20 *** willwhite (~diggersf@c-68-33-229-33.hsd1.dc.comcast.net) has joined #mapnik
00:10:48 *** dkb has quit (Quit: Leaving.)
01:17:24 *** Phurl_ has quit (Ping timeout: 268 seconds)
01:26:43 *** Phurl_ (~mdupont@2001:0:53aa:64c:2069:172f:ae2d:1b81) has joined #mapnik
01:31:18 *** cgs_bob_ has quit (Ping timeout: 240 seconds)
02:07:01 *** cgs_bob_ (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik
02:19:26 *** tcarobruce has quit (Quit: tcarobruce)
02:21:14 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
02:27:40 *** ovnicraft (~ovnicraft@190.154.247.83) has joined #mapnik
02:34:57 <ovnicraft> hi set up my ogcserver now is running now with openlayers client url is http://localhost, and in my cfg file is the same, when i open my html file with openlayers is not loaded the wms
02:35:04 <ovnicraft> appears empty
02:37:20 <ovnicraft> bounds issue :/
02:39:57 *** ajturner has quit (Quit: ajturner)
02:42:17 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
02:42:28 *** ajturner has quit (Client Quit)
02:55:14 <springmeyer> ovnicraft: can you right click on the "pink" tile in openlayers and get the url to the tile
02:55:20 <springmeyer> then only that and see what the error is?
02:55:27 <springmeyer> only/open
02:55:59 <ovnicraft> bounds were wrong
02:56:14 <ovnicraft> fixed, now i see the map
02:56:31 <ovnicraft> and playing with styles in qgis to export the xml
02:57:37 *** springmeyer_ (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
02:57:44 *** springmeyer_ has quit (Remote host closed the connection)
02:57:45 *** springmeyer has quit (Read error: Connection reset by peer)
02:57:50 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
03:03:29 <dkb> I was wondering, is the eventual goal to have all the layers specified in osm.xml to be located in their own xml.inc file?
03:45:04 <springmeyer> ovnicraft: okay
03:46:34 <springmeyer> dkb: I think the goal is to organize things so that maintaining, updating, and modifying are easier
03:47:02 <springmeyer> and yes, I think pulling more layers into incs is the plan
03:51:11 <dkb> ok
03:51:35 *** Phurl_ has quit (Ping timeout: 268 seconds)
04:31:03 *** kredik has quit (Ping timeout: 268 seconds)
04:31:15 *** kredik_ (~chatzilla@ANice-551-1-138-77.w92-143.abo.wanadoo.fr) has joined #mapnik
04:34:59 *** willwhite has quit (Quit: willwhite)
04:36:02 *** willwhite (~diggersf@c-68-33-229-33.hsd1.dc.comcast.net) has joined #mapnik
05:04:17 *** willwhite has quit (Quit: willwhite)
05:27:54 *** ajturner (~ajturner@pool-72-66-109-70.washdc.fios.verizon.net) has joined #mapnik
05:40:40 *** dkb has quit (Quit: Leaving.)
05:45:32 *** ajturner has quit (Quit: ajturner)
05:58:19 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
06:41:01 *** Phurl (~mdupont@ip-81-210-228-126.unitymediagroup.de) has joined #mapnik
06:46:56 *** Phurl has quit (Ping timeout: 246 seconds)
06:56:06 *** HounD has quit (Ping timeout: 276 seconds)
07:04:17 *** Phurl (~mdupont@2001:0:53aa:64c:cc7:2861:ae2d:1b81) has joined #mapnik
07:24:59 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
08:16:45 *** rweait has quit (Read error: Operation timed out)
08:31:32 <nikq> Mapnik Trac: Changeset [1659]: eliminate compiler warnings | http://trac.mapnik.org/changeset/1659
08:39:58 <nikq> Mapnik Trac: Ticket #475 (Rendring raster border bug) updated | http://trac.mapnik.org/ticket/475#comment:11
08:56:53 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik
08:57:24 *** HounD has quit (Ping timeout: 252 seconds)
09:41:17 *** alarmschaben (~armin@pd95bdca8.dip0.t-ipconnect.de) has joined #mapnik
09:55:19 *** alarmschaben has quit (Quit: leaving)
09:56:45 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
09:59:20 *** mperry has quit (Ping timeout: 256 seconds)
09:59:21 *** mperry_ is now known as mperry
10:27:15 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
10:32:31 *** artem has quit (Quit: artem)
10:37:09 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
10:37:54 *** HounD1 has quit (Ping timeout: 248 seconds)
10:45:09 *** HounD has quit (Ping timeout: 265 seconds)
10:45:28 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
10:47:47 *** HounD has parted #mapnik (None)
11:13:58 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik
11:13:58 *** gavinf has quit (Read error: Connection reset by peer)
11:27:11 *** Phurl is now known as Phulr
11:33:35 *** rweait (~nerd@weait.tor.istop.com) has joined #mapnik
11:35:21 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
11:36:44 *** HounD1 has quit (Ping timeout: 246 seconds)
12:23:05 *** luneff (~yury@93.178.84.240) has joined #mapnik
12:47:57 *** willwhite (~diggersf@c-68-33-229-33.hsd1.dc.comcast.net) has joined #mapnik
12:54:04 *** willwhite has quit (Quit: willwhite)
13:02:23 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
13:02:25 *** dkb has quit (Client Quit)
13:02:28 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
13:12:49 *** gavinf (~gavinf@196.211.119.210) has joined #mapnik
13:15:57 *** luneff has quit (Quit: Leaving)
13:42:40 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
13:57:46 *** willwhite (~diggersf@c-98-218-226-144.hsd1.dc.comcast.net) has joined #mapnik
14:02:47 *** willwhite has quit (Quit: willwhite)
14:06:36 *** willwhite (~diggersf@c-98-218-226-144.hsd1.dc.comcast.net) has joined #mapnik
14:19:31 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik
14:21:21 *** HounD has quit (Ping timeout: 276 seconds)
14:24:19 *** ajturner has quit (Quit: ajturner)
14:49:21 *** ovnicraft has quit (Ping timeout: 245 seconds)
14:59:31 *** HounD1 has parted #mapnik (None)
15:00:25 *** dkb has quit (Quit: Leaving.)
15:27:22 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
15:40:38 *** luneff (~yury@93.178.84.240) has joined #mapnik
16:14:40 *** willwhite has quit (Quit: Leaving)
17:15:42 *** cgs_bob_ has quit (Ping timeout: 252 seconds)
17:16:08 *** Phulr has quit (Quit: Ex-Chat)
17:37:33 *** Phurl (~mdupont@2001:0:53aa:64c:cc7:2861:ae2d:1b81) has joined #mapnik
17:38:34 *** tcarobruce (~tcarobruc@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
17:39:40 *** Phurl has quit (Client Quit)
17:44:34 *** Phurl (~mdupont@2001:0:53aa:64c:cc7:2861:ae2d:1b81) has joined #mapnik
17:53:59 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
17:53:59 *** mperry has quit (Read error: Connection reset by peer)
17:53:59 *** mperry_ is now known as mperry
17:56:24 *** cgs_bob_ (~bob@64.sub-75-210-193.myvzw.com) has joined #mapnik
18:00:50 *** Phurl has quit (Read error: Operation timed out)
18:14:13 *** Phurl (~mdupont@2001:0:53aa:64c:2051:291b:ae2d:1b81) has joined #mapnik
18:17:11 *** bitterman (~yury@93.178.86.17) has joined #mapnik
18:21:02 *** luneff has quit (Ping timeout: 265 seconds)
18:21:36 *** ajashton (~aj@c-98-218-226-144.hsd1.dc.comcast.net) has joined #mapnik
18:22:22 *** tmcw (~Adium@c-98-218-226-144.hsd1.dc.comcast.net) has joined #mapnik
18:22:53 <tmcw> Hey springmeyer
18:23:04 <tmcw> You around?
18:23:34 <springmeyer> tmcw: yes, on a conference call for another hour
18:23:37 <springmeyer> you around then?
18:24:01 <tmcw> Yep, just ping me
18:31:33 <springmeyer> thx
18:41:37 *** darth_bitterman (~yury@93.178.86.17) has joined #mapnik
18:41:46 *** rweait has quit (Ping timeout: 264 seconds)
18:45:12 *** bitterman has quit (Ping timeout: 256 seconds)
18:47:39 *** rweait (~nerd@66.11.182.154) has joined #mapnik
19:08:49 *** springmeyer_ (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
19:08:52 *** springmeyer_ has quit (Remote host closed the connection)
19:08:52 *** springmeyer has quit (Read error: Connection reset by peer)
19:08:57 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
19:09:37 *** timlinux (~timlinux@qgis/developer/timlinux) has joined #mapnik
19:09:55 <timlinux> springmeyer: actually prolly more appropriate to say 'hi' here
19:10:22 <timlinux> just wanted to clarify some mapnik stuff
19:10:24 <springmeyer> hey there timlinux
19:18:26 <springmeyer> sure, timlinux  - I'm on a conference call but will hopefully be done soon!
19:23:28 <timlinux> ok
19:23:37 <timlinux> I'm multitasking too catch up when you are done
19:28:21 * springmeyer call finishes, ugh, another begins...
19:32:14 *** Primer (~daniel@www.ceregatti.org) has joined #mapnik
19:33:34 <Primer> Hi, I recently installed mapnik-python from Fedora 11's repo, and upon running the test script found in the "Getting Started" page of the wiki, it reports this:
19:33:38 <Primer>     m = mapnik.Map(600, 300)
19:33:40 <Primer> AttributeError: 'module' object has no attribute 'Map'
19:34:02 <Primer> Not really knowing python all that well, I presume the "import mapnik" did NOT fail, yet...this...
19:34:50 <Primer> I have an application that I'm looking to debug, but the mapnik integration is C++, written into a perl XS, and ultimately called in apache using mod_perl...not an ideal debugging environment
19:50:48 <Primer> oh wow, I never realized the distro's mapnik was so old
19:50:50 <Primer> mapnik-0.5.2-0.13.svn780.fc11.x86_64
19:50:56 <Primer> guess I'll compile from source
20:05:55 *** tcarobruce has parted #mapnik (None)
20:23:43 <Primer> wow, the problem was the fact that my script was named mapnik.py
20:24:24 <Primer> python fails
20:48:36 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik
20:51:18 <Primer> Are mapnik filters applied via mapnik itself? i.e. if I set a filter, is this not passed to the backend (postgis in this case)?
20:51:59 <springmeyer> ya, Primer - don't do that (naming local file the same as the actual module) :)
20:52:08 <Primer> I'm logging the queries sent, and it seems that the only query that comes through is one that obtains the geometry and the text column that I'm filtering on, but nothing is the where clause for that text column
20:52:17 <Primer> springmeyer: I know better now
20:52:18 <springmeyer> python 2.6/3.c has some new mechanisms for avoiding that I think
20:52:35 <springmeyer> yep, certainly gotta learn it once
20:53:05 <springmeyer> upgrading to latest from 0.5.2 is a good call either way :)
20:53:37 <springmeyer> so Primer - no filters are not passed to the backend
20:54:09 <Primer> that makes sense, given what I've observed
20:55:15 <springmeyer> if you want a where clause to apply to the whole layer (no matter what styles interact with it) then apply that at the datasource level
20:55:55 <springmeyer> table = (select something from table WHERE field = 'foo') as filtered_table
20:56:32 <springmeyer> Primer: feel free to edit the wiki (noting names to avoid calling the file...)
20:57:54 <Ldp__> springmeyer: I feel a basic mode, where mapnik *will* apply whatever columns it uses in the style filters to the actual SQL query, will be a good thing to have
20:58:15 <Ldp__> but it shouldn't be automatic
20:58:52 <springmeyer> Ldp__: certainly, I've thought that myself
21:00:05 <springmeyer> where the field 'names' collected by Mapnik's attribute_collector as used in filters would be used instead of `select *` in the case that the user does not base a subselect for the table parameter
21:00:07 <Ldp__> whenever there is an actual 'WHERE' in the query, or it actually is a subquery (as most in osm.xml), it shouldn't do that
21:00:16 <springmeyer> yes
21:00:43 <springmeyer> so you are thinking it should also apply a `WHERE this,that,other not null' ?
21:00:58 <Ldp__> a bit more advanced than that
21:01:08 <Ldp__> but that's the gist of it, yeah
21:02:06 <springmeyer> okay, ya could be tricky to do right, but I guess it would be nice for many simple cases
21:02:18 <Ldp__> we use a few where key in ('l','i','s','t) constructs, and mapnik could be smart enough to build those too, whenever the list would hold just a few members
21:02:34 <springmeyer> and while interpreting potential errors could be tricky it would stil be useful
21:02:36 <springmeyer> Ldp__: yep
21:02:44 <Ldp__> but where it won't do that yet, a 'key IS NOT NULL' will do just nicely
21:03:22 <springmeyer> unless the field type uses empty strings... instead of null
21:03:28 <springmeyer> but ya... :)
21:04:23 <Ldp__> speaking of NULLs, any chance we could get rid of the awful not [key] != '' construct too?
21:04:44 <springmeyer> yes, I created a ticket for that a long while back
21:05:00 <Ldp__> <filter>[highway] = null</filter>
21:05:03 <springmeyer> and then tried to dig into it myself, but got lost in boost::spirit
21:05:21 <springmeyer> of potentially:
21:05:28 <springmeyer> <filter>not [highway]</filter>
21:05:57 <Ldp__> actually, I'd expect a value of 0 or '0' to also match
21:06:02 <Ldp__> in your example
21:06:07 <springmeyer> #318
21:06:07 <nikq> Ticket #318: Null handling missing in Filter parser?, http://trac.mapnik.org/ticket/318
21:07:00 <Ldp__> heh, 0.6.2 :)
21:07:10 <springmeyer> heh, ya
21:08:00 <Ldp__> anything that is better understood than the current awkward syntax is a win
21:09:12 <springmeyer> yes, would be really nice I agree. Hopefully next time artem looks at recent mapnik2 improvements he can address (its the same code)
21:09:28 <Ldp__> http://trac.mapnik.org/report/9
21:14:11 <Ldp__> springmeyer: how hard do you think #244 would be in mapnik2 ?
21:14:12 <nikq> Ticket #244: Implement label_position_tolerance on ShieldSymbolizer with line placement, http://trac.mapnik.org/ticket/244
21:17:06 *** tmcw has parted #mapnik (None)
21:19:03 <springmeyer> Ldp__: hard to say without digging deeper. I know a visual example would help to if I were to take a closer look
21:19:16 <springmeyer> Ldp__: though are you sure it does not already work?
21:19:20 <Ldp__> you do understand the issue?
21:19:29 <Ldp__> eh, last time I tried, with 0.6.1, it didn't
21:19:35 <springmeyer> shieldsymbolizer inherits from text_symbolizer
21:20:29 <Ldp__> what I did was split on ';' in SQL, so every value was its own row, and then attempt to render with a ShieldSymbolizer with label_position_tolerance. I only got the first row rendered, the rest were dropped
21:20:51 <Ldp__> I could try again (but not right now)
21:21:54 <springmeyer> right, I've not got the attention span to look closely now, too many deadlines approaching...
21:22:15 <Ldp__> no problem, I'll try again, and make a mockup picture if it doesn't work yet
21:22:18 <springmeyer> but when you do try/test, know that David Eastcott added a placement=VERTEX option as well
21:22:30 <springmeyer> that may help with placing more along a line...
21:22:41 <Ldp__> will try
21:35:25 * springmeyer would really benefit from thinking through adding some visual tests to mapnik sources
21:37:34 *** chad_burt has quit (Ping timeout: 245 seconds)
21:38:12 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik
22:01:24 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
22:01:24 *** mperry has quit (Read error: Connection reset by peer)
22:01:25 *** mperry_ is now known as mperry
22:33:34 *** mperry has quit (Read error: Connection reset by peer)
22:38:25 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
22:38:59 *** StormTide (~Kevin@2002:186c:64c0:0:21d:60ff:fe5e:cf66) has joined #mapnik
22:43:44 *** Ldp__ has quit ()
23:36:53 *** ajashton has quit (Remote host closed the connection)
23:36:55 <Primer> I'm still trying to debug this issue with mapnik and postgis. It seems this table contains multiple geometry types, and querying geometry_columns yields 2 rows
23:37:31 <Primer> one of type "GEOMETRY" (but they're really points) and the other of type "MULTIPOLYGON"
23:38:05 <Primer> thing is, mapnik is querying the column of points for a layer of type "poly"
23:38:28 <Primer> at least this is what I'm seeing in my postgresql logs, where I have statement logging enabled
23:39:59 <jburgess> Primer: you can force mapnik to use a specific column by setting the "geometry_field" parameter in the postgis datasource
23:40:26 <Primer> jburgess: ok
23:40:50 <jburgess> you may also want to set the srid too, if you do that then it does not query the geometry_columns at all
23:41:43 <Primer> ok