00:26:11 *** matt_c (n=mcroydon@137.147.45.66.cm.sunflower.com) has joined #mapnik
01:11:43 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
01:42:56 <CIA-23> mapnik: artem * r914 /trunk/include/mapnik/value.hpp:
01:42:56 <CIA-23> mapnik: + add specialisations for bool
01:42:56 <CIA-23> mapnik: + small fix
01:42:56 <CIA-23> mapnik: jburgess777 * r915 /trunk/src/load_map.cpp: Read spacing parameter on ShieldSymbolizer from XML
01:42:58 <CIA-23> mapnik: artem * r916 /trunk/plugins/input/sqlite/sqlite_datasource.cpp: + corrected SQL
01:42:59 <CIA-23> mapnik: nickw * r917 /trunk/plugins/input/osm/ (5 files): OSM plugin: dataset_deliverer now re-fetches data if the URL has changed
01:43:03 <CIA-23> mapnik: artem * r918 /trunk/include/mapnik/value.hpp: + ignore unused variable warning
01:43:04 <CIA-23> mapnik: nickw * r919 /trunk/plugins/input/osm/ (6 files in 2 dirs): added initial version of easymapnik: command line tool for generating Mapnik maps from OSM XML data
01:43:09 <CIA-23> mapnik: nickw * r920 /trunk/plugins/input/osm/demo/ (MapSource.cpp easymapnik.cpp MapSource.h): easymapnik: SRTM only if command line option given
03:13:57 *** cytrinox has quit (Read error: 60 (Operation timed out))
03:18:42 *** cytrinox (n=cyx@X91b0.x.pppool.de) has joined #mapnik
03:23:44 *** cytrinox_ (n=cyx@Xdc4e.x.pppool.de) has joined #mapnik
03:36:42 *** cytrinox has quit (Read error: 110 (Connection timed out))
04:11:18 *** matt_c has quit ()
04:51:42 *** aub has quit ()
05:22:18 <nikq> Mapnik Trac: Ticket #190 (Make symbolizers available/editable via a Style object in python bindings) updated | http://trac.mapnik.org/ticket/190#comment:5
05:23:16 <nikq> Mapnik Trac: Changeset [921]: + add pickling support for styles and rules - TODO expose symbolizer  ... | http://trac.mapnik.org/changeset/921
05:31:15 <CIA-23> mapnik: dane * r921 /trunk/bindings/python/ (mapnik_style.cpp mapnik_rule.cpp): + add pickling support for styles and rules - TODO expose symbolizer object in general(#190) and for pickling
06:03:08 <CIA-23> mapnik: dane * r922 /trunk/bindings/python/mapnik_rule.cpp: remove unneeded include added in r921
06:03:11 <nikq> http://trac.mapnik.org/changeset/921, at , by dane: + add pickling support for styles and rules - TODO expose symbolizer object in general(#190) and for pickling
06:24:49 *** matt_c (n=mcroydon@137.147.45.66.cm.sunflower.com) has joined #mapnik
06:27:51 <nikq> Mapnik Trac: Ticket #235 (g++: Internal error after r921) created | http://trac.mapnik.org/ticket/235
06:28:22 <nikq> Mapnik Trac: Ticket #235 (g++: Internal error after r921) updated | http://trac.mapnik.org/ticket/235#comment:1
06:30:01 *** ninja__ has quit (Read error: 60 (Operation timed out))
06:30:41 *** ninja_ (n=pankur@nat/yahoo/x-6582ac4a9f63605f) has joined #mapnik
06:44:11 <nikq> Mapnik Trac: Ticket #167 (Map pickling failure due to mapnik.Color object) updated | http://trac.mapnik.org/ticket/167#comment:14
06:44:13 <nikq> Mapnik Trac: Ticket #167 (Map pickling failure due to mapnik.Color object) updated | http://trac.mapnik.org/ticket/167#comment:14
06:54:04 <nikq> Mapnik Trac: Ticket #225 (OSM plugin compiler warnings) closed | http://trac.mapnik.org/ticket/225#comment:1
06:54:11 <nikq> Mapnik Trac: Ticket #225 (OSM plugin compiler warnings) closed | http://trac.mapnik.org/ticket/225#comment:1
07:44:21 *** xcacou (n=aga@AToulouse-157-1-16-163.w86-201.abo.wanadoo.fr) has joined #mapnik
07:49:45 <springmeyer> hey xcacou: headed to bed her, but just thought to ping you -- see if you've tried out mapnik trunk with the WMS server patches added
09:40:02 *** tomh- (i=9161e94b@gateway/web/ajax/mibbit.com/x-6568737dd3d7c261) has joined #mapnik
09:40:31 <tomh-> dear tomh, stop stealing my nick please ..
09:40:47 *** TomH is now known as Guest46246
09:40:59 *** tomh- is now known as tomh
09:41:02 <tomh> thanks
09:41:07 *** tomh has parted #mapnik ()
09:41:10 *** Guest46246 is now known as TomH1
09:51:09 *** darragh (n=darragh@83.70.173.25) has joined #mapnik
10:12:30 *** TomH1 is now known as thughes
10:14:02 *** thughes is now known as tomhughes
10:19:02 *** tomhughes has quit ("Coyote finally caught me")
10:19:08 *** tomhughes (n=tom@gate.compton.nu) has joined #mapnik
10:20:02 *** tomhughes is now known as TomH1
10:20:04 *** TomH1 is now known as Tom2
10:21:09 *** Tom2 has quit (Client Quit)
10:21:14 *** tomhughes (n=tom@gate.compton.nu) has joined #mapnik
10:21:54 *** tomhughes is now known as TomH1
10:21:57 *** TomH1 is now known as Tom2
10:24:07 *** Tom2 is now known as tomhughes
12:22:29 *** matt_c has quit (Read error: 104 (Connection reset by peer))
12:23:49 *** matt_c_ (n=mcroydon@137.147.45.66.cm.sunflower.com) has joined #mapnik
13:25:42 *** aub (n=aubrey@cpe-72-227-134-148.nyc.res.rr.com) has joined #mapnik
13:28:32 *** aub has quit (Client Quit)
14:08:04 *** aub (n=aubrey@static-70-107-236-83.ny325.east.verizon.net) has joined #mapnik
15:04:00 *** sanjiv (n=chatzill@59.180.129.47) has joined #mapnik
15:12:47 *** matt_c_ is now known as matt_c
15:20:24 <aub> does anybody have an idea on what i should expect for performance from mapnik with OSM data? i've got the data in postgis and using the XML files from the cascadenik examples, and it's taking about 2 minutes to render tiles.
15:20:35 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
15:22:17 <springmeyer> aub: in general the cascadenik OSM styles are heavy on Filters and custom postgresl selects and as such those styles are more expensive than the xml used by OSM
15:22:56 <springmeyer> I've been meaning to ask migurski if as part of the cascadenik compile step whether some of those sub-selects could be cached
15:23:18 <springmeyer> (tho I've yet to confirm that would speed things up much)
15:23:40 <aub> springmeyer: all right. interesting idea. any idea what the performance you might get from the OSM xml files would be?
15:24:12 <aub> i'm just curious about how far from expected i am
15:24:28 <springmeyer> aub: but 2 minutes is way to long still - obviously depends on your zoom level (the first few global tiles are much slower) but I get tile renders more in the range of .5-1 minute
15:24:33 <tomhughes> depends on the zoom and how much data is in the tile
15:24:58 <tomhughes> but on the osm tile server it's measured more in tiles/second ;-)
15:25:09 <artem_> aub: do you mean it takes 2 min to render 1 tile ?
15:25:29 <aub> i'm using a 5x5 metatile, and yes it's about 2 minutes or more
15:25:37 <springmeyer> aub: I've noticed that the cascadenik styles don't implement <extent = ''> I'd try adding that
15:25:55 <artem_> I usually get something like : Total tiles rendered: Rendered 1577920 tiles in 21184.47 seconds (74.48 tiles/s)
15:25:56 <aub> it's on a pretty crappy server, so i'm wondering how much benefit to expect from upgrading
15:26:16 <aub> woa, 75 tiles per second is a bit different. :)
15:26:31 *** matt_c has quit ()
15:26:41 <artem_> yes, but this is averaged over all zoom levels
15:26:59 <artem_> and server is not too crappy either
15:27:05 <aub> sure. i'm finding it taking two minutes when zoomed all the way in though
15:27:21 <springmeyer> aub: that is too long when zoomed in :)
15:27:36 <aub> yeah, clearly.
15:27:38 <springmeyer> aub: you working with the whole planet_osm or just a region?
15:27:41 <artem_> i would check spatial indexes first
15:28:05 <aub> it's just data for the UK. i believe i have the spatial indexes set up correctly, but will triple check
15:28:27 <springmeyer> aub: working off of cascadenik svn right?
15:28:51 <aub> yep. i compiled the stylesheet from cascadenik and using that
15:29:26 <aub> the server has only 360MB of memory, so i suspect that at least part of the problem is swapping
15:29:33 <springmeyer> k. data in mercator or wgs84?
15:29:41 <artem_> springmeyer: re: #235 - could you post output of gcc -v , please
15:29:41 <nikq> Ticket #235: g++: Internal error after r921, http://trac.mapnik.org/ticket/235
15:30:11 <springmeyer> you bet artem, thx!
15:30:14 <aub> springmeyer: i believe it's in mercator, tho a bit confused about projections :)
15:30:28 <artem_> I just compiled from source using : gcc -v
15:30:28 <artem_> Using built-in specs.
15:30:29 <artem_> Target: x86_64-linux-gnu
15:30:29 <artem_> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
15:30:31 <artem_> Thread model: posix
15:30:33 <artem_> gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)
15:30:51 <artem_> without any problems :D
15:30:58 <aub> sprigmeyer: converted using osm2pgsql, stored at lat/lng
15:30:58 <springmeyer> ah, cool
15:31:12 * springmeyer was worried he broke svn ;)
15:31:31 <springmeyer> $ gcc -v
15:31:31 <springmeyer> Using built-in specs.
15:31:31 <springmeyer> Target: i486-linux-gnu
15:31:31 <springmeyer> Thread model: posix
15:31:31 <springmeyer> gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)
15:31:43 <springmeyer> upps, I think that got cut off...
15:31:55 <springmeyer> http://dpaste.com/121704/
15:32:02 <artem_> ok, you're on 32-bit right ?
15:32:07 <springmeyer> yes
15:32:42 <springmeyer> maybe I'll try a clean checkout of svn...
15:32:57 <artem_> I wonder if you're running out of mem ? have you got a swap partition at all ?
15:33:14 <springmeyer> ah, that could be it
15:33:27 <artem_> yep, please. clean build would be cool
15:33:32 <springmeyer> its a VPS machine with only a bit of ram
15:33:47 <springmeyer> but the issue is strange since I can clean the build targets with scons
15:34:00 <springmeyer> and when I rebuilt it always hangs on 'rule.o'
15:34:09 <tomhughes> fine for me on 64 bit F10 (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC))
15:34:11 <springmeyer> which is why I was concerned
15:34:19 <springmeyer> okay, great (whew) :)
15:34:31 <springmeyer> doing a clean checkout now...
15:34:36 <tomhughes> strictly speaking that error is a gcc bug anyway, not a bug in your code
15:34:51 <springmeyer> :)
15:35:16 <tomhughes> actually I wonder if "Killed" means if got sigkill?
15:35:20 <tomhughes> maybe the OOM killed it
15:35:28 <springmeyer> I did read it, but figured the likely hood of a bug in gcc vs my code.... well...
15:36:55 <tomhughes> yeah, googling a bit I think the OOM got you because the machine ran out of memory
15:37:05 <springmeyer> ya, my hunch was that something wrong with the code/gcc prompted SCONS to burn through all the memory while the build process hung...
15:37:29 <springmeyer> it will hang on rule for upwards of 10-15 minutes
15:37:41 * springmeyer rebuilding from a clean checkout
15:37:44 <tomhughes> that file was quite slow to compile for me so I suspect it's just a nasty file that uses lots of memory to compile
15:37:57 <springmeyer> oh, i see
15:38:22 <artem_> yes, g++ is quite hungry for ram :)
15:38:29 <springmeyer> then it must be just mem limits.
15:38:55 <springmeyer> now that is a solvable issue on a VPS :)
15:38:58 <springmeyer> thanks guys
15:40:05 *** xcacou has quit (Remote closed the connection)
15:40:18 <springmeyer> so aub: if you reimport in mercator then mapnik won't need to reproject the data coming out of postgres - that will also save time (and memory :) )
15:40:36 <artem_> springmeyer: I would say, 512Mb of RAM is a bare minimum to compile mapnik in reasonable time.
15:41:12 <aub> springmeyer: thanks, will try that. i was using lat/lng on a suggestion that that was the thing to do for the 'google' projection
15:41:19 <springmeyer> gocha. guess I've been sneaking by till now
15:42:27 <tomhughes> aub: no, spherical merc (the default in osm2pgsql) is what you want for google
15:42:51 *** ninja__ (n=pankur@cm122.psi133.maxonline.com.sg) has joined #mapnik
15:42:58 <aub> tomhughes: cool, thanks
15:44:08 <aub> on a semi-related note, can anybody recommend a good book to help me learn the mapping-related concepts that i'm missing
15:44:20 <aub> which is pretty much all of them
15:48:00 <Berteun> aub: You mean like projections, coordinates, models for the shape of the earth and such?
15:48:16 <aub> Berteun: exactly
15:48:45 *** ninja_ has quit (Read error: 104 (Connection reset by peer))
15:48:54 <Berteun> Well, I can't help you with any books in particular, but I think : http://www.ordnancesurvey.co.uk/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf is a nice start.
15:48:57 *** ninja__ has quit ()
15:49:37 <Berteun> It at least helped me to get an idea about ellipsoids and geoids and all the stupid things you have to take care off when making a world wide coordinate system (like tectonics).
15:49:59 <aub> Berteun: thanks
15:52:57 *** matt_c (n=mcroydon@gateway.sunflowerbroadband.com) has joined #mapnik
16:09:51 <nikq> Mapnik Trac: Ticket #235 (g++: Internal error after r921) closed | http://trac.mapnik.org/ticket/235#comment:2
16:15:16 <springmeyer> hey aub: so I just booted up cascadenik styles on my local machine (mac os 2BG)
16:16:10 <springmeyer> even with that it takes just under 2 minutes to render a single tile of the whole world (given that the shapefile used is massive)
16:16:53 <springmeyer> but it only takes 4 seconds to render a tile of zoomed in data (around zoom level 13)
16:21:00 <springmeyer> aub: also latest svn now has this change:
16:21:01 <springmeyer> http://code.google.com/p/mapnik-utils/source/diff?spec=svn570&r=570&format=side&path=/trunk/serverside/cascadenik/openstreetmap/style.mml
16:21:34 <springmeyer> that will allow you to manually set extents (in google mercator) to the area you have OSM data for, which should speed things up a good bit
16:21:59 <springmeyer> let me know if you need help figuring out that 'extent' value
16:33:38 *** darragh has quit (Remote closed the connection)
16:46:49 <aub> springmeyer: thanks much. i'm going to check it out on a machine with a reasonable amount of memory and see where i get and will also check out setting the extent.
16:51:01 <CIA-23> mapnik-utils: cmarqu42 * r569 /sandbox/cascadenik/hike_n_bike/ (poi.mss rail.mss roads.mss routes.mss peaks.mss): Draw routes with the newish spacing parameter. Other small enhancements.
16:51:01 <CIA-23> mapnik-utils: dane.springmeyer * r570 /trunk/serverside/cascadenik/openstreetmap/style.mml: Add the ability to set a manual extent(in the case of estimate_extent=false), and generalize the options that users can customize in the XML entities
16:53:47 *** darragh (n=darragh@83.70.173.25) has joined #mapnik
16:54:47 <springmeyer> cmarqu: would be interested to know if you've been setting extents or not in your .mml files...
17:25:52 <darragh> Where should I set the projection for a layer when using TileCache?
17:26:48 <darragh> Sorry, wrong channel
17:41:31 *** artem_ has quit ()
17:49:38 <cmarqu> springmeyer: No, I have estimate_extent set to false, and also no explicit extents.
17:50:17 <cmarqu> springmeyer: The files are here BTW: http://mapnik-utils.googlecode.com/svn/sandbox/cascadenik/hike_n_bike/
17:50:41 <springmeyer> ya, just too lazy to look :)
17:51:25 <springmeyer> okay, well I'd try setting manual extents which is the best practice I think if estimate_extents is false
17:55:13 <cmarqu> 4 seconds per tile at zoom 13 is about what I am seeing, but it's much slower than that at zoom 10.
17:55:28 <cmarqu> But I also use a raster hillshading image
17:57:55 *** xcacou (n=aga@154.35.86-79.rev.gaoland.net) has joined #mapnik
17:58:19 <springmeyer> xcacou: ping
17:58:35 <xcacou> hello
17:58:45 <springmeyer> hey :)
17:59:17 <springmeyer> you have a chance to test the OGCServer code lately?
18:00:46 <xcacou> no recently
18:01:01 <xcacou> why ?
18:01:56 <springmeyer> r901
18:01:57 <nikq> http://trac.mapnik.org/changeset/901, at , by dane: OGCServer: add support for load_map() within WMSFactory (thanks xcacou,theosys,and tmcw for early patches) (closes #129)
18:03:16 <springmeyer> also #226
18:03:17 <nikq> Ticket #226: OGCServer Style and Layer ordering with load_map() support, http://trac.mapnik.org/ticket/226
18:05:44 <xcacou> i look this WE if you want
18:06:31 <springmeyer> great
18:06:45 <xcacou> more tomorrow because I am moving in paris
18:07:26 <xcacou> for work
18:07:53 <springmeyer> cool - you looking forward to it?
18:09:25 <xcacou> in Paris no but in the mapnik code yes
18:09:30 <xcacou> ;)
18:10:18 <xcacou> my new project is a management of det
18:10:24 <xcacou> deaths
18:11:13 <springmeyer> oh my
18:13:17 <xcacou> i go to eat (here it's 19h13)
18:13:25 <xcacou> bye
18:55:12 *** sanjiv has quit ("ChatZilla 0.9.84 [Firefox 3.0.6/2009020911]")
19:26:23 <cytrinox_> hi
19:27:04 <cytrinox_> how can I change the TTF location if I build mapnik from svn?
19:27:05 <cytrinox_> >>> from mapnik import *
19:27:05 <cytrinox_> ### WARNING: No ttf files found in '/home/cytrinox/src/mapnik/inst/usr/lib/mapnik/fonts'.
19:29:43 <springmeyer> cytrinox_: did you use a custom prefix?
19:30:23 <springmeyer> I'd like to know how the bindings ended up looking in that location - it seems quite odd
19:30:42 <cytrinox_> yes. I need to compile it as user on my user-vserver, build a *.deb file and install it on the main server
19:30:51 <springmeyer> there it currently no way to configure the fontspath, it defaults to the lib directory
19:31:07 <cytrinox_> phuu..
19:31:16 <springmeyer> but it would not be hard to add
19:31:32 <springmeyer> just another PathVariable in the main SConstruct
19:31:36 <cytrinox_> in which file the path is used? I can change that file and build a new *.deb
19:32:17 <springmeyer> for a quick hack look in 'BINDINGS/PYTHON/SCONSCRIPT'
19:32:56 <cytrinox_> fontscollectionpath = mapniklibpath + '/fonts'
19:32:59 <cytrinox_> bingo
19:33:06 <springmeyer> ie: http://patch-tracking.debian.net/patch/misc/view/mapnik/0.5.1-3/bindings/python/SConscript
19:34:01 <springmeyer> but configuring the fontscollectionpath during SCons configure would not be a bad option to have
19:37:36 <springmeyer> cytrinox_: that previous path... you used a custom prefix to build mapnik - that makes sense. by why did no fonts end up in there?
19:37:53 <springmeyer> I'd like to know/figure that out - seems buggy to me
19:38:37 <cytrinox_> I'm using python scons/scons.py PREFIX=/home/cytrinox/src/mapnik/inst/usr PYTHON_PREFIX=/home/cytrinox/src/mapnik/inst/usr install
19:39:39 <cytrinox_> ..maybe this is the wrong way
19:39:52 <springmeyer> okay.
19:40:04 <springmeyer> well I only have recently added PYTHON_PREFIX in trunk
19:40:15 <springmeyer> your usage is correct
19:40:29 <cytrinox_> ok
19:40:31 <springmeyer> but, where did the fonts go? can you tell?
19:40:58 <cytrinox_> after install the fonts are located in /usr/lib/mapnik/fonts
19:41:05 <cytrinox_> ..seems correct :)
19:41:24 <springmeyer> well...
19:42:08 <springmeyer> not exactly since I would think that if a user is specifying the prefix then  the fonts directory should also be relative to that PREFIX
19:43:14 <cytrinox_> hmm. maybe I should use PREFIX=/usr and ROOT_??=/home/cytrinox/src/mapnik/inst
19:43:42 <cytrinox_> I don't know the exact name
19:43:59 <springmeyer> generall DEST_DIR is designed to build packages and move everything to a given root
19:44:30 <springmeyer> but either way it is a bug if PREFIX causes python to look for fonts in the wrong location (or at least somewhere they are not)
19:44:48 <springmeyer> cytrinox_: could you file a ticket?
19:45:02 <springmeyer> .startrss
19:45:03 <nikq> Okay, I'll re-start rss...
19:45:19 <springmeyer> #72
19:45:20 <nikq> Ticket #72: Support MAPNIK_VERSION, http://trac.mapnik.org/ticket/72
19:45:46 <springmeyer> Anyone have comments on #72 ?
19:45:47 <nikq> Ticket #72: Support MAPNIK_VERSION, http://trac.mapnik.org/ticket/72
19:45:55 <cytrinox_> springmeyer: wait a moment. I think that isn't a bug, I have to use DESTDIR. Hel description for DESTDIR: DESTDIR: The root directory to install into. Useful mainly for binary package building
19:46:14 <springmeyer> right
19:46:34 <cytrinox_> python scons/scons.py PREFIX=/home/cytrinox/src/mapnik/inst PREFIX=/usr PYTHON_PREFIX=/usr should work as expected :)
19:46:53 <springmeyer> huh?
19:47:19 <cytrinox_> ehhh
19:47:21 <cytrinox_> :)
19:47:33 <cytrinox_> python scons/scons.py DESTDIR=/home/cytrinox/src/mapnik/inst PREFIX=/usr PYTHON_PREFIX=/usr should work as expected :)
19:48:44 <springmeyer> ah, I see, since you want mapnik to __look__ to /usr but to be built in DESTDIR
19:49:10 <cytrinox_> correct
19:49:41 <springmeyer> cytrinox_: then start a wiki page here: http://trac.mapnik.org/wiki/UsingScons :)
19:50:42 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
19:51:43 <cytrinox_> >>> from mapnik import *
19:51:43 <cytrinox_> >>>
19:51:48 <cytrinox_> ..great :-)
19:53:54 <cytrinox_> hm
19:54:02 <artem> cytrinox_ : try : >>> mapnik.mapnik_version_string()
19:54:10 <cytrinox_> the bug isn't fixed :(
19:54:39 <springmeyer> hey artem: ya, I was looking at the boost/version.hpp too :)
19:55:01 <springmeyer> perhaps I don't understand how the number gets incremented
19:57:04 <cytrinox_> artem: NameError: name 'mapnik' is not defined ... huu?
19:57:35 <artem> cytrinox_:  opps, just mapnik_version_string() sorry
19:57:47 <cytrinox_> '0.6.0
19:57:51 <artem> good :D
19:58:14 <artem> springmeyer : 100000 == 1.0.0 :)
19:58:35 <springmeyer> ah, there you go :)
19:58:57 <springmeyer> okay, so what is the best way to pull out the lib ABI from the VERSION number?
19:59:29 <springmeyer> I figure during the SCons build we should pull from the /mapnik/version.hpp
19:59:36 <cytrinox_> hrm :(
19:59:42 <cytrinox_> http://map.terminal.io/?zoom=14&lat=6319236.10549&lon=944268.41101&layers=BT
19:59:43 <springmeyer> (rather than setting that value from SCons)
19:59:55 <cytrinox_> the two shields are cutted-of
20:00:27 <cytrinox_> same bug as with 0.5.1
20:00:27 <artem> springmeyer : the same way it's done in boost libs
20:01:05 <artem> cytrinox_ : are you using mod_tile ? or generate_tiles.py? or somethings else ?
20:01:20 <cytrinox_> artem: generate_tiles.py
20:01:39 <cytrinox_> yesterday we have already checked that the offset workaround is active
20:01:54 <springmeyer> artem: you mean we should have 	#define MAPNIK_LIB_VERSION "0_60" ?
20:02:43 <artem> springmeyer: not really, we should just extract  ABI x.x.x from MAPNIK_VERSION
20:03:33 <springmeyer> okay. humm...
20:05:21 <artem> def mapnik_version_string():
20:05:22 <artem>   version = mapnik_version()
20:05:22 <artem>   patch_level = version % 100
20:05:22 <artem>   minor_version = version / 100 % 1000
20:05:22 <artem>   major_version = version / 100000
20:05:22 <artem>   return '%s.%s.%s' % ( major_version, minor_version,patch_level)
20:05:26 <springmeyer> ack
20:05:38 * springmeyer was about to say, ya I'll just use that function :)
20:05:42 <springmeyer> duh :)
20:08:53 <artem> cytrinox_ : I think you should use meta_files (render big maps and chop it up into tiles) . I can post something to get you started later on. I need to run now BBL
20:09:25 <springmeyer> artem: great, I'll commit this fix then - hopefully you can review later on...
20:09:38 <artem> great sure
20:09:41 <springmeyer> will close #72
20:09:42 <nikq> Ticket #72: Support MAPNIK_VERSION, http://trac.mapnik.org/ticket/72
20:09:47 <springmeyer> and #229
20:09:47 <nikq> Ticket #229: SCons needs to check for boost-python if building python bindings, http://trac.mapnik.org/ticket/229
20:10:01 <artem> I thinks so I don't see any problem with current approach
20:10:08 <springmeyer> and addresses a boost_version issue as well
20:10:17 <artem> yep.
20:10:27 <springmeyer> right, just need to __use__ the current approach in SCons to set the ABI for the lib
20:10:57 <artem> sounds good
20:10:58 <springmeyer> works great now that I understand how the incrementing works - brilliant
20:11:07 <artem> magic :()
20:11:13 <springmeyer> yep
20:11:14 <artem> ;)
20:11:44 <springmeyer> hopefully will begin to address #230 too
20:11:45 <nikq> Ticket #230: python module links against /usr/lib instead of /usr/local/lib64, http://trac.mapnik.org/ticket/230
20:13:24 <artem> springmeyer : on the same topic, I had problems with GDAL/OGR default lib paths on ubuntu x86_64
20:13:49 <artem> ubuntu doesn't have /usr/lib64 /usr/local/lib64 by default
20:14:32 <artem> there must be some trick we can use to avoid Scons borking
20:14:46 <springmeyer> yes, okay good to know
20:14:58 <springmeyer> just need to add  a PathVariable.PathAccept
20:15:06 <springmeyer> == Scons please don't bork
20:15:25 <artem> yep, would be smashing
20:15:34 <springmeyer> i guess we should add it for everything ?
20:15:50 <artem> why not
20:15:59 <springmeyer> there would not likely be any harm except SConstruct readility
20:16:10 <springmeyer> (which is already shot due to my mucking ;) )
20:17:07 <artem> BTW,  I managed to compile latest trunk (well almost) on  msvc_9_0
20:17:19 <springmeyer> Woot!
20:18:30 <artem> springmeyer : I think (at least for 0.6.0) default parser on win32 will be tinyxml :P
20:18:48 <artem> libxml2 is just a can of worms
20:18:53 <springmeyer> okay, good to know
20:19:08 <artem> it wants iconv and all that crap
20:19:10 <springmeyer> should we switch back in general?
20:19:36 <artem> I like <ENTITY ... > stuff
20:19:55 <artem> I think on *nix libxml2 is no probs
20:20:03 <springmeyer> ah, that is true. and now load_map_from_string()
20:20:08 <springmeyer> k, sounds good
20:20:36 * artem bbl
20:21:50 <Mrfo> does the lack of libxml2 remove entity support in win32?
20:22:00 <springmeyer> yes
20:22:04 <Mrfo> doh :(
20:22:14 <springmeyer> unless you preprocess with cascadenik
20:25:17 <nikq> Mapnik Trac: Ticket #236 (Better testing for boost version in SCons) created | http://trac.mapnik.org/ticket/236
20:31:04 <nikq> Mapnik Trac: Changeset [923]: scons: make sure to check for boost_python (closes #229), improve checking  ... | http://trac.mapnik.org/changeset/923
20:33:05 <nikq> Mapnik Trac: Ticket #72 (Support MAPNIK_VERSION) closed | http://trac.mapnik.org/ticket/72#comment:12
20:34:07 <nikq> Mapnik Trac: Ticket #229 (SCons needs to check for boost-python if building python bindings) closed | http://trac.mapnik.org/ticket/229#comment:1
20:37:20 *** artem has quit ()
20:38:02 *** xcacou has quit (Remote closed the connection)
20:38:37 *** matt_c has quit (Read error: 104 (Connection reset by peer))
20:39:22 *** matt_c_ (n=mcroydon@gateway.sunflowerbroadband.com) has joined #mapnik
20:40:32 *** matt_c_ is now known as matt_c
20:42:29 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
20:46:38 <artem> milestone 0.6.0
20:46:39 <nikq> 33 open tickets in Milestone 0.6.0: Names on areas don't seem to be correctly centered in the vertical axis, Stroke border, Ability to set label value manually in TextSymbolizer (rather than have them read from datasource field), Crashing with TextSymbolizer and line placement., Update Install Document on Mapnik.org by release and trunk, Path env variable behaving strangely on Windows binary, Mapn...
20:46:40 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.6.0&order=priority
20:46:41 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.6.0
20:50:08 <CIA-23> mapnik: dane * r923 /trunk/SConstruct:
20:50:08 <CIA-23> mapnik: scons: make sure to check for boost_python (closes #229), improve checking of
20:50:08 <CIA-23> mapnik: boost version (closes #236), and fetch ABI version from mapnik/version (closes
20:50:08 <CIA-23> mapnik: #72), as well as adding PathAccept for all PathVariables to account for various
20:50:08 <CIA-23> mapnik: 64bit systems.
20:50:09 <CIA-23> mapnik: dane * r924 /trunk/src/SConscript: + inherit libmapnik ABI version from environment (now calculated in SConstruct)
20:59:19 *** matt_c has quit (Read error: 104 (Connection reset by peer))
21:00:34 *** matt_c_ (n=mcroydon@gateway.sunflowerbroadband.com) has joined #mapnik
21:00:38 *** matt_c_ is now known as matt_c
21:00:55 *** cytrinox_ has parted #mapnik ()
21:05:12 <springmeyer> artem: yesterday I added 0.6.1 and 0.7.0 in case those would be useful if/when tickets get pushed off of 0.6.0
21:05:35 <artem> yes, I saw it. good idea.
21:12:32 <nikq> Mapnik Trac: Ticket #168 (Ability to register fonts during load_map()) updated | http://trac.mapnik.org/ticket/168#comment:6
21:13:09 <artem> springmeyer: would you like to help testing win32 (assuming you have access to windows somehow) ?
21:13:36 <springmeyer> yes
21:13:42 * artem think springmeyer is close enough to redmont to have a copy of vista
21:13:50 <springmeyer> I can run win32 within a paralells instance
21:13:54 <springmeyer> he he
21:14:02 <springmeyer> ya grew up just down the road
21:14:12 *** matt_c has quit ()
21:14:17 <springmeyer> but surely not of that world :)
21:14:33 <artem> :) cool I'll upload the latest the greatest and mail you a link
21:14:50 * springmeyer only has XP unfortunetly but perhaps could track down Vista
21:15:01 <springmeyer> okay, sounds good
21:15:10 <artem> even better (xp)
21:15:38 <Mrfo> i can help test with both if you like
21:15:52 * springmeyer paid for an xp install disc just in time
21:15:57 <Mrfo> my workstation is vista, my test box is xp, and we deploy on linux
21:16:01 <springmeyer> Mrfo: cool
21:16:40 <springmeyer> Mrfo: have you been tracking trunk at all on linux? I would appreciate any testing possible of the new SCons behavior.
21:17:04 *** matt_c (n=mcroydon@gateway.sunflowerbroadband.com) has joined #mapnik
21:17:08 <nikq> Mapnik Trac: Ticket #174 (Better exception handling for shape.input) updated | http://trac.mapnik.org/ticket/174#comment:1
21:17:33 <Mrfo> i haven't updated in a month or two, but i can do that now
21:19:18 <nikq> Mapnik Trac: Ticket #232 (Compiling python bindings to .pyc during install) updated | http://trac.mapnik.org/ticket/232#comment:2
21:19:26 <springmeyer> cool, thx!
21:20:26 *** matt_c has quit (Client Quit)
21:22:05 <artem> Mrfo : most welcome!
21:22:13 * artem starting up wndowz
21:22:23 <artem> on macmini
21:30:25 <Mrfo> springmeyer, seems the SConstruct file has changed a decent bit since I last updated. will i have issues copying my options over?
21:31:15 <springmeyer> what do you mean by options? your custom command line options?
21:31:33 <Mrfo> yeah
21:31:44 <springmeyer> in general I'm interested in your experience if you dive in blindly :)
21:31:54 <Mrfo> heh okay
21:31:57 <springmeyer> that way I'll have more feedback on how to recommend the upgrade
21:32:18 <springmeyer> so far it looks like the recommended approach is going to be either
21:32:32 <Mrfo> i dont know much about the libraries needed for sqlite and occi though
21:32:41 <springmeyer> * make sure to check out a fresh version if you are rebuilding from svn *
21:32:56 <springmeyer> or make sure to $ sudo rm .scon*
21:33:13 <Mrfo> yeah i grabbed a completely new version
21:33:16 <springmeyer> since all the temp scons files are likely going to screw folks up
21:33:17 <springmeyer> okay
21:33:57 <springmeyer> Mrfo: regarding dependencies part of the refactor makes it such that the right things are optional and if anything is required, SCons won't bail till the bitter end :)
21:35:50 <Mrfo> in that case i'll skip adding sqlite and oracle support and make sure that feature works
21:36:19 <springmeyer> exactly
21:42:53 <nikq> Mapnik Trac: Changeset [925]: minor text formatting | http://trac.mapnik.org/changeset/925
21:50:09 <artem> springmeyer :  I cannot access ~/mapnik_org_media/ as it 's owned by you :) could changes permissions, please
21:51:45 <artem> I'd like to copy ~/mapnik_0_6_0.zip to theew
21:51:49 <artem> there
21:51:56 <springmeyer> ugh. I can't
21:52:20 <springmeyer> you should be in the mapnik group thus be able to read/write
21:52:39 <springmeyer> but in general all those folders should be artem:mapnik
21:52:54 <springmeyer> hmm...
21:53:49 <springmeyer> I had no idea how I own that.
21:54:00 <artem> as a workaround, could you mv /home/artem/mapnik_0_6_0.zip /home/artem/mapnik_org_media ??
21:54:08 <springmeyer> :)
21:54:12 <springmeyer> sure I'll try
21:54:46 <springmeyer> cool, that did work
21:55:09 <Mrfo> http://pastebin.com/d5dbbf191
21:55:31 <artem> :) ok, http://media.mapnik.org/mapnik_0_6_0.zip are the latest win32 with ICU support (only shape and sqlite input plug-ins atm)
21:56:12 <springmeyer> yup Mrfo: okay I'm on it
21:56:15 <springmeyer> one sec
21:56:23 <springmeyer> awesome thx artem
22:00:31 <CIA-23> mapnik: dane * r925 /trunk/ (README AUTHORS): minor text formatting
22:09:12 <springmeyer> oh man. my custom version checking is clearly not working on linux
22:09:41 *** jburgess has quit (Remote closed the connection)
22:10:04 <springmeyer> sorry about that Mrfo - I just added that stuff this morning.
22:10:22 <springmeyer> Mrfo: for now can you test with $svn up -r 921
22:10:26 <Mrfo> just happy to help out
22:10:31 <Mrfo> kk
22:11:03 <springmeyer> artem: can you help out with advising on how to write the C++ snippet to grab the mapnik/version.hpp ?
22:11:41 <springmeyer> what I came up with was modeling on a boost snippet I found, but it clearl needs improvement
22:11:55 <springmeyer> r923
22:11:57 <nikq> http://trac.mapnik.org/changeset/923, at , by dane: scons: make sure to check for boost_python (closes #229), improve checking of boost version (closes #236), and fetch ABI version from mapnik/version (closes #72), as well as adding PathAccept? for all
22:12:43 <springmeyer> artem: line 314 would be the spot
22:12:46 <Mrfo> things seem to be going smoother this time. its compiling atm
22:14:22 <artem> springmeyer : sure, so what do you get on linux ?
22:15:10 <springmeyer> well, the current code is failing to return a value, and my python implementation therefore fails on a list index error
22:15:48 <artem> springmeyer : shouldn't you just return MAPNIK_VERSION ?  int main() { return MAPNIK_VERSION ; }
22:15:52 <springmeyer> ie, the std:cout is returning an empty string
22:16:38 <springmeyer> ya, that makes sense but the context.TryRun seems to only want to return a string
22:17:14 <springmeyer> ie I tried that it it also returned nothing (but I will try that on linux now)
22:18:51 <springmeyer> hum, yup that works great on ubuntu, cool
22:19:03 * springmeyer goes back to test on mac os
22:19:22 <springmeyer> er wait, maybe spoke too soon...
22:24:16 <springmeyer> ya, him, can't get that to return anything to Scons
22:25:11 <artem> springmeyer : not related to this problem, but you should return something from main e.g return 0;
22:25:18 <artem> of even better :
22:25:27 <artem> return EXIT_SUCCESS;
22:25:46 <springmeyer> okay, thx
22:27:10 <Mrfo> springmeyer, seemed to compile okay. still need to test to make sure it all works though
22:27:19 <springmeyer> kk
22:28:07 <artem> springmeyer : try adding    std::endl  (to flush buffer) e,g :
22:28:24 <artem> std::cout << MAPNIK_VERSION << std::endl;
22:28:53 <artem> just an idea
22:29:27 <springmeyer> ya, that is what works on os x: http://trac.mapnik.org/browser/trunk/SConstruct?rev=923#L321
22:30:14 <artem> ok, it should work in win/linux as well
22:31:26 <springmeyer> ah perfect the EXIT_SUCCESS seems to do the trick
22:31:40 <springmeyer> ack, nevermind
22:33:13 <springmeyer> error: EXIT_SUCCESS was not declared in this scope....
22:34:47 <artem> ok, just return 0; then :D
22:36:31 <CIA-23> mapnik: artem * r926 /trunk/include/mapnik/agg_renderer.hpp: + use class/struct keywords correctly
22:37:48 *** jburgess (n=jburgess@bb-87-80-234-70.ukonline.co.uk) has joined #mapnik
22:41:51 <springmeyer> yup that worked
22:41:58 <artem> cool
22:41:58 <springmeyer> thank you artem
22:42:09 <springmeyer> Mrfo: can you try with latest now?
22:42:49 <Mrfo> sure 1 sec
22:44:07 <springmeyer> thanks
22:44:22 <springmeyer> bbl
22:44:47 <Mrfo> think it failed again, but your error checking caught it and kept going
22:44:57 <Mrfo> http://pastebin.com/d2fdf3bb4
22:45:30 <springmeyer> ack, okay
22:48:25 <springmeyer> try one more time?
22:49:23 <artem> springmeyer: I'll try in a few minutes, too
22:54:20 <springmeyer> thx artem
22:54:50 <springmeyer> works for me now on ubuntu 8.04 and 8.10
22:55:31 <springmeyer> note: since we're pulling from the mapnik/version.hpp its now symlinking libmapnik.so.0.6 (which required running ldconfig for me)
22:55:39 * springmeyer heads out for a bit
23:17:22 <CIA-23> mapnik: dane * r927 /trunk/SConstruct: scons: make sure to return 0 to keep linux happy
23:17:22 <CIA-23> mapnik: dane * r928 /trunk/SConstruct: scons: move the mapnik version checking later in script, after local paths have been added
23:19:28 <nikq> Mapnik Trac: Changeset [929]: + fix msvc-9.0 compiler warnings | http://trac.mapnik.org/changeset/929
23:27:39 * springmeyer back
23:28:26 <springmeyer> artem: if the win32 builds go well I would love to get mapnik included in osgeo4w - have you ever considered that?
23:28:27 <springmeyer> http://trac.osgeo.org/osgeo4w/wiki/PackageListing
23:29:16 <springmeyer> nosgeo4w attempts to share dependencies, and I notice that libxml2 is already there: http://download.osgeo.org/osgeo4w/versions.html
23:30:53 <artem> springmeyer : sure
23:34:47 <artem> springmeyer: I believe all that bunch compiled using mingw, mapnik is built using native msvc-9.0 and linked multi-threaded DLL runtime
23:36:42 <artem> windows is very fussy about runtimes ..
23:39:33 <springmeyer> okay, so you think it could be trick/not viable to get packaged that way?
23:41:08 * artem back 
23:41:36 <artem> i think having some deps like libxml2 won't be helpful
23:41:49 <artem> well, will be useless
23:41:53 <springmeyer> ahh, okay I see
23:42:22 <artem> also, that list feels like 70s gis to me  :)
23:42:29 <artem> wtf grass
23:42:31 <springmeyer> awesome >>> import mapnik # works on xp
23:42:33 <springmeyer> lol!
23:42:58 <springmeyer> well ya I'm not a grass users either, which is why we've got to get mapnik on that list :)
23:43:17 <artem> yeah, you're right
23:43:31 <artem> could you render a map with rundemo.py ?
23:43:59 * springmeyer will go grab it....
23:44:21 <artem> opps, sorry I forgot to pkg it
23:44:23 * springmeyer wonders if he should navigate back to the mapnik source on the os x filesystem :)
23:44:45 <artem> sure, it might work
23:45:58 <springmeyer> sweet
23:46:12 <springmeyer> nik2img doctests work great
23:46:16 * springmeyer gets a call
23:46:17 <springmeyer> brb
23:46:44 <artem> blue screen of death ??
23:48:34 <artem> springmeyer : are you there ? what's up ?
23:54:41 <CIA-23> mapnik: artem * r929 /trunk/ (7 files in 2 dirs): + fix msvc-9.0 compiler warnings
23:56:01 *** ninja_ (n=pankur@nat/yahoo/x-021bb4cdb95ee579) has joined #mapnik