#mapnik log: Monday 01, March 2010

2010 | 03

previous | next
00:04:06 <nikq> Mapnik Trac: Changeset [1651]: + calculate resolution using map's current extent   (see ticket #502 for  ... | http://trac.mapnik.org/changeset/1651
00:07:19 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:6
00:11:12 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:7
00:14:55 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:8
00:58:45 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:9
01:01:08 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:10
01:01:48 <nikq> Mapnik Trac: problem.png attached to Ticket #502 | http://trac.mapnik.org/attachment/ticket/502/problem.png
01:02:20 <nikq> Mapnik Trac: old_no_buffer.png attached to Ticket #502 | http://trac.mapnik.org/attachment/ticket/502/old_no_buffer.png
01:02:40 <nikq> Mapnik Trac: old_buffer_256.png attached to Ticket #502 | http://trac.mapnik.org/attachment/ticket/502/old_buffer_256.png
01:02:51 <nikq> Mapnik Trac: old_buffer_512.png attached to Ticket #502 | http://trac.mapnik.org/attachment/ticket/502/old_buffer_512.png
01:03:12 <nikq> Mapnik Trac: new_no_buffer.png attached to Ticket #502 | http://trac.mapnik.org/attachment/ticket/502/new_no_buffer.png
01:03:22 <nikq> Mapnik Trac: new_buffer_256.png attached to Ticket #502 | http://trac.mapnik.org/attachment/ticket/502/new_buffer_256.png
01:03:33 <nikq> Mapnik Trac: new_buffer_512.png attached to Ticket #502 | http://trac.mapnik.org/attachment/ticket/502/new_buffer_512.png
01:09:57 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:11
01:11:39 <nikq> Mapnik Trac: Changeset [1652]: + calculate resolution using map's current extent | http://trac.mapnik.org/changeset/1652
01:12:19 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) closed | http://trac.mapnik.org/ticket/502#comment:12
01:13:10 <nikq> Mapnik Trac: Ticket #503 (Add tolerance to the features_at_point() query in the PostGIS plugin) updated | http://trac.mapnik.org/ticket/503#comment:1
01:17:14 <nikq> Mapnik Trac: Ticket #320 (SVG-Based Symbolizers) updated | http://trac.mapnik.org/ticket/320#comment:33
01:18:14 <nikq> Mapnik Trac: Ticket #457 (mapnik2 branch should consider using new libname/python bindings module  ...) closed | http://trac.mapnik.org/ticket/457#comment:2
01:20:06 <nikq> Mapnik Trac: Ticket #490 (memory error in python2.5 (system) osx binary when running tests) closed | http://trac.mapnik.org/ticket/490#comment:1
01:20:36 <nikq> Mapnik Trac: Ticket #511 (Change in alpha value in Mapnik color constructor between Mapnik 0.7 and  ...) updated | http://trac.mapnik.org/ticket/511#comment:2
01:22:18 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:13
01:22:38 <nikq> Mapnik Trac: Ticket #520 (Serializing map buffer_size?) created | http://trac.mapnik.org/ticket/520
01:30:05 <nikq> Mapnik Trac: Ticket #502 (Map buffer_size not accounted for within GDAL plugin scaling logic) updated | http://trac.mapnik.org/ticket/502#comment:14
02:03:26 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
02:03:28 *** dkb has quit (Client Quit)
02:03:31 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
02:13:29 *** dkb has parted #mapnik (None)
03:12:26 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
05:05:46 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
05:13:29 *** dkb has quit (Quit: Leaving.)
05:50:29 *** shoe has quit (Ping timeout: 258 seconds)
06:01:05 *** cgs_bob_ has quit (Remote host closed the connection)
06:05:31 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik
06:08:30 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
06:08:36 *** mperry has quit (Quit: mperry)
06:16:53 *** blarney (~blarney@pool-108-7-59-177.bstnma.fios.verizon.net) has joined #mapnik
06:17:29 *** blarney has parted #mapnik (None)
06:26:46 <dodobas> yello
06:31:16 * springmeyer start snoring
06:38:00 <dodobas> oh an...
06:38:03 <dodobas> *man
06:39:01 <dodobas> you need to double up your working hours..so...if you currently work 16h a day...
06:39:13 <dodobas> hmm.. thats 32h per day...seems doable :D
06:39:54 * springmeyer blinks
07:21:02 *** mishok13 (~gdmfsob@smtp-kyiv.cogniance.com) has joined #mapnik
07:25:53 *** cgs_bob has quit (Remote host closed the connection)
08:26:23 *** springmeyer has quit (Remote host closed the connection)
08:26:42 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
10:06:50 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik
10:09:58 *** HounD has quit (Ping timeout: 264 seconds)
10:30:56 *** malthe (~user@196.0.26.35) has joined #mapnik
11:41:05 *** malthe_ (~user@196.0.26.35) has joined #mapnik
11:41:11 *** malthe has quit (Remote host closed the connection)
12:03:13 *** malthe__ (~user@196.0.26.37) has joined #mapnik
12:04:46 *** malthe_ has quit (Ping timeout: 245 seconds)
12:22:34 *** luneff (~yury@93.178.69.211) has joined #mapnik
12:29:26 *** bitterman (~yury@93.178.69.211) has joined #mapnik
12:31:27 *** HounD1 has quit (Ping timeout: 258 seconds)
12:31:39 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
12:32:59 *** luneff has quit (Ping timeout: 245 seconds)
12:41:12 <nikq> Mapnik Trac: layer_tolerance.diff attached to Ticket #503 | http://trac.mapnik.org/attachment/ticket/503/layer_tolerance.diff
12:53:10 *** Genscher (~Richard@dslb-092-075-124-197.pools.arcor-ip.net) has joined #mapnik
12:59:42 *** bitterman has quit (Quit: Leaving)
13:31:06 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
13:34:05 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
14:02:26 *** luneff (~yury@93.178.83.188) has joined #mapnik
14:17:45 *** shoe (~user@ip24-250-63-6.ri.ri.cox.net) has joined #mapnik
14:26:44 *** mattbUK (~mattbridg@cpc1-stav16-2-0-cust64.aztw.cable.virginmedia.com) has joined #mapnik
14:30:58 *** bitterman (~yury@93.178.83.188) has joined #mapnik
14:31:01 *** malthe__ has quit (Ping timeout: 245 seconds)
14:32:12 <mattbUK> Hello folks - tried asking this in openlayers - no response from modem - so trying here.  I'm confused about how to get OpenLayers.Layer.OSM.Mapnik to render a singleTile - have tried {singleTile: true, ratio: 1} always returns Blue tile - going a bit crazy
14:33:37 *** luneff has quit (Ping timeout: 276 seconds)
14:37:14 <tomhughes> what do you mean exactly? singleTile is an option for WMS layers isn't it? to make them request one big image instead of a number of small ones? how does that relate to our mapnik layer?
14:39:18 <mattbUK> that's my question - my mapnik layer is returning an area that is far to large (ie: 12 tiles more than I need) I want to limit the area returned
14:43:08 <bitterman> that's for bounds
14:43:13 <bitterman> not for mapnik
14:43:23 <bitterman> but wrong bounds shift tiles numbers
14:43:29 <bitterman> i tried that sometime ago )
14:43:32 *** bitterman is now known as luneff
14:57:05 *** mattbUK has parted #mapnik (None)
15:04:40 *** ajturner_ (~ajturner@209.155.228.129) has joined #mapnik
15:07:14 *** ajturner has quit (Ping timeout: 248 seconds)
15:07:14 *** ajturner_ is now known as ajturner
15:41:20 *** bitterman (~yury@4.61.117.87.donpac.ru) has joined #mapnik
15:44:16 *** luneff has quit (Ping timeout: 258 seconds)
15:44:21 *** willwhite (~diggersf@c-98-218-226-144.hsd1.dc.comcast.net) has joined #mapnik
15:59:19 *** darth_bitterman (~yury@4.61.117.87.donpac.ru) has joined #mapnik
16:02:18 <dkb> mattbUK:how are you trying to access the tile?
16:02:34 *** bitterman has quit (Ping timeout: 245 seconds)
16:03:07 *** ajturner has quit (Quit: ajturner)
16:04:19 *** bitterman (~yury@221.37.117.87.donpac.ru) has joined #mapnik
16:05:26 *** kredik (~chatzilla@ANice-551-1-138-77.w92-143.abo.wanadoo.fr) has joined #mapnik
16:07:15 *** darth_bitterman has quit (Ping timeout: 252 seconds)
16:14:27 <kredik> Hi all, on windows, what boost modules should i install in order to compile the c++ demo samples ? is Vs 2003 supported ?
16:19:25 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
16:27:23 *** bitterman has quit (Quit: Leaving)
16:36:01 *** HounD has parted #mapnik (None)
16:36:08 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik
16:46:22 *** gavinf has quit (Read error: Connection reset by peer)
16:55:41 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
17:02:16 *** cgs_bob has quit (Ping timeout: 268 seconds)
17:13:42 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik
17:14:45 <dodobas> yello
17:16:09 <springmeyer> goodnight dodobas :)
17:16:56 <springmeyer> kredik: boost_thread,program_options,python,regex,iostream,filesystem,system
17:18:27 <dodobas> hehe...to early...
17:20:16 <springmeyer> :)
17:24:11 <dodobas> anyway, im sortingmy  rss feeds today, i've ditched google fcking reader...
17:24:53 <springmeyer> what did you move to?
17:25:11 *** luneff (~yury@93.178.79.219) has joined #mapnik
17:25:18 <dodobas> im using newsbeuter, really kuul
17:30:01 <dodobas> springmeyer: what do you use?
17:30:24 <springmeyer> mail.app, nothing special
17:31:21 <nikq> Mapnik Trac: Ticket #475 (Rendring raster border bug) updated | http://trac.mapnik.org/ticket/475#comment:4
17:31:32 <dodobas> ahh, yeah... osx :D
17:33:43 <nikq> Mapnik Trac: Ticket #475 (Rendring raster border bug) updated | http://trac.mapnik.org/ticket/475#comment:5
17:42:12 *** jctull (~jctull@adsl-75-14-218-16.dsl.renocs.sbcglobal.net) has joined #mapnik
17:48:42 *** cgs_bob (~bob@10.sub-75-210-78.myvzw.com) has joined #mapnik
17:56:01 *** tcarobruce (~tcarobruc@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
17:57:41 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
17:57:41 *** luneff has quit (Read error: Connection reset by peer)
17:57:48 *** shoe has quit (Read error: Connection reset by peer)
17:58:20 <artem> springmeyer: hey there
17:58:28 *** luneff (~yury@93.178.64.217) has joined #mapnik
17:58:38 <springmeyer> hey artem!
17:58:40 *** shoe (~user@ip24-250-63-6.ri.ri.cox.net) has joined #mapnik
17:59:00 <artem> I'll pop in later on to chat about 0.7.1
17:59:12 <springmeyer> okay, great, thanks
17:59:22 *** bitterman (~yury@93.178.64.217) has joined #mapnik
18:00:12 <springmeyer> aka the 'marcin rocks' release :)
18:00:29 <artem> yep, great work!
18:01:50 <artem> re: #516 - not sure what to do about Oracle, but sqlite should just wok
18:01:51 <nikq> Ticket #516: Evaluate proper handling of endianess in SQLite and Oracle plugins, http://trac.mapnik.org/ticket/516
18:02:06 <artem> milestone 0.7.1
18:02:06 <nikq> 4 open tickets in Milestone 0.7.1: Add tolerance to the features_at_point() query in the PostGIS plugin, Evaluate proper handling of endianess in SQLite and Oracle plugins, Serializing map buffer_size?, Rendring raster border bug
18:02:08 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.7.1&order=priority
18:02:09 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.7.1
18:02:23 <artem> hah, 4 tickets :)
18:02:50 <springmeyer> sqlite does appear to work just fine with normal wkb
18:02:57 <springmeyer> just not with 'spatiallite': http://trac.mapnik.org/ticket/514
18:03:20 <artem> ok, thanks
18:03:23 <springmeyer> which is becoming in much more common usage
18:03:42 *** luneff has quit (Ping timeout: 265 seconds)
18:04:50 <springmeyer> but if the endian change to postgis looks okay to you, thats most important
18:05:18 <artem> k, I'll build fresh spatiallite lib
18:05:39 <artem> and check postgis.input
18:06:01 <springmeyer> k. thats smart, I was using kyngchaos on ppc
18:06:25 <springmeyer> I think spatiallite on intel worked fine for me, but would be good to check again
18:06:49 <artem> great, got to run but bbl
18:07:02 <springmeyer> I also partly flagged that ticket as a reminder to me to try to get a bunch of sqlite/spatialite test data into tests/data
18:07:12 <springmeyer> but I'm not going to have time for that at this point
18:07:18 <springmeyer> k, catch you later artem - thx!
18:07:36 <artem> would be really cool - how about extract from planet.osm ?
18:07:50 <springmeyer> good idea, yes
18:08:22 <springmeyer> I have a set of extensive postgres SQL tests I need to get into the formal tests (most use osm extract)
18:08:48 *** ajturner has quit (Quit: ajturner)
18:08:49 *** artem has quit (Quit: artem)
18:15:30 *** mperry_ has quit (Read error: Connection reset by peer)
18:15:34 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
18:23:40 *** mperry has quit (Read error: Connection reset by peer)
18:23:49 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
18:26:45 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
18:26:45 *** mperry has quit (Read error: Connection reset by peer)
18:26:46 *** mperry_ is now known as mperry
18:44:20 *** gavinf (~gavinf@196.211.2.133) has joined #mapnik
18:46:00 *** jburgess (~jburgess@15.92.187.81.in-addr.arpa) has joined #mapnik
19:33:03 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
19:33:36 <springmeyer> Ldp's haiti basemap featured in ushahidi video showing now on:
19:33:37 <springmeyer> http://wbi.worldbank.org/wbi/news/2010/02/25/developers-development-using-open-source-technologies-disaster-response-and-beyond?cid=EXT_TWBN_D_EXT#links
19:35:53 <dkb> real play and windows media only?
19:37:21 <racicot> sounds like they will have a recording posted tomorrow.... hopefully in a more friendly format
19:43:04 <artem> springmeyer: not too sure about : http://trac.mapnik.org/ticket/515
19:44:00 <artem> we still need to swap if WKB comes in opposite to system's byte order
19:44:15 <artem> am I missing something ?
19:44:43 <springmeyer> artem: okay. is there a case (right now) where that can happen?
19:44:44 <artem> and current change would certainly break sqlite.input
19:45:16 * artem checking
19:45:16 <springmeyer> I thought it would but appeared to work fine (I should check again maybe I missed something)
19:45:44 <artem> you need to force big-endian wkb on  little-endian system
19:46:35 <artem> I can create a test using pgsql2sqlite
19:47:31 <springmeyer> I think jburgess may have ppc machine to test too...
19:59:23 *** luneff (~yury@160.63.117.87.donpac.ru) has joined #mapnik
20:00:07 *** luneff has quit (Read error: Connection reset by peer)
20:00:33 *** luneff (~yury@160.63.117.87.donpac.ru) has joined #mapnik
20:03:10 *** bitterman has quit (Ping timeout: 276 seconds)
20:05:39 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik
20:24:13 *** jctull has quit (Quit: jctull)
20:24:34 <springmeyer> anyone ever seen anything like this?
20:24:56 <springmeyer> 2MB png of OSM data with select colors inverted
20:25:04 <springmeyer> http://dbsgeo.com/tmp/wms_image_corruption.png
20:25:38 <springmeyer> coming from OGCServer, it happens when the image rendered gets around 10,000x10,000 pixels
20:25:56 <springmeyer> jpeg output from mapnik does not suffer from this, just png....
20:27:15 <springmeyer> png256 to be specific, have not tried normal png yet
20:27:47 <springmeyer> it should look more like: http://tile2.dbsgeo.com/?layers=__all__&bbox=18.497972,-72.479639,18.572645,-72.247381&height=1000&width=1400&service=WMS&request=GetMap&version=1.3.0&srs=EPSG:4326&format=image/png&styles=&crs=EPSG:4326
20:27:59 <artem> hmm, interesting .. it can be int32 overflowing in color reduction algo
20:28:20 <artem> too many pixels :D
20:28:48 <Ldp__> not everything is inverted. Notably the blues
20:29:05 <artem> springmeyer : new ticket ?
20:29:39 <artem> Ldp__: I think some color cubes get over flown - bg colour for example
20:29:53 <springmeyer> artem: yes, no ticket for this yet
20:29:59 <Ldp__> and being dropped, probably
20:30:00 <artem> we need to use int64_t I thin k
20:30:13 <springmeyer> I just learned late last night from haiti field folks trying to make enormous prints from ArcMap
20:30:35 <Ldp__> ford symbol is fine, collapsed building symbol is fine, but hospital symbol isn't
20:31:29 <artem> springmeyer: could you try  32bit 'png' to verify it's colour reduction that causing this ?
20:31:45 <springmeyer> yes, surely...
20:31:52 * springmeyer goes to login to server
20:37:12 <springmeyer> artem: yes, works fine with normal png
20:37:37 <artem> ok, sounds right:)
20:38:02 <springmeyer> 10,000x12,000 png looks big and nice
20:38:56 <artem> and eats lots of RAM
20:39:31 <artem> are you viewing in preview.app?
20:40:42 <springmeyer> no, directly in safari, preview seems like it wanted to crash
20:42:33 <springmeyer> I've noticed that nik2img.py always crashes preview's libpng as well
20:42:51 <springmeyer> something about overwriting an image preview.app already has open
20:43:05 <artem> I can think about two ways to fix this:
20:43:14 <artem> use uint64_t
20:44:18 <artem> or come up with clever algo which will sample smaller areas to determine important colours and apply that palette to the whole image
20:45:44 <springmeyer> it seems eventually we may need the ability to pass in a pre-generated palatte
20:46:03 <artem> springmeyer: are you running on 32 or 64 ?
20:46:14 <springmeyer> 64 ubuntu 9.10
20:46:31 <springmeyer> $ uname -a
20:46:31 <springmeyer> Linux haiti.dbsgeo.com 2.6.32-x86_64-linode11 #1 SMP Sat Dec 5 16:55:26 UTC 2009 x86_64 GNU/Linux
20:46:32 <nikq> Ticket #1: no such ticket. (list index out of range)
20:46:33 <artem> yes, pre-generated palette sounds ghood
20:46:52 <artem> let, try something simple first ...
20:47:00 <springmeyer> you bet, thanks
20:51:13 *** dkb has parted #mapnik (None)
20:53:30 *** jctull (~jctull@adsl-75-32-114-173.dsl.renocs.sbcglobal.net) has joined #mapnik
20:55:06 <artem> springmeyer: rendering 10000x10000 images from rundemo.py ..
20:55:37 <springmeyer> nice :)
20:55:40 <artem> look ok, try declaring :
20:55:47 <artem>  uint64_t reds;
20:55:47 <artem>                uint64_t greens;
20:55:47 <artem>                uint64_t blues;
20:55:47 <artem>                uint64_t count;
20:55:48 <artem>                uint64_t count2;
20:55:55 <artem> in octree.hpp
20:56:26 <springmeyer> artem: for really big images, could we use mmapping? or write in chunks? or is that  even possible with libpng/libjpeg issue?
20:56:35 <springmeyer> k, will go find that...
20:57:41 <artem> it might be possible to tweak i/o in libpng/libjpeg  I think you can define user callbacks for i/o
20:59:02 <artem> also, it might be good idea to provide mmap based Image implementation for very large output
20:59:16 <nikq> Mapnik Trac: Ticket #332 (Rendering curved paths) updated | http://trac.mapnik.org/ticket/332#comment:14
20:59:19 <springmeyer> artem: great
21:02:48 * springmeyer recompiling...
21:05:55 <artem> demo256.png: PNG image, 20000 x 20000, 8-bit colormap, non-interlaced
21:06:01 <artem> seems to be ok , too
21:06:01 * springmeyer switching ogcserver back to png256...
21:06:43 <springmeyer> 20,000 ! nice, that size previous caused 'memory error' on my machine
21:06:55 <springmeyer> I have about 1.7GB mem on VM
21:07:21 <artem> yes, you need more
21:07:51 <springmeyer> nice!!
21:08:03 <springmeyer> works, artem is a genius :)
21:08:13 <artem> cool, great
21:08:52 <springmeyer> $ file tile2-2.dbsgeo.com.png
21:08:53 <springmeyer> tile2-2.dbsgeo.com.png: PNG image data, 12000 x 10000, 8-bit colormap, non-interlaced
21:09:10 <springmeyer> brilliant :)
21:09:32 <artem> well, uin64_t might not be available on all platforms
21:10:01 <springmeyer> do we need to use boost something?
21:10:53 <artem> yes, it's better to get boost::uint64_t but it's defined in std as well I tnink
21:11:47 <nikq> Mapnik Trac: jpeg_reader.cpp attached to Ticket #518 | http://trac.mapnik.org/attachment/ticket/518/jpeg_reader.cpp
21:12:50 <nikq> Mapnik Trac: Ticket #518 (Addition of JPEGReader) updated | http://trac.mapnik.org/ticket/518#comment:1
21:13:45 <artem> springmeyer: JpegReader is cool!
21:14:35 <springmeyer> :) ya, methinks so too
21:21:17 <springmeyer> took me forever to actually figure out we didn't have jpeg read support
21:21:37 <springmeyer> by that point I was determined to have it :)
21:21:56 <springmeyer> now that I understand, that whole factory thing is wicked cool
21:23:51 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
21:24:08 <artem> great
21:25:01 <springmeyer> with jpeg reader this narly stuff should be able to be ditched:
21:25:05 <springmeyer> http://code.google.com/p/mapnik-utils/source/browse/trunk/serverside/cascadenik/cascadenik/compile.py?r=900#817
21:32:12 *** springmeyer_ (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
21:36:22 *** springmeyer has quit (Ping timeout: 264 seconds)
21:36:22 *** springmeyer_ is now known as springmeyer
21:45:36 *** bitterman (~yury@65.59.117.87.donpac.ru) has joined #mapnik
21:46:49 *** luneff has quit (Read error: Connection reset by peer)
21:59:27 *** darth_bitterman (~yury@65.59.117.87.donpac.ru) has joined #mapnik
22:03:09 *** bitterman has quit (Ping timeout: 240 seconds)
22:05:58 *** darth_bitterman has quit (Read error: Connection reset by peer)
22:06:15 *** darth_bitterman (~yury@194.53.117.87.donpac.ru) has joined #mapnik
22:29:26 *** bitterman (~yury@194.53.117.87.donpac.ru) has joined #mapnik
22:33:09 *** darth_bitterman has quit (Ping timeout: 240 seconds)
22:49:52 *** springmeyer has quit (Read error: Connection reset by peer)
22:49:57 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
22:50:13 *** artem has quit (Quit: artem)
22:57:35 *** Genscher has quit (Read error: Connection reset by peer)
22:57:49 *** Genscher (~Richard@dslb-092-075-124-197.pools.arcor-ip.net) has joined #mapnik
23:07:03 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
23:32:50 <nikq> Mapnik Trac: Ticket #521 (OGCServer and ArcMap 9.1 GetMap fails) created | http://trac.mapnik.org/ticket/521
23:34:52 <nikq> Mapnik Trac: Ticket #521 (OGCServer and ArcMap 9.2 GetMap fails) updated | http://trac.mapnik.org/ticket/521#comment:1
23:36:47 *** bitterman has quit (Quit: Leaving)
23:50:15 <nikq> Mapnik Trac: Ticket #521 (OGCServer and ArcMap 9.2 GetMap fails) updated | http://trac.mapnik.org/ticket/521#comment:2