#mapnik log: Sunday 19, April 2009

2009 | 04

previous | next
00:11:30 *** IvanSanchez has quit (Read error: 110 (Connection timed out))
02:23:45 *** Ldp__ has quit ()
09:57:10 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik
13:25:56 *** JeLuF has quit (Read error: 110 (Connection timed out))
14:04:57 *** sanjiv (n=sanjiv@59.180.136.41) has joined #mapnik
14:17:01 <ser> hello, how's going? here is a beautifull sunny afternoon
15:00:53 <ser> it looks everywhere is such a weather :-)
15:15:56 *** JeLuF (i=jf@mormo.org) has joined #mapnik
19:23:43 *** sanjiv has quit (Read error: 110 (Connection timed out))
19:25:54 *** sanjiv (n=sanjiv@59.180.159.242) has joined #mapnik
20:16:40 *** sanjiv has quit ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032711]")
21:56:32 *** Berteun has quit (brown.freenode.net irc.freenode.net)
21:57:57 *** Berteun (i=berteun@berteun.nl) has joined #mapnik
22:16:07 <cmarqu> Has this been mentioned here yet?: http://www.ancalime.de/images/scalestyle.rb
22:16:20 <cmarqu> ("Change text and line sizes of a mapnik style, to allow printing at different dpi settings.")
22:28:59 <nikq> Mapnik Trac: Ticket #319 (Symbolizers via python accepting **kwargs in constructor) updated | http://trac.mapnik.org/ticket/319#comment:1
22:29:23 <springmeyer> ya cmarqu: I saw holger script too
22:29:31 <springmeyer> crazy how different ruby looks than python
22:30:02 <springmeyer> my thought is that we need an internal scale factor, and I've chatted with Artem about this
22:30:11 <cmarqu> Ah good.
22:30:14 <springmeyer> but still needs some thinking through
22:30:18 <cmarqu> There also was a ticket for it, right?
22:30:27 <springmeyer> well kinda but not a good one
22:30:52 <springmeyer> I just found it and checked it
22:30:59 <cmarqu> What's that new Cascadenik stuff from Mike BTW?
22:31:01 <springmeyer> then updated that related one above ^^
22:31:09 <springmeyer> #190
22:31:09 <nikq> Ticket #190: Make symbolizers available/editable via a Style object in python bindings, http://trac.mapnik.org/ticket/190
22:31:30 <springmeyer> thats the ticket I first created when I realized that the symbolizers are non-editable via python
22:31:46 <springmeyer> because if they were applying a scale factor dyanmically from python would be pretty easy
22:31:56 <cmarqu> Ah yeah, I remember
22:31:57 <springmeyer> but my thought now is to have a map property
22:32:12 <springmeyer> for resolution
22:32:20 <springmeyer> so if m.resolution = 300
22:32:36 <cmarqu> Maybe Holger's script can help to guide what would be affected by the magnification
22:32:36 <springmeyer> then the appropriate scale factor would be dynamically applied to all symbolizers
22:32:50 <springmeyer> well, sure, but thats the easy part :)
22:33:07 <springmeyer> fonts, line widths, dash spacing is about it
22:33:20 <cmarqu> And Icons
22:33:26 <springmeyer> (but of course testings will help get it right once we implement)
22:33:33 <springmeyer> ya but icons are a bit different :)
22:33:46 <springmeyer> sure you need to scale them, but thats a separate ticket at this point :)
22:34:16 <cmarqu> The one about supporting SVG icons I suppose
22:35:01 <springmeyer> # 155....
22:35:45 <springmeyer> and then ideally that will morph into both svg icons and being able to draw graphics primitives (that a scalably) via some kind of ShapeSymbolizer
22:35:54 <springmeyer> #155 (trying again) :)
22:35:55 <nikq> Ticket #155: Extend PointSymbolizer to support image scaling, http://trac.mapnik.org/ticket/155
22:36:42 <springmeyer> cmarqu: mike is working on a Cascadenik implementation that will go direct form css -> mapnik
22:36:48 <springmeyer> skipping the xml generation
22:36:55 <springmeyer> form/from
22:40:13 <springmeyer> cmarqu: you may gasp at that given sounds like you have to edit/tweak the xml, eh?
22:41:04 <cmarqu> Well, I expect those bugs in the parser to get fixed of course :)
22:41:37 <springmeyer> right, my hunch was he hoped to drop cssutils, but I'm not sure if that was on the table for this branch
22:42:03 <springmeyer> and you should be able to serialized back out to XML via save_map() to get clean, editable xml if you need
22:43:12 <cmarqu> I could switch to using python for the cleanup, it's just very simple text replacements
22:45:09 <springmeyer> k
22:51:03 <nikq> Mapnik Trac: Ticket #190 (Make symbolizers editable in memory (allowing application of scaling  ...) updated | http://trac.mapnik.org/ticket/190#comment:7
22:53:12 <Ldp__> springmeyer: have you seen the OSM proposal for ref:color? That could tie in nicely with your ProportionalPointSymbolizer idea?
22:57:22 <nikq> Mapnik Trac: Ticket #190 (Make symbolizers editable in memory (allowing application of scaling  ...) updated | http://trac.mapnik.org/ticket/190#comment:8
22:57:45 <springmeyer> Ldp__: I noticed it but have not looked closely yet
22:57:49 <springmeyer> sounds like I should :)
22:58:09 <springmeyer> I quickly hacked at #190, comments appreciated
22:58:10 <nikq> Ticket #190: Make symbolizers editable in memory (allowing application of scaling factors), http://trac.mapnik.org/ticket/190
22:59:30 <Ldp__> heh, 'edibility' ... you wanna eat the symbolizers? :)
22:59:55 <springmeyer> whew, sure anything that makes them more easy to work with!
23:00:12 <springmeyer> feel free to fix that if you make any other changes :)
23:00:45 <Ldp__> nah, not today :)
23:01:17 <Ldp__> I'm just eagerly awaiting per-layer transparency
23:02:04 <springmeyer> ah, nevermind, you can't edit the comments :)
23:02:20 <Ldp__> was trying to figure out how opencyclemap does it, and I think they're cheating :)
23:02:40 <springmeyer> well andy is also pretty sharp as c++ I think
23:03:02 <springmeyer> I feel like he's got a few patches yet to get back upstream
23:03:05 <Ldp__> if they have a mapnik hack to do it, I wonder why it never got into svn
23:03:27 <springmeyer> NOTE: just a personal hunch, nothing more
23:03:37 <Ldp__> I have the same hunches
23:04:45 <Ldp__> but I guess per-layer transparency would require an interim canvas for that layer, that can be zapped onto the main canvas with transparency set
23:07:34 <tomhughes> Ldp__: the cycle map is done by merging several images together to make the final tiles
23:07:55 <Ldp__> tomhughes: yes, I kinda surmised that from looking at some of Andy's slides
23:08:36 <Ldp__> these: http://www.slideshare.net/gravitystorm/opencyclemap-presentation
23:10:04 <Ldp__> slide 23 vs 25 are revealing as to the method :)
23:10:54 <Ldp__> still, if mapnik can do it on a per-layer (or per-style), all the better
23:16:31 *** Ldp__ has quit ()