00:50:30 *** D3f0 (n=defo@190.176.250.169) has joined #mapnik
01:22:23 *** D3f0 has quit (Remote closed the connection)
01:46:26 *** rcoup (n=rcoup@ip-118-90-60-67.xdsl.xnet.co.nz) has joined #mapnik
02:19:27 <nikq> Mapnik Trac: Ticket #205 (Pickling support for Mapnik Layer) created | http://trac.mapnik.org/ticket/205
02:19:38 <nikq> Mapnik Trac: mapnik_layer_pickling_support.diff attached to Ticket #205 | http://trac.mapnik.org/attachment/ticket/205/mapnik_layer_pickling_support.diff
02:37:44 *** migurski_ has quit ()
02:42:33 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
02:56:57 *** rcoup_ (n=rcoup@ip-118-90-114-62.xdsl.xnet.co.nz) has joined #mapnik
03:13:16 *** rcoup has quit (Read error: 110 (Connection timed out))
03:45:04 *** D3f0 (n=defo@190.176.211.26) has joined #mapnik
03:49:11 *** D3f0 has quit (Remote closed the connection)
03:49:26 *** D3f0 (n=defo@190.176.211.26) has joined #mapnik
04:03:35 <CIA-23> mapnik-utils: dane.springmeyer * r521 /trunk/nikinfo/ (nikinfo.py setup.py): Spruce up nikinfo adding setup.py, python sample script support, ability to only print xml sample, and optparse - still only does shapefiles
04:28:22 *** rcoup_ has quit ()
08:10:15 *** rcoup (n=rcoup@ip-118-90-54-112.xdsl.xnet.co.nz) has joined #mapnik
09:54:23 *** CIA-23 has quit (Read error: 60 (Operation timed out))
09:54:34 *** CIA-40 (n=CIA@208.69.182.149) has joined #mapnik
10:06:21 *** migurski has quit ()
10:13:25 *** CIA-40 has quit (Killed by tomaw (stuck, restart))
10:13:27 *** CIA-23 (n=CIA@208.69.182.149) has joined #mapnik
10:19:25 *** D3f0 has quit (Remote closed the connection)
10:28:48 *** rcoup has quit ()
10:56:37 <nikq> Mapnik Trac: Ticket #204 (map.buffer_size() does not seem to fetch data within buffer zone) updated | http://trac.mapnik.org/ticket/204#comment:2
10:57:19 <nikq> Mapnik Trac: Ticket #204 (map.buffer_size() does not seem to fetch data within buffer zone) updated | http://trac.mapnik.org/ticket/204#comment:3
11:55:26 <nikq> Mapnik Trac: Ticket #206 (Correct operator* and operator/ behaviour (mapnik::Envelope object)) created | http://trac.mapnik.org/ticket/206
11:55:46 <nikq> Mapnik Trac: Ticket #206 (Correct operator* and operator/ behaviour (mapnik::Envelope object)) updated | http://trac.mapnik.org/ticket/206#comment:1
12:12:29 <nikq> Mapnik Trac: Ticket #207 (view_transform returns Envelope instead of CoordTransform) created | http://trac.mapnik.org/ticket/207
12:15:32 <nikq> Mapnik Trac: Changeset [845]: + changed operator* and operator/ behaviour as per #206 | http://trac.mapnik.org/changeset/845
12:15:42 <nikq> Mapnik Trac: Ticket #206 (Correct operator* and operator/ behaviour (mapnik::Envelope object)) closed | http://trac.mapnik.org/ticket/206#comment:2
12:21:46 <nikq> Mapnik Trac: Ticket #206 (Correct operator* and operator/ behaviour (mapnik::Envelope object)) updated | http://trac.mapnik.org/ticket/206#comment:3
12:24:11 *** adakkak_ (n=adakkak@c-98-212-194-70.hsd1.il.comcast.net) has joined #mapnik
12:27:16 <CIA-23> mapnik: artem * r845 /trunk/src/envelope.cpp: + changed operator* and operator/ behaviour as per #206
12:27:17 <nikq> Ticket #206: Correct operator* and operator/ behaviour (mapnik::Envelope object), http://trac.mapnik.org/ticket/206
15:40:06 *** ajturner (n=ajturner@pool-96-231-158-101.washdc.fios.verizon.net) has joined #mapnik
15:42:38 *** ajturner has quit (Client Quit)
16:26:37 <nikq> Mapnik Trac: Ticket #206 (Correct operator* and operator/ behaviour (mapnik::Envelope object)) updated | http://trac.mapnik.org/ticket/206#comment:4
16:38:47 <nikq> Mapnik Trac: Ticket #207 (view_transform returns Envelope instead of CoordTransform) updated | http://trac.mapnik.org/ticket/207#comment:1
16:43:51 <nikq> Mapnik Trac: Ticket #207 (view_transform returns Envelope instead of CoordTransform) updated | http://trac.mapnik.org/ticket/207#comment:2
16:44:51 *** jburgess has quit (Remote closed the connection)
16:48:04 <nikq> Mapnik Trac: Ticket #207 (view_transform returns Envelope instead of CoordTransform) updated | http://trac.mapnik.org/ticket/207#comment:3
16:56:44 *** jburgess (n=jburgess@bb-87-80-234-70.ukonline.co.uk) has joined #mapnik
17:07:48 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
17:19:27 <springmeyer> hey ajturner: I saw your question about numeric field names on shapefiles... can you post your shapefile somewhere?
17:19:38 <ajturner> springmeyer:
17:19:41 <ajturner> hey - yeah, I can
17:19:45 <springmeyer> I've not seen that behavior
17:19:46 <springmeyer> cool
17:20:10 <springmeyer> and I guess your python/xml snippet you where using for the TextSymbolizer too
17:20:14 <ajturner> been heads down on a release - but need to clean up my icon marker code to push back to the mapnik repo
17:20:26 <springmeyer> awesome
17:20:42 <springmeyer> anytime, and I'll help test
17:32:30 <nikq> Mapnik Trac: Ticket #169 (Switch to libxml2 as default parser) updated | http://trac.mapnik.org/ticket/169#comment:3
17:33:31 <nikq> Mapnik Trac: Ticket #115 (Update Install Document on Mapnik.org by release and trunk) updated | http://trac.mapnik.org/ticket/115#comment:5
18:04:30 *** D3f0 (n=defo@190.176.211.26) has joined #mapnik
18:06:21 <ajturner> springmeyer: ok
18:06:26 <ajturner> got back to the point it ws breaking
18:06:27 <ajturner> http://gist.github.com/55924
18:06:34 <ajturner> the error is at the bottom
18:06:44 <ajturner> "Failed to parse filter expression"
18:10:58 <jburgess> I was looking at this yesterday, I suspect the problem is with the setup of the "property" in either filter_parser.hpp or filter_parser_ast.hpp. Both seem to want a letter foloowing the '['
18:11:19 <ajturner> springmeyer: the shapefile is at http://highearthorbit.com/files/shp9671.zip
18:11:34 <ajturner> jburgess: yeah, seems like something that simple
18:11:53 <springmeyer> cool ajturner thanks - and sounds right on jburgess
18:11:53 <jburgess> yes... provided that there is no ambiguity in the syntax
18:12:04 * springmeyer just took a call... brb
18:19:18 <ajturner> jburgess: so should just be (alnum_p) instead of alpha_p?
18:19:21 <ajturner> whatare the implications of that?
18:19:37 <jburgess> I don't know, I was going to try it
18:20:35 <jburgess> The only downsides I can see are: [..number..] could already have a different interpretation or other code may mis-parse a purely numeric string as a number and not work properly
18:24:45 <ajturner> right, not knowing the code in& out and design decisions - wasn't sure either
18:24:51 <ajturner> are there regression tests? ;)
18:25:17 <jburgess> I can make the load_map() work with this patch: http://gist.github.com/55938
18:25:36 <jburgess> I don't know if that makes it work correctly though
18:26:30 <ajturner> lemme see
18:26:59 <ajturner> in the _ast.hpp it looks like there was an effort to make sure a alpha is first
18:27:16 <jburgess> yes, I noticed that too
18:27:32 <jburgess> it is possible a rule like that applies elsewhere, perhaps for table names in Postgresql
18:27:49 *** rcoup (n=rcoup@ip-118-90-114-62.xdsl.xnet.co.nz) has joined #mapnik
18:27:55 <ajturner> ah, well, that doesnt' affect me personally now
18:27:59 <jburgess> C has a similar rule for variables names
18:28:00 <ajturner> since only loading from shp
18:28:03 <ajturner> but concerning
18:28:47 <jburgess> I don't see it breaking anything obvious, it just allows some filter names which would have been rejected before
18:31:08 <ajturner> giving it a try
18:33:58 <ajturner> ah, tremendous
18:34:15 <ajturner> many thanks jburgess
18:34:30 <jburgess> it works?
18:35:39 <ajturner> yes, initial test ++
18:36:05 <jburgess> was there a ticket in trac for this?
18:36:32 <ajturner> no, I don't think so
18:37:41 <jburgess> ok, I'm wondering whether there should be one to attach the test case and patch to (this can help document why a certain change was made)
18:38:18 <ajturner> yes, that would seem the best idea - so if a future bug comes up can track bck to this :)
18:40:38 <CIA-23> mapnik-utils: cmarqu42 * r522 /sandbox/cascadenik/hike_n_bike/ground.mss: Support more 'green' landuse. Make buildings more opaque but desaturate the color.
18:40:39 <CIA-23> mapnik-utils: cmarqu42 * r523 /sandbox/cascadenik/hike_n_bike/roads.mss: Start supporting the lanes= tag (dotted centerline, and a bit wider than the other roads since they have gotten thinner).
18:40:39 <CIA-23> mapnik-utils: cmarqu42 * r524 /sandbox/cascadenik/hike_n_bike/poi.mss: Make ruins icon a bit bigger.
18:40:42 <CIA-23> mapnik-utils: cmarqu42 * r525 /sandbox/cascadenik/hike_n_bike/style.mml: Pull out the 'green' landuses; add road centerline for the lanes support.
18:40:45 <CIA-23> mapnik-utils: cmarqu42 * r526 /sandbox/cascadenik/hike_n_bike/roads.mss: Don't draw a lanes centerline at zoom 14.
18:43:49 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
19:52:39 *** HardDisk_WP (n=Marco@wikipedia/harddisk) has joined #mapnik
19:59:23 *** D3f0 has quit ("Konversation terminated!")
20:01:31 *** malte (n=malte@dslb-094-220-017-037.pools.arcor-ip.net) has joined #mapnik
20:01:46 <malte> hi everyone
20:02:12 <malte> i've got a problem with rendering in openstreetmap
20:02:18 <malte> can one help me?
20:04:00 <springmeyer> malte: let us know your problem and then we'll know if we can help :)
20:10:29 <cmarqu> I just read an interesting point: the height values in contour lines should always be displayed so that the base line of the text shows toward the deeper contour line.
20:11:26 <cmarqu> Can Mapnik be instructed to not rotate text (that is normally used to prvent upside-down text)?
20:13:09 <malte> springmeyer: http://www.openstreetmap.org/?lat=51.183976&lon=6.912056&zoom=18
20:13:13 <malte> look at this
20:14:34 <crschmidt> malte: generally speaking, openstreetmap.org rendering pbolems are:
20:14:39 <crschmidt>  * Incorrect data/tagging
20:14:48 <crschmidt>  * Cartographic choices by steve8
20:14:55 <crschmidt> I don't see anything obviously wrong in what you linked...
20:15:34 <malte> look at the border
20:15:53 <malte> it has got a street name and this dirty black background
20:16:40 <cmarqu> Seems that steve8 got a back halo, not a white one as he probably wanted.
20:17:38 <springmeyer> ya malte: for cartographic choices I'd join #osm on irf.oftc.net
20:17:43 <cmarqu> malte: The road there is just a named service road.
20:17:49 <malte> ok, thanks :)
20:17:51 <springmeyer> irc.oftc.net I mean
20:18:02 <malte> i'll try that server thanks
20:18:22 <malte> bye
20:18:24 *** malte has quit ("http://irc2go.com/")
20:21:45 *** adakkak_ has quit (Read error: 60 (Operation timed out))
20:32:32 <nikq> Mapnik Trac: Changeset [846]: Updated install guide for trunk, specifically noting proj as required  ... | http://trac.mapnik.org/changeset/846
20:45:35 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
20:47:32 *** springmeyer_ (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
20:47:39 *** springmeyer_ has quit (Remote closed the connection)
20:48:06 *** springmeyer_ (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
20:49:19 *** springmeyer_ has parted #mapnik ()
20:49:28 *** springmeyer_ (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
20:49:41 *** springmeyer_ has quit (Remote closed the connection)
20:49:48 *** springmeyer_ (n=springme@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
20:49:57 *** springmeyer_ has quit (Remote closed the connection)
20:51:07 <CIA-23> mapnik: dane * r846 /trunk/INSTALL:
20:51:07 <CIA-23> mapnik: Updated install guide for trunk, specifically noting proj as required
20:51:07 <CIA-23> mapnik: dependency, libxml2 as default xml, and removing path options from document
20:51:07 <CIA-23> mapnik: since the Scons changes in #186 should guide users more easily (starts to addres
20:51:07 <CIA-23> mapnik: #115)
20:51:07 <nikq> Ticket #186: Scons usability improvements, http://trac.mapnik.org/ticket/186
20:53:09 <springmeyer> all: that commit was to update the INSTALL document in trunk (which I will convert to HTML to also be here: http://mapnik.org/documentation/install/) once 0.6.0 hits the streets
20:53:45 <springmeyer> if anyone sees typos or has suggestions for improvements you can view the SVN INSTALL document here: http://trac.mapnik.org/wiki/MapnikInstallationSvn
20:55:03 <nikq> Mapnik Trac: Changeset [847]: Fixed tabs and irc link in INSTALL document | http://trac.mapnik.org/changeset/847
21:01:51 *** migurski has quit ()
21:09:24 <nikq> Mapnik Trac: Ticket #186 (Scons usability improvements) closed | http://trac.mapnik.org/ticket/186#comment:6
21:23:50 *** Mrfo (i=Mrfo@pool-96-231-166-17.washdc.fios.verizon.net) has joined #mapnik
21:24:39 <CIA-23> mapnik: dane * r847 /trunk/INSTALL: Fixed tabs and irc link in INSTALL document
21:32:45 *** Mrfo has quit ("(Deviant 1.0)")
21:45:40 *** scruggs has quit (Read error: 110 (Connection timed out))
21:46:27 *** scruggs (n=chris@72-161-105-25.dyn.centurytel.net) has joined #mapnik
22:30:02 <artem> jburgess : http://gist.github.com/55938 looks great! Would you like commit access to svn ? Or shall I apply it myself ? I don't see any wrong with allowing digits in property names
22:31:56 <jburgess> either way works for me
22:32:26 <artem> just
22:32:26 <jburgess> do you know what the filter_parser_ast.hpp is used for? That appears to duplicate some of the parsing
22:32:41 <artem> yes, it's not used at all atm
22:32:48 <artem> I'll remove it
22:33:32 <artem> jburgess: could you send my your public key, please ?
22:33:39 <artem> my->me
22:35:41 <jburgess> on its way
22:45:47 <artem> great, I just sent you email
22:46:05 *** Mrfo (i=Mrfo@pool-96-231-166-17.washdc.fios.verizon.net) has joined #mapnik
22:51:06 <jburgess> artem: It seems to be working. I can connect and perform an update. Thanks
22:51:20 <artem> no probs
22:52:00 <jburgess> should I add this change? I guess I can put something in the changelog too
22:52:11 <artem> yes, please
22:53:27 *** crschmidt has quit (Nick collision from services.)
22:53:29 *** crschmidt (i=crschmid@helios.crschmidt.net) has joined #mapnik
22:53:35 *** crschmidt has quit (Nick collision from services.)
22:54:29 <artem> jburgess: i was thinking about feature_style_processor bug. I think we need to add something like max_extent to Map object and always clip to client bbox to this extent. Otherwise, buffer_size would lead to invalid bbox.
22:54:58 <artem> I meant clip client(query) bbox to max_extent
22:55:43 <jburgess> it looked like the current code was clipping to the layer extents, is that not enough?
22:56:27 <artem> jburgess: ha , let me check ...
22:57:15 <artem> jurgess: yep, it should be enough. even better!
22:58:31 *** crschmid1 (i=crschmid@helios.crschmidt.net) has joined #mapnik
22:59:16 *** crschmid1 has quit (Client Quit)
22:59:38 <jburgess> artem: I was wondering if the map getExtent should be unchanged & have a new method "getBufferedExtent" which includes the buffer
22:59:48 <artem> jburgess: it looks like 'clipping' only occur when proj0 != proj1
23:00:08 *** crschmidt (i=crschmid@helios.crschmidt.net) has joined #mapnik
23:00:23 <artem> jburgess: yes, I like get_buffered_extent idea
23:00:42 <jburgess> I also wonder what happens if the original bbox was like -179,-89,179,89. Adding a buffer might push those over 180/90 and mess up when reprojected
23:00:48 * artem wants to lower case everything in mapnik 
23:01:21 <artem> jburgess: precisely, this is why we need a map.max_extent()
23:01:45 <artem> or proj4 will bork
23:02:53 <jburgess> It does sound like we need to define an extent parameter on the Map
23:07:43 <nikq> Mapnik Trac: Changeset [848]: Filter parsing: Allow numbers in the filter field name. This allows for  ... | http://trac.mapnik.org/changeset/848
23:13:05 <springmeyer> jburgess: Cool, just added your to the AUTHORS, pls add your email to the list if you want...
23:15:16 <CIA-23> mapnik: jburgess777 * r848 /trunk/ (CHANGELOG include/mapnik/filter_parser.hpp): Filter parsing: Allow numbers in the filter field name. This allows for shapefiles with columns like '1970'.
23:15:17 <CIA-23> mapnik: dane * r849 /trunk/AUTHORS: Added jburgess to committers list
23:19:33 <nikq> Mapnik Trac: Ticket #208 (Filter expressions fail when using numeric fields via XML) created | http://trac.mapnik.org/ticket/208
23:20:04 <nikq> Mapnik Trac: Ticket #208 (Filter expressions fail when using numeric fields via XML) closed | http://trac.mapnik.org/ticket/208#comment:1
23:25:08 <nikq> Mapnik Trac: Changeset [851]: + always clip bbox to layer extent | http://trac.mapnik.org/changeset/851
23:53:06 *** weizhuo (n=chatzill@nat/yahoo/x-b7eeb33c9baba3e8) has joined #mapnik
23:57:23 <springmeyer> so if a user has boost libs installed in two locations (and I do), how is it possible to direct SCons to only link against one specific installation?
23:58:50 <springmeyer> SCons's CheckLibwithHeader() seems to use ALL the lib paths available in the users environment rather than using JUST the paths specified for BOOST_LIBS and BOOST_INCLUDES
23:59:52 <springmeyer> so, in my case I have boost via macports in /opt/local and boost from source in /usr/local/lib