00:04:51 *** ajturner has quit (Quit: ajturner) 00:32:59 *** ajturner (~ajturner@pool-72-66-109-70.washdc.fios.verizon.net) has joined #mapnik 00:33:20 *** ajturner has quit (Client Quit) 00:33:58 *** cgs_bob has quit (Ping timeout: 264 seconds) 01:00:34 *** jfreeman (~jfreeman@203.217.61.147) has joined #mapnik 01:08:29 *** wonderchook (~wondercho@pool-71-127-43-16.washdc.fios.verizon.net) has joined #mapnik 01:12:25 <acwest> At least I found the term was looking for, generalization 01:15:30 <acwest> So does Mapnik do any type of vector generalization before it does it's rendering? 01:16:01 <Ldp> it does what it's given 01:18:14 <acwest> I'm looking for a way to reduce a vector dataset based on scale without rendering it to tiles. It seems more efficient to store maps as vectors, but I don't have room on my phone for the entire planet.osm. I would prefer not limiting it to an all or nothing system, but instead store more generalized global data with specific areas stored with higher detail 01:19:29 <acwest> somehow, Mapnik decides what details to render at different zoom levels, and whatever it is doing, it appears to work well 01:19:44 <Ldp> as the OSM db is littered with non-interesting information for a renderer, keeping all of it on a device which only intends to render, is unnecessary 01:20:21 <Ldp> the decision when to render something is separate from how to render it 01:23:16 *** chad_burt has quit (Quit: Leaving...) 01:23:35 <acwest> I think we are agreeing, in principle... I went to separate those two decisions, make the when to render decision at map 'creation' time, and the how to render at map viewing time 01:25:17 <Ldp> in your case, the 'creation' part would be to extract only the information you're interested in from the planet.osm, transforming that into a format that's both fast and small (a challenge in itself) for your mobile device, and then rendering from that the moment someone wants to look at the map 01:25:29 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 01:28:18 <acwest> Indeed, that is what I was thinking. In my case, I really don't need zoom level 16 for everywhere, and it seems likely that a significant reduction could be had by not storing detail that would not be visible at lower zoom levels 01:29:52 <acwest> I believe navit, for example, has a tool for converting osm data to a smaller, faster format, but I don't believe it does any generalization 01:32:46 *** cgs_bob has quit (Remote host closed the connection) 01:32:47 <Ldp> zoom levels are irrelevant for vector data 01:33:00 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik 01:33:50 <Ldp> and during the extration process from planet.osm to your format, you could easily simplify ways to find a balance between usability and it still looking like a good representation of that road 01:34:01 <acwest> Not really. if at a particular zoom level, multiple points are indistinguishable from each other, the points could be removed from the dataset. 01:34:34 <Ldp> if you cull them from the dataset, you cannot get them to render at *any* zoom level :) 01:35:13 <springmeyer> acwest: are you actually using Mapnik or just looking for ideas? 01:35:36 <Ldp> hi springmeyer, can you take it from here? need sleep ;) 01:35:53 <springmeyer> Ldp: good night 01:36:00 *** Ldp has quit () 01:36:01 <springmeyer> hope you are well! 01:36:04 <acwest> Looking for ideas, but right now Mapnik seems to be doing a good job of choosing what to render at various zoom levels 01:36:55 <springmeyer> acwest: sure, but choosing what features to render is different than geometry simplification 01:37:04 *** tcarobruce has quit (Quit: tcarobruce) 01:37:44 <acwest> they are different, but both are useful as ways to reduce a datasets space usage 01:39:22 <acwest> from what I have seen, though, mapnik seems to do both 01:39:34 <springmeyer> well removing features to reduce the actual size of the source dataset is not handled by Mapnik 01:39:56 <springmeyer> that would be done pre-Mapnik 01:40:35 <springmeyer> Mapnik just allows you to filter features by scale (aka zoom) at render time 01:40:43 <acwest> Mapnik must have some type of program logic for doing it, though. I am trying to find it 01:41:03 <springmeyer> Mapnik never manipulates source data, only queries and filters it 01:41:50 <springmeyer> osm2pgsql would be the tool osm users traditionally use to filter the .osm data before rendering 01:42:22 <springmeyer> but certainly even after it is in a database you can use SQL to remove stuff 01:43:11 <acwest> certainly, but that is only really useful fro removing categories of data. I want to filter it using the exact same algorithm Mapnik uses 01:43:23 <acwest> I just don't know what that is 01:44:17 <springmeyer> that only makes sense if you want to create different dumps of data to pass to your renderer at each zoom level 01:44:20 <acwest> I suspect it would be excessively non-trivial to add a vector output to mapnik :-) 01:44:34 <springmeyer> which would likely add up to more cumulative space that just using the original data 01:45:03 <springmeyer> acwest: what do you mean by vector output exactly? 01:46:06 <acwest> in the simplest case, outputting osm data, but only those elements that would be visible if they were rendered 01:48:27 <acwest> for example,planet.osm is about 13 GB of data. If you remove all of the data that is irrelevant to rendering, you can reduce that significantly without losing any detail 01:49:50 <acwest> but if, for example, you decide that you are not traveling to North America in the forseeable future, you might decide to only store data which is visible at zoom level 9 for North America, but zoom level 14 for Europe 01:50:17 <acwest> this should reduce the dataset, but still allow at least some use of the database everywhere 01:50:50 <acwest> right now, any map software I have seen which uses vector storage uses an all or nothing approach to filtering 01:52:04 <springmeyer> what data is visibly rendered at each zoom level is a subjective decision based on cartography 01:52:19 *** agimenez (~agimenez@186.16.50.54) has joined #mapnik 01:53:44 <acwest> How does mapnik currently decide? 01:53:58 <springmeyer> Mapnik does not decide 01:54:07 <springmeyer> the user writing the "stylesheet" decides 01:54:38 <StormTide> pretty sure some stuff can be set to use data from the map too (ie visible at scale x) 01:54:41 <springmeyer> which contains the logic to pull certain data for "layers" which are then rendered using "styles" which can include further filtering 01:56:27 <springmeyer> acwest: in the case of the OSM tiles you might be familiar with, it is an enormous XML file which is sent to mapnik that "decides" both how things look (color, line widths, etc) 01:56:39 <springmeyer> and at which zoom level how and which things should get displayed: 01:56:40 <springmeyer> http://svn.openstreetmap.org/applications/rendering/mapnik/osm.xml 01:57:37 <acwest> Hmmm, I think this is the key bit of information that I was missing. So that xml file essentially contains the logic for zoom level filtering... 01:58:22 <springmeyer> yes, in the case of that stylesheet 01:58:34 <springmeyer> MinScaleDenominator and MaxScaleDenominator 01:58:37 <springmeyer> are used 01:58:50 <springmeyer> to bracket which features should be rendered by zoom level 01:59:37 <springmeyer> it may be confusing in the case of that file because the actual XML that Mapnik needs is pulled in via XML entities from here: 01:59:37 <springmeyer> http://svn.openstreetmap.org/applications/rendering/mapnik/inc/entities.xml.inc 01:59:55 <springmeyer> e.g. http://trac.mapnik.org/wiki/MaxScaleDenominator 02:03:08 <acwest> I noticed that. Does that osm.xml get used for the whole osm dataset? You seem to imply mutliple style sheets 02:04:06 <springmeyer> yes osm.xml is the single stylesheet 02:04:22 <springmeyer> but when it is read other pieces are pulled into it... 02:05:22 <acwest> So this turns my problem into an exercise in xslt programming, potentially... 02:07:06 <acwest> I still like the idea of adding vector format support to mapnik, though 02:10:04 <springmeyer> acwest: Mapnik supports rendering to styled svg and pdf 02:10:29 <springmeyer> and support for a custom svg renderer is being discussed 02:11:09 <acwest> that definitely gives me a place to look, at least 02:11:12 <springmeyer> acwest: that XML contains no data, it is just logic 02:11:28 * springmeyer steps out of a while 02:11:37 <acwest> Logic is what I need, planet.osm contains all the data I cneed :-) 02:12:03 <springmeyer> agimenez: I see your mailing to dev. we should talk more tonight or tomorrow! 02:12:08 * springmeyer heads out 02:12:32 <acwest> thanks, springmeyer. You have put me on a track. We shall see if it is the right one :-) 02:16:04 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 02:23:04 <agimenez> Ok 03:47:27 <dkb> Hello. I was wondering if there would be any disadvantage in having the "coast-poly" layer represented as a tiff instead of shapefile? 04:23:18 *** wonderchook has quit (Remote host closed the connection) 04:27:14 *** agimenez has quit (Ping timeout: 240 seconds) 04:37:36 *** dkb has quit (Quit: Leaving.) 05:16:02 *** mperry has quit (Quit: mperry) 05:31:34 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 05:31:51 *** luneff (~yury@93.178.79.83) has joined #mapnik 05:45:08 *** gavinf (~gavinf@196.211.2.133) has joined #mapnik 06:46:16 *** luneff has quit (Quit: Leaving) 07:10:09 *** Genscher (~daniel@dslb-188-098-010-212.pools.arcor-ip.net) has joined #mapnik 07:28:09 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik 07:28:17 *** Ldp__ is now known as Ldp 07:38:39 *** jfreeman has quit (Remote host closed the connection) 08:41:58 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 08:44:08 <artem> good morning, where can I download SVG made with osmarender ? I need it for testing 08:48:02 <artem> ha ha wrong channel 09:21:03 *** kredik (~chatzilla@LLagny-156-35-42-212.w80-13.abo.wanadoo.fr) has joined #mapnik 09:24:37 *** jburgess has quit (Ping timeout: 264 seconds) 09:44:38 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 09:48:38 *** artem has quit (Quit: artem) 09:53:32 *** mperry has quit (Quit: mperry) 09:58:38 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 10:00:34 *** artem has quit (Client Quit) 10:01:55 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 10:01:56 *** dkb has quit (Client Quit) 10:01:58 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik 10:02:26 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 10:09:47 *** artem has quit (Quit: artem) 10:11:49 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 10:21:01 *** HounD has quit (Ping timeout: 264 seconds) 10:30:00 *** artem has quit (Quit: artem) 10:33:16 *** agimenez (~agimenez@186.16.223.71) has joined #mapnik 10:35:08 *** gavinf has quit (Read error: Connection reset by peer) 11:59:58 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 12:15:15 *** artem has quit (Quit: artem) 12:16:08 *** dkb has parted #mapnik (None) 12:33:37 *** gavinf (~gavinf@196.211.119.210) has joined #mapnik 12:34:08 *** acwest has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100318140931]) 12:45:29 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 12:46:11 *** tmcw (~Adium@c-98-218-226-144.hsd1.dc.comcast.net) has joined #mapnik 12:51:38 *** Genscher has quit (Quit: Verlassend) 12:58:26 *** Genscher (~daniel@dslb-188-098-010-212.pools.arcor-ip.net) has joined #mapnik 13:13:31 *** Genscher has quit (Quit: Verlassend) 13:21:10 *** Genscher (~daniel@dslb-188-098-010-212.pools.arcor-ip.net) has joined #mapnik 13:21:21 *** shann (~7ab5a282@gateway/web/freenode/x-xdwygqzyumyczplu) has joined #mapnik 13:21:29 <shann> hi all 13:21:56 <shann> i always end with mapnik not finding the boost regex libs 13:22:11 <shann> i tried the wiki page but could not proceed further 13:22:16 <rweait> shann: distro? 13:22:16 <artem> hi shann 13:22:22 <shann> how to resolve the errors 13:22:26 <shann> hi artem 13:22:34 <shann> centos 5 32 bit 13:22:47 <shann> to be exact centos 5.4 32 bit 13:23:35 <artem> shann: i assume you have boost_regex installed, right ? 13:23:45 <artem> shann: are you building from trunk ? ? 13:24:08 <shann> yes i guess how to check? 13:24:31 <artem> well, how did you installed boost in the first place ? 13:24:45 <artem> rweait: hi there! 13:25:04 <rweait> Morning artem! 13:25:27 <artem> more like afternoon over here, cheers! 13:25:45 <rweait> Yeesh, I can never keep track. 13:25:59 <artem> rweait: have you tried mapnik2 ? 13:25:59 <shann> the boost was installed as 13:26:12 <shann> got boost tar.gz file, 13:26:19 <shann> bootstarpped as 13:26:32 <artem> which boost version ? 13:27:04 <shann> ./bootstrap.sh 13:27:07 <shann> and then 13:27:18 <shann> ./bjam --with-thread --with-filesystem --with-iostreams --with-python --with-system --with-program_options --with-regex -sHAVE_ICU=1 -sICU_PATH=/usr/local toolset=gcc stage 13:27:23 <shann> ./bjam --with-thread --with-filesystem --with-iostreams --with-python --with-system --with-program_options --with-regex -sHAVE_ICU=1 -sICU_PATH=/usr/local toolset=gcc install 13:27:31 <shann> boost 1.4.2 13:27:45 <rweait> artem: Mapnik2, Yes. Sort of. I have it installed and tested a couple of generate_image. I've been battling hardware issues. 13:27:50 <artem> ok, 1.42 13:28:12 <artem> rweait: hardware ? do you mean compilation times ? 13:28:19 * rweait can't wait to do some interesting things with mapnik2 13:28:24 <rweait> Artem, 13:28:26 <shann> followed every bit of the wiki page http://trac.mapnik.org/wiki/Mapnik2#fromlatestrelease|Mapnik2%27s 13:28:40 <rweait> no, sadly, hard crashes during database load. 13:28:45 <shann> but i am stuck boost regex support while building mapnik 13:29:18 <artem> rweait: hmm... dodgy disks? 13:29:38 <rweait> artem, So I can't even get to the point where mapnik (1 or 2) has a full database to work with. Only small extracts. 13:29:40 <artem> shann: could you post error message to dpaste ? 13:29:55 <rweait> artem, I wish it was the disks. 13:29:57 <shann> how to do that? 13:30:15 <rweait> artem, Looks like a disk controller driver has a regression. 13:30:20 <shann> FYI i tried with mapnik2 as well as mapnik 0.7.1 13:30:22 <artem> shann: http://dpaste.com/ 13:30:29 <rweait> I have an ubuntu bug filed. 13:31:18 <artem> rweait: loading the whole planet is an experience 13:31:36 <artem> i have to admit I usually play with UK only 13:31:56 <rweait> artem: It's kind of the point of my new hardware. I'd kind of like to have it work. ;-) 13:32:08 <shann> ok here it is http://dpaste.com/180446/ 13:32:18 <artem> but looks like once you controller driver is fixed you're good to go ? 13:32:46 <shann> artem here is the console output after the scons http://dpaste.com/180446/ 13:32:47 * artem reckons rweait has 16GB of ram and terrabytes of spaces 13:32:55 <rweait> artem: I'm very excited about mapnik2 and look forward to sharing my experiences with it. 13:33:15 * rweait blushes about 32GB and 2.5TB. 13:33:30 <artem> me too:) sounds good (I have lots more new features to add !) 13:33:53 <artem> rweait: wow 13:34:09 <artem> I bet it's noisy ;P 13:34:26 <artem> shann: thanks, let me have a look 13:34:28 <rweait> It's intended to be my tile playground. and I want to play! now, load, database, LOOOOOAD!!!!! 13:35:11 <rweait> artem: Sounds like a hovercraft when the fans start. It's super-quiet at idle. Sadly, it's mostly at idle. 13:36:43 <artem> rweait: have you tried diff distros? 13:36:57 <artem> shann: could you post output from : 13:37:08 <artem> ls -l /usr/local/lib/libboost_* 13:37:21 <artem> and if regex library os there, then : 13:37:31 <artem> ldd /usr/local/lib/libbbost_regex* 13:37:54 <rweait> Yup. Centos 5.4 loaded the db just fine. But Centos 5.4 put me in a very bad place regarding dependencies right from the start. Made me uncomfortable. 13:38:18 <rweait> But the Centos experience tells me the disks are fine. 13:39:07 <artem> rweait: I can help with building mapnik on centos , shouldn't be a problem 13:39:16 <shann> the output of ls -l /usr/local/lib/libboost_* is in http://dpaste.com/180451/ 13:39:28 <artem> same with mod_tile, osm2pgsql etc 13:39:54 <shann> i tried with ldd /usr/local/lib/libboost_regex.so and then ldd /usr/local/lib/libboost_regex.so.1.42.0 13:40:02 <shann> but the output is same i also ran ldconfig 13:40:43 <artem> shann: I'd like to see output from ldd, btw it should be the same (symlinks!) 13:40:50 <shann> hi reweait .. i read your post about building mapnik on ubuntu ... that was my first reading 13:41:06 <rweait> artem: I appreciate that. I expect that everything else would be a problem too. osmosis, maposmatic, mod_tiles, and his dog... And having to use unapproved repositories from the start gives me the willies. Too much bad luggage from Fedora Core 3 13:41:18 <shann> ok pasting ldd /usr/local/lib/libboost_regex.so linux-gate.so.1 => (0x00bce000) libicudata.so.36 => not found libicui18n.so.36 => not found libicuuc.so.36 => not found librt.so.1 => /lib/librt.so.1 (0x00268000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00110000) libm.so.6 => /lib/libm.so.6 (0x001fb000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00be9000) libpthr 13:41:28 <rweait> shann; Cool thanks for visiting. 13:42:01 <shann> wait the output of ldd /usr/local/lib/libboost_regex.so is in http://dpaste.com/180453/ 13:42:03 <artem> shann: as you can see, some dependencies are missing 13:42:33 <shann> which ones ? 13:42:58 <artem> shann: where is your ICU libs ? for mapnik2 you need >4.0 but 3.6 should work for 0.7.1 13:42:59 <shann> i installed the following deps 13:43:25 <artem> you might need to adjust LD_LIBRARY_PATH or ldconfig 13:44:26 <shann> i also did that i used icu 4.4 boost 1.4.2 13:44:50 <artem> shann: when scons checks for libraries it tries to compile minimal C/C++ program ... 13:45:26 <artem> shann: your libboost_regex linked to ICU 3.6 (see output from ldd ...) 13:45:27 *** kredik has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 13:46:26 <artem> shann: I'd recommend you check if you have multiple boost. icu etc libraries on your system 13:46:36 <shann> how to check that? 13:47:56 <shann> ok i am removing the old icu 3.6 libs and its devel libs 13:48:07 <shann> let me run the whole thing once again 13:49:16 <artem> shann: good plan! 13:49:41 <artem> you need to rebuild boost_regex with ICU 4.4!! 13:51:17 <shann> yep i know i was also refering the wiki page about building mapnik in centos and hence had installed libicu* as instrcuted ... i have removed the libicu3.6 and now i am recompiling the icu 4.4 along with boost 1.4.2 13:51:43 <artem> is anybody using gdal.input with mod_tile ? It seems it doesn't like multiple threads hmm... 13:53:47 *** xreal (~mweber@mailgw.FB12.Uni-Dortmund.DE) has joined #mapnik 13:53:57 <xreal> Has anyone seen jburgess? 13:54:05 <xreal> !seen jburgess 13:54:38 *** wonderchook (~wondercho@pool-71-127-43-16.washdc.fios.verizon.net) has joined #mapnik 13:55:52 <artem> xreal: not for a while ? 14:06:35 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik 14:07:53 *** HounD has parted #mapnik (None) 14:08:35 *** jburgess (~jburgess@15.92.187.81.in-addr.arpa) has joined #mapnik 14:09:21 <xreal> There he is ! 14:09:25 <xreal> jburgess: Can I PM you? 14:10:15 <xreal> A bot only? ;-) 14:13:12 *** tmcw has parted #mapnik (None) 14:16:29 <artem> xreal: can we help you ? 14:18:29 *** ajturner (~ajturner@173-8-19-179-WashingtonDC.hfc.comcastbusiness.net) has joined #mapnik 14:23:23 *** agimenez has parted #mapnik (None) 14:23:46 *** agimenez (~agimenez@186.16.223.71) has joined #mapnik 14:26:10 *** Genscher_ (~daniel@dslb-188-098-010-212.pools.arcor-ip.net) has joined #mapnik 14:26:56 <xreal> artem: We've fixed osm2pgsql's hstore import and I want to ask jburgess to compile it for windows again. 14:27:15 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 14:28:04 <artem> xreal: ok, I haven't compiled osm2pgsql for windows for a while, you'd better ask him indeed 14:28:34 *** joelodom (~joelodom@frontend.gtri.gatech.edu) has joined #mapnik 14:29:09 <xreal> artem: It needs very nasty dependencies. It even doesn't work in cygwin here ;-( 14:30:09 *** Genscher has quit (Ping timeout: 276 seconds) 14:31:11 <shann> ok artem ... i think you nailed the issue .... the mapnik scons is able to configure ... i am running the install command 14:31:19 <artem> I used to compile it , I had to clean up GCC specific (or C99?) features which vc++ couldn't handle 14:31:26 <artem> shann: great! 14:31:37 <joelodom> Hello. I've got mapnik building on Windows. Now I'm trying to build the shape input plugin. I'm quite new to this. I have a .lib and .dll built, but what is this shape.input file? How do I create it? Thanks. 14:32:05 <shann> will buzz when it is complete ... i think we need to change the wiki pages to reflect the correct process. i will jot down all the steps and send ... btw whom to send? 14:33:03 <artem> shann: you can sign up to trac and edit it's wiki!! 14:33:08 <shann> the mapnik2 has the correct process but the main wiki says to install libicu thru yum install process which install 3.6 14:33:16 <shann> ok thats great 14:33:39 <shann> wbrb 14:34:03 <artem> joelodom: *.dll -> *.input 14:34:12 <joelodom> Ah! I'll try that. Thanks. 14:35:40 *** artem has quit (Quit: artem) 14:37:15 <joelodom> Works like a charm. c++ demo output looks great. Thanks again. 14:37:19 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 14:37:27 <artem> springmeyer: aiming for 17:00 (local time) skype meeting 14:37:51 <joelodom> artem: Works like a charm. c++ demo output looks great. Thanks again. 14:38:06 <artem> no probs, great! 14:40:31 *** wonderchook has quit (Remote host closed the connection) 14:55:00 *** shann has quit (Ping timeout: 248 seconds) 14:56:02 * springmeyer arrives 14:56:07 <springmeyer> hey artem - sounds great 14:56:27 <springmeyer> so, to confirm that is one hour from now? 14:59:32 <springmeyer> joelodom: hey there 14:59:39 <joelodom> Hello. 15:00:03 <springmeyer> great stuff getting mapnik compiled on windows 15:01:04 <springmeyer> we are missing a wiki page describing approaches, so if you have a minute to do a brain dump that could be great 15:01:07 <joelodom> Thanks. We're evaluating it to use with FalconView as a choice for rendering components. It's very impressive so far. I'll write up a quick blog post for those who may be interested in getting it to compile. 15:01:15 <springmeyer> ah nice 15:01:18 <joelodom> Yes, I'd be glad to contribute my notes to the community. 15:01:33 * springmeyer has not heard of FalconView, but great that you are liking it! 15:02:11 <joelodom> http://www.falconview.org/ It's a mission planning system for (mostly) military use. 15:03:48 <springmeyer> nice, looks powerful 15:05:50 <springmeyer> wow. it can open and edit mxd files - impressive 15:11:30 <xreal> springmeyer: Yes, it has got OpenSource some weeks ago. 15:11:54 <joelodom> The mxd stuff requires ArcEngine, though. 15:12:20 <xreal> joelodom: As always ;- 15:12:22 <xreal> ;-( 15:12:39 <joelodom> http://giscoder.blogspot.com/2010/04/building-mapnik-on-windows.html 15:13:49 <springmeyer> right on, thanks 15:14:02 <springmeyer> I'm sure many will benefit from your notes 15:14:23 <joelodom> Not a problem. I hope they are useful. They are sometimes a bit sketchy as they are mostly notes to myself. 15:17:55 * springmeyer nods :) 15:18:20 <springmeyer> I provide the osx binaries and my notes are surely a bit sketchy :) 15:42:06 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik 15:43:35 *** agimenez has parted #mapnik (None) 15:44:23 *** wonderchook (~wondercho@209.155.228.129) has joined #mapnik 15:44:46 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik 15:45:57 *** mperry has quit (Ping timeout: 268 seconds) 15:45:57 *** mperry_ is now known as mperry 15:53:08 *** agimenez (~agimenez@186.16.223.71) has joined #mapnik 15:57:47 *** artem has quit (Quit: artem) 15:59:51 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 16:08:15 *** agimenez has parted #mapnik (None) 16:13:00 *** ajturner has quit (Quit: ajturner) 16:14:56 *** racicot has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920]) 16:15:12 *** cgs_bob has quit (Ping timeout: 240 seconds) 16:16:49 *** Genscher (~daniel@dslb-188-098-010-212.pools.arcor-ip.net) has joined #mapnik 16:19:23 *** Genscher_ has quit (Ping timeout: 258 seconds) 16:20:56 <springmeyer> hey artem - waldamar's proposal: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/waldemarquevedo1/t127017081069 16:40:11 *** tcarobruce (~tcarobruc@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik 16:46:34 *** racicot (~chatzilla@dsl-66-228-218-217.dsl.fibercloud.net) has joined #mapnik 16:56:52 *** jctull (~jctull@75.0.4.106) has joined #mapnik 17:07:36 *** shann (~7ab5a282@gateway/web/freenode/x-jpjktunrljyxmilk) has joined #mapnik 17:17:23 *** artem has quit (Quit: artem) 17:25:45 <joelodom> springmeyer, If I have a Shapefile and an SLD file, is there a simple way, using the C++ api, that I can draw the Shapefile with the SLD? Something that loads both and draws in a few lines of code? (Sorry if this is answered on the wiki, but I haven't been able to find the answer. I'm still new to Mapnik. Thanks.) 17:27:29 <springmeyer> certainly 17:27:38 <springmeyer> on a call right now, but basically: 17:28:09 <springmeyer> 1) Mapnik has a load_map() method that can be used to attach styles to a map 17:28:20 <springmeyer> it can be used to load just styles if you like 17:29:15 <springmeyer> we don't currently have a convenience wrapper to directly apply a style to a layer 17:29:35 <joelodom> Excellent. I'll check that out. Thanks much. I'm looking at the python docs now, but is there a set of reference documentation for the C++ API, or should I stick to examining the header files? Thanks. 17:29:43 <springmeyer> because the object model is to apply a style name to a layer and the actual style object to the map 17:29:56 <springmeyer> no C++ api docs, sorry... 17:30:05 <springmeyer> we need them but none have been generated yet 17:30:28 <joelodom> Gotcha. Not a problem. I'll figure it out. So I create a map, add a layer, add the style rule to the map, and then associate the style with the layer? 17:30:45 <joelodom> (then render) 17:30:53 <springmeyer> bingo 17:31:07 <joelodom> Thanks much again. 17:31:19 <springmeyer> np! 17:52:37 <shann> hi 17:52:56 <shann> i was able to build mapnik2 properly however when i try to run the demo i get 17:53:06 <shann> The mapnik library and python bindings must have been compiled and installed successfully before running this script. 17:54:52 <shann> anyone ? 17:55:17 <shann> also the 17:55:49 <shann> import mapnik mapnik2 does not work 17:56:00 <shann> here is the output 17:56:25 <shann> http://dpaste.com/180522/ 18:11:24 <shann> hi anyone there to help me? 18:11:32 <springmeyer> shann: on a call 18:11:33 *** agimenez (~agimenez@200.10.228.62) has joined #mapnik 18:11:36 <springmeyer> I can fix soon 18:12:26 <shann> spingmeyer: i would wait for you 18:16:50 <shann> spingmeyer: are you ther? 18:17:18 <springmeyer> yes, but on phone call currently 18:18:12 <shann> spingmeyer: ok will wait for you to be back here on the irc channel 18:23:36 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 18:23:51 *** artem has quit (Client Quit) 18:24:46 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 18:24:58 *** mogi (~quassel@79.125.249.122) has joined #mapnik 18:25:58 *** mogi has quit (Client Quit) 18:26:19 *** mogi (~quassel@79.125.249.122) has joined #mapnik 18:30:28 <shann> springmeyer: i know i am troubling you ... are you thru with your call ? 18:30:48 <shann> hi artem ... i was able to compile and install mapnik2 on centos 5.4 32 bit properly 18:31:16 <artem> shann: great news! 18:32:00 <shann> however while i run the rundemo.py i get 18:32:02 <shann> The mapnik library and python bindings must have been compiled and installed successfully before running this script. 18:32:22 <springmeyer> hey shann - ya just finished up 18:32:39 <shann> the build info is in http://dpaste.com/180527/ 18:32:44 <springmeyer> it looks like alberto committed some python code that is incompatible with python 24 18:33:31 <shann> ok is it possible for me revert back to the stable version of mapnik-0.7.1 18:33:33 <artem> shann: someone already replied on mailing list - looks like you need to upgrade python or get earlier revision from of mapnik from svn 18:34:02 <artem> shann: I think it's a smart idea 18:34:51 <springmeyer> artem: seems we should keep compatibility with py24... 18:35:25 <springmeyer> kinda crazy syntax I am noticing :( 18:35:44 <shann> which version of python is prefered ? 18:35:49 <artem> springmeyer: sure, I'm on 2.6 and I haven't noticed breakage 18:36:45 <artem> shann: looks like 2.5 should work (you need to recompile boost_python and mapnik) or even better we should fix it in trunk to be compatible with 2.4 18:37:25 <springmeyer> alberto is a lead developer of turbogears so he knows what he's doing of course 18:37:33 <shann> when can it be done ? how can i help ? 18:37:45 <springmeyer> but I sense perhaps solving things in python that should maybe use boost::python... 18:37:53 * springmeyer is close to fixing shann - one sec 18:38:37 * springmeyer is making sure tests are working... 18:40:29 <springmeyer> hmm, mapnik2 compiling, going to be a bit... 18:42:09 *** mogi has quit (Remote host closed the connection) 18:44:54 <nikq> Mapnik Trac: Changeset [1759]: maintain python24 compatibility | http://trac.mapnik.org/changeset/1759 18:45:04 <springmeyer> shann: try now 18:45:05 <springmeyer> svn up 18:45:08 <artem> I asked already but no reply so far : is anyone using gdal.input with mod_tile in production ? It looks like gdal doesn't like to be run in multithreaded env. I'm getting random seg faults, sometimes some raster bands are missing 18:45:13 <springmeyer> python scons/scons.py install 18:45:43 <springmeyer> artem: interesting. I've not yet but should test 18:46:15 <springmeyer> I know that marcin ran into race conditions in the past which he solved by upgrading libtiff library 18:46:38 <shann> running python scons/scons.py configure OPTIMIZATION=3 18:46:40 <artem> springmeyer: ok, interesting 18:46:49 <shann> and then python scons/scons.py install 18:47:05 <springmeyer> #294 18:47:07 <nikq> Ticket #294: thread unsafe gdal layer initialization (libgeotiff), http://trac.mapnik.org/ticket/294 18:48:03 <springmeyer> hmm, looks like I remember wrong - that he solved by locking in mod_tile during load_map... 18:48:33 <springmeyer> shann: yes 18:48:44 <springmeyer> er, no 18:48:46 <artem> springmeyer: that the one, yes re:#294 18:48:51 <springmeyer> shann: you don't need to run configure again 18:49:41 <shann> sorry that was a typo .. i am running python scons/scons.py install only 18:50:03 <springmeyer> shann: okay 18:52:01 <springmeyer> artem: would be interesting to know if passing 'shared=true' to gdal driver has any effect... 18:52:23 <artem> nope, I've tried that 18:52:40 <springmeyer> k 19:03:11 *** artem has quit (Quit: artem) 19:04:51 *** mogi (~quassel@79.125.249.122) has joined #mapnik 19:04:59 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 19:15:38 <shann> bingo .... i am able to generate the images 19:15:51 <shann> no issues so far 19:16:19 <shann> thanks artem, springmeyer and all others who helped to resolve this 19:16:49 <shann> i would create new wiki page with all my learnings so that it is available for everyone else 19:16:58 <shann> as suggested by artem 19:17:00 <springmeyer> shann: good, sorry about that 19:17:08 <artem> great, you're welcome. wiki sounds good! 19:17:16 <springmeyer> shann: the other problem was what? 19:17:27 <shann> no probs at all ... i am very happy that the fix was real quick and we were able to test it here also 19:17:58 <springmeyer> shann: good 19:18:08 <springmeyer> shann: can you run the python tests? 19:18:23 <shann> the other one was that i was refering to the wiki page which detailed about installing mapnik in centos / rhel since it suggests to do libicu thru yum install process 19:18:30 <springmeyer> sudo easy_install nose <-- that is a depedency 19:18:47 <shann> the yum install ... installs libicu-3.6 which is incompatible with mapnik-2 19:18:47 <springmeyer> shann: ah, right and that will not work with trunk, sure 19:19:08 <springmeyer> shann: for now maybe we should just link to http://trac.mapnik.org/wiki/Mapnik2 page 19:19:21 <shann> nope its not about trun ... the first error i got stuck with was about boost_regex libs 19:19:21 <springmeyer> from each other install page? not sure exactly 19:19:35 <shann> yes thats what we must do 19:19:37 <springmeyer> oh? 19:19:38 <springmeyer> k 19:19:53 <springmeyer> shann: either way, thanks for offering to edit the wiki 19:20:20 <springmeyer> it is users like you that can help the most in cleaning and softening the path of others... 19:20:27 <shann> so shall just edit the page to refer to the new mapnik2 wiki page ... so that folks dont end with incompatible libs 19:21:06 <springmeyer> sounds reasonable 19:21:16 <shann> it is the least i can do for the people who have build such good / great tool ... and always pleasure is mine 19:21:33 <shann> ok shall do that tomorrow 19:21:36 <springmeyer> we could also eventually break out a page on Boost specific details... 19:21:39 <springmeyer> shann: okay 19:21:41 <shann> is there any review process ? 19:21:51 <shann> for wiki edits ? 19:21:52 <springmeyer> for the trac wiki? 19:21:56 <shann> yes 19:21:56 <springmeyer> shann: no 19:22:12 <springmeyer> me, and I assume a variety of others, subscribe to the Wiki RSS 19:22:31 <springmeyer> so we can see each edit, and can jump in to fix things up 19:22:56 <shann> ok i will just edit the page to refer to mapnik2 wiki page in the centos/rhel installation wiki page 19:23:32 <shann> also installation of some deps are missing ... so i will add them also 19:23:40 *** mogi__ (~quassel@79.125.248.86) has joined #mapnik 19:23:53 <rweait> #543 19:23:53 <nikq> Ticket #543: Mapnik2 headers overwrite mapnik headers when installing both, http://trac.mapnik.org/ticket/543 19:23:57 *** mogi has quit (Ping timeout: 276 seconds) 19:23:59 <mogi__> which libicu is compatible with mapnik? 19:24:06 <shann> ok its time for me to sleep now ... thanks everyone 19:24:28 *** mogi__ is now known as mogi 19:24:33 <shann> libicu*-3.6 which gets installed if you do yum install libicu libicu-devel in centos 19:24:56 <springmeyer> rweait: yes, I see the problem but don't know the right approach 19:25:05 <shann> the libicu*3.6 is incompatible with mapnik2 19:25:12 <springmeyer> artem: what is the overall plan for namespaces? 19:25:15 <rweait> springmeyer: Oh good. It isn't just me. 19:25:18 <mogi> ah, yes thanks, but which one is compatible? 19:25:48 <springmeyer> shann: we also need to add a configure time check for latest icu... 19:25:56 <springmeyer> I think there is a ticket for this somewhere... 19:25:57 <shann> mogi: mapnik2 svn trunk and libicu-3.6 cannot work together 19:26:43 <artem> springmeyer: at the moment we have: namespace mapnik {} but it would be great to follow boost style and use private namespaces and more 19:26:44 <shann> yep ... we may have to add some scripts to do the check and suggest the correct deps for the folks 19:27:41 *** cgs_bob (~bob@9.sub-75-211-114.myvzw.com) has joined #mapnik 19:27:55 <springmeyer> artem: and the headers should be in /include/mapnik2 ? 19:29:34 <artem> I thought about it, it'll require renaming #include <mapnik/xxx to #include <mapnik2/xxx I can do this if you like ? 19:30:28 <artem> I think we should, as it'll allow for side by side testing mapnik vs mapnik2.0 :P 19:31:25 <springmeyer> honestly I'm not sure 19:31:45 <springmeyer> ability for side-by-side testing is nice surely 19:32:01 <shann> ok signing off guys have nice day / good night 19:32:08 <artem> but then you can always use diff PREFIX 19:32:14 <artem> shann: you too 19:32:17 <springmeyer> but I think longer term stability for other applications to be able to hook into mapnik is perhaps more critical 19:32:47 <mogi> Hello, I am interested in sending a GSoC application for the Layer Compositing option in Mapnik, and I have some questions 19:32:55 <springmeyer> artem: I guess that raises question: Do you see any need to continue to maintain 0.7.x series? 19:33:38 <springmeyer> or any probability/need to have parallel development after we fix up trunk test/etc and get all parts working again? 19:34:08 <springmeyer> hi mogi 19:34:17 <springmeyer> sure, feel free to ask here 19:34:39 <springmeyer> also you should send a mail very soon to the mapnik-users and mapnik-devel list introducing yourself 19:34:57 <mogi> great, first of all let me say sorry for barging into your conversation 19:35:09 <artem> springmeyer: I think low key maintenance should be fine, but all new stuff should go into trunk. Well, it depends how much breakage will mapnik2 intriduce 19:35:16 <springmeyer> we only are accepting max two spots, so timeline is tight 19:35:23 <artem> mogi: no probs, I'm about to go out a little while 19:35:27 <mogi> i am writing my introduction now, and i had some questions 19:35:56 *** artem has quit (Quit: artem) 19:35:58 <springmeyer> mogi: ya, no worries. multiple conversations is fine, just prefix your statement with person's irc name if needed 19:35:59 <mogi> i see youre moving into a new codebase and i didn't see it linked on the wiki 19:36:31 <springmeyer> mogi: yes, http://trac.mapnik.org/wiki/Mapnik2 represents some active refactoring 19:36:32 <mogi> springmeyer: i understand 19:36:53 <springmeyer> but its the same codebase essentially 19:36:55 <mogi> springmeyer: so which one should i play with, mapnik or mapnik2? 19:37:00 <springmeyer> mapnik2 19:37:20 <mogi> so, mapnik stays version 0.7.1? 19:37:31 <springmeyer> but, as we've been discussing, they should be able to run together 19:37:39 <springmeyer> so installing 0.7.1 is great too 19:38:06 <springmeyer> yes, mogi 0.7.1 is likely last or penultimate release in 0.7.x series 19:38:15 <springmeyer> while "Mapnik2" is trunk/0.8.0 19:38:42 <mogi> springmeyer: ok, no problem with that, since i have some programming experience with C++ and Python 19:39:09 <springmeyer> great. any experience with the Boost Libraries, AGG, or Cairo? 19:39:37 <mogi> springmeyer: unfortunately not, but I am quite a fast learner 19:39:58 <mogi> springmeyer: and this would be my first open-source contrubution 19:41:06 <springmeyer> okay. great that you are interested in open source 19:41:07 <mogi> springmeyer: I have tried to play around with Cairo using Python on Windows, you might assume it was a bit complicated to get the system to run 19:41:34 <springmeyer> yes, cairo on windows could be tricky to install 19:41:46 <springmeyer> I've not done it myself 19:41:49 <mogi> springmeyer: especially using python bindings 19:42:20 <springmeyer> ya, pkg-config and friend... ugh :) 19:43:08 <mogi> springmeyer: so I'm going to go through the Mapnik2 source in an hour, and i was wondering if you had suggestions on where to start 19:43:38 <mogi> springmeyer: I'm particulary interested in doing the layer compositing part 19:44:34 <springmeyer> mogi: have you done graphics work in the past with PIL or anything like that? 19:45:02 <mogi> springmeyer: no i haven't 19:45:47 <springmeyer> basically adding composing will require both graphics/blending work (likely as methods of mapnik.Image / mapnik::image_32) 19:46:53 <springmeyer> and extensions to cairo_renderer.cpp and agg_renderer.cpp or a set of classes that wrap them 19:47:23 <mogi> i'm going to look into it 19:47:40 <springmeyer> so those are places to look to get a feel. include/mapnik/{graphics|image*} stuff and the renderer.cpp files 19:48:53 <mogi> springmeyer: thanks alot 19:49:07 <springmeyer> mogi: enjoy 19:54:05 *** joelodom has quit (Read error: Connection reset by peer) 20:02:41 *** agimenez1 (~agimenez@200.10.228.31) has joined #mapnik 20:02:45 *** agimenez has parted #mapnik (None) 20:04:34 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik 20:08:18 <agimenez1> hello springmeyer, I have some questions about the operation of the mapnik render engine concerning to layer compositing 20:08:57 <springmeyer> agimenez1: you bet. artem may also have ideas 20:09:02 <agimenez1> ok 20:09:09 <agimenez1> I 20:09:30 <artem> hi alberto 20:09:41 <agimenez1> I've noticed that the raster_symbolizer has some "modes" that could be as well used on other symbolizers 20:09:46 <agimenez1> hi artem 20:11:07 <artem> agimenez1: yes, compositing modes can be applied to strokes and fills etc 20:12:27 <agimenez1> But, we would have to code on every renderer (agg, cairo) the same functionality, don't we? 20:14:34 <artem> well, agg and cairo are distinctively different renders, but I agree current code in agg_renderer.cpp should be refactored to avoid duplications 20:19:33 *** Genscher has quit (Quit: Verlassend) 20:20:52 <agimenez1> artem: ok, do you think that in some postdrawing phase AGG should do the work? (to not introduce another library dependency) 20:23:56 <artem> agimenez1: are you talking about per layer compositing modes? If yes, I think we should use agg (all compositing modes as per svg 1.2 are implemented afaik) . But it might be difficult to use cairo surfaces... not sure. 20:25:26 <artem> just to clarify - compositing is implemented in agg already, so it's just a matter of integrating in mapnik in a best possible way. I guess we might have to have this functionality in agg only 20:25:39 <agimenez1> ok 20:26:39 <artem> and in svg_renderer. because we'll have full control over output 20:28:13 <artem> btw, can svg support per later compositing ? 20:31:06 <agimenez1> you are right, the painter model composite all the symbology items in one surface, so adding extra "effects" to symbology should do the work 20:31:33 <agimenez1> per layer? 20:33:41 <agimenez1> I don't certainly know 20:49:49 <artem> agimenez1: if layer hasn't overlapping features (often the case in GIS world) then per feature compositing == per layer I think 20:51:24 <agimenez1> yes, I think so, thank you artem 20:53:38 <artem> agimenez1: this needs some R&D , I can see how we can introduce some artifacts when features overlap not geometrically but because stroke-width=<big number> 20:59:50 <agimenez1> The idea behind this proposal [http://trac.mapnik.org/wiki/Ideas/Compositing] has a diferent aproach but it's based on compositing Maps outputs as layers, but this it's a kind of external postprocesing program 21:00:22 <springmeyer> agimenez1: I spoke last week with the fellow that put that together 21:00:46 <springmeyer> I think that composing map objects is what TopOsm is doing 21:01:28 <springmeyer> so he was just brainstorming how that could look in XML 21:01:58 <springmeyer> maybe it all can be done between layers, not sure myself, but please comment on wiki as you have ideas 21:02:09 <agimenez1> springmeyer: ok, yes, I see the idea behind that wiki 21:02:21 <springmeyer> I think that cmarqu and Ldp will have ideas too when they are around... 21:03:03 <springmeyer> a shortcut could be to add the "modes" you noticed as methods that could be called from python 21:03:23 <springmeyer> e.g, currently from python we can do mapnik.Image.blend() 21:04:02 <springmeyer> and I could see some users being able to leverage mapnik.Image.subtract(), etc 21:04:27 <agimenez1> springmeyer: ok, I'll write the idea. According to the painter model we can't composite Mapnik Layers, right? artem? 21:05:42 <agimenez1> springmeyer: I get it, thanks, then using python seems to be more appropriate than experimenting with symbolizers modes 21:05:47 <artem> agimenez1: well, we don't have to follow painter model if it stops rendering cool maps. Also, I can't see why not? Let me try something ... 21:05:49 <springmeyer> but again, ideally it could be generic as possible, so it could be used programmtically from python as well as with properties in XML (but the latter is harder for me to get my mind wrapped around) 21:08:47 <agimenez1> artem: I think, mapnik might use several surface or canvas (for each layer) instead of one for the whole map, I don't know if I'm wrong. 21:09:25 <artem> yes, you're right it can 21:09:44 <agimenez1> but seems to be a big change 21:13:22 *** Genscher (~daniel@dslb-188-098-010-212.pools.arcor-ip.net) has joined #mapnik 21:14:47 <artem> it should be possible to implement this as a policy : struct agg_renderer<typename Image,typename CompositingPolicy=DefaultPolicy> 21:15:01 <Ldp> not following the painter's model would have serious implications for svg/pdf vector output through cairo, right? 21:16:01 <artem> Ldp: I'm not sure it would 21:16:06 <artem> http://media.mapnik.org/os-map.jpg 21:16:54 <artem> the above is not as pretty as TopOSM but this is standard mapnik. 21:17:42 <agimenez1> Nice 21:17:53 <Ldp> I'm talking about doing more gfx based tricks, like my 'erasing stroke' (would be unneeded by springmeyer's offset lines, but without the corner issues), etc 21:19:03 <Ldp> and I'd love to have more ways to perform 'freeform' painting in mapnik. Like drawing arrows, lines, patterns solely based on rules, not geometries 21:19:11 <artem> I'm trying to understand pros and cons regarding per layer vs per f eature compositing 21:19:52 <Ldp> but I haven't been following the entire previous discussion 21:20:41 <artem> Ldp: yes, drawing interface would be really cool and should be fairly easy to implement for both agg and cairo 21:22:04 <agimenez1> sorry artem: what did you try to get such a map? 21:23:34 <Ldp> artem: a notable example is osmarender's tunnel rendering. Can't make such a thing in mapnik, with the slanted lines at the entrances. An approach could be to be able to define separate patterns for the beginning, middle, and end bits of a line geometry 21:24:05 <artem> agimenez1: do you mean, how ? 21:25:00 <artem> Ldp: good point. 21:25:19 <agimenez1> artem: yes, how? 21:25:49 *** xreal has quit () 21:25:51 <artem> agimenez1: the key is :<RasterSymbolizer> 21:25:51 <artem> <CssParameter name="opacity">1.0</CssParameter> 21:25:51 <artem> <CssParameter name="scaling">bilinear</CssParameter> 21:25:52 <artem> <CssParameter name="mode">multiply</CssParameter> 21:25:52 <artem> </RasterSymbolizer> 21:26:11 <artem> which is used by last layer in the map 21:26:52 <artem> this is approach that marcin is using afaik 21:27:41 <artem> the last layer is a shaded relief raster 21:29:18 <artem> Ldp: I think SVG has notion of start/end markers for a linear geometries, we should have something similar 21:31:59 <Ldp> in the same vein: if I could set a skip distance in LinePatternSymbolizer, I could use it to draw markers alongside a line. Direction arrows, for instance. Could do it now by padding and offsetting the image file, I suppose. 21:33:00 <Ldp> but that won't guarantee they're never broken off 21:33:53 <Ldp> artem: lots of little things (as a cartographer, can't comment about the coding) that could be so useful 21:39:06 <artem> Ldp: we should really solve direction arrows soon. There is a patch somewhere in svn to draw arrows long the path. The proper fix would be to allow any vector based symbol along the path with a way to control spacing etc 21:39:17 <artem> Ldp: thanks for your feedback! 21:39:42 <Ldp> vector symbols would be cleaner than warping an image along a geometry :) 21:39:57 <artem> indeed 21:40:48 * artem thinks he should study svg spec 21:41:48 <agimenez1> artem: I think that it's pretty much the idea, Mapnik already has composite capabilities like TopOSM like to have, but need more "modes" besides screen, multiply, etc. 21:44:42 <artem> agimenez1: yes, sounds good. Also at the moment compositing is only works with raster! 21:45:06 *** eocampos (~c80ae486@gateway/web/freenode/x-ukksmbirqvnfirln) has joined #mapnik 21:45:52 <artem> I got to go soon. Great thread, thanks everyone! 21:46:56 * springmeyer just wraps up a call 21:46:59 <springmeyer> artem: great stuff 21:47:09 <springmeyer> I'll post a link to these irc logs on the GSOC page... 21:47:38 <artem> sure 21:48:58 <nikq> Mapnik Trac: GSOC2010/Ideas edited | http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=18 21:49:38 <nikq> Mapnik Trac: GSOC2010/Ideas edited | http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=19 21:50:16 <Ldp> springmeyer: mapnik can do everything! it can even do composting :) 21:50:26 <Ldp> springmeyer: wiki typo :) 21:50:35 <springmeyer> ack 21:51:06 <springmeyer> ya, I think I can handle that alone 21:51:13 <springmeyer> no need to involve mapnik :) 21:51:35 <artem> : ) see you later 21:51:50 <nikq> Mapnik Trac: GSOC2010/Ideas edited | http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=20 21:51:53 <springmeyer> see you! 21:55:42 *** artem has quit (Quit: artem) 22:07:04 *** agimenez1 has parted #mapnik (None) 22:11:10 *** jctull has quit (Quit: jctull) 22:14:45 *** wonderchook has quit (Remote host closed the connection) 22:42:07 *** agimenez (~agimenez@186.16.45.90) has joined #mapnik 22:43:59 *** mogi has quit (Remote host closed the connection) 22:46:10 *** Ldp has quit (Ping timeout: 260 seconds) 22:50:39 *** mogi (~quassel@79.125.248.86) has joined #mapnik 22:50:53 *** mogi has quit (Remote host closed the connection) 22:55:39 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik 23:16:35 *** Ldp__ has quit (Ping timeout: 260 seconds) 23:20:13 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik 23:22:02 *** Ldp__ is now known as Ldp 23:23:27 <nikq> Mapnik Trac: GSOC2010/Ideas edited | http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=21 23:31:49 *** Ldp has quit (Ping timeout: 264 seconds) 23:34:58 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik 23:44:14 *** jfreeman (~jfreeman@203.217.61.147) has joined #mapnik