00:09:38 *** Genscher has quit (Quit: Verlassend) 00:17:42 <nikq> Mapnik Trac: InternationalText created | http://trac.mapnik.org/wiki/InternationalText?version=1 00:18:02 <nikq> Mapnik Trac: DeveloperTopics edited | http://trac.mapnik.org/wiki/DeveloperTopics?version=9 00:30:43 *** cgs_bob has quit (Ping timeout: 246 seconds) 00:37:38 <nikq> Mapnik Trac: InternationalText edited | http://trac.mapnik.org/wiki/InternationalText?version=2 01:11:54 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 01:13:46 *** jfreeman has quit (Remote host closed the connection) 01:34:55 *** tcarobruce has quit (Quit: tcarobruce) 02:01:53 *** jfreeman (~jfreeman@203.217.61.147) has joined #mapnik 02:22:39 *** jctull (~jctull@75.0.29.113) has joined #mapnik 02:26:02 *** c_lopez (~ccaarloos@189.169.32.250) has joined #mapnik 02:26:27 <c_lopez> good evening Mr. Springmeyer 02:52:43 *** c_lopez has quit (Ping timeout: 252 seconds) 03:03:32 *** eocampos has quit (Ping timeout: 248 seconds) 03:06:59 *** c_lopez (~ccaarloos@189.169.32.250) has joined #mapnik 03:08:52 *** agimenez has parted #mapnik (None) 03:14:16 *** wonderchook (~wondercho@pool-71-127-43-16.washdc.fios.verizon.net) has joined #mapnik 04:00:04 *** shann has quit (Ping timeout: 248 seconds) 04:02:36 *** jburgess has quit (Read error: Connection reset by peer) 04:03:26 *** jburgess (~jburgess@15.92.187.81.in-addr.arpa) has joined #mapnik 04:35:01 <springmeyer> c_lopez: hey there carlos! 04:36:43 <springmeyer> er c_lopez 04:37:31 *** waldemarq (~waldemarq@189.161.233.150) has joined #mapnik 04:37:48 *** mperry has quit (Quit: mperry) 04:43:48 <c_lopez> hi Mr. Springmeyer, how are you? 04:44:15 <c_lopez> I read you comments, thanks a lot! 04:44:27 <springmeyer> hey there 04:44:35 <springmeyer> I'm doing well 04:44:49 <springmeyer> finally getting a bit rested and caught back up after conferences 04:45:49 <c_lopez> great! I saw the ideas you gathered for mapnik while being there, the future plans for mapnik I mean 04:46:21 <springmeyer> yes, that was a fun brainstorming session :) we'll see how many come true over time... 04:47:58 <c_lopez> Tom Carden answered my email yesterday, he knows a lot about the project. 04:48:08 <springmeyer> ah, nice. 04:48:25 <springmeyer> good, yes I was impressed when I talked to him too 04:50:22 <c_lopez> I think that my proposal needs more details, and I think I confused things when I wrote about scaling elements 04:51:10 <nikq> Mapnik Trac: GSOC2010/Ideas edited | http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=22 04:51:34 <springmeyer> c_lopez: do you feel on the right track now? 04:51:40 <springmeyer> or do you have some questions? 04:53:16 <springmeyer> c_lopez: it might be useful to break out scaling elements into catagories 04:54:08 <springmeyer> e.g1) things that can be scaled easily: line width, font size 04:54:14 <c_lopez> I still have some doubts, related to what is already implemented in agg and cairo especially 04:54:57 <springmeyer> vs. others... 04:54:57 <c_lopez> oh ok 04:55:08 <springmeyer> c_lopez: say more? 04:55:35 <c_lopez> sorry, I didn't understand 04:56:36 <springmeyer> oh, I am asking about "I still have some doubts, related to what is already implemented in agg and cairo especially" 04:56:58 <springmeyer> you mean that you are not sure what can be done using those tools in general? 04:57:21 <c_lopez> sorry, I meant about agg_renderer and cairo_renderer 04:57:25 <springmeyer> or what is currently being done in agg_renderer.cpp and cairo_renderer.cpp in our implementation? 04:57:28 <springmeyer> ah, right 04:57:36 <c_lopez> yes that's right 04:57:36 *** waldemarq has quit (Ping timeout: 245 seconds) 04:57:47 <springmeyer> currently nothing is being done in the renderers around scaling objects 04:57:59 <springmeyer> except for in RasterSymbolizer 04:58:21 <springmeyer> as that is a case where raster geo-data needs to be (usually) reduced in size 04:58:54 <springmeyer> but that is a different issue, though functions to scale rasters could be re-used to scale raster symbols, if needed 04:59:04 <c_lopez> oh ok. I tried to to use a stylesheet for raster symbolizers, but the script didn't recognize the tiff files I gave it 04:59:08 <springmeyer> the live in /include/mapnik/graphics.hpp 04:59:15 <springmeyer> c_lopez: oh, maybe I can help? 04:59:25 <springmeyer> http://dpaste.com your stylesheet? 04:59:50 <c_lopez> let me look for it 05:00:16 <springmeyer> c_lopez: I think playing around with rendering Maps is the right approach for you now, you've done great research so learning the tools will certainly help re-inforce learning 05:02:12 <c_lopez> I was reading about raster symbolizers, because I thought that was what needed to be scaled in the project, so I tried this style: http://trac.mapnik.org/wiki/RasterSymbolizer, combined with word_borders from the beginner's tutorial, but python rejected the tiff file. Let me paste the complete stylesheet, maybe I did a mistake 05:03:04 <springmeyer> sure, please paste 05:04:55 <nikq> Mapnik Trac: GSOC2010/Ideas edited | http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=23 05:05:10 <springmeyer> c_lopez: I think you may be confusing 'raster symbols' vs. 'raster datasources' 05:05:28 <springmeyer> both are pixels image, like a photo 05:05:49 <c_lopez> here's what I tried: http://dpaste.com/180743/ 05:05:51 <springmeyer> it is the former that we've really been discussing as needing attention 05:06:34 <springmeyer> c_lopez: okay, looks descent 05:06:48 <springmeyer> c_lopez: do you have the GDAL/OGR utilities installed? 05:06:50 <c_lopez> let me give you the output from python 05:07:10 <springmeyer> e.g gdalinfo, ogr2ogr, etc ? 05:07:50 <springmeyer> you likely have GDAL installed as (optional) dependency of mapnik... 05:08:18 <springmeyer> if so you should use GDAL to figure out the projection of that .tiff file 05:08:21 <springmeyer> gdalinfo /home/carlos/Documents/Projects/python/mapnik/mapnik-0.7.1/mapnik-osm-stuff/world_borders_xml_raster/beach.tiff 05:08:40 <springmeyer> http://dpaste.com the result 05:09:23 <c_lopez> it seems that I don't have it installed. 05:09:41 <c_lopez> but it suggest me to install gdal-bin 05:09:45 <springmeyer> I recommend installing GDAL, very useful 05:09:57 <springmeyer> yes, thats the 'utilities' I mentioned, perfect 05:11:03 <c_lopez> ok it's being installed now. So what I'm trying to pull is raster datasource? 05:11:49 <springmeyer> yes, based on that XML 05:12:00 <springmeyer> I encourage you to get it working either way :) 05:12:27 <c_lopez> here's the output of gdalinfo: http://dpaste.com/180746/ 05:12:54 <springmeyer> okay, interesting 05:13:11 <springmeyer> so that .tiff does not have a geographic reference system... 05:13:29 <springmeyer> which makes it hard to use as a test dataset 05:14:09 <c_lopez> oh I'm using a wrong file then. 05:14:45 <c_lopez> I read about geotiff, is that what I'm supposed to use? 05:15:19 <springmeyer> yes, that is easier 05:15:34 <springmeyer> you can read any kind of raster as a base datasource 05:15:50 <springmeyer> but a geotiff has info about how the pixels match real world coordinates 05:15:58 <springmeyer> which makes a geotiff much easier to use as map data 05:18:26 <c_lopez> ok, then let me read about gdal, I hadn't heard of it before. 05:18:50 *** waldemarq (~waldemarq@189.161.100.110) has joined #mapnik 05:18:53 <c_lopez> about your comments to my proposal, you say "The trick is that certain objects need to be scaled BEFORE being painted onto raster surfaces" 05:19:00 <springmeyer> c_lopez: great, I also recommend installing QuantumGIS 05:19:11 <springmeyer> which will allow you to view data easiely 05:19:34 <springmeyer> c_lopez: yes, what I mean by that is... 05:19:35 <c_lopez> thanks for the recommendation :) 05:19:56 <springmeyer> if you are using the agg_renderer.cpp to output say, PNG image 05:20:22 <springmeyer> a scale_factor is applied to line width, fonts, etc during the render time ("painting") 05:20:59 <springmeyer> because of course, once the map is turned into a PNG, changing the size will just result in poor looking quality 05:21:07 <springmeyer> like with townguide... 05:22:29 <c_lopez> right, I was thinking about scaling them after being rendered, I have to correct that. 05:23:25 <springmeyer> yes, perfect 05:23:39 <c_lopez> ticket #259 mentions something about scaling rasters, but it's inside the context of hill shading, is this related in any sense? 05:23:40 <nikq> Ticket #259: Hill Shading support, http://trac.mapnik.org/ticket/259 05:23:53 <springmeyer> c_lopez: not really 05:25:06 <springmeyer> mostly I think you'll be concerned with raster symbols 05:25:18 <springmeyer> like map icons 05:25:50 <springmeyer> but, I still recommend installing gdal (which is used to read raster datasources) 05:26:07 <c_lopez> are they the same as the 'raster symbolizers' involved in that style I showed to you? 05:27:15 <c_lopez> I mean the raster symbols 05:27:18 <springmeyer> yes, the terminolgy is confusing! 05:27:45 <springmeyer> 'raster symbolizers' control how 'raster datasources' are displayed 05:28:13 <springmeyer> both are different than symbols/map icons 05:28:53 <springmeyer> symbols/map icons are currently placed on the map with either 05:29:01 <springmeyer> `PointSymbolizer 05:29:01 <nikq> http://trac.mapnik.org/wiki/PointSymbolizer 05:29:05 <springmeyer> or 05:29:07 <springmeyer> the 05:29:11 <springmeyer> `ShieldSymbolizer 05:29:11 <nikq> http://trac.mapnik.org/wiki/ShieldSymbolizer 05:29:23 <springmeyer> but really just the PointSymbolizer... 05:29:47 <springmeyer> but, to follow through on the 'raster datasources', try somemore more like: 05:29:48 <springmeyer> http://dpaste.com/180748/ 05:30:17 <springmeyer> there is also a sample XML + geotiff here: 05:30:18 <springmeyer> http://mapnik-utils.googlecode.com/svn/example_code/gdal/ 05:30:20 <c_lopez> symbolizers are used to build other complex elements, right? like, for example, a polygon symbolizer to display a lake. 05:30:28 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 05:30:33 *** waldemarq has quit (Ping timeout: 276 seconds) 05:30:45 <springmeyer> c_lopez: yes, exactly 05:31:08 *** Genscher (~daniel@dslb-188-099-088-153.pools.arcor-ip.net) has joined #mapnik 05:31:10 <springmeyer> 'symbolizers' are different than 'symbols' 05:31:29 <springmeyer> us mapping people have confusing terms I admit ;) 05:31:48 <c_lopez> oh, what are symbols then? 05:31:51 <springmeyer> so ya, 'symbolizers' are use to apply some style to data 05:32:16 <springmeyer> and 'symbols' are a common cartography term for map icons 05:33:24 <springmeyer> aka as 'markers, placemarks, etc': 05:33:25 <springmeyer> http://code.google.com/p/google-maps-icons/ 05:34:19 <c_lopez> do you recommend some kind of website or book to get acquainted with the terms? I've been reading 'Web mapping' in google books, but it is mainly about open source tools, rather than cartography 05:34:29 <c_lopez> oh thanks that may be useful 05:35:19 <springmeyer> yes: http://pragprog.com/titles/sdgis/gis-for-web-developers 05:35:38 <c_lopez> wow! thanks 05:36:30 <c_lopez> so the scaling bit of the project is really about these symbols? 05:36:32 *** nikq has quit (Ping timeout: 276 seconds) 05:36:57 *** nikq (~nikq@li21-121.members.linode.com) has joined #mapnik 05:38:22 <springmeyer> c_lopez: also potentally a general resource: http://linfiniti.com/dla/ 05:39:20 <springmeyer> c_lopez: the scaling bit is about: fonts, line widths, scale_demoninator, and symbols 05:40:01 <springmeyer> the symbols piece I recommend you understand, but in reality it is only proper solved by adding support for "SVG symbols" 05:40:34 <springmeyer> so, the ability to read not pixel-based symbols but svg-based symbols that can be scaled properly 05:40:57 <springmeyer> again, it is not hard to scale pixel-based or raster images, it is just likely they will get blurry depending on the original size 05:42:11 <springmeyer> c_lopez: here is a very simple example you can play with that loads in a raster symbol (of fixed pixel dimensions): 05:42:11 <springmeyer> http://mapnik-utils.googlecode.com/svn/sandbox/testing/point_opacity/ 05:42:14 <c_lopez> are raster symbols generated from image files? 05:42:32 <springmeyer> raster symbols == image files 05:42:49 <springmeyer> in most cases they are actually generated from SVG files 05:43:39 *** waldemarq (~waldemarq@189.161.179.63) has joined #mapnik 05:44:32 <c_lopez> ok, I should try some examples first as you say 05:45:51 <springmeyer> yes, sounds good 05:46:03 <springmeyer> I recommend trying many of the examples in: http://mapnik-utils.googlecode.com/svn/example_code/ 05:46:46 <springmeyer> a few may have broken paths to data, but most data can be found in: http://mapnik-utils.googlecode.com/svn/data/ 05:53:13 <c_lopez> just a final question: I mentioned that the interface for specifying the resolution is going to receive some kind of parameter (like you do in ticket 343), but affect things differentyl: fonts, for example, should be scaled differently than other elements. does that description makes sense? 05:53:31 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik 05:54:08 <springmeyer> c_lopez: yes, my though is the same 05:54:24 <springmeyer> that perhaps fonts, for example, will need different scaling 05:54:33 <springmeyer> this is where Tom Carden can help 05:54:49 <springmeyer> you can implement different options for him to test for example 05:55:14 *** HounD has quit (Ping timeout: 240 seconds) 05:55:27 <springmeyer> His goal is to be able to use the same stylesheet for both web output and print, so this can be tested once you start coding 05:56:23 <c_lopez> yes that's what the ideas' page says, but I hadn't understood it. 05:56:47 <springmeyer> oh, okay 05:57:05 <springmeyer> well your description sounds good. do you feel like you understand better know? or still have questions? 05:58:31 <c_lopez> I feel like I described things very abstractly, I certainly need to look deeper at the code, but I need to try those examples before asking anything else 05:59:17 <springmeyer> :) okay 06:00:03 <c_lopez> thank you for your time Mr Springmeyer 06:00:18 <springmeyer> you are welcome c_lopez - have a good night 06:02:08 <c_lopez> you too :) 06:02:23 <springmeyer> thanks :) 06:36:07 *** Genscher has quit (Quit: Verlassend) 06:37:47 *** Genscher (~daniel@dslb-188-099-088-153.pools.arcor-ip.net) has joined #mapnik 06:57:47 *** gavinf has quit (Quit: gavinf) 06:58:15 *** gavinf (~gavinf@196.211.119.210) has joined #mapnik 07:33:37 *** c_lopez has parted #mapnik (None) 07:50:22 *** waldemarq has quit (Quit: ããããªã) 07:54:02 *** jfreeman has quit (Read error: Connection reset by peer) 07:56:01 *** c_lopez (~ccaarloos@189.169.32.250) has joined #mapnik 08:15:01 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 08:24:24 <c_lopez> hello Mr. Pavlenko. 08:31:22 <artem> c_lopez: hi there! 08:31:43 <artem> c_lopez: I'm reading through your proposal, it's looking good 08:33:02 <artem> c_lopez: there are couple extra points I'd like to add I'll email them to you asap 08:33:25 <c_lopez> thanks! I still need to define the timeline, incorporate the comments of Mr Springemeyer and add some detail 08:34:06 <artem> c_lopez: sounds good. Are you planning to submit your proposal today ? I think there is a deadline ? 08:35:43 <artem> c_lopez: btw, are you developing on linux,mac or win? 08:37:08 <c_lopez> in linux, I have ubuntu 9.10 08:37:46 <c_lopez> yes, I'll submit it today, I think the deadline is tomorrow, april 9 08:38:47 <artem> c_lopez: great! 08:44:06 <c_lopez> I have to correct the part about scaling symbols, Mr Springmeyer explained me some things earlier today that made me realize that I wrote that part incorrectly. 08:45:23 <artem> c_lopez: yes, I saw that email 08:46:48 <artem> I think your proposal overall looks great, let me write quick email to you 08:47:23 <artem> good research, also 08:48:40 <c_lopez> thanks 08:49:15 <c_lopez> :) 09:21:48 *** c_lopez has parted #mapnik (None) 10:33:52 *** gavinf has quit (Read error: Connection reset by peer) 10:40:38 *** gavinf (~gavinf@196.211.2.133) has joined #mapnik 11:32:28 *** rweait has quit (Ping timeout: 265 seconds) 11:47:26 *** rweait (~nerd@weait.tor.istop.com) has joined #mapnik 11:52:41 *** artem has quit (Quit: artem) 11:53:35 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 11:55:15 *** artem has quit (Client Quit) 11:59:39 *** agimenez (~agimenez@200.10.228.31) has joined #mapnik 12:05:53 *** HounD1 has quit (Ping timeout: 276 seconds) 12:31:33 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 13:10:24 *** artem has quit (Quit: artem) 13:13:12 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 13:15:38 *** chad_burt has quit (Quit: Leaving...) 13:15:45 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik 13:27:07 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 13:29:06 *** wonderchook has quit (Remote host closed the connection) 13:57:30 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik 14:39:08 *** wonderchook (~wondercho@209.155.228.129) has joined #mapnik 14:52:47 *** tephe (~tephe@95.77.216.153) has joined #mapnik 14:59:23 *** tephe has quit (Quit: leaving) 15:21:19 *** Genscher has quit (Quit: Verlassend) 15:34:50 *** artem has quit (Quit: artem) 15:48:58 *** mishok13 has quit (Read error: Connection reset by peer) 15:51:37 *** rweait has quit (Ping timeout: 248 seconds) 15:52:03 *** rweait (~nerd@weait.tor.istop.com) has joined #mapnik 16:06:23 *** jctull has quit (Quit: jctull) 16:07:47 *** racicot has quit (Read error: Connection reset by peer) 16:11:16 *** racicot (~chatzilla@dsl-66-228-218-217.dsl.fibercloud.net) has joined #mapnik 16:25:14 *** cgs_bob has quit (Ping timeout: 240 seconds) 16:37:25 *** Herm (~r2d2@77-23-156-226-dynip.superkabel.de) has joined #mapnik 16:47:46 *** springmeyer has quit (Read error: Connection reset by peer) 16:48:07 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 16:48:52 *** springmeyer has quit (Read error: Connection reset by peer) 16:48:57 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 16:51:46 *** racicot has quit (Ping timeout: 245 seconds) 16:54:56 *** jctull (~jctull@75.0.29.113) has joined #mapnik 16:58:11 *** tcarobruce (~tim@c-98-210-194-147.hsd1.ca.comcast.net) has joined #mapnik 17:10:06 *** luneff (~yury@93.178.93.11) has joined #mapnik 17:17:26 *** rweait has quit (Quit: Leaving.) 17:22:08 *** wonderchook has quit (Read error: Connection reset by peer) 17:22:22 *** wonderchook (~wondercho@209.155.228.129) has joined #mapnik 17:22:51 *** ajturner_ (~ajturner@209.155.228.129) has joined #mapnik 17:23:58 *** ajturner has quit (Ping timeout: 268 seconds) 17:23:58 *** ajturner_ is now known as ajturner 17:36:10 *** cgs_bob (~bob@13.sub-75-210-142.myvzw.com) has joined #mapnik 17:39:57 *** mishok13 (~gdmfsob@smtp-kyiv.cogniance.com) has joined #mapnik 17:44:55 *** Genscher (~daniel@dslb-188-099-088-153.pools.arcor-ip.net) has joined #mapnik 17:48:13 *** ajturner has quit (Quit: ajturner) 17:50:02 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 17:52:51 *** artem has quit (Client Quit) 18:07:50 *** StormTide has quit (Read error: Connection reset by peer) 18:07:53 *** agimenez has parted #mapnik (None) 18:08:31 *** StormTide (~StormTide@2002:186c:64c0:0:21d:60ff:fe5e:cf66) has joined #mapnik 18:23:13 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 18:30:32 <artem> springmeyer: ping 18:30:53 <springmeyer> artem: pong 18:30:59 <artem> :) 18:31:02 <springmeyer> hey there 18:33:49 <artem> I'd like to get rid of <CssParameter> thingy and just use attributes e.g 18:34:01 <artem> <LineSymbolizer stroke-width="2" /> 18:35:04 * artem was reading svg spec 18:35:31 <springmeyer> ah, interesting 18:35:41 <springmeyer> yes, I wondered about the same thing when... 18:35:53 <artem> anyone got strong feelings? would like to defend OGC ? 18:35:57 <springmeyer> I was thinking about where to put line 'offset' parameter 18:36:23 <artem> I got offset parameter already as an attributes :P 18:36:35 <springmeyer> he he, nice 18:36:44 <artem> stroke-dashoffset="123" 18:37:27 <springmeyer> it noticed when I realized that *PatternSymbolizer does not use CSSParameters, etc 18:37:37 <springmeyer> artem: my feeling is that we've already moved reasonable far from SLD/Symbol Encoding Spec 18:38:16 <springmeyer> that the best way to handle compatibility is external translator 18:38:54 <artem> yes, CSSParameters don't make much sense. 18:39:25 *** jbronn has quit (Remote host closed the connection) 18:40:58 <springmeyer> artem: yes, they sure are verbose. 18:42:22 <artem> Also, geometries - what we really deal in Mapnik are "paths" - sequence of x,y,command tuples. As in SVG not geometries as in GIS, so we can: 18:42:51 <artem> 1. read geometries from data sources into paths 18:42:55 <artem> or 18:43:06 *** chad_burt has quit (Quit: Leaving...) 18:43:30 <springmeyer> re: changing XML/compatibility: have you seen the script I started here: http://trac.mapnik.org/wiki/Mapnik2#Compatibility ? 18:43:44 <artem> have proper OGC compliant geometry model and provide path_adapters 18:44:19 <artem> springmeyer: Yes I did and I'll update it to deal with new style 18:44:37 <springmeyer> maybe we could improve that and add that to python bindings as a 'old' mapnik compatibility load_map or something? 18:44:50 *** jbronn (~jbronn@70-138-113-15.lightspeed.hstntx.sbcglobal.net) has joined #mapnik 18:44:50 * springmeyer would need to remove lxml dependency, but thats not hard... 18:45:26 <springmeyer> artem: okay. I like the idea of refactoring and honing mapnik2 as the same time as offering a way to "upgrade" 18:46:04 <springmeyer> artem: re: storing as paths. are you thinking that would be faster/more flexible? 18:46:35 <artem> we could, but providing a update-to-future.py script seems better approach. After all new syntax will so much better that nobody will look back :) 18:46:45 <artem> will be 18:47:15 <springmeyer> okay, that makes sense 18:47:37 <springmeyer> to a script to make it easy to upgrade existing xml... (rather that keep on using it) 18:47:43 <springmeyer> sure 18:47:48 <springmeyer> to/so 18:47:54 <artem> yep 18:48:00 <springmeyer> k 18:49:08 <springmeyer> artem: re: paths vs. geometry... 18:49:11 <springmeyer> we also talked about potentially moving to using Boost.Geometry for geometry objects... 18:49:20 <artem> ok, I'll try to commit something tonight to get ball rolling 18:49:36 <springmeyer> seems that could be cool, to allow for more geometry ops in syles 18:49:53 <springmeyer> so would move to paths represent a different direction? 18:50:24 <springmeyer> re: ball rolling - sounds good :) 18:50:31 <artem> Yes, indeed. I had a little play with ggl and it looks flexible enough for adapting external data structures 18:52:04 <artem> I just not entirely convinced that spatial processing should be glued to styling ?? I'd like to discuss this in great detail 18:53:51 <springmeyer> certainly. I'm not there either, just have in the back of my mind 18:55:38 <artem> There are lots of inertia from paleo-ogc way of thinking, mapnik2 is a great chance to move forward 18:56:52 * springmeyer raises glass to that :) 18:57:22 <artem> I see even geoserver paleotards are moving towards _web_ standards like CSS - must be right then 18:58:02 * artem thinks it is a bit early for springmeyer to have a drink ;) 18:58:20 <artem> springmeyer: cheers! 18:58:23 <springmeyer> he he 18:58:33 <springmeyer> yes, but cheers nevertheless! 18:59:05 <springmeyer> artem: regarding move to css 18:59:20 <springmeyer> I will likely be freeing some time in the coming months to work on cascadenik a bit 19:00:12 <springmeyer> on my mind are: finishing the "XML bad" which using mapnik python bindings to build up objects 19:00:17 <artem> springmeyer: cool, I'd like to give a cascadnik a thorough look and see if we can learn and improve mapnik core from it 19:00:28 <springmeyer> and the serializes to XML using mapnik.save_map() 19:00:39 <springmeyer> rather than writing XML itself 19:00:57 <springmeyer> which will be nice approach to maintain compatibility, etc 19:01:34 <springmeyer> also thinking about integrating test suite a bit to keep mapnik symbolizers properties in line with cascadenik 19:02:06 <springmeyer> so, yes I too will be thinking about css informing learning 19:03:28 <artem> well, we could go further and question the whole xml malarky. why xml ? json ? 19:03:56 * artem feels like pushing boundaries :D a bit 19:04:09 <springmeyer> artem: certainly 19:04:13 <springmeyer> did you see http://trac.mapnik.org/wiki/Ideas/FutureMapnik ? 19:04:22 <springmeyer> "Not Just XML" section =) 19:04:55 <artem> exactly ! 19:05:07 * springmeyer raises another glass :) 19:05:34 <artem> :) 19:06:41 <artem> json would be easy 19:09:12 <springmeyer> artem: what do you think about each C++ class having methods to load/serialize itself? 19:10:28 <springmeyer> I figure it would allow us to more easily build up not just a Map from XML (load_map), but say just a set of styles, rules, or symbolizers from chunks of xml/json.. 19:11:36 *** rweait (~nerd@weait.tor.istop.com) has joined #mapnik 19:11:39 <artem> yes, sure, but it's better to decouple serialisation from the data, so yes we should add methods similar to operator<< 19:12:28 <artem> boost::serialization lib has got some ideas !! 19:12:39 <springmeyer> ah ha, okay 19:12:43 <springmeyer> I'll need to read up 19:13:32 <springmeyer> I'm not sure about impl of course 19:13:43 <springmeyer> but dream of being able to do something like 19:14:06 <springmeyer> sty = Style.from_json('json_string') 19:14:11 <springmeyer> etc 19:14:16 <artem> no worries, we figure it out:) 19:14:20 <springmeyer> :) 19:15:15 <artem> My main design concern at the moment is : 19:15:30 <artem> data -> ogc geometry -> path or 19:15:34 <artem> data -> path 19:15:47 * springmeyer nods 19:15:52 <artem> plus geometry -> path 19:18:43 <artem> I think I'll update mapnik2 to work with paths (including curves!) = easy and we can look into the best way to integrate with boost::geometry 19:19:17 <Ldp__> keep it coming! 19:20:17 <springmeyer> :) 19:21:41 <artem> Ldp__: I lost it :) LOL 19:25:55 <artem> springmeyer: I realised I sent rather confusing remarks to Carlos regarding scaling/resolutions. I wonder how do you see this working with multiple rules (which can for example different stroke-width attributes) ? 19:26:11 <artem> can have 19:26:22 *** rweait has quit (Quit: Leaving.) 19:28:26 <artem> also, I'm in favour of preserving current logic as an option. 19:29:13 <springmeyer> yes, certainly I think current behavior should be default 19:29:38 <springmeyer> then an attempt should be made to allow a global scale factor to be applied to fonts,stroke-width, etc 19:30:02 <artem> with Min/Max scale denominators we have cut off points - should we attempt to interpolate values in between for example? 19:30:09 <springmeyer> and after that, I figure he can experiment, and get feedback from Tom Carden (who is very sharp with this) 19:30:41 <artem> ok, global scale factor sounds good 19:30:57 <springmeyer> artem: yes, something will need to be done around min/max scale factors, but that is beyond my research into it 19:31:28 <springmeyer> I think the question for us is whether scale_factor should be applied at render time in agg_renderer.cpp and cairo* 19:31:40 <springmeyer> or when objects are created 19:32:25 <artem> i would say at rendering time for sure 19:32:44 *** wonderchook has quit (Remote host closed the connection) 19:33:08 <springmeyer> yes 19:33:18 *** wonderchook (~wondercho@209.155.228.129) has joined #mapnik 19:34:27 * springmeyer just not sure where yet to support conversion from variable units -> px 19:34:32 <artem> ah, do you mean symbolisers ? well, we need some internal units I think 19:34:39 <artem> units we trust:) 19:35:17 <springmeyer> yes, for symbolizers 19:35:36 <artem> I guess this all could form Carlos's r&d 19:36:11 * artem think we should support non-square pixels 19:38:12 <springmeyer> ya, I remember this conversation :) 19:38:13 <springmeyer> http://trac.mapnik.org/ticket/196 19:38:33 <springmeyer> I'm not sure how that would work, can you say more? 19:39:22 * artem thinks springmeyer has extraordinary memory 19:39:43 <springmeyer> lol 19:40:26 <artem> computer-aided, /me thinks 19:40:40 <springmeyer> secret!!! 19:40:41 <artem> #196 yes, sure we can 19:40:42 <nikq> Ticket #196: Support dynamic pixels, http://trac.mapnik.org/ticket/196 19:42:39 <artem> right, we need to read lots of specs to make intelligent decisions. I'm off to get kids to bed and I'll pop in later on 19:43:02 <springmeyer> right on, enjoy 19:43:10 <artem> he he 19:47:18 *** artem has parted #mapnik (None) 19:48:41 *** waldemarq (~c824f804@gateway/web/freenode/x-gpvtrjrhprtbzpuy) has joined #mapnik 19:49:15 <waldemarq> hi everyone 19:55:48 *** waldemarq has quit (Ping timeout: 248 seconds) 19:56:18 *** racicot (~chatzilla@dsl-66-228-218-217.dsl.fibercloud.net) has joined #mapnik 19:56:57 *** racicot has quit (Changing host) 19:56:57 *** racicot (~chatzilla@osgeo/member/racicot) has joined #mapnik 20:16:56 *** springmeyer has quit (Quit: springmeyer) 20:40:57 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 20:51:26 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik 21:08:30 *** Genscher has quit (Quit: Verlassend) 21:08:51 *** gavinf has quit (Ping timeout: 245 seconds) 21:12:40 *** artem has quit (Quit: artem) 21:18:26 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 21:31:30 *** waldemarq (~c824f804@gateway/web/freenode/x-wgukwtqwrpsilnoe) has joined #mapnik 21:33:50 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik 21:34:11 *** bitterman (~yury@93.178.79.189) has joined #mapnik 21:37:01 *** luneff has quit (Ping timeout: 246 seconds) 21:45:07 *** darth_bitterman (~yury@93.178.79.189) has joined #mapnik 21:46:09 <CIA-70> mapnik-utils: dane.springmeyer * r918 /trunk/serverside/cascadenik/ (4 files in 2 dirs): put docs and command line scripts in sync - closes #33 21:46:10 <nikq> Ticket #33: The mapnik build system doesn't check for the python lib directory, http://trac.mapnik.org/ticket/33 21:48:59 *** bitterman has quit (Ping timeout: 260 seconds) 22:05:28 *** artem has quit (Quit: artem) 22:24:10 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 22:24:10 *** mperry has quit (Read error: Connection reset by peer) 22:24:11 *** mperry_ is now known as mperry 23:06:47 *** gavinf (~gavinf@196.212.72.157) has joined #mapnik 23:12:11 *** ajturner has quit (Quit: ajturner) 23:29:08 *** waldemarq has quit (Ping timeout: 248 seconds) 23:32:40 *** gkmngrgn has parted #mapnik ("Konversation terminated!") 23:35:10 *** waldemarq (~c824f804@gateway/web/freenode/x-zjtwrhjxdmsijyed) has joined #mapnik 23:46:14 *** wonderchook has quit (Remote host closed the connection)