#mapnik log: Wednesday 07, April 2010

2010 | 04

previous | next
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 feature 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