00:01:02 <springmeyer> because both those paths are being picked up because of other dependencies even if I point BOOST_* at /usr/local SCons still links against /opt/local
00:02:46 <springmeyer> seems like there has got to be a better workaround (within Scons) for this than manually removing duplicate boost installs, but I recognize that is best practice
00:02:48 *** ajturner has quit ()
00:05:40 *** artem has quit ()
00:21:07 *** ajturner (n=ajturner@pool-96-231-158-101.washdc.fios.verizon.net) has joined #mapnik
00:29:42 *** ajturner has quit ()
01:00:24 <CIA-23> mapnik: artem * r850 /trunk/include/mapnik/filter_parser_ast.hpp: + remove unused header
01:00:24 <CIA-23> mapnik: artem * r851 /trunk/include/mapnik/feature_style_processor.hpp: + always clip bbox to layer extent
01:22:02 *** D3f0 (n=defo@190.176.211.26) has joined #mapnik
02:32:56 *** weizhuo has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.20/2008121709]")
03:26:54 *** D3f0 has quit ("Konversation terminated!")
03:33:17 *** D3f0 (n=defo@190.176.211.26) has joined #mapnik
04:01:05 *** rcoup has quit (Read error: 110 (Connection timed out))
04:06:46 *** ajturner (n=ajturner@pool-96-231-158-101.washdc.fios.verizon.net) has joined #mapnik
04:08:46 *** ajturner has quit (Client Quit)
04:11:20 *** ajturner (n=ajturner@pool-96-231-158-101.washdc.fios.verizon.net) has joined #mapnik
04:13:41 *** ajturner_ (n=ajturner@static-71-166-236-36.washdc.east.verizon.net) has joined #mapnik
04:17:09 *** ajturner_ has quit (Client Quit)
06:02:20 *** ajturner has quit ()
06:04:43 <nikq> Mapnik Trac: UbuntuInstallation edited | http://trac.mapnik.org/wiki/UbuntuInstallation?version=23
06:33:37 <nikq> Mapnik Trac: MacPythonUpgradeIssues edited | http://trac.mapnik.org/wiki/MacPythonUpgradeIssues?version=3
07:01:11 <nikq> Mapnik Trac: scons_python_usability_improvements.patch attached to Ticket #209 | http://trac.mapnik.org/attachment/ticket/209/scons_python_usability_improvements.patch
07:02:32 <nikq> Mapnik Trac: Ticket #209 (SCons python install usability improvments) updated | http://trac.mapnik.org/ticket/209#comment:2
07:02:57 <nikq> Mapnik Trac: Ticket #10 (Installing in a non-standard location as non-root user (PREFIX not  ...) closed | http://trac.mapnik.org/ticket/10#comment:12
07:03:27 <nikq> Mapnik Trac: Ticket #48 (installing python modules with respect to the PREFIX build option) closed | http://trac.mapnik.org/ticket/48#comment:5
07:18:16 <nikq> Mapnik Trac: UbuntuInstallation edited | http://trac.mapnik.org/wiki/UbuntuInstallation?version=24
07:21:19 <dukeku> does mapnik work with gcc 4.x?
07:30:43 <springmeyer> hey dukeku: just headed to bed up here..
07:30:44 <springmeyer> dukeku: give it a go and post your errors :)
07:59:27 <CIA-23> mapnik-utils: migurski * r527 /trunk/serverside/cascadenik/ (test.py tests/test.py cascadenik/style.py): Allowing quotes in attribute selectors (issue:9)
07:59:27 <CIA-23> mapnik-utils: migurski * r528 /trunk/serverside/cascadenik/ (test.py tests/test.py): Corrected value quoting in attribute selectors (issue:12)
07:59:48 *** xcacou (n=aga@AToulouse-157-1-48-149.w86-201.abo.wanadoo.fr) has joined #mapnik
08:19:58 *** kunitoki (n=55121f9a@67.159.35.76) has joined #mapnik
08:54:42 *** rcoup (n=rcoup@ip-118-90-54-112.xdsl.xnet.co.nz) has joined #mapnik
09:25:36 *** D3f0 has quit ("Konversation terminated!")
11:17:24 *** rcoup has quit ()
13:19:55 *** kunitoki has quit ("CGI:IRC (Session timeout)")
13:22:24 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
13:28:43 *** kunitoki (n=55121f9a@67.159.35.76) has joined #mapnik
14:57:14 *** ajturner has quit ()
15:38:13 *** kunitoki has quit ("CGI:IRC (EOF)")
16:29:55 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
16:42:51 *** xcacou has quit (Remote closed the connection)
17:01:08 *** D3f0 (n=defo@190.176.219.207) has joined #mapnik
17:14:55 <nikq> Mapnik Trac: Ticket #39 (Scons seems to build backwards) updated | http://trac.mapnik.org/ticket/39#comment:3
17:16:43 <nikq> Mapnik Trac: map_pickling_avoid_setting_color_if_null.patch attached to Ticket #167 | http://trac.mapnik.org/attachment/ticket/167/map_pickling_avoid_setting_color_if_null.patch
17:28:43 <nikq> Mapnik Trac: Ticket #210 (Misleading SCons 'could not find required header or shared library for m'  ...) created | http://trac.mapnik.org/ticket/210
17:29:44 <nikq> Mapnik Trac: Ticket #210 (Misleading SCons 'could not find required header or shared library for m'  ...) updated | http://trac.mapnik.org/ticket/210#comment:1
17:31:05 <nikq> Mapnik Trac: Ticket #210 (Misleading SCons 'could not find required header or shared library for m'  ...) updated | http://trac.mapnik.org/ticket/210#comment:2
17:32:58 <nikq> Mapnik Trac: Ticket #210 (Misleading SCons 'could not find required header or shared library for m'  ...) updated | http://trac.mapnik.org/ticket/210#comment:3
18:26:25 *** ser has quit (kubrick.freenode.net irc.freenode.net)
18:30:12 *** Fearliss (n=warirc@71-209-245-91.phnx.qwest.net) has joined #mapnik
18:30:31 *** Fearliss has parted #mapnik ()
18:34:24 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik
18:54:48 <dukeku> springmeyer: i will once i get home :)
18:55:03 <dukeku> springmeyer: they changed a *lot* of includes in 4.2.x
18:55:25 <dukeku> uses a lot of shit like #include_next, breaks a lot of existing code :)
19:01:18 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
19:09:10 *** ajturner has quit ()
19:17:26 *** rcoup (n=rcoup@ip-118-90-114-62.xdsl.xnet.co.nz) has joined #mapnik
19:23:14 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
19:28:07 *** ajturner has quit (Read error: 104 (Connection reset by peer))
20:08:26 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
20:08:49 *** ajturner has quit (Client Quit)
20:09:07 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
20:31:17 *** D3f0 has quit ("Konversation terminated!")
20:54:17 *** D3f0 (n=defo@190.176.196.70) has joined #mapnik
21:27:32 *** D3f0 has quit (Remote closed the connection)
21:29:15 *** ajturner has quit (Read error: 54 (Connection reset by peer))
21:39:06 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
21:54:56 *** D3f0 (n=defo@190.176.205.189) has joined #mapnik
22:36:27 *** kunitoki (n=4f0731d2@67.159.35.76) has joined #mapnik
22:36:34 *** kunitoki has quit (Client Quit)
22:37:44 *** kunitoki (n=4f0731d2@67.159.35.76) has joined #mapnik
22:37:55 <kunitoki> hi to all
22:37:55 <nikq> kunitoki: 28 Jan 21:15Z <springmeyer> tell kunitoki why was the cairo svg support commented out of rundemo? did it not compile with your version?
22:37:58 <nikq> kunitoki: 29 Jan 04:28Z <springmeyer> tell kunitoki that the geojson geometrycollection rendering is working now: http://dbsgeo.com/tmp/mapnik_ogr_plugin_tests/geometrycollection_type-geojson.png
22:38:25 <kunitoki> i've got a question for the programmer
22:39:14 <kunitoki> how do i handle datasource types that are different from mapnik::Integer/Double/String ? (ie i want to visualize DateTime from a database)
22:39:57 <kunitoki> should i add a parameter in the datasource creation where i specify a DateTime 2 String format conversion and treat DateTime fields as String ?
22:41:09 <kunitoki> springmeyer: cairo svg support was commented mainly for demo application running speed when in the code-test-fix cycle
22:41:57 <kunitoki> the only thing it didn't compile was HAVE_CAIRO_SURFACE define
22:42:26 <kunitoki> i think we can close the ticket for OGR support
22:43:14 <springmeyer> kunitoki: okay, great, let's close. also I removed the HAVE_CAIRO_SURFACE in a separate commit
22:43:23 <kunitoki> cool
22:43:31 <springmeyer> yes, cool :)
22:43:49 <kunitoki> we can test and make new tickets if we want more features from the support
22:43:52 <springmeyer> I like the idea of time visualization - definetly should be supported
22:43:57 <kunitoki> but as it is i'm getting no more crash
22:44:11 <kunitoki> yeah i have some date fields that i want to visualize
22:44:16 <springmeyer> yes. excellent. me neither
22:44:55 <kunitoki> what about my first question ?
22:45:07 <kunitoki> what about a "dateformat" option in the datasource ?
22:45:26 <kunitoki> i quite finished straight oracle (occi) support here
22:45:40 <kunitoki> cause i need it here at work
22:45:54 <springmeyer> a dateformat sounds good to me but we'll have to ask artem_ about how/where to integrate
22:46:09 <springmeyer> wow. oracle support - cool
22:46:37 <kunitoki> well, i don't think we need a Type in the layer_descr
22:47:06 <kunitoki> at least we should need to be aware on how to convert the date to a string when parsing feature metadata
22:47:23 <kunitoki> cause in a png map, or a svg the date is a string afterall
22:47:43 <springmeyer> right, of course
22:47:44 <kunitoki> but we should be aware that we can code filters based on a Date column
22:48:33 * springmeyer has wondered also about adding filters that can reach back and access the geometry type
22:49:28 <kunitoki> mmmmh
22:49:32 <kunitoki> me too
22:50:11 <springmeyer> in some cases I've really wished I could symbolize based on whether a feature is a poly, multipoly, point, etc...
22:50:30 <kunitoki> but shouldn't be hard to do, at least you can code a special type of filter which parse the geometry instead of the metadata
22:50:56 <kunitoki> actually, i don't know much about mapnik internal
22:51:20 <kunitoki> i know the base logic behind a gis framework, but i have to look closer to it
22:51:25 <kunitoki> to implement such a thing
22:51:29 <springmeyer> cool :) I know only about the peripheries as well
22:51:49 <jburgess> I think you can do some filtering on the geom type, with [mapnik:geometry] = 1/2/3 .. I'm not sure where the values come from but I think they are poine,line,polygon
22:52:07 <kunitoki> well, geometry based filters could be interesting
22:52:51 <springmeyer> jburgess: ya, I've seen that syntax in the osm.xml but never been able to get it to work
22:53:00 <kunitoki> implementing some base operators like "[mapnik:geometry] intersects [poly2d: 0,0, 0,1, 1,1]"
22:53:05 <kunitoki> or the like
22:53:08 <springmeyer> ewwwww
22:53:17 <jburgess> For the dateTime question, I think the answer is to define the new type in value.hpp. The current types are: null, boo, int, double, unicodeString
22:53:55 <jburgess> if you add a new type, you then get to define function for how you make equality tests and other comparisons
22:54:20 <kunitoki> yeah sure
22:54:54 <kunitoki> also in the TextRasterizer (or whatever is called) the new type should be handled as a string
22:56:04 <jburgess> springmeyer: I've never used the [mapnik:geometry] either, but I guess this is what it is for
22:56:28 <kunitoki> second question for you
22:56:39 <springmeyer> okay jburgess: thx
22:57:05 <kunitoki> i've seen a ticket too (http://trac.mapnik.org/ticket/195)
22:57:27 <kunitoki> how projection is handled in a mapnik map file ?
22:58:12 *** artem_ has quit ()
22:58:16 *** jbaird (n=jbaird@shiva.mochimedia.net) has joined #mapnik
22:58:17 <jburgess> for the current postgis plugin you have to manually specify the SRS for the layer/datasource
22:58:24 <kunitoki> i see the epsg number is read from postgis metadata
22:58:26 <kunitoki> yeah
22:58:48 <kunitoki> so that should go also into OGR/GDAL and ORACLE support
22:59:15 <kunitoki> i can have multiple datasource in a map ?
22:59:21 <jburgess> it would be good if it could read the srid and work out the proj string from that using the spatial_ref table or use epsg:SRID
22:59:21 <jbaird> noob question: when specifying an Envelope using Coord(), what are the arguments to coord? are those longitude/latitude pairs? or are they in local coordinate space?
22:59:29 <kunitoki> (actually i have only implemented one)
23:00:02 <jburgess> yes, a typical map may have lots of data sources, some shapefiles, others postgis, ...
23:00:17 <kunitoki> what about coordinate transformation ?
23:00:29 <springmeyer> jbaird: tuple in coordinate system (can be long/lat but also projected)
23:00:31 <kunitoki> in GDAL / OGR we can convert each point on the fly
23:00:58 <jburgess> kunitoki: currently mapnik does all the reprojection
23:01:04 <kunitoki> so what if i have 2 datasource with different projection and want to convert one ?
23:01:13 <jbaird> springmeyer: so Envelope(Coord(top left), Coord(bottom right)) ?
23:01:22 <kunitoki> mmmh how i tell to mapnik which srid i have
23:01:23 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
23:01:37 <jburgess> kunitoki: that is fine, each layer can have its own SRS and the map can be something different again
23:01:47 <jburgess> everything ends up getting projected to the map srs
23:01:47 <kunitoki> jburgess: ok
23:01:55 <kunitoki> ok map srs
23:02:08 <jburgess> but mapnik does not expect the datasources to do this, it'll project the data itself
23:03:01 <jburgess> I don't know which would be more efficient for things like GDAL, but others like the shape plugin have ability to reproject themselves
23:03:05 <springmeyer> jbaird: Coord(minx,miny), Coord(maxx,maxy) i think
23:03:29 <jburgess> sorry, make that ... NO ability to reproject themselves :-)
23:03:38 <springmeyer> jbaird: not that if you want an Envelope you can skip Coord and just send it a 4 item tuple
23:03:51 <springmeyer> jbaird: example for mercator here: http://mapnik-utils.googlecode.com/svn/example_code/google_mercator_projection/world_mercator.py
23:03:53 <kunitoki> jburgess: understood thanx... but i see the srs is a layer attribute, not datasource
23:04:10 <kunitoki> and also i don't see srs attribute in postgis plugin
23:04:11 <jburgess> right, you can (I think) have only 1 datasource in a layer
23:04:13 <jbaird> springmeyer: thanks, I'll give that a try
23:04:28 <springmeyer> currently if NOT SET the layer srs inherits from the map...
23:04:59 <kunitoki> so i cannot mix a shapefile with a gdal raster ?
23:05:12 <jburgess> sure, but in different layers
23:05:23 <kunitoki> ok ok so i can have multiple datasource
23:05:31 <jburgess> 1 per layer
23:05:39 <kunitoki> 1ds = 1lyr ?
23:05:42 <jburgess> lots of layers & lots of styles for those layers
23:05:46 <jbaird> springmeyer: I guess I'm doing something else wrong. Thanks for the help though
23:06:04 <jburgess> I think 1:1 yes, but not entirely certain. Have never seen anything else
23:07:11 <kunitoki> ok perfect i think i got it
23:07:11 <jburgess> looking at the code... the layer object just has a single datasource pointer, so yes only 1 datasource per layer
23:07:22 <nikq> Mapnik Trac: Changeset [852]: + implement buffered_extent method on Map object | http://trac.mapnik.org/changeset/852
23:08:25 <kunitoki> last question
23:08:33 <nikq> Mapnik Trac: Changeset [853]: + use 'buffered' extent in bbox query | http://trac.mapnik.org/changeset/853
23:09:20 <kunitoki> there is a specific design goal to have functions coded with underscores and some others with camel case in the same class ?
23:09:56 <kunitoki> getCurrentExtent and get_buffered_extent in the same class
23:10:06 <artem> kunitoki: mapnik style == stl/boost style -> no CamelCase
23:10:15 <jburgess> last night Artem mentioned that he wants to get rid of the camel case, so I expect more things will become _'s
23:10:26 <kunitoki> ok just to clearify
23:10:28 <artem> yes :)
23:10:47 <kunitoki> cause i'm trying to stick to mapnik code style as much as i can
23:11:05 * artem about to apply some patches ..
23:11:05 <kunitoki> so you don't have to revise and rewrite a lot of variable names
23:11:10 <kunitoki> :D
23:11:52 <artem> exactly :D
23:12:01 <kunitoki> tomorrow i will send a patch for straight oracle spatial support
23:12:19 <kunitoki> not exactly planned, but i needed here at work
23:12:31 <artem> great! I haven't played with Oracle spatial for years
23:12:47 <kunitoki> we have some applications going on
23:12:54 <artem> last time I tried it was Oracle 8i
23:12:56 <kunitoki> and have mapnik style some data is wonderful
23:13:24 <kunitoki> wh oracle 81 was not especially spatial
23:13:37 <kunitoki> 81=8i
23:13:59 <kunitoki> 10g is a beautiful beast :) spatially speaking
23:14:17 * artem got to try it one day
23:14:56 <kunitoki> taking apart the cost
23:15:10 <kunitoki> probably most people can stick with postgres
23:15:19 <artem> i think so :)
23:15:54 <kunitoki> but when you work with grids, millions point interpolation and graphs with linear referencing system
23:16:17 <kunitoki> then nothing can compare... cause you can do everything with a query
23:16:24 <kunitoki> well ~ everything
23:17:00 <artem> I might be working on sqlite input plug-in for Mapnik . Has anyone got any experience ? some gotchas ?
23:17:20 <kunitoki> i tried visualizing sqlite with my OGR plugin
23:17:30 <kunitoki> cause OGR supports sqlite
23:17:52 <kunitoki> i converted a SHP file to sqlite, then visualized the sqlite.db with ogr.input
23:18:22 <artem> ok, I'm trying to figure out if sqlite can hold complete OSM ???
23:18:49 <kunitoki> osm ?
23:18:55 <kunitoki> openstreetmap ?
23:19:04 <artem> and their R*tree implementation is robust enough
23:19:12 <artem> yep, Openstreetmap
23:19:17 *** weizhuo (n=chatzill@nat/yahoo/x-1de226c3932554e8) has joined #mapnik
23:20:01 <kunitoki> well i don't know actually
23:20:23 <kunitoki> http://www.gdal.org/ogr/drv_sqlite.html
23:20:28 <kunitoki> here is a start
23:20:38 <kunitoki> for trying in mapnik
23:20:48 *** weizhuo has parted #mapnik ()
23:21:10 <artem> I'll give it try.
23:21:16 <kunitoki> no spatial index tho
23:21:22 <jburgess> artem: I think I've seen sqlite patchs both for mapnik and osm2pgsql. want some links?
23:21:32 <artem> yes, please
23:21:57 <artem> kunitoki: sqlite 3.6 has R*tree index
23:22:36 <kunitoki> uhu !
23:22:40 <kunitoki> interesting
23:22:54 <kunitoki> so it have an internal spatial data ?
23:22:57 <jburgess> http://trac.openstreetmap.org/ticket/1371
23:23:12 <artem> jburgess: thanks!
23:23:36 <artem> kunitoki: No, you can store whatever you like as a blob
23:23:50 <artem> and spatially index
23:23:52 <jbaird> once a map has been panned and zoomed is there a way to find what the maps extent is, its minx/miny maxx/maxy?
23:24:06 <artem> m.envelope()
23:24:11 <artem> (in Python()
23:24:13 <kunitoki> how can i spatially index a binary blob ?
23:24:22 <artem> by its MBR
23:24:31 <kunitoki> mbr of a binary ?
23:24:51 <kunitoki> where sqlite reads the mbr from a opaque blob ?
23:24:58 <artem> well, assuming you know what inside this blob
23:25:08 <jbaird> artem: what coordinate system are those numbers in?
23:25:22 <artem> well, you can create a virtual table :
23:25:58 <artem> create virtual table spatial_index using rtree(id,minx,mmax,miny,maxxy);
23:26:03 <springmeyer> jbaird: they are in the coord system of the map.srs
23:26:27 <artem> jbaird: yep
23:26:30 <springmeyer> jbaird: if you did not set the map.srs then it defaults to lon/lat
23:26:38 <kunitoki> yeah that's ok
23:26:45 <jburgess> artem: I think Bradley Kite is the one porting mapnik to Java... http://code.google.com/p/osmdroid/source/browse/branches/osm-contributor/src/org/andnav/osm/views/tiles/renderer/mapnik/feature/MapnikFeature.java?spec=svn47&r=47
23:26:47 <jbaird> springmeyer: my srs is latlong but envelope is giving me: Envelope(5765681.10682,1932281.58259,6246635.49149,2292997.37109)
23:28:29 <springmeyer> artem: is <FIlter>[mapnik:geometry] = 1</Filter> supposed to work?
23:28:40 <jburgess> artem: this was his first mail announcing his intentions to osm-dev: http://www.mail-archive.com/dev@openstreetmap.org/msg04671.html
23:28:40 <kunitoki> ok going to bed.... keep an eye on tomorrow !
23:28:46 <kunitoki> cheers
23:28:52 <artem> cheers
23:28:55 <springmeyer> and if so, any idea how the int codes match with geoms?
23:29:00 <springmeyer> see ya kunitoki!
23:29:20 *** kunitoki has quit ("CGI:IRC (EOF)")
23:29:39 <artem> springmeyer: the above filter exp will work if you have property mapnik:geometry
23:29:57 <springmeyer> ah... :)
23:30:05 <springmeyer> simple enough!
23:30:16 <artem> For 1.0.0 we should add support for geometry based filters.
23:30:29 <springmeyer> yes!
23:30:40 <springmeyer> er, wait what do you mean by property exactly?
23:31:18 <artem> feature['mapnik:geometry']
23:31:43 <artem> column in database for example (but not geometry)
23:31:56 <springmeyer> ah, interesting
23:31:57 <springmeyer> thx
23:32:20 <jburgess> artem: some filters with [mapnik:geometry] have been in the osm.xml for ages.. but I guess they have no use in the normal style?
23:32:45 <jbaird> springmeyer: ah, I see, my shapefile is in another projection
23:33:15 <artem> jburgess: yes, we should remove them
23:33:58 <artem> In my custom qt viewer I'm using these names to visualise 'selection' features
23:34:24 <springmeyer> ah....
23:34:56 <jburgess> so I should delete the: <Style name="mapnik:selection"> ... </Style>
23:35:13 <artem> yes
23:35:57 <nikq> Mapnik Trac: Changeset [854]: + mapnik_png256_reduce.patch (Marcin Rudowski) | http://trac.mapnik.org/changeset/854
23:35:58 <jbaird> springmeyer: nevermind, I guess it's giving me the envelope in local coordinates?
23:37:19 <nikq> Mapnik Trac: Changeset [855]: + mapnik_text_overlap.patch (Marcin Rudowski) | http://trac.mapnik.org/changeset/855
23:39:19 <CIA-23> mapnik: artem * r852 /trunk/ (include/mapnik/map.hpp src/map.cpp): + implement buffered_extent method on Map object
23:39:20 <CIA-23> mapnik: artem * r853 /trunk/include/mapnik/feature_style_processor.hpp: + use 'buffered' extent in bbox query
23:39:20 <CIA-23> mapnik: artem * r854 /trunk/include/mapnik/octree.hpp: + mapnik_png256_reduce.patch (Marcin Rudowski)
23:39:20 <CIA-23> mapnik: artem * r855 /trunk/ (include/mapnik/placement_finder.hpp src/placement_finder.cpp): + mapnik_text_overlap.patch (Marcin Rudowski)
23:39:21 <nikq> Mapnik Trac: Changeset [856]: +  reflect buffered_envelope method +  fix view_transform to return ctrans  ... | http://trac.mapnik.org/changeset/856
23:40:26 <artem> jburgess: latest trunk should handle buffer_size, give it a try
23:40:54 <jburgess> yes, seems to be working with r853
23:40:55 <nikq> http://trac.mapnik.org/changeset/853, at , by artem: + use 'buffered' extent in bbox query
23:41:19 <artem> good
23:41:30 <springmeyer> artem on fire!
23:41:39 <jburgess> I needed to increase the buffer from 128 to 256 to get Cambridge to appear
23:42:01 <jburgess> actually no, forget that, 128 was fine... I just needed to recompile the renderd
23:42:34 <jburgess> I think the feature_style_processor.hpp ends up getting compiled into the renderd executable so it did not get the change until it was recompiled
23:42:55 <artem> yep
23:43:10 <jburgess> great!
23:43:53 <jburgess> I think I can probably update to the very latest mod_tile + mapnik code on the osm tile server. I might leave that until tomorrow though
23:44:40 <jburgess> I'll have to test out this png256 fix on a few 'bad' tiles
23:44:44 <artem> jburgess: good idea. png256 patch seems to be working , I don't see any grea-ish
23:44:44 <jburgess> I can't think of any more bugs :-)
23:44:59 <artem> :) there are plenty I'm sure
23:45:03 <crschmidt> have a few beers first. It makes the process seem much smoother
23:45:30 <crschmidt> :)
23:46:13 <artem> crschmidth: I bit too late for a beer around here, maybe tomorrow
23:47:04 * springmeyer just heard from J.F Doyon - he says he's been bitten by some health problems so is not able to spend much time at the computer
23:47:32 * springmeyer scratches his head about the OGCServer code for 0.6.0...
23:48:36 <springmeyer> jbaird: just http://dpaste.com your code and we'll take a look
23:51:37 *** D3f0 has quit ("Konversation terminated!")
23:55:35 <jbaird> springmeyer: http://dpaste.com/115919/  -- png file is at http://instrumentlanding.com/media/world.png, shpfile is LCC - NAD83
23:57:01 <jbaird> I guess the envelope is measuring in meters from the datum?
23:58:05 <springmeyer> okay, so you've zoomed the map to the layer's coordinates, so yes that Envelope is now in Lambert Conic
23:58:33 <springmeyer> but you also need to reproject the map so that it knows the units are meters not degress
23:59:01 <springmeyer> .g spatialreference.org LCC-NAD83
23:59:02 <nikq> springmeyer: http://osdir.com/ml/gis.mapnik.user/2008-05/msg00057.html
23:59:13 <springmeyer> .g site:spatialreference.org LCC-NAD83
23:59:14 <nikq> springmeyer: http://spatialreference.org/ref/sr-org/113/
23:59:44 <jbaird> springmeyer: and use the proj4 string?
23:59:48 <springmeyer> yes