00:59:07 *** ninja_ (n=pankur@nat/yahoo/x-0246e48aa161b4a3) has joined #mapnik
00:59:42 *** antstam (n=antstam@nat/yahoo/x-f42b7674fd273e0a) has joined #mapnik
00:59:47 *** antstam is now known as stamf
01:02:32 <ninja_> hey springmeyer!
01:02:55 <springmeyer> hey ninja_ !
01:03:34 <ninja_> resuming our conversation from last week .. tickets for 0.6.0 release , Ill try and get the layer="off" ticket done
01:03:47 <springmeyer> ah, cool cool
01:04:10 <stamf> greetings all
01:04:11 <ninja_> also svn access started magically working a couple of hours after we spoke
01:04:28 <springmeyer> that might be super easy, but I've yet to look at where that conditional would happen...
01:04:38 <springmeyer> ah, good, that sure was weird...
01:04:49 <springmeyer> welcome stamf!
01:05:08 <stamf> thank you
01:05:15 <ninja_> yeah but its one of those things that needs to be done, I have suffered the effects of the bug :)
01:05:30 <springmeyer> :)
01:05:35 <ninja_> hey stamf:
01:11:03 <springmeyer> milestone 1.6.0
01:11:04 <nikq> No Milestone for that release number
01:11:10 <springmeyer> ack
01:11:22 <springmeyer> milestone 0.6.0
01:11:22 <nikq> 34 open tickets in Milestone 0.6.0: Names on areas don't seem to be correctly centered in the vertical axis, Stroke border, Support for OSX Leopard and Solaris (using Sun Studio compiler), Ability to set label value manually in TextSymbolizer (rather than have them read from datasource field), Support MAPNIK_VERSION, Main library gets linked against unnecessary libraries, Crashing with TextSymboli...
01:11:24 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.6.0&order=priority
01:11:25 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.6.0
01:11:46 <springmeyer> ah #153
01:11:47 <nikq> Ticket #153: "Avoid processing layer datasource if status=""off""", http://trac.mapnik.org/ticket/153
01:23:12 <nikq> Mapnik Trac: Ticket #153 (Avoid processing layer datasource if status="off") updated | http://trac.mapnik.org/ticket/153#comment:3
01:30:01 <ninja_> hmm saw that springmeyer: also migurski;s comment ideally should be another ticket right ?
01:30:20 <ninja_> to give something more meaningful instead of RuntimeError
01:36:17 <springmeyer> ninja_: ya probably
01:36:33 <springmeyer> right around here: http://trac.mapnik.org/browser/trunk/src/load_map.cpp#L410
01:37:07 <springmeyer> you could skip I guess add more explicit error handling
01:37:39 <ninja_> yeah .. it should be a little more verbose as to why it failed
01:37:40 <springmeyer> or I guess you could catch the error and if the status=off just don't throw an exception
01:37:52 <springmeyer> yeah
01:38:55 <nikq> Mapnik Trac: Ticket #153 (Avoid processing layer datasource if status="off") updated | http://trac.mapnik.org/ticket/153#comment:4
01:39:00 <springmeyer> tho, I've wondered whether more explicit exception handling for datasources should be be per/datasource?
01:39:08 <springmeyer> hence, #174
01:39:09 <nikq> Ticket #174: Better exception handling for shape.input, http://trac.mapnik.org/ticket/174
01:39:49 <ninja_> yeah should ideally be per datasource
01:40:26 <springmeyer> ya, so nothing fancy in the xml I guess...
01:41:15 * springmeyer will honestly be a little sad to see 'got exception' go 174 is address
01:41:27 <ninja_> hmm .. nothing fancy in the xml ?
01:41:28 * springmeyer might have to patch mapnik locally to say 'got milk' ;)
01:41:39 <ninja_> hehe
01:42:25 <springmeyer> ah, ya, just figure nothing fancy needed error reporting wise in the xml as the 'human readable' errors should get throw in the datasource specific code
01:43:18 <ninja_> yeah just something to indicate its a missing file
01:46:30 <jburgess> I had a quick look at that bug before. to me, it was not obvious that not processing the layer would be the right thing to do. You might, for example, load the xml from a file then use python methonds to enable/disable layers then save hte XML again
01:46:54 <jburgess> If you didn't load any layer set to off, then it would not be in the saved output.
01:47:48 <jburgess> and you can't load the layer and datasource definitions without some sources like the shape reader going off to see if the file is present.
01:47:54 <springmeyer> jburgess, yes I was just pondering that as well. very good point
01:48:59 <jburgess> having a decent human-readable error message for a missing shapefile is a great idea though :-)
01:49:45 <springmeyer> yes yes! lol
01:50:08 <ninja_> jburgess, you are saying that read all layers whether set to off or not ?
01:50:20 <springmeyer> the main thing I was thinking about when I filed #153, was trying to get mapnik's behavior a bit more like mapservers in this regard
01:50:20 <nikq> Ticket #153: "Avoid processing layer datasource if status=""off""", http://trac.mapnik.org/ticket/153
01:50:26 <jburgess> yes, I don't think we have any choice
01:50:44 <ninja_> hmm that attribute then is misleading
01:51:55 <springmeyer> when a mapserver layer's STATUS is OFF is seems that enough is skipped in the processing (I've yet to look in detail) that its a major speed boost above mapnik when you are using an xml file with multiple layers that are akin to multiple maps
01:52:15 <jburgess> a speed boost at startup or when rendering?
01:52:29 <springmeyer> I was starting to work on the comparison of speed between the bench.xm and bench.map here: http://mapnik-utils.googlecode.com/svn/sandbox/benchmarks/mapfiles/
01:52:33 <springmeyer> only startup, right
01:52:52 <springmeyer> ( I would imagine)
01:53:00 <jburgess> I think the code is already skips any querying the datasource during rendering if the layer is off
01:53:27 <springmeyer> but the underlying issue here is that mapservers mapfile format is used differently in this regard I think
01:53:48 <jburgess> the question is whether it would be better to delay the initialisation of the shapefile reader etc until it is first called (which might be never for some map renders)
01:54:09 <jburgess> or if you should always initialize it so that you get an error straight away.
01:54:40 <springmeyer> hmmm...
01:54:42 <jburgess> The second behaviour means that a map might render fine at one zoom level, but then fail at another when it first tries to use a missing shapefile
01:55:44 <springmeyer> yes. interesting
01:55:51 <jburgess> I dislike these sorts of latent bugs and would rather have the whole map sanity checked at load time
01:56:23 <jburgess> We do have a "strict" flag on load_map() so we could make the behaviour switch on that
01:56:35 <jburgess> This is already done for some of the font validation
01:58:09 <jburgess> Would like to discuss further, but It is late and I need to go.
01:58:21 <springmeyer> ah, I have been wondering what that strict flag would do.
01:58:25 <springmeyer> thanks!
01:58:29 <springmeyer> talk to you later
01:58:48 <jburgess> bye
02:57:39 *** D3f0 (n=defo@190.176.240.31) has joined #mapnik
03:09:03 <nikq> Mapnik Trac: Ticket #153 (Avoid processing layer datasource if status="off") updated | http://trac.mapnik.org/ticket/153#comment:5
03:52:14 *** ale1 (n=aled@81-179-6-240.dsl.pipex.com) has joined #mapnik
04:09:45 *** aled has quit (Read error: 101 (Network is unreachable))
05:08:33 *** D3f0 has quit (Remote closed the connection)
06:08:58 <springmeyer> cool, nik2img and cascadenik work perfectly with mapnik svn trunk built against python26 on leopard
06:09:05 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
06:11:46 <springmeyer> hey migurski: just ran the cascadenik tests against mapnik svn trunk with python 26 - works great btw
06:11:58 <migurski> oh sweet
06:12:03 <migurski> phew =)
06:12:09 <springmeyer> :)
06:12:17 <migurski> I just sent a followup to the list re: my build problems
06:12:24 <migurski> everything's working beautifully
06:12:31 <springmeyer> nice
06:12:50 <migurski> now I can get access to other bleeding edge mapnik features =)
06:13:08 <springmeyer> and oh my they are cool
06:14:58 <migurski> it's great that you guys have some apparent momentum for 0.6 - I feel like tickets are actually getting dealt with, which is awesome
06:15:12 <migurski> because I keep thinking of new ponies I want =D
06:15:51 *** Mrfo (i=Mrfo@pool-96-231-166-17.washdc.fios.verizon.net) has joined #mapnik
06:19:55 <springmeyer> yes, yes :)
06:21:16 <migurski> re cascadenik, I recently made a change that helps it deal with python 2.4 as well
06:21:31 <migurski> elementtree was only included in the standard lib as of 2.5
06:21:56 <springmeyer> migurski: regarding boost source install there is also a Scons variable to specify the BOOST_TOOLKIT
06:22:08 <migurski> ah how does that work?
06:22:09 <springmeyer> which is usually the compiler name
06:23:06 <springmeyer> with BOOST_TOOLKIT=xgcc40 that avoids needing to manually create any symlinks when boost is built from source on osx
06:23:23 <migurski> oh that's useful
06:23:33 <migurski> good to know
06:23:39 <migurski> compilers are still something like a mystery to me
06:23:49 <springmeyer> ya, recently added. I plan to document once I get some other scons stuff in order
06:24:06 <springmeyer> I feel the same.
06:24:35 <springmeyer> I was reading up a bit on them, and amazed how different the options are between compilers, just for c++
06:25:17 <springmeyer> one standout thing I want to understand more is when to use -O2 vs. -O3 for speed optimization
06:25:37 <migurski> what do those mean?
06:25:41 <springmeyer> (just the first thing I realized matters, but I nothing about)
06:25:41 <Mrfo> isn't O2 vs O3 stuff like loop unrolling
06:26:14 <springmeyer> Mrfo: tell us! :)
06:26:37 <springmeyer> I just know that you use -O0 when in debug mode and the code runs much slower
06:27:05 <Mrfo> ummm, to my knowlege its just various levels of optimization that the compiler does. unless you're doing the optimizations yourself, you want to use the highest level
06:27:50 <springmeyer> I started reading about compiler options because of an interesting thread in #gdal where crshmidt was seeing highly different speeds between patched shapefile stuff
06:27:51 <migurski> loop unrolling, like it looks for loops that only run a few times and turns them into a series of instructions instead?
06:28:12 <Mrfo> things can get messy if it tries to optimize some already optimized code. so theres different levels
06:28:19 <springmeyer> and then he realized that it was actually a difference between his source build of gdal and a binary build on mac osx
06:28:19 <Mrfo> migurski, yeah
06:28:51 <springmeyer> my thought was maybe there are mac specific optimization flags... etc etc
06:28:57 <springmeyer> Mrfo: interesting
06:29:32 <springmeyer> Mrfo: so mapnik uses -O2, but seems to build fine with -O3, but I've yet to test the code speeds or functions when build with -O3
06:30:22 <Mrfo> they both should run roughly the same
06:30:29 <springmeyer> okay.
06:30:39 <springmeyer> I was looking at the bottom of http://svn.mapnik.org/trunk/SConstruct
06:31:31 <Mrfo> O3 is going to be the best optimization, and it will include hardware specific stuff
06:31:51 <Mrfo> its been awhile though, this is largely based on optimization class i took a few years back heh
06:32:08 <springmeyer> local guru I'd say :)
06:33:51 <Mrfo> if i remember correctly O2 an O3 are a space vs time tradeoff optimization
06:34:19 <Mrfo> that said, i can't remember which optimizes for which
06:35:46 <Mrfo> migurski, you have an mapnik xml snipet on your blog that has varibles for each zoom level
06:36:04 <migurski> remind me which one?
06:36:04 <Mrfo> do you use any other varibles when you work with mapnik xml
06:36:56 <Mrfo> http://mike.teczno.com/img/mapnik/zoom-levels.txt
06:37:13 <Mrfo> i guess entities would be the correct word im looking for
06:37:39 <migurski> ah yeah
06:38:08 <migurski> Dane suggested entities for pgsql params like username and password
06:38:23 <Mrfo> hmmm, thats a good idea
06:38:35 <migurski> recently though I think I've been doing 100% of my mapnikking through cascadenik
06:39:18 <Mrfo> ah
06:39:48 <Mrfo> atm i have to use vanilla mapnik, so i was just trying to figure out some cleaner ways to organize my files
06:40:25 <springmeyer> .ManagingLargeXmlFiles
06:40:48 <Mrfo> bot acting up again?
06:40:55 <springmeyer> ack. nm
06:40:56 <springmeyer> http://trac.mapnik.org/wiki/ManagingLargeXmlFiles
06:41:07 <migurski> Mrfo one thing I have found useful is to use entities for entire files
06:41:18 <migurski> whole included blocks of stuff
06:41:30 <Mrfo> thx springmeyer
06:41:57 <Mrfo> migurski, yeah i was mostly hoping to pick your brain for ways you've used them. it didn't occur to me to make entites for each zoom level till i saw your code block
06:42:36 <migurski> I started using those when I first made mapnik styles for a client project ... the scaledenominators make no sense to me
06:42:44 <migurski> I mean I understand them, but they're unscannable
06:42:56 <Mrfo> yeah i completely agree
06:43:22 <Mrfo> how do you handle doing blocks of zooms? like zoom 14-18
06:43:24 <springmeyer> note: scaledenominators will accept scientific notation
06:43:35 <springmeyer> (which for some may be more 'scannable')
06:43:41 * springmeyer not for I tho :)
06:43:44 <Mrfo> oh, nevermind that was stupid question
06:43:57 <migurski> they do? wow
06:43:57 <nikq> Mapnik Trac: InstallationTroubleshooting edited | http://trac.mapnik.org/wiki/InstallationTroubleshooting?version=22
06:44:39 <springmeyer> yes.
06:44:43 <migurski> for blocks of zooms, I use the min scale and max scale numbers from that text file
06:44:53 <migurski> and do my best to remember that min = max and max = min =)
06:44:53 <springmeyer> oh and migurski: see r794
06:44:53 <nikq> http://trac.mapnik.org/changeset/794, at , by dane: Made Scale Denominator available as a property of the Map
06:45:04 <migurski> yay
06:45:09 <migurski> that's super useful
06:45:50 <springmeyer> yep yep.
06:47:03 <springmeyer> also r787 might be useful for you while you are still hanging with xml
06:47:04 <nikq> http://trac.mapnik.org/changeset/787, at , by dane: + add load_map() and save_map() support for reading and writing of abstract, title, minzoom, maxzoom, and queryable attributes
06:47:28 <springmeyer> being able to stick things in abstract and title I find useful
06:47:44 <Mrfo> hmmm. what do those do?
06:48:14 <springmeyer> abstract and title don't do anything
06:48:28 <springmeyer> other than store strings that you would want to stick in them
06:49:00 <springmeyer> which fits the SLD spec and is great for alternate (ie long names) for layers for such things as legends, etc
06:49:09 <Mrfo> ahh
06:49:14 <migurski> that's great
06:49:26 <migurski> they're like entities that are evaluated later?
06:49:30 <springmeyer> queryable is a property that is default false but must be set true to be able to query featuresets in python
06:50:23 <springmeyer> all that happens now with abstract and titles is if they are set in the xml that is loaded the are available in python, and then they can be serialized back into xml with save_map()
06:51:03 <springmeyer> minzoom and maxzoom are scale_denominators that bracket when a layer can be viewable/rendered
06:51:22 <springmeyer> note, they apply to the whole layer, not just a style/rule
06:51:45 <migurski> an extra dimension for layer extent
06:56:37 <nikq> Mapnik Trac: InstallationTroubleshooting edited | http://trac.mapnik.org/wiki/InstallationTroubleshooting?version=23
07:02:22 <nikq> Mapnik Trac: Ticket #186 (Scons usability improvements) created | http://trac.mapnik.org/ticket/186
07:05:47 <springmeyer> migurski: if you have any install notes from your debian fun send em to me or post em here: #115
07:05:47 <nikq> Ticket #115: Update Install Document on Mapnik.org by release and trunk, http://trac.mapnik.org/ticket/115
07:06:24 <springmeyer> I'll be pulling together a new install doc for the release as best I can.
07:06:28 * springmeyer heads to bed...
07:06:31 <migurski> oh yeah, will do
07:06:33 <migurski> gnight
07:09:30 <springmeyer> 'night!
07:09:35 *** springmeyer has quit ()
07:13:16 <migurski> Mrfo you had some question the other day - was the entity thing it?
07:18:55 *** scruggs has quit (Read error: 60 (Operation timed out))
07:28:17 <Mrfo> ohh. that was a style issue
07:28:31 <Mrfo> and i dont think theres easy solution to it
07:28:47 <Mrfo> lemmie upload a screenshot
07:29:29 <migurski> k
07:31:06 <Mrfo> http://img440.imageshack.us/img440/7201/trafficed3.png
07:31:29 <Mrfo> so thats a mapnik generated overlay on top of some existing tiles
07:31:30 <migurski> is this google traffic?
07:31:33 <migurski> oh
07:31:34 <migurski> wow
07:31:38 <migurski> looks nice =)
07:31:43 <Mrfo> heh thanks
07:32:01 <Mrfo> so basically, as you zoom out the roads merge together
07:32:04 <migurski> right
07:32:20 <migurski> the two carriageways on either side of 95?
07:32:28 <Mrfo> yeah
07:32:54 <migurski> hm
07:33:04 <Mrfo> i dont think theres an easy solution with mapnilk
07:33:18 <migurski> I guess you could make the two lines thinner and thinner, but yeah this seems more like a geometry problem than a styling one
07:34:06 <Mrfo> yeah
07:34:27 <Mrfo> only solution i can think of is to create a geometry set for each zoom
07:34:34 <Mrfo> thats correctly spaced apart
07:34:47 <migurski> yeah
07:35:15 <migurski> it'd be interesting to do that in pgsql
07:35:21 <migurski> it can offset lines, right?
07:35:49 <migurski> like maybe it could tell which way each carriageway was going, figure out the centerline, and then make new lanes with zoom-correct offsets in each direction
07:36:05 * migurski reachs hands toward pie in the sky
07:36:09 <Mrfo> hmmm. iwhat do you mean by offset lines?
07:36:33 <nikq> Mapnik Trac: Ticket #115 (Update Install Document on Mapnik.org by release and trunk) updated | http://trac.mapnik.org/ticket/115#comment:4
07:38:12 <migurski> like, take a line, and move it some number of units to the side, dealing with kinks and so on
07:39:17 <Mrfo> do you think that could be done on the fly?
07:39:26 <migurski> kinda doubt it =\
07:39:32 <migurski> and I don't see anything relevant in http://postgis.refractions.net/documentation/manual-1.3/ch06.html
07:40:14 <Mrfo> hmmm
07:41:30 <Mrfo> yeah its no biggie. i dont imagine the solution is going to be easy
07:41:38 <Mrfo> i figure ill back burner it for a bit
08:07:25 *** xcacou (n=aga@AToulouse-157-1-184-2.w86-221.abo.wanadoo.fr) has joined #mapnik
09:44:24 *** Mrfo has quit (Read error: 104 (Connection reset by peer))
10:02:34 *** ninja_ has quit ()
11:27:18 *** ale1 has parted #mapnik ()
13:57:53 *** CIA-57 has quit ()
14:08:44 *** CIA-58 (n=CIA@208.69.182.149) has joined #mapnik
14:53:19 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
15:02:19 *** scruggs (n=chris@72-161-119-87.dyn.centurytel.net) has joined #mapnik
15:38:00 <nikq> Mapnik Trac: Changeset [817]: + mapnik-use-rgba-in-color-to-string.patch (jonb)   Make  ... | http://trac.mapnik.org/changeset/817
15:40:03 <nikq> Mapnik Trac: Changeset [818]: + mapnik-roundup-alpha-conversion.patch (jonb)     Round up alpha values  ... | http://trac.mapnik.org/changeset/818
15:41:45 <nikq> Mapnik Trac: Changeset [819]: mapnik-polygon-symbolizer-wants-fill-opacity.patch (jonb)   The save_map &  ... | http://trac.mapnik.org/changeset/819
15:43:59 <nikq> Mapnik Trac: Changeset [820]: + mapnik-write-colors-using-rgba-not-hex.patch (jonb)      When you use  ... | http://trac.mapnik.org/changeset/820
15:47:27 <CIA-58> mapnik: artem * r817 /trunk/src/color.cpp:
15:47:27 <CIA-58> mapnik: + mapnik-use-rgba-in-color-to-string.patch (jonb)
15:47:27 <CIA-58> mapnik:  Make color::to_string() generate appropriate rgb() or rgba() strings
15:47:27 <CIA-58> mapnik: depending on alpha() value. It also changes the alpha range to be
15:47:28 <CIA-58> mapnik: 0.0-1.0, not 0-255.
15:47:30 <CIA-58> mapnik: artem * r818 /trunk/include/mapnik/css_color_parser.hpp:
15:47:32 <CIA-58> mapnik: + mapnik-roundup-alpha-conversion.patch (jonb)
15:47:34 <CIA-58> mapnik:  Round up alpha values when converting float to int otherwise the value
15:47:36 <CIA-58> mapnik:  to changes each time we read/write the color to XML.
15:47:38 <CIA-58> mapnik: artem * r819 /trunk/src/save_map.cpp:
15:47:40 <CIA-58> mapnik: mapnik-polygon-symbolizer-wants-fill-opacity.patch (jonb)
15:47:42 <CIA-58> mapnik:  The save_map & load_map disagree about the name of the CSS parameter
15:47:44 <CIA-58> mapnik:  for the opacity in PolygonSymbolizer. Make them consistent changing
15:47:50 <CIA-58> mapnik:  save_map to output fill-opacity.
15:47:52 <CIA-58> mapnik: artem * r820 /trunk/include/mapnik/ptree_helpers.hpp:
15:47:54 <CIA-58> mapnik: + mapnik-write-colors-using-rgba-not-hex.patch (jonb)
15:47:56 <CIA-58> mapnik:  When you use save_xml() the colors are written out in #RGB format
15:47:58 <CIA-58> mapnik:  which can not represent alpha information. The patch makes it save using
15:48:00 <CIA-58> mapnik:  the rgb()/rgba() strings.
16:39:01 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
16:43:16 *** xcacou has quit (Read error: 60 (Operation timed out))
16:47:57 <artem> hello all:)  I have a question (from JonB) : Should load_map() clear any existing map information? Any thoughts?
16:57:29 *** D3f0 (n=defo@190.176.213.175) has joined #mapnik
17:09:53 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
17:10:15 <kredik> Hi all, where can i get osm.xml and generate_image.py ?
17:12:05 <springmeyer> .g generate_tiles.py
17:12:06 <nikq> springmeyer: http://svn.openstreetmap.org/applications/rendering/mapnik/
17:12:23 <springmeyer> kredik: generate_image.py is there as well
17:12:29 <springmeyer> hey artem :)
17:12:33 <kredik> thanks a lot.
17:12:45 <springmeyer> I'm not sure :)
17:12:48 <artem> hey, springmeyer
17:13:12 <springmeyer> I figure being able to accumulate map information (ie from multiple loads of different xml) might have its uses
17:13:44 <springmeyer> and you can always call map.remove_all() right?
17:13:49 <springmeyer> (if you want to clear the layers and styles before calling load_map() again)
17:13:52 <artem> springmeyer: yep
17:14:18 * springmeyer exposed that in the python bindings last week (was stoked when he found it! :) )
17:14:24 *** Ruffiano (n=ruffiano@static-70-21-119-183.res.east.verizon.net) has joined #mapnik
17:14:31 <artem> I'm undecided on this so +1 for keeping things as it is
17:14:44 <springmeyer> I guess the issue is duplication when names conflict huh?
17:15:46 <Ruffiano> Is there a way to specify a bounding box, or some form of dont render in this bounding box, for a layer/style in the osm.xml ?
17:17:13 <artem> Ruffiano: don't think so
17:18:13 <artem> but you might be able to craft Postgis/SQL to achieve this behavior
17:18:37 <artem> don't render this bbox == render everything else. right ?
17:19:04 <Ruffiano> well, I just dont want a certain box of a specific layer rendered
17:19:45 <Ruffiano> render this shape file for all of the world, but not those silly Australians, or something similar =)
17:20:19 <artem> ok gotcha, you need to consult postgis docs should be possible :)
17:20:53 <Ruffiano> sounds good, yeah I didn't see any reference to doing this within the style sheet alone
17:21:04 <Ruffiano> many thanks
17:21:43 <kredik> Does anyone on this channel has a pretty mapnick xml config file for rendering osm shapefiles ?
17:22:22 * springmeyer notices that calling load_map() twice on the same xml results in duplicated registration of layers but not styles - figures that make sense
17:23:44 <springmeyer> ya, keeping as it seems fine to me artem
17:24:19 <artem> springmeyer: cool, lets leave as it is for 0.6
17:24:20 <springmeyer> kredik: I've not heard of someone here pulling that together since most use/modify the osm.xml or cascadenik styles that work with PostGIS
17:24:24 <springmeyer> cool
17:24:36 <springmeyer> kredik: sure would be useful of course
17:25:18 * artem bbl
17:26:06 <springmeyer> cheers
17:26:43 *** Ruffiano has parted #mapnik ()
17:28:58 *** artem has quit ()
17:30:14 <kredik> thanks
17:30:24 *** migurski has quit ()
17:31:11 <springmeyer> kredik: which osm shapefiles are you thinking btw? the ones from cloudmade?
17:33:01 <kredik> i have downloaded shapefiles from http://download.geofabrik.de/osm/europe/
17:51:53 <cmarqu> Hi guys.
17:53:43 <cmarqu> springmeyer: FWIW, I was getting a backtrace from nik2img.py yesterday: http://rafb.net/p/LAa6Sy53.html
17:54:18 <cmarqu> (I have -i pdf but -o image.png, that was just a mistake)
17:55:19 <cmarqu> Generating PNG seems to have worked, but I couldn't find the resulting file (it failed to open up gthumb because I don't have it installed).
17:55:47 <springmeyer> funky, thanks for the info
17:56:09 <springmeyer> ya I need to disable that gthumb thing - automatic opening in an image viewer seems dicey on linux
17:56:42 <cmarqu> This is with mapnik SVN trunk and mapnik-utils SVN trunk
17:56:54 <springmeyer> also when gthumb is used it becomes a subprocess and the script won't finish until gthumb is closed
17:57:00 <springmeyer> which is kinda silly :)
17:57:09 <springmeyer> okay.
17:57:24 <springmeyer> so, obvious one is that you have permissions to write a file where you are rendering?
17:57:25 <cmarqu> Hmm, so can it be that the process is still running/waiting?
17:57:41 <springmeyer> what happens if you try to render a png and add the flag --noopen ?
17:57:49 <cmarqu> springmeyer: Oh, right. No, I haven't.
17:57:52 <springmeyer> (that will suppress the attempt to use gthumb)
17:58:42 <cmarqu> Ok, trying.
17:59:43 <cmarqu> springmeyer: Yep, that worked, thanks.
18:00:42 <springmeyer> cool.
18:02:20 <springmeyer> cmarqu: are you running a linux desktop or server through ssh?
18:02:41 <cmarqu> springmeyer: Desktop
18:02:50 <cmarqu> Ubuntu Intrepid amd64
18:02:54 <springmeyer> k, what is your default image viewer?
18:03:27 <cmarqu> In Gnome, it's eog these days I think.
18:03:35 <cmarqu> My personal one is still qiv.
18:03:44 <springmeyer> any idea? ie if you 'clicky' on a png file?
18:03:54 <cmarqu> Ah, let me see.
18:04:31 <cmarqu> Yes, eog (Eye of Gnome)
18:05:30 <springmeyer> okay, what do you get with --app qiv ?
18:06:32 <cmarqu> Ah, hmm, my postgres user cannot open the display
18:06:52 <springmeyer> interesting. what is the error?
18:07:29 <cmarqu> http://rafb.net/p/Mby82261.html
18:08:26 <cmarqu> I'm actually kinda surprised that nik2img tries to support image viewers.
18:08:38 <cmarqu> Doesn't feel unixy to me :)
18:09:35 <springmeyer> eww. no good :)
18:10:11 <springmeyer> ya, I agree. cmarqu: you think it should be default off for linux?
18:10:14 *** migurski (n=migurski@h-68-165-1-62.snvacaid.covad.net) has joined #mapnik
18:10:16 <cmarqu> As my regualar user I'd need to be able to connect to the DB which I usually don't do
18:10:22 <cmarqu> springmeyer: Yes, absolutely.
18:10:55 <springmeyer> cmarqu: as far as connecting to the db you should be able to add all the postgis config options in the xml...
18:11:18 <springmeyer> rather than running as the postgres user (depending on your postgres conf of course)
18:12:41 <cmarqu> I guess I'd need to give it a password in the first place (since Ubuntu does that sudo thing always)
18:13:44 <springmeyer> depends, for my dev setup I use the postgres user in the xml without a password and then allow only connections from localhost
18:14:45 <cmarqu> Well, I just gave it a password now.
18:15:03 <cmarqu> Do you think the PDF problem has to do with permissions?
18:15:28 <springmeyer> I don't know, doesn't feel unixy to me ;)
18:15:41 <cmarqu> Oh. "IOError: error while writing to output stream". I only see that now.
18:15:45 <cmarqu> Heh! :)
18:15:52 <springmeyer> :) kidding around
18:16:01 <springmeyer> huh, so the same problem even with --noopen huh?
18:16:21 <springmeyer> I'm not sure, seems like it could be a nik2img bug or perhaps a cairo install problem
18:16:25 <cmarqu> No, didn't try --noopen with PDF yet, it was PNG always.
18:16:53 <springmeyer> ah, ya try the PDF with --noopen
18:17:10 <springmeyer> or try rendering cairo stuff in isolation from nik2img with the sample code here: http://mapnik-utils.googlecode.com/svn/example_code/cairo_renderer/render_cairo_formats.py
18:18:39 <cmarqu> Works now! And it's vectory! :)
18:20:10 <cmarqu> Hmm. A 2.3MB file though...
18:20:59 <springmeyer> ya that's the idea - full res PDF
18:21:05 <springmeyer> PS will be even bigger
18:21:15 <springmeyer> so --noopen works for ya?
18:22:39 <cmarqu> Yes, it works. Is the PDF vectors or bitmapped though?
18:23:45 <springmeyer> vectors
18:24:36 <cmarqu> Good. Your "full res" sounded like bitmap.
18:25:00 <springmeyer> ah sorry
18:25:40 *** kredik_ (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
18:25:40 <springmeyer> probably wrong on another account too :) I don't think the exact vector geometries are preserved
18:25:59 *** kredik has quit (Read error: 104 (Connection reset by peer))
18:26:12 <springmeyer> cmarqu: sudo easy_install http://mapnik-utils.googlecode.com/svn/trunk/nik2img/
18:26:33 <springmeyer> 'noopen' now default on linux, pls test :)
18:27:24 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
18:27:33 *** kredik_ has quit (Read error: 104 (Connection reset by peer))
18:27:44 <springmeyer> ps, cairo support is fairly new and not too many have worked with it
18:27:53 <springmeyer> feel free to document your findings here http://trac.mapnik.org/wiki/MapnikRenderers
18:28:02 <springmeyer> or
18:28:02 <springmeyer> http://trac.mapnik.org/wiki/OutputFormats
18:29:11 <cmarqu> Will do. I have also found some Mapnik rendering problems, want to see them before I file bugs?
18:29:30 <springmeyer> sure sir
18:29:37 <cmarqu> SVN trunk works fine now without --noout, thanks.
18:29:46 <springmeyer> cool
18:30:34 <cmarqu> http://opentiles.com/cmarqu/?zoom=15&lat=50.96286&lon=14.06721&layers=00B000000
18:30:52 <cmarqu> Directly above the Elbe, there is the Haldenweg.
18:31:09 <cmarqu> Other than all the other ways, it has the name rendered below the line
18:31:29 <cmarqu> (It uses the same style.)
18:33:21 <cmarqu> Then at about the center of the map, at the other end of "Griesgrund", there is "Grüner Strich/RoteXnkt"
18:33:40 <cmarqu> At the X, there is text missing.
18:33:44 <springmeyer> hum. ya I'm no guru on text placement, ticket is best :)
18:33:54 <springmeyer> nice map though! geez
18:34:14 <cmarqu> Thanks to the power of Cascadenik and Mapnik.
18:34:43 <springmeyer> ya, nice mod of cascadenik's styles, wow
18:36:01 <springmeyer> we should get a style exchange going at some point...
18:36:30 <cmarqu> Was gonna ask, where should I host this style? Cascadenik SVN, or OSMs?
18:36:31 <springmeyer> ie post various cascadenik mml's and be able to read'em in from remote urls with nik2img
18:36:37 <cmarqu> Ooops, BBIAB
18:36:45 <springmeyer> BBIAB ?
18:36:49 <springmeyer>  help me out :)
18:38:52 <springmeyer> ah, be back in a bit, duh
18:47:52 *** kredik has quit (Read error: 110 (Connection timed out))
18:48:06 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
18:54:00 *** kredik has quit (Read error: 104 (Connection reset by peer))
18:54:08 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
19:22:16 *** kredik_ (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
19:22:16 *** kredik has quit (Read error: 104 (Connection reset by peer))
19:22:18 *** kredik_ is now known as kredik
19:33:03 <cmarqu> Ok, back.
19:33:22 <cmarqu> Typo in nik2img: "constuct"
19:47:38 <nikq> Mapnik Trac: Ticket #187 (Text rendering problems) created | http://trac.mapnik.org/ticket/187
19:48:09 <nikq> Mapnik Trac: mapnik_trunk_2009-01-19_bugs.png attached to Ticket #187 | http://trac.mapnik.org/attachment/ticket/187/mapnik_trunk_2009-01-19_bugs.png
19:49:11 <nikq> Mapnik Trac: Ticket #157 (Add transfer mode & opacity to RasterSymbolizer) updated | http://trac.mapnik.org/ticket/157#comment:4
19:50:27 <springmeyer> thanks cmarqu : http://code.google.com/p/mapnik-utils/source/detail?r=491
19:50:59 <cmarqu> Hey, I am a mapnik developer now! :)
19:51:11 <springmeyer> !
19:52:18 *** kredik has quit (Read error: 145 (Connection timed out))
19:52:54 <cmarqu> migurski: I have a gdal raster layer in my style.mml, but after compiling it, the status in the XML is "off". When I change it to "on" by hand, everything works fine though.
19:55:16 <CIA-58> mapnik-utils: dane.springmeyer * r490 /trunk/nik2img/ (CHANGELOG.txt nik2img.py): Turned off automatic opening when used on linux since this is unpredictable, and most often unneeded since their is no default viewer on linux servers
19:55:17 <CIA-58> mapnik-utils: dane.springmeyer * r491 /trunk/nik2img/nik2img.py: Fixed typo in usage (thanks cmarqu)
20:02:06 *** springmeyer has quit ()
20:21:28 <migurski> cmarqu, it might be a factor of me not knowing how rastersymbolizer works when I wrote cascadenik
20:21:57 <migurski> I can patch it today if you're not in a serious hurry
20:23:58 <cmarqu> No, not a particular hurry.
20:24:43 <cmarqu> Do you have any useful tricks to share when something you styled doesn't render?
20:25:23 <cmarqu> I sometimes don't know if a feature is in planet_osm_line or planet_osm_polygon, and I don't know SQL to ask for it.
20:30:13 <migurski> ah yeah I usually just hit pgsql directly
20:30:35 <cmarqu> And then put in the SELECT command from the style?
20:30:43 <migurski> but I also often start with a really dumb stylesheet that just makes everything from planet_osm_line a black line, and everything _polygon a translucent white one
20:30:46 <cmarqu> To see if it find anything?
20:31:01 <cmarqu> Ah.
20:31:03 <migurski> yeah, though maybe be more selective in your column choice
20:31:17 <migurski> otherwise you get giant, screen-filling geometry literals that are a hassle to scroll through
20:31:53 <migurski> so like select osm_id, name from planet_line where ...
20:32:24 <cmarqu> Ah, osm_id would be the way ID of a feature I know has the right tags?
20:34:01 <migurski> yeah exactly
20:34:15 <cmarqu> Cool
20:36:35 <cmarqu> And if I have, say, a natural=peak that I display. And that peak has an extra tag, importance=1.5 (in the planet file), can I check for that importance tag (like [importance>=1.0]) in the style?
20:36:44 <migurski> yes, just like that
20:37:09 <cmarqu> Really? Because that didn't seem to work.
20:37:42 <cmarqu> Instead, all such POIs were not rendered.
20:37:51 <jburgess> be careful of whether it has imported the column as text or a number
20:38:12 <jburgess> almost all the default columns in the osm default.style are text
20:38:47 <jburgess> the >= type operators work in odd ways when things are treated as strings, e.g. 2 > 10
20:39:08 <cmarqu> Oh. importance is my own invention, so maybe they are not even in the DB?
20:39:35 <jburgess> look at the columns with \d table-name
20:39:57 <cmarqu> Or does it take all natural=peak and all tags on such a feature?
20:40:00 <jburgess> they will only be a column in the db if listed in the osm2pgsql default.style
20:40:16 <jburgess> no, only the tags listed in the default.style
20:40:36 <migurski> cmarqu - it didn't?
20:40:37 <cmarqu> Ok, that would explain something. :)
20:41:06 <migurski> oh yeah that would definitely explain it
20:41:42 <cmarqu> I'll have to do some reading on driving pgsql from the terminal first.
20:42:24 <jburgess> if you can describe what you want then I can probably help
20:43:28 <cmarqu> jburgess: Unrelated, I had some problems after I was importing a planet excerpt from Geofabrik, and when I leter wanted to append another such excerpt (an adjoining area). It complained about uniqueness.
20:43:55 <jburgess> right, I had that complaint a week or two ago from someone else
20:44:10 <jburgess> the issue is with ways which cross the boudary between the two files
20:44:20 <jburgess> they appear in boths sets of data
20:45:07 <cmarqu> Ah. But that must be a solved problem, no? Or is nobody using those excerpts?
20:45:31 <jburgess> lots of people use them, but only 1 file at a time
20:46:15 <cmarqu> Interesting.
20:46:25 <jburgess> the obvious thing is to either discard the duplicate or try to join them together
20:46:44 <jburgess> I have not looked myself. It would be good to know if the two copies of the way are identical
20:46:52 <jburgess> or whether they are two halves
20:48:47 <cmarqu> I could probably do the typing for you if you want to try with my DB, but it might be quicker to load them yourselves. I'm a total newbie to databases.
20:49:24 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
20:49:49 <cmarqu> My two files are http://download.geofabrik.de/osm/europe/germany/sachsen.osm.bz2 and http://download.geofabrik.de/osm/europe/germany/thueringen.osm.bz2
20:49:49 <jburgess> it is probably better/easier for me to download and test myself. Then I can test a solution too
20:49:58 <jburgess> how big?
20:50:08 <cmarqu> 18M and 13M
20:51:26 <cmarqu> http://download.geofabrik.de/osm/europe/germany/mecklenburg-vorpommern.osm.bz2 and http://download.geofabrik.de/osm/europe/germany/berlin.osm.bz2 are smaller and should have the same problem
20:51:41 <cmarqu> 2x 7M
20:52:29 <cmarqu> jburgess: I'm not in a hurry at all with this problem.
20:53:13 <jburgess> I'm downloading the 18 + 13 now.
20:53:24 <cmarqu> Cool
20:53:46 <cmarqu> I was using files two days older, but the problem is likely still there
21:19:41 <jburgess> cmarqu: the first rejected way has id=4554624. Looking at the contents of the two files, the both contain the way with different nodes in each. The code would have to merge the ways to make things work correctly. I'll have to give it some thought
21:20:11 <cmarqu> jburgess: Ok, thanks.
21:20:25 <cmarqu> In the meantime, I have added the following line to default.style:
21:20:31 <cmarqu> node    importance      real
21:20:46 <cmarqu> That should be fine for a peak, right?
21:21:00 <jburgess> looks good
21:21:14 <cmarqu> I put it at the end of the file, does order matter?
21:21:18 <jburgess> no
21:21:45 <cmarqu> Cool. And does that now require a full import of the osm file?
21:22:18 <jburgess> yes if you want all the data, but there is a quick hack if you just want to test one or two nodes
21:22:45 <jburgess> you can add the column to the existing table & then set a value on one or tow nodes
21:22:58 <jburgess> but if a re-import is only a few minutes, then do that instead
21:22:59 <cmarqu> Hmm. I'll probably want all the data.
21:23:04 <cmarqu> Yes, it is.
21:54:17 <cmarqu> migurski: As soon as I have a style with ".poi.point[natural=peak][importance>1] name", I lose all my POIs. If I remove that [importance>1] part, they show up again.
21:54:47 <cmarqu> I now have importance in my DB, as a real.
21:55:10 <cmarqu> With [importance>1.0], it doesn't work either.
21:55:34 <jburgess> can you paste the xml to somewhere like http://rafb.net/paste/
21:55:46 <cmarqu> The generated one you mean?
21:55:50 <jburgess> chkec if the ">" appears as "&gt;", if not, then that is a bug
21:56:29 <jburgess> yes the generated one (that is the one I can parse most easily)
21:59:17 <cmarqu> http://rafb.net/p/a4cAYE71.html
21:59:29 <cmarqu> Generated from .poi.point[natural=peak][importance>1] name
22:00:11 <cmarqu> I selected both a negative and a positive occurrence, it has many more of course.
22:03:34 <jburgess> can I see the <Parameter name="table"> line for the one with importance?
22:05:22 <jburgess> by positive and negative do you mean that one works and one does not? or just that one uses > and the other <= ?
22:06:24 <cmarqu> No, just that Cascadenik generates lines that look like what you have written, and then some with the logical inversion of it.
22:06:46 <cmarqu> you=the guy writing the style
22:07:05 <jburgess> ok, do you have the <Parameter name="table"> line ?
22:07:25 <cmarqu> Yes, I suppose it's the one here:
22:07:28 <cmarqu>             <Parameter name="table">![CDATA[         (SELECT * FROM planet_osm_polygon                      WHERE building IS NOT NULL                       ORDER BY z_order ASC, way_area DESC) AS citylike]]</Parameter>
22:07:40 <cmarqu> Although I don't understand why it's polygon...
22:08:13 <jburgess> no that surprise me also
22:08:27 <jburgess> I would have expected a query on planet_osm_point
22:08:32 <cmarqu> Yep
22:09:00 <cmarqu> Let me keep the file and generate a working one, then do a diff.
22:09:11 <jburgess> I have checked the osm style and it looks OK, that does the same
22:09:34 <jburgess> I think the code picks the area centroid for the placement
22:10:17 <jburgess> ah... this would be the problem I think
22:10:26 <jburgess> didn't you only set importance for nodes?
22:10:35 <cmarqu> Yes.
22:10:42 *** D3f0 has quit (Read error: 60 (Operation timed out))
22:10:50 <jburgess> that won't work here since this isn't a node, but a polygon
22:11:30 *** D3f0 (n=defo@190.176.213.175) has joined #mapnik
22:11:33 <cmarqu> http://rafb.net/p/1DXm1t45.html is my layer definition in Cascadenik
22:11:39 <jburgess> you need to make your default.style line: node,way   importance   real
22:11:58 <cmarqu> I think I have that.
22:11:59 <jburgess> won't make any difference. you won't currently have a column called importance in your DB
22:12:03 <cmarqu> Let me re-check
22:12:16 <jburgess> what you told me earlier was jusr "node  importance  real"
22:12:53 <jburgess> at the time you were just talking about elevations on peak nodes
22:13:30 <cmarqu> Yeah, I was extending that silentely later since I thought it might be useful for linear features.
22:14:15 <cmarqu> \d planet_osm_polygon shows me  importance       | real     |
22:14:19 <jburgess> as you can see, mapnik is rather unforgiving about rules referencing columns which don't exist. It just silently throws away the whole style
22:15:12 <cmarqu> I have importance as real for planet_osm_point and planet_osm_line too.
22:15:46 <cmarqu> Or am I checking the wrong thing?
22:16:04 <jburgess> is there anything you need to hide in the generated xml or is it just too large to paste all of it?
22:16:29 <jburgess> you are checking the right thing
22:17:34 <cmarqu> It's very big, but let me put it online.
22:17:42 <cmarqu> http://cmarqu.dyndns.org/~colin/osm_teczno_customized.xml
22:17:53 <cmarqu> Well, "just" 4.4MB
22:18:36 <jburgess> a little on the large size, but should be ok
22:19:40 <jburgess> do you know the name of a style which is not rendering?
22:20:37 <cmarqu> I can find one I think
22:21:01 <jburgess> are you using a recent build of mapnik?
22:21:16 <cmarqu> Yes, SVN as of two days ago
22:21:54 <jburgess> ok, fine. I'm just trying to rule things out
22:22:37 <cmarqu> Finding the style is hard
22:25:14 <cmarqu> Maybe I forgot to mention something. When I place the definition with the "importance" at the end of my Cascadenik style, it correctly selects peaks with importance >1 and shows them. But all other peaks and also all other pois in that style are not shown.
22:25:36 <jburgess> one quick thing, try replacing 1 with 1.0 etc
22:25:37 <cmarqu> Other pis are e.g. [historic] = 'castle'
22:25:46 <cmarqu> Did that already, no change.
22:26:03 <cmarqu> Maybe the logical inversion does not work?
22:26:36 <jburgess> possibly. I'm not sure how well some binations have been tested
22:27:11 <cmarqu> I guess I'll try with a very very simple style.
22:27:29 <cmarqu> Then the inversion is much easier to check.
22:27:32 <jburgess> the only place in the osm style which uses numerical comparisons are fairly simple range tests like "if area >= 100 and area < 1000"
22:28:32 <cmarqu> Come to think of it, nik2img shows good debugging info when working on a style. Would that be of help?
22:29:03 <jburgess> I have not really worked with nik2img so I'm not sure it would help
22:29:29 <jburgess> what might be more useful would be for me to add code into mapnik to report errors instead of just being silent
22:29:51 *** dthomas has quit (Read error: 60 (Operation timed out))
22:29:52 *** dreamil has quit (Read error: 60 (Operation timed out))
22:29:55 <cmarqu> That would be more useful in all such cases, yes.
22:31:05 *** dreamil (n=swapnil@freemap.in) has joined #mapnik
22:31:20 *** dthomas (n=darkness@linode.caliginous.net) has joined #mapnik
22:31:32 <jburgess> it would be handy if cascadenik inserted comments in each block of generated output including with the original import rules
22:33:23 <jburgess> For pois with no importance, do you have 0 or a blank (nul) entry?
22:33:43 <cmarqu> blank
22:33:50 <cmarqu> Oh.
22:33:51 <jburgess> that may be the reason then
22:34:11 <jburgess> blank would not pass the "[importance] <= 1" test
22:34:16 <jburgess> (probably)
22:34:22 <cmarqu> Indeed.
22:34:30 <jburgess> one fix maybe to execute something like:
22:34:47 <jburgess> update planet_osm_polygon set importance=0 where importance is null;
22:35:23 <cmarqu> gis=# update planet_osm_polygon set importance=0 where importance is null;
22:35:23 <cmarqu> UPDATE 32222
22:35:46 <jburgess> may need to repeat on planet_osm_points too
22:39:00 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
22:39:44 <jburgess> artem: good evening
22:40:40 <artem> jburgess: just got back from oxford geek night , someone was talking about rgba(..) colours we already have support :)
22:40:54 <jburgess> yep :)
22:41:52 <cmarqu> jburgess: Just noticed that if I use importance>1.0, Cascadenik compiles that to [importance] &lt;= '1.0' (as stinrg I suppose?)
22:41:56 <cmarqu> string
22:42:19 <jburgess> artem: one minor related thing that I'm not sure we did, was making sure the rendering did the right thing when you have both a color with alpha and an opacity set
22:42:39 <cmarqu> jburgess: Yes, it works with importance>1 now! Great, thanks!
22:42:49 <jburgess> cmarqu: sounds like a bug, it perhaps expects all numbers to be [0-9] only.
22:42:59 <jburgess> would be interesting to test with +- too
22:43:30 <artem> jburgess: yes, multiplying opacity * alpha might be the answer but we need to check
22:43:31 <cmarqu> http://opentiles.com/cmarqu/?zoom=13&lat=50.95991&lon=14.10906&layers=000B00000 is the effect (exaggerated)
22:43:50 <jburgess> cmarqu: ah... the fix for this is the normal weird negtive thing.. let me give the example
22:44:10 <jburgess> cmarqu: instead of "importance <= 1" for the negative, instead it must generate "not importance > 1"
22:44:25 <artem> cmarqu:  nice map:)
22:44:43 <jburgess> the two statements differ in the key area of how they handle NUL values
22:45:09 <cmarqu> jburgess: Oh, and then it would work even without the database mangling?
22:45:14 <jburgess> yes
22:45:43 <cmarqu> artem: http://opentiles.com/cmarqu/?zoom=12&lat=50.96238&lon=14.01169&layers=0B0000000 is nicer (albeit without POIs still)
22:45:56 <cmarqu> But we got that fixed essentially
22:46:09 <jburgess> it is rather complicated to explain why this works, you really have to look at and understand the implementation
22:46:19 <cmarqu> jburgess: Thanks so much.
22:46:54 <jburgess> sounds like this requires a cascadenik fix though right? Or did you hand code those <=1's ?
22:47:16 <cmarqu> No, it's a Cascadenik fix. Let me see if I can find where to do that.
22:47:35 <artem> cmarqu: very nice indeed
22:49:45 <artem> jburgess: agree on clamping rgb values to 0 .. 255
22:50:41 <artem> jburgess: I'll modify css_color_parser to accept signed int and clamp them to 0-255 range
22:51:11 <jburgess> artem:  ok, good.
22:51:44 <scruggs> I have a couple of questions about building mapnik... I've finally managed to cross-compile mapnik for an ARM8 (will be testing it soon), but I've tried to make by build as 'thin' as possible, so I didn't want to add in the postgres stuff, etc....
22:52:03 <scruggs> I should probably add that this is the first time I've uses scons, so mabye I'm missing something
22:52:54 *** kredik has quit (Read error: 104 (Connection reset by peer))
22:54:05 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
22:54:11 <scruggs> for example with the pgsql libs, the script uses the PGSQL_INCLUDES/LIBS vars, and later adds those settings in the 'for preq in (...' line
22:54:42 <scruggs> and if its not set, it uses the default path.. but if I'm not building the pgsql plugin, shouldn't it disregard that prereq?
22:56:11 <artem> scruggs: you can pass plugins parameter to scons.py e.g plugins=shape or plugins=shape,raster
22:56:16 <jburgess> I don't think there is an option to disable building the plugin. If it finds the relevant headers then it will try to compile it
22:57:00 <scruggs> seems that if I don't explicitly set it it will use the default value
22:57:23 <jburgess> right.. and if that works it will build the plugin. If it doesn't then the plugin will be skipped
22:57:33 <scruggs> ok... its not a huge deal. I've patched the file to have it work for my CC environment, but I was just wanting to make sure I was reading it right
22:58:24 *** forrestv has quit (Read error: 113 (No route to host))
22:58:27 <artem> scruggs: by default all plugins will be compiled but you should be able to control this with 'plugins'  param
22:58:38 <scruggs> I think my situation is unique because of the cross-compiling... since I wasn't setting a val for PGSQL_INCLUDES it would find the headers/libs on my build machine
22:59:18 *** forrestv (n=forrestv@unaffiliated/forrestv) has joined #mapnik
22:59:35 <scruggs> the problem is that it did a -I/usr/include, which screws with the cross-compilation
22:59:59 <scruggs> where all my includes need to be -I/path/to/cross-includes/
23:00:04 <artem> scruggs: ok, I see.
23:00:29 <scruggs> no big deal... I can patch around it
23:01:14 <artem> scruggs: cool
23:17:43 <jburgess> cmarqu: I had an idea about your problem with multiple planet extracts with Mapnik
23:17:59 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
23:18:08 <jburgess> cmarqu: you could load each one into a different DB, or different table prefix in one DB
23:18:47 <jburgess> cmarqu: then you should be able to render images which combine them togther
23:18:56 <cmarqu> Ah.
23:19:07 <jburgess> It would not really scale up to handle lots of extracts but for a couple it might be ok
23:20:09 <cmarqu> Yeah, my computer wouldn't handle them anyway
23:23:14 <nikq> Mapnik Trac: Ticket #188 (Add optional blur property to text halo) created | http://trac.mapnik.org/ticket/188
23:23:19 <cmarqu> jburgess: Thanks, I'll try that (in a few days only I fear) and report back.
23:32:24 *** artem has quit ()
23:33:11 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
23:40:27 *** artem has parted #mapnik ()