00:03:05 <dukeku_> is there any written explanation of the expected returns of any functions, like features_at_point()?
00:03:19 <dukeku_> how are those functions called?
00:03:49 <springmeyer> not that I am aware of
00:04:21 *** lucasd (n=lucasd@c-98-246-72-107.hsd1.or.comcast.net) has joined #mapnik
00:04:24 <lucasd> doh
00:04:29 <lucasd> irc box died
00:04:32 *** lucasd is now known as dukeku
00:04:50 <dukeku> not trying to be generic, i'm not sure what amount of data would be returned with features_at_point()
00:05:08 <dukeku> is it a radius search, bounding box, what?
00:10:13 <springmeyer> I think it is more of a hit test, to grab an iterable of features
00:10:24 <springmeyer> at truly a single point
00:11:49 <springmeyer> you can see the idea of a featureset operating in this python script
00:11:51 <springmeyer> http://mapnik-utils.googlecode.com/svn/example_code/memory_datasource/sea.py
00:13:33 <dukeku> hm
00:14:18 * dukeku might be spending a few weekends writing a plugin
00:16:28 <springmeyer> features_at_point returns a featureset_ptr which can be used to create a feature_ptr which is the point at which rules are evaluated
00:17:36 <springmeyer> cool dukeku_
00:17:44 <springmeyer> then you can teach us all :)
00:18:04 <springmeyer> my sense is this is the stop that features of a datasource are accessed:
00:18:04 <springmeyer> http://trac.mapnik.org/browser/trunk/include/mapnik/feature_style_processor.hpp#L190
00:18:44 *** dukeku_ has quit (Read error: 104 (Connection reset by peer))
00:21:14 <dukeku> oh, so features() are given a query (bbox, resolution)
00:21:21 <dukeku> s/are/is/
00:21:23 <dukeku> that makes more sense
00:42:52 *** dukeku_ (i=dukeku@adhd.irule.net) has joined #mapnik
00:43:10 *** dukeku has quit ("bye")
00:43:14 *** dukeku_ is now known as dukeku
00:47:46 *** weizhuo has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.20/2008121709]")
00:55:00 *** dukeku has quit (Remote closed the connection)
01:21:25 *** dukeku (i=dukeku@adhd.irule.net) has joined #mapnik
02:55:34 *** ninja_ (n=pankur@nat/yahoo/x-7eb4b92fafc78039) has joined #mapnik
03:37:13 *** rcoup has quit (Read error: 60 (Operation timed out))
03:41:56 *** ninja_ has quit (Read error: 104 (Connection reset by peer))
03:42:12 *** ninja_ (n=pankur@nat/yahoo/x-e2be5f65e52873ff) has joined #mapnik
03:43:07 *** rcoup (n=rcoup@ip-118-90-22-54.xdsl.xnet.co.nz) has joined #mapnik
03:50:52 *** tomhughes has quit (brown.freenode.net irc.freenode.net)
03:50:52 *** nikq has quit (brown.freenode.net irc.freenode.net)
03:50:58 *** tomhughes (n=tom@gate.compton.nu) has joined #mapnik
03:50:58 *** nikq (n=nikq@li21-121.members.linode.com) has joined #mapnik
05:18:32 <CIA-6> mapnik-utils: dane.springmeyer * r596 /trunk/nikinfo/nikinfo.py: touchup auto xml output
05:22:09 <springmeyer> .startrss
05:22:09 <nikq> Okay, I'll re-start rss...
07:50:33 *** xcacou (n=aga@AToulouse-157-1-22-249.w86-201.abo.wanadoo.fr) has joined #mapnik
08:15:15 *** ninja_ has quit ()
08:33:28 *** FR^2 (n=frzwo@frquadrat.de) has joined #mapnik
08:33:31 <FR^2> Hiho
08:38:22 <FR^2> Aaah... building mapnik using gcc 3.4.6 seems to work ;)
11:30:22 <FR^2> horray! importing map data to the postgre db ;)
11:48:45 <FR^2> "excepton caught processing way" :(
11:51:34 <tomhughes> it's an exceptional way!
11:53:43 <FR^2> Well, the "i" is missing in the error message, but I just dropped the database, recreated it and imported a smaller subset of the osm data, and it worked.
11:53:57 <FR^2> I read about some memory issues when importing large osm datasets.
12:41:03 *** xcacou_ (n=aga@AToulouse-157-1-1-3.w86-201.abo.wanadoo.fr) has joined #mapnik
12:54:12 *** xcacou has quit (Read error: 110 (Connection timed out))
15:41:50 *** FR^2 has quit ("Connection reset by peer")
16:45:01 *** xcacou_ has quit (Remote closed the connection)
18:16:50 <cmarqu> springmeyer: Not sure if you read this or if it's interesting at all: http://www.mail-archive.com/dev@openstreetmap.org/msg06315.html
18:17:30 <cmarqu> Seems a bit like tilelite
18:42:56 *** D3f0 (n=defo@190.176.196.130) has joined #mapnik
20:08:25 *** D3f0 has quit (Read error: 104 (Connection reset by peer))
20:47:05 <dukeku> 2. Run this script. It might take some minutes, but you only have to do this once each month, after you download the new planet.osm dump. The resulting file OpenStreetMap is almost as big as the planet.osm file (for May 2006, planet.osm is 93 megabytes, and OpenStreetMap is 59 megabytes).
20:47:12 <dukeku> jeez, planet.osm at only 93mb
20:48:45 <cmarqu> :)
20:49:03 <cmarqu> "Small world"
20:53:18 <dukeku> apparently
22:13:00 *** weizhuo (n=chatzill@nat/yahoo/x-0fe74ade110a186e) has joined #mapnik
23:06:58 *** ortelius (n=chatzill@67.111.118.67.ptr.us.xo.net) has joined #mapnik
23:08:19 <ortelius> hello all, had a question about the SRTM demos I am seeing ... am I correct in my understanding that the PerryGeo GDAL DEM Utils are used to render the hillshade and then mapnik is used for the Hypsometric tints (graduated colors by elevation)?
23:10:16 <cmarqu> ortelius: No, I think there is another perrygeo tool to do it in one step.
23:10:32 <ortelius> ok, but mapnik itself does not do the hillshading?
23:11:11 <cmarqu> No.
23:11:23 <ortelius> and, if the perrygeo tools are doing the whole thing, then these are not mapnik demos per se?
23:12:30 <cmarqu> These are demoing Mapnik's ability to user raster images.
23:12:36 <cmarqu> s/user/use/
23:12:37 <ortelius> ah, excellent
23:12:44 <ortelius> ok, just a bit confusing for me
23:12:47 <cmarqu> http://mike.teczno.com/notes/hillshading.html has some info
23:13:05 <ortelius> so, the perrygeo tools are my best bet for hillshading and hypsometric tints?
23:13:10 <ortelius> outside of something like grass
23:13:12 <ortelius> ?
23:13:44 * springmeyer stumbles in
23:13:59 <springmeyer> no cmarqu: I had'nt seen that. sure similiar ya
23:14:02 <cmarqu> I don't know, I just followed well written instructions when I did my map, and they happed to use the perrygeo tools :)
23:14:24 <springmeyer> nice to see lots of tools about
23:14:31 <ortelius> ok, I am using the perrygeo tools, just wanted to make sure this was the current state of the art
23:15:49 <springmeyer> ortelius: confusion is founded. they are demoing only mapnik's ability to server rasters currently, but artem has yet unreleased integration of the concepts of the hillshading tools within mapnik (too)
23:16:28 <ortelius> nice
23:16:31 <ortelius> thats what I was getting at
23:16:35 <springmeyer> he's said it is just a matter of cleaning them up
23:16:42 <cmarqu> Oh, interesting.
23:16:55 <springmeyer> and I sense it is now a matter of integrating the features of a few other patches
23:17:06 <ortelius> hmm, maybe I should have a chat with him, I am going to kick off a cache of the worldwide srtm data set on EC2 here pretty quick
23:17:18 <springmeyer> that provide cool raster symbolization
23:18:36 <springmeyer> I would guess artem has other priorities right now, including the 0.6.0 release
23:18:50 <ortelius> no worries, I can rerun the cache at some later date
23:18:56 <springmeyer> so if I were you I'd start caching
23:18:58 <springmeyer> :)
23:19:01 <ortelius> yep
23:19:04 <springmeyer> cool
23:19:09 <ortelius> its not my $, so if I have to rerun it, such is life :)
23:19:29 <springmeyer> if you want to demo stuff, let me dig up marcin's raster stuff...
23:20:25 <cmarqu> I only knew about http://trac.mapnik.org/wiki/Compositing
23:21:24 <springmeyer> here is it...
23:21:27 <springmeyer> .g My patches for hill shading
23:21:28 <nikq> springmeyer: https://lists.berlios.de/pipermail/mapnik-users/2009-February/001651.html
23:22:10 <ortelius> thx
23:22:32 <cmarqu> Man, I had totally forgotten about that.
23:24:46 <springmeyer> caveat: I've applied but not used marcin's patch so I don't know what kind of overlap it has with artem's composing modes
23:32:42 *** ortelius has quit ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]")
23:38:10 *** D3f0 (n=defo@190.176.196.8) has joined #mapnik
23:46:05 * springmeyer response to the osm-dev list and added Tilelite to the list here:
23:46:05 <springmeyer> http://code.google.com/p/mapnik-utils/
23:46:40 * springmeyer hopes cmarqu's segfault magically dissapears :)
23:48:33 <cmarqu> springmeyer: I'm working on that right now actually
23:52:58 <nikq> Mapnik Trac: Changeset [1012]: minor fix in revision number for scale_denominator map property | http://trac.mapnik.org/changeset/1012
23:53:39 <cmarqu> springmeyer: Ok, I had my first successful reload after I commented out my raster layers.
23:53:52 <springmeyer> mmm. interesting
23:54:29 <cmarqu> I was modifying the file while it was still busy rendering tiles
23:54:46 <springmeyer> ya, you should be able to do that no problem
23:54:48 <cmarqu> So pretty stressful for it :)
23:55:05 <springmeyer> or at least I've stressed it as hard as I could without getting a segfault
23:55:06 <springmeyer> right
23:56:17 <cmarqu> I noticed one thing:
23:56:24 <springmeyer> okay...
23:56:33 <cmarqu> I touch the XML file.
23:56:36 <springmeyer> I've stepping out for a sec thougt
23:56:43 <springmeyer> be back in 15 minutes
23:56:45 <cmarqu> It says "Mapfile **changed**, reloading..."
23:56:50 <cmarqu> Okay
23:56:56 *** D3f0 has quit ("Konversation terminated!")
23:56:59 <springmeyer> keep typing of course if you want
23:57:04 <cmarqu> I'm leaving a backlog for you then
23:57:06 <cmarqu> Yep
23:57:23 <cmarqu> I move the slippy map.
23:57:50 <cmarqu> I get multiple messages like "localhost.localdomain - - [18/Mar/2009 00:55:46] "GET /a/16/35328/21954.png HTTP/1.1" 404 9"
23:58:10 <cmarqu> Then it says "Mapfile successfuly reloaded from /home/colin/mapnik/osm_teczno_customized.xml"
23:58:59 <cmarqu> But it seems to have forgotten about the tiles that I requested in the meantime.