00:32:59 * migurski re-reads the past few hours of stuff
00:33:23 <migurski> jburgess, you mention a suggested change to cascadenik that includes the declarations used to generate a set of styles
00:35:24 <migurski> cmarqu, can you explain a bit more about the greater than / less than business?
00:35:48 <migurski> trying to understand cases where the "not" prefix makes sense
00:36:02 <cmarqu> migurski: Well, I'm trying to pull out importance=1.0
00:36:15 <migurski> pull out = display?
00:36:17 <cmarqu> All other such nodes don't have any such importance tag set
00:36:21 <cmarqu> Yes.
00:36:58 <cmarqu> And Cascadenik generates styles with >1.0 and <=1.0 from that.
00:37:01 <migurski> I'm trying to be somewhat smart about ranges with cascadenik, for cases where there are integer or real number columns
00:37:26 <migurski> so you have a rule that says "= 1.0" and it makes ">" and "<=" out of it?
00:37:43 <cmarqu> The nodes without any importance tag set are not matching the <=1.0 part though
00:37:49 <migurski> right
00:37:55 <cmarqu> No, my rule is [importance>1]
00:38:00 <migurski> there are things I'm learning about how postgresql handles nulls
00:38:04 <migurski> ah
00:38:30 <cmarqu> Actually, using 1.0 instead of 1 makes them strings which then doesn't work in any case
00:38:33 <migurski> the ones with no importance fail to show?
00:38:50 <migurski> hrmph
00:38:53 <migurski> I understand
00:39:18 <migurski> makes sense, I may not be correctly finding floats for range comparisons
00:39:50 <cmarqu> the th no importance fail to show unless you set importance=0 in the database
00:40:05 <migurski> right
00:40:18 <migurski> because "importance < 1" does not match a null importance
00:40:40 <migurski> I'll see if there's something I can do to address the problem
00:43:38 <cmarqu> That would be cool.
00:43:54 <cmarqu> And the rgba() thing would also be great to have
00:45:19 <cmarqu> migurski: Does the stretched text thing (name_stretched) work? Do you have a rendered example?
00:45:38 <migurski> no rendered examples, but it does work okay
00:45:52 <cmarqu> Cool, I'll try it then
00:45:52 <migurski> it just adds extra non-breaking spaces between letters, a total hack
00:46:09 <cmarqu> Was gonna ask...
00:46:19 <migurski> it's connected to http://trac.mapnik.org/ticket/121
00:47:29 <cmarqu> me wants
00:47:29 <nikq> Mapnik Trac: Ticket #121 (Add letter spacing to TextSymbolizer parameters) updated | http://trac.mapnik.org/ticket/121#comment:7
00:48:18 <cmarqu> Has anyone tried to automatically produce a map legend yet?
00:48:32 <cmarqu> Apart from http://crschmidt.net/osm/mapnik/legend
00:52:29 *** ChanServ has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** scruggs has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** CIA-58 has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** kredik has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** D3f0 has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** jlivni has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** racicot has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** dodobas has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** jbronn has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** jburgess has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** dthomas has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** dreamil has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** jbglaw has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** dukeku has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** ser has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** forrestv has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** cmarqu has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** springmeyer has quit (kubrick.freenode.net irc.freenode.net)
00:52:29 *** nikq has quit (kubrick.freenode.net irc.freenode.net)
00:54:03 *** CIA-58 (n=CIA@208.69.182.149) has joined #mapnik
00:54:09 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
00:54:09 *** D3f0 (n=defo@190.176.213.175) has joined #mapnik
00:54:14 *** springmeyer (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
00:54:14 *** nikq (n=nikq@li21-121.members.linode.com) has joined #mapnik
00:54:21 *** forrestv (n=forrestv@unaffiliated/forrestv) has joined #mapnik
00:54:21 *** cmarqu (i=colin@oemcomputer.oerks.de) has joined #mapnik
00:54:29 *** ChanServ (ChanServ@services.) has joined #mapnik
00:54:34 <CIA-58> mapnik-utils: dane.springmeyer * r492 /sandbox/ (5 files in 2 dirs): Adding Jochen's xslt transform for mapnik xml
00:54:34 <CIA-58> mapnik-utils: dane.springmeyer * r493 /sandbox/xslt_stylesheet/ (test.html transform_mapfile.xml mapnik-overview.xsl): Setting correct mime-types
00:54:41 *** dthomas (n=darkness@linode.caliginous.net) has joined #mapnik
00:54:41 *** dreamil (n=swapnil@freemap.in) has joined #mapnik
00:54:41 *** racicot (n=chatzill@osgeo/member/racicot) has joined #mapnik
00:54:41 *** jburgess (n=jburgess@bb-87-80-234-70.ukonline.co.uk) has joined #mapnik
00:54:41 *** jlivni (n=josh@c-24-4-60-236.hsd1.ca.comcast.net) has joined #mapnik
00:54:41 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik
00:54:41 *** jbronn (n=jbronn@70-138-113-15.lightspeed.hstntx.sbcglobal.net) has joined #mapnik
00:54:41 *** dukeku (i=dukeku@adhd.irule.net) has joined #mapnik
00:54:41 *** dodobas (n=dodobas@unaffiliated/dodobas) has joined #mapnik
00:54:41 *** jbglaw (n=jbglaw@lug-owl.de) has joined #mapnik
00:55:56 <springmeyer> cmarqu: that's another route: http://mapnik-utils.googlecode.com/svn/sandbox/xslt_stylesheet/test.html
00:57:31 <springmeyer> would be cool to see a python script that uses Cairo to render a scalable svg legend. I've yet to play around with that.
00:58:54 <cmarqu> Yes. That is also a constant source of questions in OSM
01:05:14 *** kredik_ (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
01:05:54 *** kredik has quit (Read error: 104 (Connection reset by peer))
01:05:55 *** kredik_ is now known as kredik
01:12:55 *** scruggs (n=chris@72-161-119-87.dyn.centurytel.net) has joined #mapnik
01:13:15 *** springmeyer has quit ()
01:13:29 *** kredik_ (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
01:13:36 *** kredik has quit (Read error: 104 (Connection reset by peer))
01:13:40 *** kredik_ is now known as kredik
01:17:24 *** kredik has quit (Read error: 54 (Connection reset by peer))
01:17:56 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
01:35:49 *** kredik has quit (Read error: 104 (Connection reset by peer))
01:37:51 *** kredik (n=chatzill@LRouen-152-83-27-212.w80-13.abo.wanadoo.fr) has joined #mapnik
02:57:35 *** migurski has quit ()
03:49:40 *** CIA-58 has quit ()
04:01:04 *** CIA-57 (n=CIA@208.69.182.149) has joined #mapnik
05:47:18 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
06:05:24 *** D3f0 has quit ("Konversation terminated!")
06:23:13 *** Mrfo (i=Mrfo@pool-96-231-166-17.washdc.fios.verizon.net) has joined #mapnik
06:30:23 <Mrfo> anyone know if its faster to do let mapnik do the filtering or postgis?
06:32:02 <Mrfo> something like this: http://pastebin.com/d51e8d86b
07:56:12 *** xcacou (n=aga@AToulouse-157-1-184-2.w86-221.abo.wanadoo.fr) has joined #mapnik
08:37:08 *** migurski has quit ()
09:10:53 *** ChanServ has quit (kubrick.freenode.net irc.freenode.net)
09:11:28 *** ChanServ (ChanServ@services.) has joined #mapnik
12:08:38 *** D3f0 (n=defo@190.176.213.175) has joined #mapnik
13:26:35 *** D3f0 has quit (Remote closed the connection)
13:34:16 *** kredik has quit ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]")
15:16:02 *** D3f0 (n=defo@190.176.245.220) has joined #mapnik
16:10:33 *** D3f0 has quit ("Konversation terminated!")
16:11:47 <nikq> Mapnik Trac: Ticket #155 (Extend PointSymbolizer to support image scaling) updated | http://trac.mapnik.org/ticket/155#comment:10
16:12:08 *** Mrfo has quit (Read error: 54 (Connection reset by peer))
16:12:13 *** Mrfo (i=Mrfo@pool-96-231-166-17.washdc.fios.verizon.net) has joined #mapnik
16:41:41 *** xcacou has quit (Remote closed the connection)
16:50:56 *** springmeyer (n=springme@dsl-209-166-85-189.whidbey.net) has joined #mapnik
18:00:10 *** D3f0 (n=defo@190.176.213.175) has joined #mapnik
18:04:49 <nikq> Mapnik Trac: Ticket #167 (Map pickling failure due to mapnik.Color object) updated | http://trac.mapnik.org/ticket/167#comment:4
18:05:09 <nikq> Mapnik Trac: Ticket #167 (Map pickling failure due to mapnik.Color object) closed | http://trac.mapnik.org/ticket/167#comment:5
18:26:57 <nikq> Mapnik Trac: Ticket #189 (Text wrapping is wrong for RTL languages) created | http://trac.mapnik.org/ticket/189
19:00:39 *** __d3f0__ (n=defo@190.176.213.175) has joined #mapnik
19:00:57 *** D3f0 has quit (Read error: 104 (Connection reset by peer))
20:54:02 <cmarqu> My compiled style file is 9MB now, but Mapnik does fine.
21:32:55 <cmarqu> Bitmaps along a line seem to trigger a bug in Cairo when I export to PDF with nik2img.py
21:33:00 <cmarqu> http://oerks.net/~colin/mapnik_pdf_export_bug.pdf
21:33:18 *** jburgess has quit (Remote closed the connection)
21:44:45 *** jburgess (n=jburgess@bb-87-80-234-70.ukonline.co.uk) has joined #mapnik
21:45:09 <springmeyer> cmarqu: by bug you mean the symbols are low res?/fuzzy?
21:45:35 <cmarqu> springmeyer: No, totally off. Take a look at that PDF
21:45:52 <cmarqu> Actually, it might be evince rendering it wrong too
21:46:41 <springmeyer> off? maybe you could post a png to compare to?
21:47:08 <cmarqu> Will do.
21:49:12 <jburgess> looks ok in acroread and okular, bad in evince
21:49:30 <cmarqu> Aha.
21:49:38 <cmarqu> So it;s a libpoppler thing :/
21:50:55 <cmarqu> http://oerks.net/~colin/mapnik_pdf_export_bug_in_evince.png
21:52:24 <jburgess> I think we had problems with bitmaps along a line causing bloat in the PDF file too. Try commenting out this style and see what effect that has on the file size
21:54:21 <jburgess> the fix in the OSM style file was to replace the bitmap pattern with some slightly complex line pattern symbolizer rules which obtained a similar pattern using vector drawing
21:55:29 <cmarqu> I'll just wait for SVG support :)
21:55:35 <jburgess> actually it was the linesymbolizer we used, e.g. see how we use it to draw the one way arrow
21:55:42 <cmarqu> Matt Amos supposedly has a patch for that?
21:55:57 <cmarqu> (for SVG)
21:55:59 <jburgess> I noticed that cairo has some simple svg support, it might be possible to use that
21:58:12 <cmarqu> Oh. My printer understands PDF directly, and it looks okay there.
21:58:37 <cmarqu> Not awesome, but not buggy at least.
22:00:14 <cmarqu> Hrrm. I broke my style now...
22:33:14 <cmarqu> jburgess: Commenting out that style made the map work in evince, and the file size dropped from 2.2M to 790k.
22:35:27 <jburgess> ok, that is similar to what I saw before. If you wanted, it looks like that railway patter would be quite easy to generate using the LineSymbolizer. One continuous line + a thick line which only occus for 1 pixel in every 20 along the length.
22:37:38 <cmarqu> Sounds like line-width: 8; line-dasharray: 1, 20; in Cascadenik.
22:38:26 <cmarqu> Right, let me try that.
22:39:00 <jburgess> sounds about right (but I don't know Cascadenik).
22:39:02 <cmarqu> OTOH... the PDF does not look good enough that I would use it for printing.
22:39:49 <cmarqu> Lines are getting quite bulky
22:39:50 <jburgess> any particular issues? When I was doing this I found I had to scale up several things in the style and the bitmap icons were poor
22:41:25 <cmarqu> Yeah, bitmaps are poor, but I could live with that. Lines are too thick, text is too big and seems to be kerned wrong
22:42:06 <jburgess> I'm surprised they look bulky, I thought the higher dpi made things too small
22:42:38 <cmarqu> Well, that's with what my printer shows me.
22:42:46 <jburgess> maybe i'm getting confused though. My initial print tests were done with large size png bitmaps instead of pdfs
22:42:56 * cmarqu checks the fixed evince rendering again
22:43:26 <jburgess> the mapnik cairo engine did not exist at the time
22:44:51 <cmarqu> If you look at the PDF and compare with http://opentiles.com/cmarqu/?zoom=13&lat=51.09123&lon=13.81954&layers=B0000000000, it's obvious
22:45:06 <jburgess> I was surprised how well the pngs turned out, I was rendering bitmaps with sizes in the range of 5000 x 10000 pixels
22:45:07 <cmarqu> The bigger text makes most of it disappear even
22:46:00 <jburgess> try rendering some large pngs instead and see how they turn out.
22:46:26 <cmarqu> It would be nice if nik2img.py could produce high-resolution PNGs without needing to change the style
22:46:30 <jburgess> As I mentioned before, you'll need to scale up some features because you'll want a higher dpi output for printing vs screen
22:46:55 <cmarqu> Yes, but it could be done automatically, right?
22:47:07 <jburgess> I think so but not certain
22:47:56 <cmarqu> FWIW, the OSM export tab produces PDF where the woods are missing.
22:48:16 <jburgess> can you grab a permalink to the location?
22:48:25 <cmarqu> I mention that because someone talked about the OSM export in mapnik-users a few days ago as I read in the archives
22:48:50 *** d3f0 (n=defo@190.176.245.135) has joined #mapnik
22:49:00 <cmarqu> jburgess: What location?
22:49:36 <springmeyer> 'It would be nice if nik2img.py could produce high-resolution PNGs without needing to change the style'...
22:49:41 <springmeyer> cmarqu: you mean PDF's?
22:50:07 <cmarqu> springmeyer: No, PNGs actually. But at 600dpi, a 1px line will be very thin
22:50:25 <springmeyer> ah, okay.
22:50:29 <springmeyer> right, so...
22:50:39 <cmarqu> springmeyer: PDFs strangely come out with too thick lines
22:51:27 <springmeyer> a plan with nik2img is absolutely to allow helpers that will sweep through the styles and make systematic tweaks for varied resolution output
22:51:41 <springmeyer> I just have not gotten around to it.
22:51:42 <jburgess> cmarqu: a location where the woods are missing when you export that area
22:52:32 <cmarqu> jburgess: Ah. I think I have never seen woods in the mapnik PDF export on osm.org, the few times that I tried. But let me check...
22:52:57 <springmeyer> but the python bindings should work well to do that given a good rubric for knowing _how_ to tweak styles based on desired ppi
22:56:04 <cmarqu> jburgess: http://www.openstreetmap.org/?lat=51.19041&lon=13.57914&zoom=16&layers=B000FFFT for instance. The wood will not show but the farmland will
22:56:32 <cmarqu> This is with evince, but I have seen it with acroread (7 I think) at work
22:56:51 <cmarqu> I reckoned it has to do withthe little tree bitmaps
22:59:14 <cmarqu> springmeyer: Naively I would try starting with a user-definable multiplication factor for all thicknesses.
22:59:26 <cmarqu> Then... dasharrays as well I suppose.
22:59:58 <jburgess> cmarqu: looks fine to me http://tile.openstreetmap.org/direct/map-1.png
23:00:06 <springmeyer> cmarqu: sounds good. patches welcome!
23:00:40 <jburgess> oh... pdf?
23:00:47 <cmarqu> jburgess: This is a screenshot of the PDF?
23:00:51 <cmarqu> Yes :)
23:00:52 <jburgess> no, plain png
23:01:00 <cmarqu> Yeah, PNG always worked for me
23:01:01 <jburgess> I don't think you mentioned it was a pdf you were trying
23:01:13 <jburgess> I thoughy you meant it was all plain broken
23:01:36 <cmarqu> "FWIW, the OSM export tab produces PDF where the woods are missing."
23:01:54 <cmarqu> Nah, I was specifically meaning PDF
23:02:15 <springmeyer> actually I wonder if something distinct like thickness mulitiplication factors could live in mapnik itself.
23:02:36 <jburgess> oh well, must be time for me to get some sleep instead of staying up too late!
23:02:48 <springmeyer> I'm not sure whether methods to do so should be available off the the map, layer, or styles however...
23:03:00 <springmeyer> g'night jburgess!
23:03:12 *** __d3f0__ has quit (Connection timed out)
23:08:17 <cmarqu> springmeyer: Actually, using high-res PNG is just a crutch until well-looking PDF can be produced. If the thickness could be reduced there, and maybe the fontsize mapping tweaked...
23:12:47 <springmeyer> ah, so you mean tweaked default sizes?
23:13:08 <springmeyer> ppi/res dependent tweaking is still a cool thing to tackle
23:13:51 <jburgess> cmarqu: it looks like the woods are broken in the Cairo mapnik renderer. I just tested it locally producing pngs, the Agg renderer on the same area works fine.
23:14:07 <cmarqu> Not sure if we can find a good default for all cases, but for playing around, a switch would be good.
23:14:18 <cmarqu> jburgess: Oh, even when you produce PNGs via cairo?
23:14:21 <jburgess> yes
23:14:25 <cmarqu> Ah.
23:16:03 <jburgess> that points the finger at the PolygonPatternSymbolizer in cairo_renderer.cpp
23:19:08 <CIA-57> mapnik-utils: dane.springmeyer * r494 /sandbox/ (4 files in 2 dirs): for testing patches to load_map and save_map
23:22:06 <cmarqu> springmeyer: I found a few typos while looking at nik2img: http://oerks.net/~colin/nik2img_typos.patch
23:25:21 <springmeyer> applied! thanks :)
23:28:44 <CIA-57> mapnik-utils: dane.springmeyer * r495 /trunk/nik2img/nik2img.py: Applied nik2img_typos.patch (aka dane's fingers can't spell patch) from cmarkqu - thx
23:29:20 <cmarqu> "cmarkqu [sic!] ..."
23:29:40 <springmeyer> lol
23:29:48 <cmarqu> :)
23:29:50 * springmeyer is hopeless
23:36:15 <cmarqu> jburgess: Wow, thanks for the idea about the railway as a LineSymbolizer, it works at the first attempt
23:41:15 <springmeyer> ah darn. looks like symbolizer properties are not yet exposed in the python bindings off of a style object
23:41:28 <springmeyer> >>> dir(sty_obj.rules[0].symbols[0])
23:41:28 <springmeyer> ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__']
23:43:52 <nikq> Mapnik Trac: Ticket #190 (Make symbolizers available/editable via a layer object in python bindings) created | http://trac.mapnik.org/ticket/190
23:44:01 * springmeyer heads out walking...