00:12:01 <scruggs> does anyone know of a mapnik revision that will work with cairomm 1.2.4? ./configure is dying on not finding cairomm >= 1.4.4... I'm running ubuntu 7.10 and really don't want to do an alternate install of a newer cairomm if I don't have to
00:13:23 <cmarqu> migurski: In roads.mss, you have a typo: "motoryway"
00:18:04 <migurski> that is a type, thanks
00:18:09 <migurski> *typo =)
00:18:41 <migurski> the prominence tag comes from postGIS - I do a bunch of extra stuff in the query to get sorting and rendering to work better
00:18:41 <nikq> http://trac.mapnik.org/wiki/postGIS
00:19:47 <cmarqu> Ah. We were thinking of something like that for peaks. We have lot of little peaks in that area I linked to, and height is not a differentiator.
00:20:58 <cmarqu> What determines the background color? It's not map-bgcolor in styles.mml apparently.
01:43:56 <scruggs> anyone built mapnik/demo/c++/* lately???
01:45:07 <scruggs> I've run into a number of issues so far... had to manually copy boolean_filter.hpp to /usr/local/include/mapnik/ to get past one failure
01:45:53 <scruggs> also had to copy libagg.* to /usr/local/lib/ ...
01:46:16 <scruggs> still failing on: /usr/local/lib/libmapnik.so: undefined reference to `mapnik::color::to_hex_string() const'
01:47:50 <scruggs> I'm running the compile command from the readme file. The included Makefile gives me freetype2 errors
03:00:58 *** migurski has quit ()
03:06:19 <scruggs> anyone have any ideas on my compile issues?
04:02:04 *** hayduke (i=48a17dbc@gateway/web/ajax/mibbit.com/x-0017ba03c7d89121) has joined #mapnik
04:26:20 *** hayduke has quit ("http://www.mibbit.com ajax IRC Client")
04:29:16 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
04:58:52 *** migurski has quit ()
08:28:46 *** Mrfos has quit (Read error: 110 (Connection timed out))
16:35:39 <cmarqu> Does Mapnik have something like text halo opacity?
16:51:23 <jburgess> I imagine you can set the color to something which has an alpha value set.
16:52:45 <cmarqu> Ah, that would be cool.
16:53:46 *** __d3f0__ (n=defo@190.176.249.133) has joined #mapnik
16:54:52 <cmarqu> cascadenik.style.ParseException: Unrecognized color value for property "text-halo-fill"
16:55:09 <cmarqu> Though that might actually be a Cascadenik bug?
16:57:36 <jburgess> what colour value are you trying? Try "transparent"
16:58:12 <cmarqu> I was trying #11111180 - dark grey with 50% transparency?
16:58:13 <nikq> Ticket #11111180: no such ticket. (list index out of range)
16:58:41 <jburgess> try with the named color, in case it doesn't recognise the #RGBA
16:59:21 <jburgess> a completely transparent halo is pointless but may narrow down where the bug is
17:00:14 <cmarqu> cascadenik.style.ParseException: Hash value only for property "text-halo-fill"
17:01:32 <cmarqu> I'll try #RGBA in the file generated from Cascadenik
17:03:06 <cmarqu> UserWarning: Failed to parse attribute 'halo_fill'. Expected type color but got '#11111180' in TextSymbolizer in style 'text style 34 (height)'
17:03:06 <nikq> http://trac.mapnik.org/wiki/TextSymbolizer
17:04:04 <cmarqu> Ah well. It's not the most important features.
17:04:35 <jburgess> I have a feeling the XML syntax does not understand the #RGBA, but will take named colors like "transparent"
17:04:47 <cmarqu> True, just tried that.
17:04:55 <jburgess> Unfortunately I think transparet is the only one with an alpha value
17:05:00 <cmarqu> halo_fill="transparent" works.
17:07:04 <cmarqu> FWIW, halo_fill="rgba(255, 0, 0, 0.2)" also doesn't work.
17:08:17 *** D3f0 has quit (Read error: 110 (Connection timed out))
17:09:11 * cmarqu wants a 300 dpi monitor
17:13:01 <jburgess> cmarqu: I'm looking at the underlying code. I think it can be easily extended to take #RGBA, but none of the current forms accepts alpha (except named colors)
17:14:39 <cmarqu> #RGBA would be a fix for the height lines value in the wood here: http://cmarqu.dyndns.org/~colin/osm/?zoom=15&lat=50.96362&lon=14.09772&layers=B
17:17:08 <jburgess> cmarqu: You could try this patch. It is completely untested, but does compile http://tile.openstreetmap.org/direct/mapnik-css-rgba.patch
17:18:23 <cmarqu> jburgess: Thanks very much. I'll have to compile mapnik first, I'm using a package right now.
17:29:32 <jburgess> looking at the w3c specs, the standard way to do this is with rgba(r,g,b,a). They don't define a hex variant.
17:40:04 <cmarqu> Ok, Mapnik built, testing if it works unpatched first.
17:55:29 <cmarqu> I suppose I do not use my own mapnik, since it doesn't work (no change in the error message),
17:55:48 <cmarqu> (The patch doesn't seem to have an effect I mean)
17:56:42 <cmarqu> I'm using generate_tiles.py, how would I force it to pick my own version?
17:58:10 <jburgess> the easiest way is normally to uninstall the packaged version. Otherwise you can never be completely certain which is being used
17:58:20 <cmarqu> Ok, did that now.
17:58:29 <cmarqu> ImportError: No module named mapnik
17:58:44 <jburgess> you installed your new version?
17:58:48 <cmarqu> I suppose the python path doesn't include /usr/local
17:58:50 <cmarqu> Yes.
17:59:40 <jburgess> for me the python stuff does not end up in /usr/local, it goes to /usr/lib64/python2.5/site-packages/mapnik/_mapnik.so
18:00:27 <jburgess> do you have the /usr/local lib directory in /etc/ld.so.conf (or file in /etc/ld.so.conf.d ?
18:00:42 <jburgess> also try running: ldconfig
18:02:12 <cmarqu> Uhm, wait, I don't see anything about python in the make install step.
18:06:36 <cmarqu> I do have /usr/local/lib in /etc/ld.so.conf.d/libc.conf
18:06:51 <cmarqu> But /usr/local/lib/python2.5/site-packages/ is empty.
18:07:54 <cmarqu> Oh, maybe I should follow the instructions and run python scons/scons.py
18:08:58 <jburgess> I use scons, when I started with Mapnik there was no Makefile.
18:09:24 <cmarqu> I used autogen.sh and make until now.
18:09:43 <cmarqu> Build runs now.
18:10:18 <jburgess> the important point is to watch the first 10-20 lines of output. Make sure that it finds things like "pq" if you want to use Postgresql
18:10:40 <cmarqu> Checking for C library pq... yes
18:10:50 <cmarqu> Checking for C++ library gdal... no
18:11:14 <jburgess> is gdal important to you?
18:11:29 <cmarqu> I don't know, does it use it for reprojection?
18:11:44 <jburgess> no, you only use it if you have a gdal datasource
18:12:03 <cmarqu> Ah, then I don't need it.
18:24:33 <cmarqu> jburgess: Yay, it all works! http://cmarqu.dyndns.org/~colin/osm/tiles/13/4416/2743.png
18:26:04 <jburgess> the black halo around the counter numbers?
18:26:11 <jburgess> contour
18:26:23 <cmarqu> Right.
18:26:59 <jburgess> I've made another version of the patch which supports the CSS colours as defined in http://www.w3.org/TR/css3-color/
18:27:27 <jburgess> these specify them as rgba(r,g,b,a) and not #rrggbbaa.
18:28:12 <jburgess> http://tile.openstreetmap.org/direct/mapnik-css-rgba2.patch
18:28:37 <cmarqu> That would also be easier to use for Cascadenik, via text-halo-fill-opacity (following the naming style of the other names)
18:31:46 <cmarqu> Or maybe not, since it would need to convert form hex to dec.
18:36:02 <cmarqu> Still compiling...
18:37:22 <cmarqu> jburgess: Hmm... UserWarning: Failed to parse attribute 'halo_fill'. Expected type color but got 'rgba(10, 10, 10, 0.2)' in TextSymbolizer in style 'text style 34 (height)'
18:37:22 <nikq> http://trac.mapnik.org/wiki/TextSymbolizer
18:37:59 <jburgess> strange it works for me. I'll try your exact example
18:39:29 <jburgess> It works if you remove the spaces
18:39:41 <jburgess> the code should be more forgiving though
18:40:10 <cmarqu> Confirmed.
18:41:31 <cmarqu> If you now remove #RGBA though, Cascadenik will fail. :)
18:43:07 <jburgess> It only worked withthat first patch I sent.
18:43:19 <cmarqu> Right.
18:43:40 <jburgess> I guess that Artem might consider adding #RGBA since it is an obvious format, even if it isn't in the w3c css standard
18:43:52 * cmarqu would welcome that
18:44:09 <jburgess> it would help if it accepted white space in there too :)
18:47:11 <cmarqu> There is now only one styling problem left that I guess cannot be fixed: I would like to have a river with casing, but if I create the style like that, it also shows that line where the riverbanks are split along the length of the river.
18:47:47 <jburgess> I don't think there is an easy answer for that.
18:48:34 <jburgess> The proper fix is probably to perform some pre-processing which joins the polygons together into a single large river polygon (but would still be wrong where it meats the sea)
18:50:40 <cmarqu> If we could determine that the casing touches another casing with the same style, it could suppress drawing that line.
18:50:59 <cmarqu> But easier said than done I suppose.
19:11:16 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
19:13:19 <artem> jburgess: thanks for patches ! I'll be on IRC from 20:00 (gmt) to apply them
19:13:40 <jburgess> artem: ok, cool. I should be around
19:13:48 <artem> great
19:15:36 <jbronn> artem: I would also defer to mloskot on that patch -- his C++ skills far supercede my own
19:16:50 <jbronn> (I'm referring to #63, discussed a few days ago)
19:16:51 <nikq> Ticket #63: Support for OSX Leopard and Solaris (using Sun Studio compiler), http://trac.mapnik.org/ticket/63
19:17:53 <artem> jbronn: yes, I patched headers already
19:18:47 <artem> jbronn: unfortunately I don't have access to sun compiler to test.
19:20:14 * artem will be back around 8pm
19:21:14 <jbronn> cheers
19:59:12 *** artem has quit ()
20:05:50 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
20:18:47 <nikq> Mapnik Trac: Changeset [807]: + mapnik-serialize-fontset.patch from jonb This adds the fontset support  ... | http://trac.mapnik.org/changeset/807
20:21:25 <artem> jburgess:  not sure what to do about mapnik-libxmlpp.patch I'll need to think about. There must be a way to avoid glibmm dependency
20:22:06 <jburgess> I don't think so, it is one of the core types used by the parser for holding all strings
20:23:57 <artem> hmm... I'll leave it for now and have proper look then.
20:24:16 <jburgess> libxml++ is part of Gnome so they don't see it as a problem: http://libxmlplusplus.sourceforge.net/docs/manual/html/index.html
20:24:32 <jburgess> "Because Standard C++ has no string class that can fully handle UTF-8, libxml++ uses the Glib::ustring class from the glibmm library"
20:26:08 <jburgess> oh well, it looked like it could be a cleaner interface into libxml2. If you liked it then I hoped it could replace the existing one, but I understand that we don't want to keep adding more dependencies
20:27:15 <artem> jburgess: I was reading "libxml++ - An XML Parser for C++"
20:28:03 <jburgess> well, sort of. Really it is just a c++ wrapper around libxml2
20:28:49 <artem> yep, but glibmm dependency is a bit drastic
20:29:21 <artem> jburgess: let me look at all options regarding this issue.
20:29:54 <jburgess> No problem.
20:30:02 <artem> there were some talks about implementing boost-fied interface for libxml too
20:30:26 <jburgess> that would probably be very useful
20:31:49 <jburgess> the existing libxml2_loader works but isn't particularly pretty. I wanted to look around to see if anyone else had written proper C++ bindings for libxml
20:32:51 <cmarqu> Hmm. I now need a gdal source, but mapnik doesn't want to find my gdal: Checking for C++ library gdal... no
20:33:02 <cmarqu> This is on Ubuntu Intrepid.
20:33:19 <artem> jburgess: I think your prev patch that adds support for reading from mem string is good for 0.6
20:33:25 <cmarqu> I have all packages from http://trac.mapnik.org/wiki/UbuntuInstallation
20:33:42 * artem is looking at mapnik-image-from-cairo-in-python.patch 
20:35:02 <nikq> Mapnik Trac: Changeset [808]: + mapnik-image-from-cairo-in-python.patch from jonb   adds a method to the  ... | http://trac.mapnik.org/changeset/808
20:36:21 <jburgess> cmarqu: have you tried adding this to the scons line: GDAL_INCLUDES=/usr/include/gdal
20:36:27 <CIA-59> mapnik: artem * r807 /trunk/ (4 files in 2 dirs):
20:36:27 <CIA-59> mapnik: + mapnik-serialize-fontset.patch from jonb
20:36:27 <CIA-59> mapnik: This adds the fontset support into save_xml
20:36:27 <CIA-59> mapnik:  - Adds fontset_name into the text attributes
20:36:27 <CIA-59> mapnik:  - Adds the fontset definitions
20:36:28 <CIA-59> mapnik:  - glue to read fontsets from map
20:36:32 <CIA-59> mapnik: artem * r808 /trunk/bindings/python/mapnik_image.cpp:
20:36:34 <CIA-59> mapnik: + mapnik-image-from-cairo-in-python.patch from jonb
20:36:36 <CIA-59> mapnik:  adds a method to the python bindings to create an Image from a
20:36:38 <CIA-59> mapnik:  Cairo.ImageSurface().
20:37:41 <cmarqu> jburgess: I hadn't, but the wiki page says GDAL_INCLUDES=/usr/include
20:38:48 <jburgess> cmarqu: is there a /usr/include/gdal.h or /usr/include/gdal/gdal.h ?
20:38:53 <cmarqu> Where does scons store its cache?
20:39:11 <cmarqu> jburgess: The latter.
20:39:22 <artem> cmarqu : rm -rf .scons*
20:40:04 <cmarqu> artem: Thanks, good to know.
20:40:13 <cmarqu> jburgess: Didn't help either though.
20:40:45 <jburgess> cmarqu: the way to debug is to look into the config.log file
20:41:10 <cmarqu> GDAL_LIBS=/usr/include - can that be correct?
20:42:03 <jburgess> cmarqu: you want to see something like http://rafb.net/p/Z4FCiP69.html in config.log
20:42:14 <jburgess> I suspect you will see some errors
20:42:14 <artem> cmarqu: (correction!) rm -rf  .scon*   (to catch sconf_temp/    and  .sconsign.dblite)
20:43:16 <cmarqu> jburgess: Yes, there are errors. Which now reminds me... to compile PerryGeo's demtools, I had to say GDAL_LIB=-I /usr/include/gdal/ -L/usr/lib/ -lgdal1.5.0
20:44:09 <cmarqu> So -lgdal vs. -lgdal1.5.0
20:45:58 <nikq> Mapnik Trac: Changeset [809]: + mapnik-fix-threaded-python-exceptions.patch from jonb | http://trac.mapnik.org/changeset/809
20:46:29 <cmarqu> Patched SConstruct, now it works apparently: Checking for C++ library gdal1.5.0... yes
20:52:26 <nikq> Mapnik Trac: Changeset [810]: + mapnik-check-fonts-during-load-map.patch from jonb   This patch adds  ... | http://trac.mapnik.org/changeset/810
20:57:01 <artem> jburgess: I love mapnik-css-rgba2.patch . Why don't we provide support for #RRGGBBAA format, too ?
20:57:23 * artem searching for CSS color docs
20:57:28 <jburgess> I have a patch for it, but it wasn't listed in the W3C CSS doc
20:57:52 <jburgess> http://www.w3.org/TR/css3-color/
20:58:33 <jburgess> section 4.2.2: "Unlike RGB values, there is no hexadecimal notation for an RGBA value. "
20:59:32 <jburgess> I'm sure you could add it anyway, an old patch was: http://tile.openstreetmap.org/direct/mapnik-css-rgba.patch
20:59:45 <jburgess> may conflict slightly with the second one
20:59:49 * cmarqu also loves that patch :)
21:00:03 <cmarqu> And yes, it conflicted.
21:00:51 <artem> jburgess: ok, lets stick to CSS spec for now
21:01:36 <jburgess> while cmarqu was trying this earlier he found that it would not parse if there were spaces, e.g. rgba(10, 10, 10, 0.5)
21:02:28 <jburgess> from a quick look at the spirit docs, it suggests that having space_p may fix this ... but you already have that and it isn't working
21:02:53 <artem> jburgess: ok, let me try ..
21:03:22 <jburgess> I don't feel like digging too deep in the spirit docs. Way too many templates and operator overloads for my liking :)
21:06:29 <artem> :) i really like spirit, it takes a few hours to screw your brain to start making sense
21:06:49 <artem> there is spirit2 also :D
21:08:17 <artem> jburgess: I don't see space_p anywhere in css_color_parser.hpp
21:08:46 <jburgess> color_factory.hpp: parse_info<> info = parse(css_color, grammar, space_p);
21:09:04 <jburgess> the last parameter is meant to be the skip option
21:10:01 <jburgess> the only thing I found which could be relevant was the #1 FAQ item which gave a case of getting the scanner&parsers mixed up if you use the wrong templates
21:10:01 <nikq> Ticket #1: no such ticket. (list index out of range)
21:10:10 <artem> jburgess: gotcha, thanks
21:13:01 <artem> right, looks like 'rgb' parser has got a bug - it sets alpha to 0 instead of 255
21:15:32 *** CIA-59 has quit (Remote closed the connection)
21:18:36 <jburgess> I've just been looking into what happens in things like the PolygonSymbolizer when you've got both a colour and opacity. Any transparency in the color is discarded in favour of the opacity setting. I'm not sure this is right
21:18:36 <nikq> http://trac.mapnik.org/wiki/PolygonSymbolizer
21:18:58 <cmarqu> GDAL_LIBS=/usr/lib/ogdi seems to have worked for me now.
21:20:10 <jburgess> It looks like we could could either store the opacity value in the color or maybe multiply the two together when we come to use them. I'm not sure what the spec says if you've got both specified
21:21:25 <artem> jburgess: multiplying makes sense.
21:22:42 <artem> jburgess: color parser at the moment is not setting alpha correctly for everything but 'named' and rgba
21:26:33 <jburgess> artem: are you certain they are incorrect? It looks like the constructor for color() uses an alpha of 255 and all the set_xx methods leave the alpha uchanged
21:27:57 <artem> jburgess: I'm confused :)
21:28:01 <artem> in Python :
21:28:09 <artem> c = Color('red')
21:28:12 <artem> c.a
21:28:14 <artem> >>> 255
21:28:33 <artem> c = Color('rgb(255,0,0)')
21:28:36 <artem> c.a
21:28:37 <artem> >>> 0
21:29:41 <artem> ok, there is a new ctor color(std::string const& )
21:30:12 *** CIA-57 (n=CIA@208.69.182.149) has joined #mapnik
21:31:21 <artem> yep, this is a new bug :)
21:34:41 <jburgess> c = Color('#FFFFFF')
21:34:48 <jburgess> >>> c.a
21:34:50 <jburgess> 41
21:34:55 <jburgess> most odd
21:35:00 <artem> it's caused by calling  init_from_string(*this, ...) in ctor  -> at this stage  'this'  is uninit
21:35:03 <jburgess> do you think this is something new with my changes?
21:35:27 <artem> jburgess: nope, this is my bug most certainly
21:39:40 <jburgess> just for a laugh, I ran the python interpreter through valgrind and entered the lines above. It spewed out a warning when accessing c.a
21:39:52 <CIA-57> mapnik: artem * r809 /trunk/bindings/python/mapnik_python.cpp: + mapnik-fix-threaded-python-exceptions.patch from jonb
21:39:53 <CIA-57> mapnik: artem * r810 /trunk/src/load_map.cpp: (log message trimmed)
21:39:53 <CIA-57> mapnik: + mapnik-check-fonts-during-load-map.patch from jonb
21:39:53 <CIA-57> mapnik:  This patch adds some extra exceptions for missing fontsets.
21:39:54 <CIA-57> mapnik:  Without this checking, you only notice the error at rendering time when
21:39:55 <CIA-57> mapnik:  it first needs to render a missing font.
21:39:58 <CIA-57> mapnik:  It also cleans up the font exception messages which were displaying the
21:39:59 *** __d3f0__ has quit (Read error: 104 (Connection reset by peer))
21:40:00 <CIA-57> mapnik:  font name twice.
21:41:02 <artem> jburgess: good old valgrind :)
21:44:04 <nikq> Mapnik Trac: Changeset [811]: + init alpha to 255 in actions | http://trac.mapnik.org/changeset/811
21:44:35 <artem> jburgess: ok, r811 seems to fix this problem.
21:44:36 <nikq> http://trac.mapnik.org/changeset/811, at , by artem: + init alpha to 255 in actions
21:49:37 <artem> cmarqu: Color('rgba(10, 10, 10, 0.5)').to_hex_string() works for me.
21:49:45 <artem> e.g spaces
21:51:00 <cmarqu> artem: The error was: UserWarning: Failed to parse attribute 'halo_fill'. Expected type color but  got 'rgba(10, 10, 10, 0.2)' in TextSymbolizer in style 'text style 34 (height)'
21:51:00 <nikq> http://trac.mapnik.org/wiki/TextSymbolizer
21:51:35 <cmarqu> This was with the patch  of course.
21:52:03 <artem> ok, thanks.
21:52:06 <jburgess> your example above works for me but I still get a failure in when doing this in XML
21:52:09 <jburgess> Expected type color but got 'rgba(242, 239,233,0.5)' in PolygonSymbolizer in style 'world-1'
21:52:09 <nikq> http://trac.mapnik.org/wiki/PolygonSymbolizer
21:52:20 <jburgess> without the space it is OK
21:52:35 <artem> hmm.. interesting
21:57:39 <artem> jburgess: yes, I get the same error when loading from xml
21:58:29 <jburgess> I think it must be coming from ptree_helpers.hpp, those are the only strings which match
22:02:06 <jburgess> I think: 'node.get_own<T>();' must be throwing the exception, is this some automatic string de-serialization?
22:02:58 <artem> jburgess: ptree_helpers.hpp looks suspicious . I'm looking through, this is not my code ..
22:05:28 * artem needs a cup of tea
22:10:15 <CIA-57> mapnik: artem * r811 /trunk/include/mapnik/css_color_parser.hpp: + init alpha to 255 in actions
22:10:21 <scruggs> are there any C++ examples that show loading styles and layers from xml?
22:13:12 <jburgess> scruggs: do you mean something which calls the c++ load_map() ?
22:13:38 <scruggs> I think so... I'm still getting familiar with the apis
22:17:12 <jburgess> scruggs: a very simple one is something like: http://rafb.net/p/2dcOlE79.html
22:17:56 <jburgess> but that does not get anything rendered, it just loads the XML
22:18:02 <scruggs> exactly what I was after
22:18:54 <scruggs> thanks much!
22:31:14 <scruggs> can I have multiple xml files and make multiple calls to load_map() ?
22:37:18 <jburgess> are you trying to load them into a single map render or multiple maps?
22:37:47 <scruggs> a single map
22:38:51 <jburgess> I think there is a way in which one xml can pull in several others. I don't think you can incrementally load the xml using load_map itself
22:39:11 <jburgess> alternatively, you can pull all the files into memory and then call load_map on this
22:40:26 <scruggs> ahh... that should work fine
22:41:55 <jburgess> which?
22:43:36 <jburgess> scruggs: this may help you http://trac.mapnik.org/wiki/ManagingLargeXmlFiles
22:45:24 <cmarqu> Are there image manipulation tools that can work with geotiffs? I want to change the gamma or the brightness. imagemagick and graphicsmagick don't produce usable files.
22:45:45 <cmarqu> As a better alternative, can mapnik do this?
22:46:22 <scruggs> jburgess: thanks - that helps too. My thought is to enable/disable styles with command line options, so loading files into memory might be the best approach
22:47:52 <jburgess> cmarqu: I'm not aware of any gamma function in mapnik. Maybe something which can be added. You might be able to do something like this be rendering an image with the geotiff layer, applying some effects like gamma, then rendering an overlay and combining the two images together.
22:49:09 <cmarqu> Sounds pretty complicated...
22:50:10 <jburgess> could be. It would certainly be simpler if mapnik supported it natively. Using something like the python bindings with cairo makes it fairly easy to apply effect and composite images together
22:50:29 <cmarqu> Just making the hillshaded geotiff brighter by overlaying another transparent whitish layer between it and my map features would be fine - can this be done from within mapnik?
22:51:05 <jburgess> I believe the cycle map is built from something like 6 different rendered images which all combined togther afterwards
22:51:32 <cmarqu> OSM doesn't have a polygon for every land area, so I'd need to synthesize one.
22:52:23 <cmarqu> jburgess: Yeah, I read that. But my map almost looks ideal for me without doing that, it's just "that little bit" :)
22:53:23 <jburgess> can you not just make the land colour whiter and make the geotiff layer slightly transparent?
22:54:24 <jburgess> I think the cyclemap is rendered by inverting the standard OSM style. They create polygons for the sea and overlay these on top to clip the layer with the contour lines
22:55:28 <jburgess> cmarqu: what are you using to render & serve the tiles?
22:55:30 <cmarqu> I'm not sure I understand. The geotiff layer is the lowest layer I thought, then I render "ground" above it. I make ground half transparent. But if there is no wood for instance, it's fully transparent, so the dark geotiff image shows through.
22:55:45 <cmarqu> jburgess: Cascadenik and OpenLayers.
22:56:03 <cmarqu> I'm mostly following http://wiki.openstreetmap.org/wiki/HikingBikingMaps
22:56:35 <cmarqu> http://cmarqu.dyndns.org/~colin/osm/?zoom=15&lat=50.96293&lon=14.10499&layers=B is my map (DSL line)
22:57:03 <cmarqu> I like the look of the wood area, but not the other, grey one.
23:00:13 <jburgess> you would like to make the dark bits of the hill shading a little lighter? I imagine that should be something you can change in the hillshade tool
23:00:51 <cmarqu> Exactly. But the hillshade tool doesn't have such an option (at least not the one from demtools)
23:01:42 <cmarqu> Maybe I should ask the guys in ... #gdal about such a tool?
23:02:37 <jburgess> maybe, or else I'd be tempted to tweak some numbers in the hillshade tool
23:03:26 <cmarqu> Right, I could try that.
23:03:57 <jburgess> cang = 1.0 + (254.0 * cang);
23:04:23 <jburgess> looks like you could make that 128 + (127*cang)
23:04:38 <cmarqu> Oh. Without realizing it, I am now talking about something that Mike mentioned yesterday: http://trac.mapnik.org/ticket/157
23:04:56 <cmarqu> And he said it sounded like it might go in 0.6
23:06:15 <jburgess> yes, those might do it. I think adding a gamma to the image should be even easier than those changes
23:06:44 *** CIA-57 has quit (kubrick.freenode.net irc.freenode.net)
23:07:02 *** CIA-57 (n=CIA@208.69.182.149) has joined #mapnik
23:07:03 *** CIA-57 has quit (kubrick.freenode.net irc.freenode.net)
23:07:04 *** CIA-57 (n=CIA@208.69.182.149) has joined #mapnik
23:07:04 <jburgess> maybe he is the right guy to ask
23:15:06 <cmarqu> Running the geotiff through some gaussian filter would also be nice...
23:15:06 <nikq> http://trac.mapnik.org/wiki/filter
23:15:37 <cmarqu> nikq: filter is at http://trac.mapnik.org/wiki/Filter
23:15:37 <nikq> http://trac.mapnik.org/wiki/filter
23:16:04 <cmarqu> nikq: no, filter is at http://trac.mapnik.org/wiki/Filter
23:16:04 <nikq> http://trac.mapnik.org/wiki/filter
23:18:31 <jburgess> :) nikq is a bot, if you didn't know
23:19:22 <cmarqu> I know, but starting with "no, ... is at ..." was the command language for some older bots.
23:20:01 <cmarqu> But to be honest, he had me stumped the first 2-3 replies :)
23:45:22 <nikq> Mapnik Trac: Changeset [812]: + added specializations for mapnik::color to avoid to/from stream  ... | http://trac.mapnik.org/changeset/812
23:47:06 <artem> jburgess: i committed fix for the css color parser space issue. cmarqu: could you try latest trunk ?
23:48:25 <cmarqu> artem: Building right now
23:48:52 <artem> jburgess: operator>> for color type wasn't working correctly.
23:50:06 <artem> but we don't need to use lexical_cast<color> when we have color_factory::from_string
23:50:28 <artem> cmarqu : thanks! lets see:)
23:53:09 <nikq> Mapnik Trac: Changeset [813]: + mapnik-load-map-checks.patch (jonb)    This patch adds more reporting of  ... | http://trac.mapnik.org/changeset/813
23:53:35 <cmarqu> artem: Works fine, thanks very much!
23:53:48 <artem> cmarqu : no probs, thank you:)
23:55:00 <cmarqu> Now I need Mike to adapt Cascadenik (it cannot parse rgba() yet)
23:56:28 <artem> sure
23:57:37 <artem> cmarqu: I did some tests with compositing which might be useful for you : http://trac.mapnik.org/wiki/Compositing
23:57:37 <nikq> http://trac.mapnik.org/wiki/compositing
23:58:39 <artem> also, I'm yet to publish SRTM -> shaded relief code I written almost a year ago now, but just never had a time
23:58:51 <cmarqu> nikq needs to be case sensitive...
23:59:04 <cmarqu> artem: Oh, that's all very interesting, yes