00:00:00 <jbaird> springmeyer: and adapt this code? http://mapnik-utils.googlecode.com/svn/example_code/google_mercator_projection/world_mercator.py 00:00:04 <springmeyer> is your projection canada wide? 00:00:14 <springmeyer> or did I hit the wrong one? do you know? 00:00:34 <jbaird> springmeyer: I didn't see anything in the metadata about canada, no 00:01:41 <springmeyer> well # 133 on sr.org says that is the proj for LCC canada (small text) 00:02:09 <springmeyer> maybe dpaste your '.prj' file from your shapefile? 00:02:19 <artem> jburgess: shoreline_300 seems to have some bad tiles, is it 'simplify' magic ? 00:02:49 <jburgess> I think they are an error in the coastcheck utility 00:03:42 <artem> ok, thanks 00:03:44 <jburgess> I think i've spotted maybe 5 around the world, they disappear at higher zoom where the coastcheck tool uses some different parameters 00:03:53 <springmeyer> jbaird: once you have the right projection in proj4 format assign it like: http://dpaste.com/115920/ 00:04:00 <jbaird> springmeyer: http://dpaste.com/115921/ 00:05:11 <springmeyer> okay jbaird: that looks to me like the cali teal albers 00:05:23 <springmeyer> .g site:spatialreference.org teal albers 00:05:24 <nikq> springmeyer: No results found for 'site:spatialreference.org teal albers'. 00:05:38 <jburgess> artem: the slightly odd thing with them is that they don't show up as data errors on the coastline checker (many of the bad ones used to be due to bad coastline data confusing the utility) 00:05:45 <springmeyer> ah, but it is lambert, huh... 00:07:15 <forrestv> how can i configure the python bindings to release the GIL? 00:07:48 <CIA-23> mapnik: artem * r856 /trunk/bindings/python/mapnik_map.cpp: 00:07:48 <CIA-23> mapnik: + reflect buffered_envelope method 00:07:48 <CIA-23> mapnik: + fix view_transform to return ctrans (TODO) 00:08:36 <artem> forrestv: in particular call ?? tell us more 00:09:02 <springmeyer> ah jbaird, this looks close... 00:09:03 <jburgess> forrestv: in the SVN version it releases the lock in the common render() calls 00:09:05 <springmeyer> .g site:spatialreference.org 102643 00:09:05 <nikq> springmeyer: http://spatialreference.org/ref/esri/102643/ 00:09:07 <forrestv> artem, when using threading, map.render blocks all other threads due to the GIL 00:09:12 <forrestv> jburgess, ah, cool 00:09:20 <artem> not anymore 00:09:24 <forrestv> artem, why? 00:09:39 <jbaird> springmeyer: thanks for the spatialreference.org tip, didn't know that was there 00:09:52 <springmeyer> jbaird: how can you live without it? 00:09:54 <artem> it doesn't block I meant to say 00:10:14 <jbaird> springmeyer: I've only been doing this for one day, so, from now on probably not 00:10:20 <forrestv> oh, i thought you were responding to jburgess :P 00:10:43 <springmeyer> :) one day and you are rendering with mapnik? not possible! 00:11:05 <jburgess> forrestv: the threading got enabled around commit r809 (actually that was a bug fix for the threading... but you can see the changes there) 00:11:06 <nikq> http://trac.mapnik.org/changeset/809, at , by artem: + mapnik-fix-threaded-python-exceptions.patch from jonb 00:11:18 <forrestv> thanks! 00:12:06 <jbaird> springmeyer: hmm, by adding the layer srs before adding it to the map the map is now blank 00:12:34 <jbaird> I guess I could just use the layers coordinate space, I just didn't understand that it was in meters at first 00:12:55 * springmeyer looks back at the code... 00:13:12 <jburgess> must go now... bye all. 00:14:20 <springmeyer> oh jbaird: comment out 'm.pan_and_zoom(491, 420, .5)' 00:14:32 <springmeyer> cheers jburgess 00:14:49 <jbaird> springmeyer: still blank 00:15:06 <jbaird> springmeyer: let me paste the new code 00:15:09 <springmeyer> try m.zoom_all() 00:15:25 <springmeyer> sure 00:15:54 <jbaird> ho! there it is, and envelope is reporting in lat/lng 00:16:27 <jbaird> springmeyer: now does that mean I can't zoom? 00:17:14 <springmeyer> standard way to zoom is the zoom_to_bbox() 00:17:29 <springmeyer> the zoom() is 'zoom by a factor of...) 00:17:54 <springmeyer> and the pan is the the pixel space of the graphic not coordinates IIRC 00:18:48 <springmeyer> jbaird: what is the big picture? ie do you want to crop your map at specific extents or just learning? 00:19:18 <jbaird> springmeyer: just learning 00:19:32 <springmeyer> cool. 00:19:40 <jbaird> springmeyer: thanks for all the help 00:20:00 <springmeyer> well for learning I find it must easier to play with mapnik with the map and the data in long/lat 00:20:33 <springmeyer> so you could reproject your data to long/lat with ogr2ogr perhaps? 00:20:33 <jbaird> springmeyer: yeah, I was going to play with javascript overlays though, thinking that the data may be easier to use with meters though 00:21:03 <jbaird> I'm guessing proj4js kind of does that though, right? 00:21:07 <springmeyer> so going to play with OpenLayers? 00:21:20 <jbaird> springmeyer: no, just doing my own overlays 00:21:43 <springmeyer> 'own overlays' ? 00:22:09 <springmeyer> yes proj4js will allow you to do transformations between crs's in js... 00:22:14 <CIA-23> mapnik-utils: cmarqu42 * r529 /sandbox/cascadenik/hike_n_bike/ (7 files): First stab at supporting routes. 00:22:51 <jbaird> springmeyer: yeah, nothing like openlayers does, for example I want to be able to use the bay area in a top down game. I'll be drawing my own layers on top of this image 00:23:13 <jbaird> springmeyer: so meters may be better to work with overall 00:23:44 <springmeyer> sure, if you think in meters that's great 00:24:20 <springmeyer> so drawing in javascript - with cavas or something like that? 00:24:25 <springmeyer> canvas i mean... 00:24:25 <jbaird> springmeyer: yeah 00:24:47 <springmeyer> okay, cool sounds like fun 00:25:07 <jbaird> springmeyer: and I like the level of realism mapnok gives, plus I know python, so it seemed a good idea at the time. If anything you learn something else 00:25:14 <jbaird> s/mapnok/mapnik 00:25:56 <springmeyer> ya. mapnik is rewarding to learn 00:26:52 <jbaird> springmeyer: plus I guess 1º ~ 1 nautical mile, so the conversion to meters wouldn't be to hard if needed 00:27:15 <jbaird> err, on 1minute 00:33:36 *** ajturner has quit () 00:37:09 * cmarqu wants LinePatternSymbolizer to have a MinSpacing 00:37:56 <cmarqu> Otherwise you have to resort to shields like in http://turaterkep.hostcity.hu/?zoom=15&lat=47.74324&lon=18.89841&layers=BF 00:38:27 <Mrfo> why not just create more than one shield 00:39:49 <cmarqu> Mrfo: I suppose it would still try to cram two shields into a short way and be spaced out for a long way? 00:42:09 <Mrfo> i was thinking you could have trees with different buffer sizes around them maybe 00:42:50 <Mrfo> btw, that overlay you have is quite nice 00:43:02 <cmarqu> Mrfo: That's not my map unfortunately 00:43:15 <cmarqu> I'm also wondering how he did it :) 00:43:15 <Mrfo> ohh 00:43:46 <cmarqu> I'm working on http://opentiles.com/cmarqu myself 00:43:49 <Mrfo> the osm wiki has some instructions for making things like that 00:44:12 <Mrfo> quite nice 00:45:13 <cmarqu> Getting the parameters right it quite some experimentation even with instructions. The .hu guy has it right with the transparency. 00:45:35 <artem> cmarqu: file a ticket for 1.0.0 00:45:55 <cmarqu> artem: Ok, will do 00:46:05 <artem> tnx 00:47:12 <artem> jburgess: would applying daily diffs with osm2pgsql -a work ? 00:58:30 <CIA-23> mapnik-utils: cmarqu42 * r530 /sandbox/cascadenik/hike_n_bike/ (51 files in 2 dirs): Add Mike's original icons, and some hiking symbols. 01:33:51 *** D3f0 (n=defo@190.176.219.207) has joined #mapnik 01:33:54 *** artem has quit () 01:38:15 *** ajturner (n=ajturner@pool-96-231-158-101.washdc.fios.verizon.net) has joined #mapnik 01:48:16 *** jbaird has quit () 02:35:54 <CIA-23> mapnik-utils: cmarqu42 * r531 /sandbox/cascadenik/hike_n_bike/ (routes.mss style.mml): Better route support. Use PointSymbolizer instead of ShieldSymbolizer, the latter always wanted to print text. 02:59:00 <nikq> Mapnik Trac: Changeset [857]: + add Marcin Rudowski to authors list for patchs applied in r854 and r855 | http://trac.mapnik.org/changeset/857 03:05:13 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) closed | http://trac.mapnik.org/ticket/170#comment:14 03:07:57 *** jbaird (n=jbaird@c-24-23-238-70.hsd1.ca.comcast.net) has joined #mapnik 03:21:22 *** ajturner has quit () 03:23:56 *** rcoup_ (n=rcoup@ip-118-90-96-141.xdsl.xnet.co.nz) has joined #mapnik 03:29:01 *** ajturner (n=ajturner@pool-96-231-158-101.washdc.fios.verizon.net) has joined #mapnik 03:29:03 <CIA-23> mapnik: dane * r857 /trunk/AUTHORS: + add Marcin Rudowski to authors list for patchs applied in r854 and r855 03:29:03 <CIA-23> mapnik: dane * r858 /trunk/include/mapnik/placement_finder.hpp: Fix compiler warnings introduced in r855 by moving allow_overlap below has_dimensions 03:29:03 <nikq> http://trac.mapnik.org/changeset/855, at , by artem: + mapnik_text_overlap.patch (Marcin Rudowski) 03:29:05 <nikq> http://trac.mapnik.org/changeset/855, at , by artem: + mapnik_text_overlap.patch (Marcin Rudowski) 03:39:16 *** rcoup has quit (Read error: 110 (Connection timed out)) 03:43:42 <nikq> Mapnik Trac: Ticket #173 (Accept multi-line SQL queries in table parameter) updated | http://trac.mapnik.org/ticket/173#comment:3 03:45:41 <nikq> Mapnik Trac: Ticket #63 (Support for OSX Leopard and Solaris (using Sun Studio compiler)) closed | http://trac.mapnik.org/ticket/63#comment:7 03:46:20 *** ajturner has quit () 03:52:02 <CIA-23> mapnik-utils: dane.springmeyer * r532 /sandbox/ (multiline_tests multiline_tests/mapfile.xml): Add wacked out multiline queries with tabs the line breaks to try to trip up mapnik postgres driver - see #173 03:52:02 <nikq> Ticket #173: Accept multi-line SQL queries in table parameter, http://trac.mapnik.org/ticket/173 04:14:18 *** rcoup_ has quit () 06:19:43 *** jbaird has quit () 06:32:46 *** jbaird (n=jbaird@c-24-23-238-70.hsd1.ca.comcast.net) has joined #mapnik 06:48:38 *** __d3f0__ (n=defo@190.176.195.125) has joined #mapnik 07:06:11 *** D3f0 has quit (Read error: 110 (Connection timed out)) 07:11:27 *** d3f0 (n=defo@190.176.198.236) has joined #mapnik 07:20:23 *** d3f0 has quit (Read error: 60 (Operation timed out)) 07:27:13 *** __d3f0__ has quit (Read error: 110 (Connection timed out)) 07:30:41 *** __D3f0__ (n=defo@190.176.193.117) has joined #mapnik 08:04:20 *** __D3f0__ has quit (Remote closed the connection) 08:28:08 <nikq> Mapnik Trac: Ticket #211 (Support min_distance in LinePatternSymbolizer) updated | http://trac.mapnik.org/ticket/211#comment:1 09:43:11 *** rcoup (n=rcoup@ip-118-90-78-242.xdsl.xnet.co.nz) has joined #mapnik 09:43:32 *** rcoup has quit (Remote closed the connection) 10:46:04 *** xcacou (n=aga@vel78-2-82-243-106-36.fbx.proxad.net) has joined #mapnik 11:18:37 *** kunitoki (n=55121f9a@67.159.35.76) has joined #mapnik 11:19:45 <kunitoki> hi to all 11:20:11 <kunitoki> i've got a question about srs. is possible to instantiate a map with a srs from a epsg code ? 11:20:52 <kunitoki> i mean i need to pass EPSG::3004 11:20:56 <kunitoki> is that possible 11:28:36 <Berteun> kunitoki: You can always use this one: http://spatialreference.org/ref/epsg/3004/proj4/ 11:40:14 <kunitoki> ah yes ok 11:40:17 <kunitoki> cool 12:26:50 *** Jon__ (n=Jon@93-97-6-206.zone5.bethere.co.uk) has joined #mapnik 12:28:10 *** jbglaw has quit (Read error: 60 (Operation timed out)) 12:28:13 *** jbglaw (n=jbglaw@lug-owl.de) has joined #mapnik 12:29:57 <Jon__> hi.. not sure if this is the right place to post, but I'm having an issue with using Mapnik tiles from http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames - basically the problem I'm trying to solve is I have 4 divs each containing consecutive tiles and I have the longitude and latitude of the center of the map in WGS84 format - how do I decide what should be the style.top and style.left properties to put each of these tiles in the right pl 12:52:59 <crschmidt> Jon__: Have you considered using OpenLayers, which generally solves this problem for you? 12:53:35 <Jon__> yeh, but this is an experimental map I'm working on using canvas 12:54:12 <crschmidt> And you're aware OpenLayers has canvas drawing support? 12:54:20 <Jon__> yep 12:54:24 <crschmidt> k 12:54:34 <crschmidt> then my education process is over. good luck :) 12:56:09 <Jon__> could you point me to the code which does this tiling process in openstreetmap? 12:56:22 *** jbglaw has quit (Read error: 104 (Connection reset by peer)) 12:57:17 *** jbglaw (n=jbglaw@lug-owl.de) has joined #mapnik 12:57:42 <crschmidt> Jon__: http://svn.openlayers.org/trunk/openlayers/lib/OpenLayers/ 12:57:48 <Jon__> thanks 12:58:02 <crschmidt> Layer/Grid.js, Tile/Image.js, etc. It's not something that is in one place 12:58:23 <Jon__> ok no problem 12:58:31 <Jon__> I'll have a dig much appreciated! 12:59:36 <crschmidt> in general, I'd recommend that #openlayers is probably slightly better for this kind of thing, since it's really about javascript mapping rather than mapnik 13:17:03 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik 14:29:41 *** ajturner has quit () 14:57:24 *** D3f0 (n=defo@190.176.193.117) has joined #mapnik 15:35:55 *** loumf has quit ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 15:36:25 *** D3f0 has quit (Remote closed the connection) 15:39:25 <nikq> Mapnik Trac: Ticket #212 (Add OCCI.input plugin to read all ORACLE (> 10g) supported vector formats) created | http://trac.mapnik.org/ticket/212 15:47:48 <nikq> Mapnik Trac: Ticket #212 (Add OCCI.input plugin to read all ORACLE (> 10g) supported vector formats) updated | http://trac.mapnik.org/ticket/212#comment:1 15:49:06 <kunitoki> here it is 15:49:07 <kunitoki> ! 16:03:05 *** kunitoki has quit ("CGI:IRC (EOF)") 16:03:30 *** jbaird has quit () 16:03:33 *** kunitoki (n=55121f9a@67.159.35.76) has joined #mapnik 16:17:00 <springmeyer> kunitoki: regarding instanctiating a map from an srs code, rather than the proj4 literial, yes __both__ can be done 16:17:11 <springmeyer> from mapnik import Projection 16:17:33 <springmeyer> Projection('+init=epsg:3004') 16:18:05 <springmeyer> will be the same as Projection('+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=2520000 +y_0=0 +ellps=intl +units=m +no_defs') 16:19:11 <springmeyer> other than the expense of requiring the Proj4 to look up the proj4 literal from the epgs code via the files in /usr/share/proj 16:23:35 <kunitoki> ok cool i thought it was possible somehow 16:26:41 <kunitoki> since mapnik is using proj4 internally 16:32:27 <springmeyer> yes, those are the two ways to call proj4 directly (there may be others that I don't know about though) 16:33:42 <Mrfo> you guys know any alternatives to tilecache for dynamic content? 16:34:36 <springmeyer> you mean alternative to tilecache in FORCE=1 mode? 16:34:59 <Mrfo> well i dont want the client to be forcing tile recreation 16:35:40 <springmeyer> should just be skipping it without caching, but I feel like we've chatting about that before... 16:35:48 <springmeyer> (me without looking back at the code) :) 16:36:10 <Mrfo> yeah we have talked about it, but the solutions didn't end up working too well 16:36:24 <springmeyer> anyway, Mrfo: how 'to-spec' do you need your service to be? 16:37:07 <springmeyer> also, do you want/need dynamic/arbitrary bounding boxes? 16:37:34 <springmeyer> by 'to-spec' I mean how much of a normal WMS service do you want/need to support? 16:37:52 <Mrfo> i dont need really any of the WMS service 16:38:15 <springmeyer> and what is your client software again? 16:38:41 <Mrfo> just if a user requests X,Y,Z in the google tileschema, it always needs to be using the more current version of the tiles 16:38:49 <Mrfo> openlayers 16:40:34 <springmeyer> so you want google tile schema requests without __any__ caching? 16:40:42 <Mrfo> with all the time i've spent on other solutions, i could have just written something to do exactly what i need by now 16:40:53 <Mrfo> cache for about 5 minutes 16:41:07 <springmeyer> well, thats kinda of what I was thinking too... 16:41:32 <Mrfo> tilecache is nice, but it was designed for static content 16:41:42 <springmeyer> I've written a bunch of one off mod_wsgi script to server tiles (although not using the x/y/z schema 16:43:26 <springmeyer> should be 'scripts to serve' 16:43:37 <Mrfo> interesting. ill look into that then 16:44:22 <Mrfo> thanks, springmeyer 16:44:28 <springmeyer> for what? 16:44:37 <springmeyer> :) 16:45:00 <Mrfo> you seem to have a solution to everything gis related 16:45:48 <springmeyer> naw, definitely not! 16:46:38 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 16:47:01 <artem_> Mrfo: have you look into mod_tile ? 16:49:08 * artem_ is looking at ogr.input source and is wondering if OGRPolygon* boxPoly = new OGRPolygon(); will ever be deleted ... 16:50:04 <artem_> kunitoki: do methods in OGR transfer object's ownership ? 16:50:06 <Mrfo> hmmm i completely forgot about that 16:50:29 * Mrfo is wondering how artem know what was going on when he just joinned the channel 16:50:42 <Mrfo> *knew 16:50:57 <artem_> Mrfo: I found mod_tile by far better solution for tile cache 16:51:10 <artem_> Mrfo: yes, i did 16:51:15 <springmeyer> the purty new #mapnik logs: http://mapnik.dbsgeo.com/days/2009-02-03 16:51:58 <Mrfo> this might be exactly what i need then 16:52:02 <Mrfo> ahh, the log! 16:52:14 * springmeyer lines numbers and a more official title pages to come.... (then I'll send out notice) 16:52:19 <kunitoki> artem_: i think yes, at least from the examples 16:52:58 <artem_> kunitoki: might be a good idea to run in valgrind to check 16:53:57 <kunitoki> ah no sorry the case of SetSpatialFilter is wrong this way 16:54:17 <kunitoki> but i think stuff can be optimized by calling SetSpatialFilterRect instead 16:54:34 <kunitoki> without allocating 16:54:58 <artem_> sounds good 16:55:18 <kunitoki> tell me if you find some other suspicious things inside 16:55:26 <artem_> sure, I will 16:55:56 <artem_> here is another suspicious one : http://trac.mapnik.org/browser/trunk/plugins/input/ogr/ogr_datasource.cpp#L225 16:56:09 <kunitoki> i tried using shared_ptr and scope_ptr, but most of the time ogr wants to call some internal functions to delete the objects, and not delete operator directly 16:56:58 <artem_> kunitoki: yes, I found this kind of hacks in gdal/ogr in the past 16:57:05 <kunitoki> yeah i thought initially ogr take ownership of that object 16:58:26 <kunitoki> we can use in both a stack object without allocating 16:59:17 <kunitoki> i patch it or you patch it ? 16:59:28 * springmeyer looks to apply the occi patch... 16:59:54 * springmeyer fixed SConstruct so that it won't build occi unless in the env['LIBS'] 17:00:08 <artem_> kunitoki: could you? you're more familiar with ogr internals :) 17:00:17 <kunitoki> ok sure :) 17:00:22 <springmeyer> artem: what's the gigabase plugin? 17:01:48 <artem_> sprinmeyer : I was playing with storing data in gigabase db and coded prototype plug-in. It shouldn't appear in trunk 17:02:04 <artem_> where did you see it ? 17:02:18 <springmeyer> okay, should I remove the reference in the main SConstruct? 17:02:27 <artem_> yes, please 17:02:32 <springmeyer> okay 17:04:53 <artem_> kunitoki: looks dangerous : OGRFeature* feat = layer_.GetNextFeature(); ... ; OGRFeature::DestroyFeature (feat); 17:06:02 <kunitoki> in case of breakage in the middle ? 17:06:12 <artem_> yes 17:06:24 <nikq> Mapnik Trac: Changeset [859]: + apply patch for Oracle 10g support from kunitoki - see #212 | http://trac.mapnik.org/changeset/859 17:07:21 <kunitoki> mmmh how can we fix it ? 17:07:41 <kunitoki> boost::fucked_ptr ? 17:07:44 <kunitoki> eheheh 17:08:27 <artem_> kanitoki: I can think about some thin wrapper that'll take care calling DestroyXX in dtor or boost::fucked_ptr 17:09:19 <kunitoki> mmmh yes 17:09:52 <artem_> kunitoki: simple wrapper created on stack should do the trick 17:10:15 <kunitoki> i think so, so i should make a thin wrapper around everything then... cause everything need to be closed with a call on OGRDestructSomething 17:10:30 <springmeyer> kunitoki: you mind if I comment out the __default__ building of the 'occi' plugin? 17:11:02 <springmeyer> or, artem perhaps we should change the list of default plugins to compile from 'all' to a select set? 17:11:27 <artem_> yes, cool 17:11:44 * springmeyer figures it should be easy to flip on the occi driver but most won't ever have the opportunity :) 17:12:37 <artem_> kunitoki: how about templated wrapper then ? which would store function pointer to the destroy_whatever 17:12:53 <kunitoki> yeah could be 17:12:54 <artem_> springmeyer : yes :) 17:13:12 <kunitoki> springmeyer: no problem, that is experimental code as it is OGR 17:13:44 <kunitoki> springemeyer: you can disable it by default as many people don't have oracle 17:14:06 <kunitoki> artem_: you can write such a thing ? 17:14:44 <artem_> kunitoki: ok, I'll have a go. I might even have something like that somewhere 17:16:48 <springmeyer> okay. so the select set could be 'postgis,shape,raster' and others will be enabled by INPUT_PLUGINS=listed.... sound good? 17:17:03 <artem_> sounds good to me 17:17:26 <springmeyer> I'll rework SConstruct so that if the plugin is not requested the CheckLibWithHeaders is also not called 17:18:03 <artem_> good idea 17:19:01 * artem_ is still trying to figure out if sqlite3/r*tree is any good for OSM 17:22:45 <nikq> Mapnik Trac: ogr.patch attached to Ticket #170 | http://trac.mapnik.org/attachment/ticket/170/ogr.patch 17:23:29 <kunitoki> artem_: done 17:23:55 <artem_> kunitoki: cheers 17:24:43 <kunitoki> the occi patch should be improved with stack_ptr everywhere 17:25:17 <kunitoki> i see what i can do without make the code fat 17:25:45 <kunitoki> most of oracle objects must be free by another one. so you wouldn't see a delete in the code 17:25:46 <artem_> :) 17:26:08 <kunitoki> and that makes the usage of boost ptrs pointless 17:26:16 <artem_> sure 17:26:49 <springmeyer> artem: tiff is only a dependency for the TIFF reader? or is it used elsewhere? 17:27:22 <artem_> don't think so. but reader is a part of core lib 17:27:51 <springmeyer> right, just curious if there was also the ability to write to tiff hiding somewhere :) 17:27:56 <artem_> yes, it would be nice to have readers configurable at compile time 17:28:30 <artem_> i thnk cairo backend can do tiffs ?? 17:28:37 <CIA-23> mapnik: dane * r859 /trunk/ (15 files in 3 dirs): + apply patch for Oracle 10g support from kunitoki - see #212 17:28:38 <nikq> Ticket #212: Add OCCI.input plugin to read all ORACLE (> 10g) supported vector formats, http://trac.mapnik.org/ticket/212 17:28:39 <CIA-23> mapnik: dane * r860 /trunk/SConstruct: Remove gigabase reference - not an active plugin 17:28:55 <springmeyer> ah, good point 17:29:22 <artem_> or you can use agg renderer then create cairo:SUrface with mapnik::Image and .... 17:29:39 <artem_> save it as tiff :) 17:29:49 <springmeyer> ya, can't wait to test that stuff! 17:30:06 <kunitoki> ok people, going back home 17:30:11 <artem_> hey, you can use PIL too 17:30:13 <kunitoki> have a nice patching time 17:30:16 <springmeyer> see ya 17:30:18 <kunitoki> :) 17:30:21 <kunitoki> byez 17:30:21 <springmeyer> :) 17:30:28 <artem_> see you 17:30:31 *** kunitoki has quit ("CGI:IRC") 17:44:33 *** jbaird (n=jbaird@shiva.mochimedia.net) has joined #mapnik 17:51:30 *** rick68_ (n=rick68@www.athenaeum.idv.tw) has joined #mapnik 18:31:13 *** artem_ has quit () 18:31:33 *** kunitoki (n=4f0731d2@67.159.35.76) has joined #mapnik 18:40:06 <CIA-23> mapnik: artem * r861 /trunk/plugins/input/ogr/ (ogr_featureset.cpp ogr_datasource.cpp): + ogr.patch (kunitoki) 18:46:59 *** xcacou has quit (Remote closed the connection) 19:25:13 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 19:27:15 *** rcoup (n=rcoup@ip-118-90-96-141.xdsl.xnet.co.nz) has joined #mapnik 19:43:20 <nikq> Mapnik Trac: Ticket #213 (Make it a bit easier to control the building of plugins in SConstruct) created | http://trac.mapnik.org/ticket/213 19:43:41 <nikq> Mapnik Trac: scons_plugin_build_config_modularization.patch attached to Ticket #213 | http://trac.mapnik.org/attachment/ticket/213/scons_plugin_build_config_modularization.patch 19:44:45 <springmeyer> artem_: would be great to get your feedback on both #213 and #209 19:44:45 <nikq> Ticket #209: SCons python install usability improvments, http://trac.mapnik.org/ticket/209 19:45:22 <artem_> springmeyer: it works great for me so far. I'm on mac and linux 19:45:38 <springmeyer> me too :) 19:46:01 <springmeyer> but you mean my commits so far, or that you've also tested those patches? 19:46:20 * artem_ realises there are some patches 19:46:38 <artem_> springmeyer: let me try them out :) 19:46:48 <springmeyer> those last two ones contained quite a bit of mucking around, so I figured it would be good to have a smarter eye do a gut check 19:46:51 <springmeyer> cool, thx! 19:47:31 * springmeyer guesses that # 209 may not apply cleanly now after #213 19:47:45 <springmeyer> so I'd try 213 first 19:48:17 <artem_> ok, should I apply #213 first, too ? 19:48:17 <nikq> Ticket #213: Make it a bit easier to control the building of plugins in SConstruct, http://trac.mapnik.org/ticket/213 19:48:27 <kunitoki> springmeyer, while you are at SConstruct 19:48:50 <springmeyer> yes.... 19:48:53 <kunitoki> there is a little patch for compiling oracle input plugin on some version of the instantclient 19:49:18 <kunitoki> add this 19:49:34 <kunitoki> ['ociei', ['occi.h'], False] 19:49:56 <kunitoki> to the list of C_LIBSHEADERS 19:50:04 <kunitoki> ops sorry CXX 19:50:15 <springmeyer> okay, cool 19:50:55 <kunitoki> well it doesn't compile the same 19:51:44 <kunitoki> how can i add that ociei lib to the build of the occi input plugin 19:51:57 <springmeyer> upps, you mean after #213? 19:51:58 <nikq> Ticket #213: Make it a bit easier to control the building of plugins in SConstruct, http://trac.mapnik.org/ticket/213 19:52:22 <kunitoki> i can't remember how i've added -locci to the scons checkLibWithHeader 19:52:36 <springmeyer> i think you want: ['occi', ['ociei', 'occi.h'], False] 19:52:58 <kunitoki> ociei is a library, not a header 19:53:18 <springmeyer> ah, ah 19:53:59 <kunitoki> ah sorry SConscript 19:54:09 <kunitoki> in the plugin directory.. me nuff nuff 19:54:13 <springmeyer> ah, yes, right 19:54:31 <kunitoki> libraries = [ 'occi', 'ociei' ] 19:55:05 <springmeyer> sounds good, but of course only you will be able to test :) 19:55:40 <kunitoki> yeah of course, but still it doesn't like 19:56:12 <kunitoki> g++ -o .sconf_temp/conftest_13 ... -licudata -lgdal -locci 19:56:22 <kunitoki> there is no -lociei 19:56:27 <kunitoki> where is gone ? 19:57:19 <springmeyer> hmm... well the tests in .sconf_temp are done with CheckLibWithHeader in the main SConscruct 19:57:50 <kunitoki> yeah 19:58:02 <springmeyer> so to get it in there you'd need: ['ociei', ['occi.h'], False] in the CXX_LIBSHEADERS just like you said before 19:58:35 <kunitoki> and is failing cause with the version i have here at home of the oracle-instantclient-basic libraries it needs linkage with both libocci and libociei 19:59:14 <kunitoki> yeah but ['occi', ['occi.h'], False] is failing cause it needs to link ociei too 19:59:42 <kunitoki> this scons stuff 19:59:47 <springmeyer> hmmm, I think our plugin setup is kinda 1:1 .. 1 plugin: 1 library 19:59:52 <springmeyer> hmmm, how to remedy... 19:59:57 <kunitoki> ah 20:00:34 <kunitoki> well, you can't cause CheckLibWithHeader don't take 2 libs as input 20:00:50 <kunitoki> so it is a useless function 20:01:19 <springmeyer> likely you can... look in scons/scons-local/SConf.py .... 20:01:33 <springmeyer> or perhaps you did? 20:02:25 <springmeyer> ya, looks like the library argument you send to CheckLibWithHeader can be a list 20:02:53 <kunitoki> ok 20:02:57 <kunitoki> lemme check 20:03:08 <kunitoki> ah a fast q 20:03:19 <kunitoki> what about the Makefile.am in the plugins directory ? 20:03:22 <kunitoki> it is used by scons ? 20:03:27 <springmeyer> no 20:03:30 <kunitoki> i need to keep it updated ? 20:03:39 <springmeyer> separate system updated less frequently 20:03:40 <kunitoki> to make things work 20:04:06 <springmeyer> if you do that is great, but not essential 20:04:12 <kunitoki> [['occi','ociei'], ['occi.h'], False] 20:04:16 <kunitoki> should be ? 20:04:39 <springmeyer> yes, seems like that is the right approach 20:04:59 * springmeyer hopes his patch will like that still :) 20:05:14 <kunitoki> no it doesn't work 20:05:31 <kunitoki> it still produce 2 different tests with a single lib each 20:05:48 <kunitoki> ok so i might keep out occi test and test for ociei 20:05:50 <kunitoki> only 20:06:02 <kunitoki> not that great cause at work is the opposite 20:07:05 <kunitoki> ok that is only a safe check, and ociei is the base for occi so i think is better to have ['ociei', ['occi.h'], False] in SConstruct 20:07:21 <kunitoki> and libraries = [ 'occi', 'ociei' ] in SConscript 20:07:36 <kunitoki> even if one could have one and not the other 20:07:41 <springmeyer> okay, seems like an easy way out :) 20:08:44 <kunitoki> it doesn't compile my library here 20:08:57 <kunitoki> have you changed something in sconstruct ? 20:09:00 <springmeyer> ack! 20:09:15 <kunitoki> what about env['LIBS'] stuff that i see in the changelog 20:09:32 <nikq> Mapnik Trac: Changeset [862]: + allow multi-line SQL queries in table parameter (#173) | http://trac.mapnik.org/changeset/862 20:10:03 <kunitoki> how should i set that 20:10:10 <kunitoki> to make my new library compile 20:10:41 <springmeyer> kunitoki: just to be clear are you testing with trunk or also with my patch from #213 ? 20:10:41 <nikq> Ticket #213: Make it a bit easier to control the building of plugins in SConstruct, http://trac.mapnik.org/ticket/213 20:11:20 <kunitoki> yeah 20:11:44 <springmeyer> which? :) 20:11:44 <kunitoki> ah no i'm using trunk with no patch 20:11:54 <springmeyer> ah, okay, then yes... 20:12:19 <springmeyer> I modified your patch to add the 'if in env['LIBS']:' check 20:12:37 <CIA-23> mapnik: artem * r862 /trunk/plugins/input/postgis/postgis.cpp: + allow multi-line SQL queries in table parameter (#173) 20:12:38 <springmeyer> otherwise the plugin will attempt to build even if the CheckLibwithHeader fails 20:13:14 <kunitoki> ah ok 20:14:25 <springmeyer> kunitoki: so, it should be being put into env['LIB'] if the line ...'for prereq in ('BOOST', 'PNG', 'JPEG', 'TIFF', 'PGSQL', 'PROJ', 'GDAL', 'OGR', 'OCCI'):' 20:14:56 <springmeyer> ( i think ), but my confusion over that prompted me to write the patch at #213 20:14:56 <nikq> Ticket #213: Make it a bit easier to control the building of plugins in SConstruct, http://trac.mapnik.org/ticket/213 20:15:03 <kunitoki> it fails applying the patch 20:15:10 <kunitoki> how i have to apply it properly 20:15:14 <kunitoki> sorry if i bother 20:15:14 <springmeyer> sorry about that... 20:15:43 <springmeyer> it should apply with: $ patch -p0 -i patch_name 20:16:07 <springmeyer> make sure to do that from within the mapnik source code directory you are working on... 20:16:43 <springmeyer> kunitoki: I've noticed that your patches seem to have the root at one directory above the mapnik source code (in this case trunk)... 20:17:22 <springmeyer> kunitoki: feel free to wait until we hear back from artem about whether #213 makes any sense however! :) 20:17:23 <nikq> Ticket #213: Make it a bit easier to control the building of plugins in SConstruct, http://trac.mapnik.org/ticket/213 20:18:08 <kunitoki> ok perfect ! 20:18:38 <kunitoki> yeah i usually make a diff of the complete directory cause i keep 20:18:42 <kunitoki> mapnik/ 20:18:47 <kunitoki> mapnik-original 20:19:00 <springmeyer> ya, makes sense 20:19:02 <kunitoki> and do a diff over complete recursive 20:19:15 <kunitoki> so you use -p1 instead of -p0 20:19:32 <kunitoki> anyway i had local modifications of SConstruct, so your patch failed 20:19:35 <springmeyer> okay 20:19:40 <springmeyer> upps :) 20:19:43 <kunitoki> i rechecked the trunk version and now ok 20:23:53 <kunitoki> ok it compiled with my new fixes and smashed_ptr implementation everywhere... 20:23:59 <kunitoki> ehehehe 20:24:24 <kunitoki> tomorrow i will test it with a huge amount of data and see what happend 20:24:28 <kunitoki> -d +s 20:25:04 <springmeyer> cool. so trunk with the patch from #213 compiled for you? 20:25:05 <nikq> ... 20:33:37 <springmeyer> artem_: just noticed that I forgot in that patch to remove the 'CPPPATH' and 'LIBPATH' for C_LIBSHEADERS if not found (which would affect postgres) 20:34:19 <artem_> ok, i haven't tried it yet. I'll wait for a fix :) 20:36:23 <kunitoki> springmeyer: yes 20:38:26 <kunitoki> next step, apart continue testing and improve the input plugins i've made could be take over the viewer testing application to the next level 20:38:37 <kunitoki> maybe using juce 20:52:08 <springmeyer> artem_: okay, should I just commit my revised patch for #213 and then you can test? :) 20:52:09 <nikq> ... 20:52:25 <artem_> sure 20:52:38 <springmeyer> okay 20:53:01 <crschmidt> poor nikq 20:53:40 <springmeyer> ya, nikq is stuck huh ? 20:53:44 <springmeyer> to much action today 20:54:58 <kunitoki> springmeyer: i have only one suggestion for the SConstruct you are doing 20:55:23 <springmeyer> kunitoki: sure... please 20:55:24 <kunitoki> why you are still keeping configuration and code togheter 20:55:57 <kunitoki> i think a lot of stuff can be in a different file, with no functions or loops, only configuration tables 20:56:13 <springmeyer> :) yes I agree. 20:56:29 <kunitoki> i don't see the point of having a config.py practically empty 20:56:34 <springmeyer> I'm new to SCons but yes, the more I muck around that has been my thinking too 20:56:59 <springmeyer> ah, well my config.py is quite full on mac osx with very different default paths... 20:57:09 <kunitoki> a lot of stuff can be put there, leaving the real checks in the SConstruct 20:57:14 <kunitoki> ok 20:57:52 <springmeyer> but having a separate config file for configuring the SConstruct is a great idea, rather than storing dics/lists or other constants in the code 20:57:53 <kunitoki> also, i think the configure stage should be in the plugin SConscript itself 20:58:02 * springmeyer figured that's what you mean? 20:58:27 <kunitoki> yeah, and also put the search for libraries only the plugin need only inside the plugin 20:58:43 <springmeyer> ah, yes the configure stage, and when it happens... I'm still understanding/learning how and when that can happen 20:58:47 <springmeyer> yes, good plan 20:58:51 <kunitoki> there is no need to have the libraries of the plugin in two places 20:59:03 <springmeyer> yes. 20:59:10 <kunitoki> only the plugin SConscript should specify the libraries and headers it uses 20:59:18 <kunitoki> ok fair point, i see you understood- 20:59:22 <kunitoki> :) 21:00:07 <springmeyer> in some sense I have tended to move things into the main SConstruct (like for http://trac.mapnik.org/ticket/209) 21:00:26 <springmeyer> but that is only so that the user gets some nice sense of what is happening in a logical order 21:00:28 <springmeyer> BUT.. 21:01:11 <springmeyer> I bet if I knew hows SCons worked a bit better it would be just as easy/logical to do in each child SConscript and to still have the debug printing happen for the user at a good time 21:01:38 <kunitoki> yeah debug printing could be buffered as well 21:01:50 <springmeyer> anyway, kunitoki: I'm aiming to get the behavior a bit more predictable and then a big refactor would be great :) 21:02:00 <kunitoki> or plugin configure / make could be 2 functions and not plain code in the root of the file 21:02:03 <springmeyer> kunitoki: could you start a ticket of your ideas? 21:02:20 <springmeyer> yes, I have thought about that one too! 21:02:48 <kunitoki> yeah sure... i create a new one or i attach to 209 ? 21:03:00 * springmeyer looked at google use of SCons for chrome and other similiar projects and realized there is a lot to improve potentially 21:03:03 <springmeyer> new one! 21:03:13 <kunitoki> ok 21:03:19 <springmeyer> thank you! 21:14:48 <nikq> Mapnik Trac: Changeset [863]: + scons: work towards more modular lists of which plugins to build, and ... | http://trac.mapnik.org/changeset/863 21:15:34 <springmeyer> kunitoki: if you could check to make sure I got that extra lib change in r863, that would be great 21:15:36 <nikq> http://trac.mapnik.org/changeset/863, at , by dane: + scons: work towards more modular lists of which plugins to build, and switch new occi plugin lib names - revised commit based on #213 21:15:59 <CIA-23> mapnik: dane * r863 /trunk/ (plugins/input/occi/SConscript SConstruct): + scons: work towards more modular lists of which plugins to build, and switch new occi plugin lib names - revised commit based on #213 21:16:00 <nikq> Ticket #213: Make it a bit easier to control the building of plugins in SConstruct, http://trac.mapnik.org/ticket/213 21:16:13 <nikq> Mapnik Trac: Ticket #213 (Make it a bit easier to control the building of plugins in SConstruct) closed | http://trac.mapnik.org/ticket/213#comment:1 21:18:35 <nikq> Mapnik Trac: Ticket #214 (SConstruct build engine refactoring) created | http://trac.mapnik.org/ticket/214 21:20:13 <nikq> Mapnik Trac: Changeset [864]: Fixed typo | http://trac.mapnik.org/changeset/864 21:35:30 <kunitoki> enough ? 21:35:31 <kunitoki> ehehehe 21:37:24 <springmeyer> ya, exactly, there is no shut up nikq command yet, but we need one :) 21:44:26 <CIA-23> mapnik: dane * r864 /trunk/SConstruct: Fixed typo 21:46:17 <artem_> springmeyer: r864 builds great! is oracle lib really called ociei ? 21:46:18 <nikq> http://trac.mapnik.org/changeset/864, at , by dane: Fixed typo 21:46:54 <springmeyer> artem_: good :) 21:47:14 <springmeyer> kunitoki: did it get that oracle lib right? 'ociei'? 21:49:11 <nikq> Mapnik Trac: Ticket #215 (g++ (Ubuntu 4.3.2-1ubuntu11) compiler warnings) created | http://trac.mapnik.org/ticket/215 21:49:23 <kunitoki> yes it compiles and link 21:49:26 <artem_> springmeyer: i think it's right 21:49:39 <springmeyer> cool 21:50:13 <kunitoki> artem_: oracle lib is ociei (C bindings) and occi (c++ bindings) 21:50:25 <kunitoki> and occi requires ociei in some builds 21:50:50 <springmeyer> upps, well I think I added it so that the checking would be as if it were C++ 21:50:53 <artem_> kunitoki: ok, thanks 21:51:10 <springmeyer> so the CheckLibWithHeader *should* be failing :) 21:51:16 <springmeyer> for kunitoki... 21:51:46 <kunitoki> actually... it compiles fine 21:53:06 <kunitoki> artem_: the problem is, we need to check the presence of occi.h with libocci.so and libociei.so 21:53:51 <kunitoki> cause a program linked with only libocci.so couldn't compile if you don't link also with libociei.so (c++ stuff is built on the C bindings) 21:54:15 <kunitoki> but CheckLibWithHeader can check only a library at a time 21:54:40 <kunitoki> so when it checks libocci.so, it can't find some symbols defined in libociei.so 21:55:07 <kunitoki> it is a mess... probably because of the CheckLibWithHeader function implementation 21:55:31 <kunitoki> maybe we can implement CheckLibsWithHeader :) 21:55:45 <springmeyer> ya, or just use something totally custom 21:56:24 <kunitoki> like premake :P 21:59:20 <nikq> Mapnik Trac: occi-input-plugin-2.patch attached to Ticket #212 | http://trac.mapnik.org/attachment/ticket/212/occi-input-plugin-2.patch 21:59:40 <kunitoki> added some safeguard around the variables 21:59:55 *** Jon__ has quit () 22:00:22 <kunitoki> mushroom_ptr namely 22:00:31 <kunitoki> :| 22:14:24 <nikq> Mapnik Trac: scons_python_usability_improvements2.patch attached to Ticket #209 | http://trac.mapnik.org/attachment/ticket/209/scons_python_usability_improvements2.patch 22:15:08 <springmeyer> artem: anything look fishy with that one ^^^, or should I also apply to trunk for your testing? 22:23:37 <nikq> Mapnik Trac: Changeset [865]: + apply occi-input-plugin-2.patch (kunitoki) (#212) | http://trac.mapnik.org/changeset/865 22:32:54 *** MasterNayru has quit (Remote closed the connection) 22:44:27 <CIA-23> mapnik: dane * r865 /trunk/plugins/input/occi/ (4 files): + apply occi-input-plugin-2.patch (kunitoki) (#212) 23:00:04 <nikq> Mapnik Trac: Changeset [866]: + scons_python_usability_improvements2 (springmeyer) | http://trac.mapnik.org/changeset/866 23:00:21 <artem_> springmeyer: seems to work fine 23:00:38 <springmeyer> :) cool. 23:01:38 <springmeyer> it definitely puts mapnik in a better place on a vanilla install of leopard :) 23:06:49 *** weizhuo (n=chatzill@nat/yahoo/x-9fc612fa414b2d83) has joined #mapnik 23:06:55 *** weizhuo has parted #mapnik () 23:07:41 <kunitoki> bye ppl 23:07:47 <kunitoki> god night 23:08:17 *** kunitoki has quit ("CGI:IRC (EOF)") 23:14:20 <CIA-23> mapnik: artem * r866 /trunk/ (bindings/python/SConscript SConstruct): + scons_python_usability_improvements2 (springmeyer) 23:18:32 *** D3f0 (n=defo@190.176.193.117) has joined #mapnik 23:20:42 *** artem_ has quit () 23:22:32 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 23:25:37 <artem> springmeyer: I have an idea, can config.py remember PKG_CONFIG_PATH from previous runs ? 23:26:39 <springmeyer> config.py will remember automatically any 'opts' that we've added, so if you add PKG_CONFIG_PATH as a user variable that will do it 23:27:06 <springmeyer> if we want it as a private variable, that could also likely be done by sticking into 'opts' manually... 23:33:02 <artem> hmm.. maybe we should leave it as it for now 23:33:11 <artem> it is 23:33:48 *** artem has quit ("see you tomorrow")