00:07:02 *** dkb has quit (Quit: Leaving.) 00:21:03 *** willwhite has quit (Quit: willwhite) 01:08:50 *** rweait (~nerd@weait.tor.istop.com) has joined #mapnik 01:35:30 *** Genscher has quit (Quit: Leaving) 01:57:14 *** jctull has quit (Quit: jctull) 02:00:34 *** cgs_bob has quit (Ping timeout: 248 seconds) 02:16:08 *** Ldp__ has quit () 02:24:08 *** tcarobruce has quit (Quit: tcarobruce) 02:29:00 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 03:02:06 <dkb> If I wanted to create a tile layer with only the highway tags and another layer with everything but the highway tag it looks like I would have to heavily edit the osm.xml file, is this correct? I was worried about losing the ability to easily checkout updates to the osm.xml file. 03:10:22 <springmeyer> any edits you make to files other than the inc/*.example can potentially conflict with versioned files 03:10:32 <springmeyer> but thats not a problem really 03:10:43 <springmeyer> you don't loose the ability to check out 03:11:05 <springmeyer> you just run the risk of conflicts, but subversion can help with that 03:12:16 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 03:12:57 <dkb> Ok, thanks. I assume removing all the xml related to non-highway tags would significantly decrease rendering time as well? 03:14:02 <springmeyer> dkb: sure, depends on the zoom level though which layers are taking the most time to render 03:15:12 <dkb> Ok good. I will try it out. 03:26:42 *** jfxberns (~jfxberns@ppp-58-8-239-26.revip2.asianet.co.th) has joined #mapnik 03:26:43 *** jfxberns has quit (Excess Flood) 03:28:05 *** jfxberns (~jfxberns@ppp-58-8-239-26.revip2.asianet.co.th) has joined #mapnik 03:31:15 <nikq> Mapnik Trac: Changeset [1653]: now that we're using an image cache missing images will not/can not throw | http://trac.mapnik.org/changeset/1653 03:31:55 <nikq> Mapnik Trac: Changeset [1654]: print warning if images are not found | http://trac.mapnik.org/changeset/1654 03:46:55 *** springmeyer_ (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 03:50:49 *** springmeyer has quit (Ping timeout: 264 seconds) 03:50:50 *** springmeyer_ is now known as springmeyer 03:55:22 *** ajturner has quit (Quit: ajturner) 03:58:43 *** jfxberns_ (~jfxberns@ppp-58-8-125-95.revip2.asianet.co.th) has joined #mapnik 04:00:06 *** jfxberns has quit (Ping timeout: 240 seconds) 04:00:06 *** jfxberns_ is now known as jfxberns 04:14:58 *** jfxberns has quit (Quit: Going to hide someplace dark and quiet...) 04:34:14 *** rweait has quit (Read error: Connection reset by peer) 04:57:36 *** dkb has quit (Quit: Leaving.) 05:16:27 *** malthe (~user@196.0.26.38) has joined #mapnik 05:32:50 *** malthe has quit (Remote host closed the connection) 05:34:41 *** chad_bur_ (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik 05:37:07 *** chad_burt has quit (Ping timeout: 276 seconds) 05:51:48 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 05:55:06 *** dkb has quit (Client Quit) 05:56:21 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 05:57:28 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 05:59:13 *** mperry has quit (Ping timeout: 276 seconds) 05:59:13 *** mperry_ is now known as mperry 06:49:45 *** springmeyer has quit (Remote host closed the connection) 06:49:51 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 07:13:45 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik 07:15:13 *** HounD has quit (Ping timeout: 260 seconds) 07:19:39 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 07:20:02 *** HounD1 has quit (Ping timeout: 248 seconds) 07:39:01 *** HounD has quit (Ping timeout: 256 seconds) 08:15:28 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 08:53:32 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik 10:00:22 *** Ldp__ has quit (Ping timeout: 276 seconds) 10:13:06 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik 10:13:18 *** HounD1 has parted #mapnik (None) 10:13:57 *** HounD has quit (Ping timeout: 260 seconds) 10:31:49 *** harobed_ (~stephane@pda57-1-82-231-115-1.fbx.proxad.net) has joined #mapnik 10:56:28 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 11:13:35 <nikq> Mapnik Trac: Ticket #203 (Align polygon pattern fills globally) updated | http://trac.mapnik.org/ticket/203#comment:2 11:14:12 *** gavinf has quit (Read error: No route to host) 11:17:54 *** HounD has quit (Ping timeout: 276 seconds) 11:32:17 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 11:58:26 *** jbronn has quit (Ping timeout: 265 seconds) 12:00:01 *** jbronn (~jbronn@70-138-113-15.lightspeed.hstntx.sbcglobal.net) has joined #mapnik 12:11:48 <nikq> Mapnik Trac: Ticket #467 (Logging for PostGIS plugin) updated | http://trac.mapnik.org/ticket/467#comment:1 12:14:10 <nikq> Mapnik Trac: Ticket #499 (Graceful recovery if postgres connection is lost) updated | http://trac.mapnik.org/ticket/499#comment:1 12:27:22 <nikq> Mapnik Trac: Ticket #521 (OGCServer and ArcMap 9.2 GetMap fails) updated | http://trac.mapnik.org/ticket/521#comment:3 12:56:37 <nikq> Mapnik Trac: python_bindings.diff attached to Ticket #503 | http://trac.mapnik.org/attachment/ticket/503/python_bindings.diff 13:14:01 *** gavinf (~gavinf@196.211.2.133) has joined #mapnik 13:29:49 <nikq> Mapnik Trac: tolerance_full_patch.diff attached to Ticket #503 | http://trac.mapnik.org/attachment/ticket/503/tolerance_full_patch.diff 13:33:59 *** kredik has quit (Read error: Connection reset by peer) 13:39:48 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 13:54:44 <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:2 14:09:15 *** rweait (~nerd@weait.tor.istop.com) has joined #mapnik 14:30:40 *** mperry has quit (Read error: Connection reset by peer) 14:31:13 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 14:40:43 *** Phurl_ has quit (Read error: Operation timed out) 14:46:00 *** Phurl_ (~mdupont@2001:0:53aa:64c:2069:172f:ae2d:1b81) has joined #mapnik 14:49:07 *** HounD has parted #mapnik (None) 14:56:41 *** Phurl_ has quit (Read error: Operation timed out) 14:58:08 *** Phurl_ (~mdupont@2001:0:53aa:64c:2069:172f:ae2d:1b81) has joined #mapnik 15:43:53 <nikq> Mapnik Trac: mapnik-0.7.1.mr.scaling_offset.diff attached to Ticket #475 | http://trac.mapnik.org/attachment/ticket/475/mapnik-0.7.1.mr.scaling_offset.diff 16:18:26 *** mperry has quit (Read error: Connection reset by peer) 16:18:53 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 16:25:42 <nikq> Mapnik Trac: Ticket #521 (OGCServer and ArcMap 9.2 GetMap fails) updated | http://trac.mapnik.org/ticket/521#comment:4 16:29:40 *** kredik (~chatzilla@LLagny-156-35-42-212.w80-13.abo.wanadoo.fr) has joined #mapnik 16:45:30 <nikq> Mapnik Trac: Ticket #475 (Rendring raster border bug) updated | http://trac.mapnik.org/ticket/475#comment:6 17:10:45 <dkb> Using Quantumnik, how do I translate the Scale to a zoom level and Coordinate to lat/lon? I seemed to have lost the US State that is was rendering and can't zoom in/out or move around to locate it again. 17:13:50 <springmeyer> dkb: not sure, making the full extent zoom work would require hijacking QGIS more and I've not looked into that 17:14:39 *** cgs_bob has quit (Ping timeout: 245 seconds) 17:16:35 <dkb> so how do I locate the rendering areas again? or where is it saving the previous view? it appears restarting gqis and loading mapnik xml displays same areas as before quitting 17:17:39 <springmeyer> loading the XML in a newly opened app will zoom to the full extent of the data 17:17:40 *** harobed_ has quit (Quit: Ex-Chat) 17:18:08 <springmeyer> so if nothing is showing then you may have a different problem then where you a looking 17:22:04 <dkb> I'm going to try restarting machine 17:22:27 *** dkb has quit (Quit: Leaving.) 17:24:53 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 17:37:52 *** cgs_bob (~bob@43.sub-75-229-48.myvzw.com) has joined #mapnik 17:40:23 *** tcarobruce (~tcarobruc@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik 17:46:24 *** jctull (~jctull@adsl-75-32-114-173.dsl.renocs.sbcglobal.net) has joined #mapnik 18:06:31 <dkb> I checked out fresh copy of osm.xml and inc directory and that solved the problem. I had been modifying the xml files and a modification must have caused Qnik to no longer render anything. 18:25:41 <springmeyer> sure, okay 18:28:06 *** luneff (~yury@93.178.93.173) has joined #mapnik 18:41:30 *** bitterman (~yury@93.178.93.173) has joined #mapnik 18:45:22 *** luneff has quit (Ping timeout: 264 seconds) 18:45:26 <springmeyer> rweait: faired well? 18:46:16 <springmeyer> rweait: also, not sure when you last played with Mapnik2, but I've recently made it backwards compatible with existing osm.xml 18:46:40 <springmeyer> so, that might change you need for running two versions... 18:51:54 *** jctull has quit (Ping timeout: 258 seconds) 18:56:46 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 18:57:04 *** jctull (~jctull@ppp-71-142-132-250.dsl.renocs.pacbell.net) has joined #mapnik 18:58:56 *** mperry has quit (Ping timeout: 245 seconds) 18:58:56 *** mperry_ is now known as mperry 19:31:10 <rweait> springmeyer: sorry. I was out. I was able to render with generate_image.py under mapnik and mapnik2. I'm looking for the mapnik2 docs so I can confirm that I'm actually using mapnik2 by changing a few rules. 19:31:19 <rweait> So far, so good. 19:33:07 <springmeyer> ah, great 19:33:34 <springmeyer> you'll know you are using mapnik2 if you get deprecation warnings with existing xml Text/Shield symbolizers 19:33:50 <springmeyer> docs: http://mapnik.org/news/2009/dec/08/future_mapnik2/ 19:35:49 <rweait> I don't remember warnings, so maybe I didn't get the mapnik2 module. I'll try it again. 19:36:59 *** springmeyer has quit (Read error: Connection reset by peer) 19:37:00 *** springmeyer_ (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 19:39:14 <springmeyer_> python -c "import mapnik;print mapnik.__file__" 19:39:29 <springmeyer_> ^^ will give you a hint which one is on your current PYTHONPATH 19:40:03 <rweait> it's my path. 19:40:12 <rweait> /home/nerd/src/mapnik2/lib64/python2.6/site-packages 19:40:22 <rweait> is 2.6 a problem? 19:42:29 <rweait> _mapnik.so: undefined symbol: _ZN6mapnik15text_symbolizer11set_fontsetERKNS_8font_setE 19:42:57 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 19:43:05 *** springmeyer has quit (Remote host closed the connection) 19:43:10 *** springmeyer_ has quit (Read error: Connection reset by peer) 19:43:11 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 19:43:21 <rweait> wow. connection problems? 19:43:24 <rweait> ;-) 19:43:35 <rweait> electrical storm? 19:46:16 <springmeyer> ethernet cord without that special little tab :) 19:46:35 <springmeyer> 2.6 is fine 19:46:58 <springmeyer> $ ldd /home/nerd/src/mapnik2/lib64/python2.6/site-packages/mapnik/_mapnik.so 19:46:59 <springmeyer> ? 19:47:33 <rweait> long list. 19:47:43 <springmeyer> oh ya, this is linux... forgot bout that :) 19:47:59 <springmeyer> on osx libraries at link time can be found anywhere 19:48:13 <springmeyer> rweait: can you http://dpaste.com 19:48:14 <springmeyer> ? 19:48:19 <rweait> sure 19:48:47 <springmeyer> export LD_LIBRARY_PATH=/home/nerd/src/mapnik2/lib64/ 19:49:17 <springmeyer> will likely be needed for the mapnik2 python bindings to correctly find the mapnik2 core c++ library 19:49:49 <rweait> http://dpaste.com/167054/ 19:49:53 <springmeyer> so, maybe put that plus the pythonpath setting in a little bash file, 'setup_mapnik2.sh' or something... 19:50:17 <springmeyer> ew... not good 19:50:26 <springmeyer> we don't like: 'libmapnik.so.0.6 => /usr/lib/libmapnik.so.0.6' 19:50:49 <springmeyer> means that when you compiled mapnik2 it directly linked the libmapnik from packages 19:51:02 <springmeyer> rather than itself, which is odd 19:51:07 <rweait> could that be left from the package installation of libmapnik? 19:51:09 <springmeyer> we need to recompile mapnik2 19:51:15 <springmeyer> yes it is 19:51:28 <springmeyer> but even with it there that should not happen (ideally) 19:51:36 <springmeyer> rweait: please do... 19:51:42 <springmeyer> cd mapnik2_sources 19:51:50 <springmeyer> python scons/scons.py -c 19:52:00 <springmeyer> sudo python scons/scons.py install 19:52:17 <springmeyer> then grep through the output (when that finishes) 19:52:35 <springmeyer> and find the linker line that includes the text 'libmapnik.so' 19:55:36 <rweait> still waiting on it. This box is importing planet as well. 19:56:14 <springmeyer> okay, ya trunk compile times are currently slow, so no hurry :) 19:56:44 <springmeyer> oh, rweait sorry, would be good to make sure we reconfigure to... 19:57:00 <springmeyer> python scons/scons.py configure 19:57:02 <springmeyer> before install... 19:57:12 <springmeyer> find to ctrl-c mid-way... 19:59:06 <rweait> scons/scons.py -c then scons/scons.py configure ? 19:59:26 <rweait> then install and find the linker line? 20:01:50 <springmeyer> yes 20:02:08 <springmeyer> er, test again before searching for the linker line 20:02:16 <springmeyer> cuz hopefully a clean re-compile will work 20:02:34 <springmeyer> if not I'll need that linker line to debug-bub-bug 20:04:16 <rweait> configuring. had to do some permissions cleanup 20:22:21 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik 20:34:27 <rweait> ldd: /home/nerd/src/mapnik2/lib64/python2.6/site-packages/mapnik/_mapnik.so: No such file or directory 20:34:49 <springmeyer> ah, its in lib now not lib64 20:36:13 <rweait> no lib or lib64 20:37:16 <rweait> /home/nerd/src/mapnik2/bindings/python/_mapnik.so 20:37:29 <rweait> libmapnik.so.0.6 => /usr/lib/libmapnik.so.0.6 (0x00007fadb491c000) 20:38:48 <springmeyer> hmm 20:39:15 <springmeyer> so help me understand, '/home/nerd/src/mapnik2/' is the spot you checked out the sources? 20:39:18 <springmeyer> and where did you install? 20:39:36 <springmeyer> but yes, either way that linking is not what we want... 20:40:48 <rweait> yes, ~/src/mapnik2 was the checkout and the configure, -c, install 20:41:06 <rweait> er, -c, configure, install 20:41:38 <springmeyer> right, okay 20:41:56 <springmeyer> and did you pass any custom options to configure or install? 20:42:08 <rweait> nothing. 20:43:18 <springmeyer> oh, okay, gotta pass custom options as discussed yesterday if we want both mapnik2 installed and other version 20:43:28 <springmeyer> but maybe you are not there yet? 20:43:37 <springmeyer> do you have 0.7.x installed? 20:43:40 <rweait> oops. 20:43:49 <rweait> yes 0.7.1 is in 20:44:29 <springmeyer> okay, again either way it looks like (your third install) the packaged mapnik 0.6.x is going to trip up the linker 20:44:34 <springmeyer> need to do: 20:44:34 <rweait> again with gusto. 20:44:47 <springmeyer> sudo apt-get remove libmapnik0.6 python-mapnik 20:44:50 <springmeyer> etc, etc 20:47:17 <rweait> sudo python scons/scons.py PYTHON_PREFIX=~/src/mapnik2 LIB_DIR_NAME=/mapnik2 ? 20:47:38 <rweait> or LIB_DIR_NAME=~/src/mapnik2 20:47:41 <springmeyer> rweait: want to jump on skype for a sec to chat? 20:48:06 <rweait> I may not have a working mic, but sure. 20:48:14 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik 20:48:58 <springmeyer> oh, phone works too (either 360.298.1580 or d.springmeyer) 20:49:25 <rweait> okay. calling 20:55:25 <springmeyer> rm /usr/local/lib/libmapnik* 20:55:42 <springmeyer> rm -rf /usr/local/lib/mapnik 20:56:14 <springmeyer> rm -rf /usr/lib/python2.6/dist-package/mapnik 20:56:57 <Ldp__> I have this as zapmapnik.sh: 20:56:58 <Ldp__> rm -rf /usr/local/lib64/mapnik 20:56:58 <Ldp__> rm -f /usr/local/lib64/libmapnik* 20:56:58 <Ldp__> rm -rf /usr/local/include/mapnik 20:56:58 <Ldp__> rm -rf /usr/lib64/python2.6/site-packages/mapnik 20:57:37 <Ldp__> ymmv :) 21:08:49 <rweait> Thanks springmeyer ! 21:08:55 <springmeyer> cheers! 21:09:31 <springmeyer> rweait confirmed that I need to get my sorry butt to SOTM to meet you all :) 21:18:58 *** mperry has quit (Ping timeout: 248 seconds) 21:19:27 <shoe> I'm seeing what look like faint cross-hatch (vertical and horizontal, not diagonal) stripes 21:20:03 <shoe> is that because I don't have a fully opaque map? 21:20:21 <springmeyer> shoe: best to post an example 21:20:39 <shoe> http://a14.tile.mine.nu/default/8/135/90.png 21:21:45 <shoe> I've tried putting fully opaque raster layers in, but I still see those cross hatches. 21:24:32 <jburgess> shoe: I would guess that is from the shoreline_300 shapefile 21:25:04 <jburgess> the land areas are formed with lots of overlapping squares, the overlap is very large and would probably look something like that 21:26:30 *** dkb has parted #mapnik (None) 21:26:35 <shoe> oh, yes. I'm making the "world" layer slightly transparent, so the overlapped areas are showing up. 21:26:42 <rweait> that's an argyle map. Very rare. 21:27:25 <shoe> LOL, actually, it's more Tartan. 21:27:40 <jburgess> I believe that a change was recently made in Mapnik which would let us get rid of this overlap but I have not tried it yet 21:28:10 <Ldp__> the gamma value, but I'm waiting on the 0.7.1 release before using the new features in osm.xml 21:29:22 <jburgess> shoe: this will also need new shapefiles to be generate so you can not just set the value right now 21:29:35 <Ldp__> but I don't know if that works well with semi-transparent polygons. You might still see faint lines 21:30:02 <jburgess> shoe: one way which some people get around this is to generate multiple non-transparent images and then composite together to add the transparency 21:30:38 <jburgess> this avoids similar issues which occur when two semi-transparent features overlap / cross 21:32:10 <shoe> hmm.. IIUC, that might be what I'm doing... I have a color-relief raster and a hill shading raster, both non-transparent, combined with "multiply" mode. 21:33:24 <jburgess> shoe: one fairly complex example is explained in a fair amount of detail at http://wiki.openstreetmap.org/wiki/TopOSM/Details 21:33:35 <shoe> I think my problem might be related to another issue... I think I need inverted shoreline shapefiles. 21:34:44 <shoe> jburgess: wow! that's a nice example! 21:34:53 <jburgess> If you are setting the rendering of the shoreline_300 polygon to have some transparency then you are not doing it the way I'm talking about 21:35:38 <jburgess> that requires you to render each individual layer without any transparency. Then you merge together and add transparency in the final step. 21:37:31 <shoe> my rasters have no transparency themselves... I just dumbly copied the tranparent shorelines from: http://wiki.openstreetmap.org/wiki/HikingBikingMaps/HillShading without really knowing what I was doing. 21:40:23 <jburgess> the problem in your example is with the shoreline_300 shapefile and its rendering style, not the rasters 21:40:35 <shoe> any tips on how to create an inverted coastline shapefile? 21:41:04 <shoe> jburgess: right. I'm pretty satisfied with the rasters for now. 21:41:46 <shoe> I've turned off the shoreline_300 now, and the stripes are gone. 21:41:47 <jburgess> I think the guy which did the HikingBikingMaps mentioned that he saw similar grid artifacts in his rendering 21:42:36 <jburgess> see the yellow horizontal strip just up from the bottom of the map @ http://wiki.openstreetmap.org/wiki/HikingBikingMaps 21:43:19 <jburgess> the stripe is narrower because this is at higher zoom which uses the processed_p shapefile which has a smaller overlap 21:43:57 <shoe> jburgess: oh, good eye. I read the mention of that in the text but didn't notice it in the image. 21:44:15 <shoe> yeah, it's got to be the same effect. 21:46:14 <springmeyer> Ldp__ said "but I don't know if that works well with semi-transparent polygons. You might still see faint lines" 21:46:24 <springmeyer> .. in regards to using non-overlapping polygons + gamma 21:46:33 <Ldp__> + transparency 21:46:41 <springmeyer> yes, gamma attribute ability to fix depends on transparency 21:46:46 <springmeyer> is complex ways 21:47:15 <springmeyer> so it may still work, but would require different gamma value than for non-transparent polygons 21:47:54 <springmeyer> I will try to add test for transparency stuff to: 21:47:55 <springmeyer> http://svn.mapnik.org/trunk/tests/data/good_maps/agg_poly_gamma_map.xml 21:48:00 <springmeyer> when I have a moment 21:48:00 *** shoe has quit (Read error: Connection reset by peer) 21:48:18 *** shoe (~user@ip24-250-63-6.ri.ri.cox.net) has joined #mapnik 21:57:38 *** tomhughes has quit (Ping timeout: 268 seconds) 21:57:59 *** tomhughes (~tom@gosford.compton.nu) has joined #mapnik 22:11:09 <StormTide> springmeyer, you're headed to djangoski right? 22:12:20 <shoe> jburgess: turning off world and coast-poly layers definitely made the stripes go away at some zoom levels, but I still see light "griding". Is there another layer with overlapping squares? 22:13:00 <Ldp__> just the inc/layer-shapefiles.inc.xml 22:13:14 <jburgess> the processed_p and shoreline_300 shapefiles are the only ones I know of 22:14:04 <jburgess> IIRC you can also get similar artifacts at the edges of your rasters, if they are built from multiple files (e.g. 1 x 1 degree SRTM or similar) 22:15:19 <shoe> this is much, much finer than 1 degree. 22:15:19 <jburgess> this can effect hillshading and contours which are generated from these too 22:15:35 <jburgess> I don't know how big your raster files are 22:15:47 <shoe> http://h.tile.mine.nu/image2.png 22:16:16 <shoe> I stitched about 25 of the 1 deg SRTMs together. 22:16:46 <springmeyer> StormTide: no, just drooled, but not going 22:16:46 <shoe> and I'm generating one color relief raster and one hill shading raster 22:17:16 <jburgess> II would look closely at the images which you get if you just have these rasters on individually 22:17:24 <StormTide> ah, wish i coulda gone too ;)... buddy of mine is there ;) 22:18:02 <jburgess> there are other possibilities which can happen with sampling / upscaling etc 22:18:25 <StormTide> springmeyer, doesn't look like the list has anything to say about my lgpl exception :( 22:18:27 <jburgess> for example if the interpolation uses nearest-neighnour then you can get regular bands every N pixels 22:19:59 <shoe> I used cubic spline to resample, and it looks the same as the un-resampled. and I tried enabling/disabling bilinear scaling. 22:22:11 <shoe> actually, cubic spline fills the nulls nicely, but the grids are the same. 22:23:01 <jburgess> did you try the method mentioned on the HikeBike map during the warping "This specifies the best interpolation method for warping (-rcs -order 3, this can take a while if the region is large) " 22:23:30 <shoe> I didn't at first, and then I did. 22:23:48 <shoe> (that's what I meant by cubic spline) 22:25:12 <jburgess> I'm just wondering because you might find the image itself looks OK to the naked eye but then when you run subsequent tools like the hillshading they might emphasize certain artifacts which are present in the image 22:25:46 <jburgess> this might occur if (say) two consequetive rows were always equal then gradient between them would always be zero 22:26:20 <jburgess> which might then show as a constant line in the hill shading 22:27:16 <shoe> I'm looking at the hillshading raster in gthumb and it looks beautiful, even zooming all the way in. 22:28:11 <jburgess> I'd suggest turning on/off each layer in your style, it should be fairly quick to identify which has the grid effect 22:28:12 <shoe> jburgess: oh... I'm using "TILED=yes" 22:30:11 <jburgess> I'm not sure I can be of any more help. I don't run any maps styles like these myself. 22:32:17 <shoe> adding status="0" to each layer. :) 22:37:40 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 22:48:51 <shoe> every layer except the single, unstyled hillshaing raster disabled. 22:50:00 <shoe> so maybe it's some artifact introduced by mapnik scaling the raster? 22:51:35 <jburgess> I guess you are using the RasterSymbolizer, try setting the scaling parameter http://trac.mapnik.org/wiki/RasterSymbolizer 22:53:17 <jburgess> It looks like 'fast' is the default mode 22:55:04 <jburgess> I can see how this might cause some squareness on the output but I still don't really see why this should cause such wide variations in the image 22:55:47 *** bitterman has quit (Quit: Leaving) 22:55:56 <shoe> I just tried all 3 scaling options, and I don't see any difference: 22:56:46 <jburgess> are you reading the geotiff directly or via gdal? It might be worth trying the other method 22:57:23 <Ldp__> jburgess: small fix in osm.xml committed 22:57:48 <Ldp__> don't know if you had deployed already 22:58:05 <jburgess> shoe: do you think the edges might align with the 'TILED' boundaries? I would guess this could be part of the problem 22:58:14 <shoe> jburgess: gdal. what's the parameter for geotif? 22:58:56 <jburgess> http://trac.mapnik.org/wiki/Raster 22:59:02 *** luneff (~yury@93.178.93.173) has joined #mapnik 22:59:52 <shoe> jburgess: ah.. let me try that. 22:59:59 *** Ldp__ has quit () 23:01:33 * springmeyer scrolls 23:01:39 <springmeyer> shoe: can you post an example of what you are talking about now? 23:03:24 <jburgess> springmeyer: an old example was http://h.tile.mine.nu/image2.png 23:04:31 <springmeyer> ah, okay 23:04:50 <springmeyer> so shoe that blockyness is not in the original image? 23:04:55 <springmeyer> does the tile have overviews? 23:05:03 <springmeyer> or tiff I mean.. 23:07:01 <shoe> um... raster driver behaves same as gdal. 23:07:22 <shoe> I don't think it has overviews... at least I didn't mean to make it have any. 23:07:51 <shoe> the gridlines are not visible in the original raster 23:08:25 <springmeyer> shoe: can you post the original raster? 23:08:50 <shoe> one sec.. let me double check before I seriously embarrass myself. :) 23:09:05 <springmeyer> or, ideally just a small chunk of it that demostrates the problem 23:10:35 <shoe> no griding in original raster visible in gthumb or gimp. 23:12:29 <shoe> http://h.tile.mine.nu/hill.tif (86MB) :( 23:12:59 <shoe> I'm going to try without TILED=yes 23:19:49 <shoe> no difference. 23:26:12 <springmeyer> shoe: I certainly see the problem in the original tiff 23:26:50 <springmeyer> this looks like you need to use bilinear or lanzcos resampling when warping with gdal 23:29:51 <shoe> oh dear, you're right. I see it now in the original tif 23:30:36 <shoe> I don't know why I didn't see it before... it's somehow different from what I was looking for. 23:32:32 <shoe> springmeyer: thank you for setting me straight. 23:33:20 <springmeyer> gthumb seems to automaticlly apply bilinear filter (EDIT > preferences > zoom quality "high vs low") 23:33:36 <springmeyer> which only slightly blurs the artififacts 23:33:50 <springmeyer> but there are visible for me on both linux and os x 23:35:55 <shoe> it's too bad the " -rcs -order 3 -tr 30 30" didn't help - it created a HUGE file. 23:36:13 <shoe> I'll have to look into resampling techniques after dinner... 23:40:12 *** IvanSanchez (~ivan@138.3.222.87.dynamic.jazztel.es) has joined #mapnik 23:45:48 *** ajturner has quit (Quit: ajturner)