02:20:24 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik 02:59:02 *** migurski has quit () 04:04:52 *** rcoup_ has quit () 04:27:50 *** D3f0 has quit (Remote closed the connection) 04:30:58 *** aub has quit () 06:20:37 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik 07:48:00 *** xcacou (n=aga@AToulouse-157-1-165-31.w83-193.abo.wanadoo.fr) has joined #mapnik 08:21:05 *** kunitoki (i=55121f9a@gateway/web/ajax/mibbit.com/x-c2361faf062ca282) has joined #mapnik 08:21:12 *** kunitoki_ (i=55121f9a@gateway/web/ajax/mibbit.com/x-28ecd17717c67dc3) has joined #mapnik 08:22:37 *** kunitoki1 (n=kraken@host210-49-dynamic.7-79-r.retail.telecomitalia.it) has joined #mapnik 08:23:09 *** kunitoki has quit (Client Quit) 08:24:09 *** kunitoki_ has quit (Client Quit) 08:36:55 *** kunitoki1 is now known as kunitoki 12:32:22 *** aub (n=aubrey@cpe-72-227-134-148.nyc.res.rr.com) has joined #mapnik 12:41:04 *** aub has quit () 14:04:54 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 14:08:52 *** aub (n=aubrey@static-70-107-236-83.ny325.east.verizon.net) has joined #mapnik 14:09:32 *** aub_ (n=aubrey@static-70-107-236-83.ny325.east.verizon.net) has joined #mapnik 14:09:32 *** aub has quit (Read error: 104 (Connection reset by peer)) 14:48:03 <kunitoki> artem: any chance to apply sqlite patches ? i know they are uber-alpha but may be simpler for tracking changes if they gets checked in 14:52:08 <artem> kunitoki: yes, I'm playing with your patches at the moment. I'll apply then asap . We need to decide how we're going to ref spatial index table. How about extending 'geometry_columns' to have extent and spatial index table name 14:52:23 <artem> ? 14:57:20 <kunitoki> well it is interesting 14:57:41 <kunitoki> anyway spatialite wkb already have extent 14:58:31 <kunitoki> if you look here: 14:58:48 <kunitoki> http://www.gaia-gis.it/spatialite-2.3/spatialite-2.3_manual.html#t3 in section 3.3 14:59:34 <kunitoki> but probably you mean table-wise-extent and not single-row-extent ? 15:00:27 <kunitoki> ah yes 15:00:31 <artem> yes, layer extent 15:01:19 <kunitoki> yes, if you look at my code, in the sqlite_datasource there is a #if 0 around that 15:01:41 <kunitoki> you can specify that table, and it looks for minx, miny, maxx, maxy 15:01:49 <kunitoki> i call it geocatalog 15:02:57 <kunitoki> anyway there is also the MBR Caching support in spatialite (which adds some triggers for managing cache of table extents) 15:03:13 <kunitoki> the only drawback is: "creation of both R*Tree and MbrCache on the same Geometry column is not supported" 15:03:20 <artem> kunitoki: yep, I saw it. I just winder if using 'standard' geometry_columns is better strategy 15:03:58 <kunitoki> yeah but 'standard' geometry_columns doesn't have extent. nor we require triggers to keep those extent in sync with the table 15:04:38 <kunitoki> we shuld use MbrCache for that purpose, but we lose the spatial index on that column 15:04:49 <kunitoki> which is unacceptable 15:05:36 <artem> I'm about to go out but I'll read about MbrCache . 15:06:58 <artem> I don't quite understand why MbrCache and r*tree index are self excluding 15:07:41 <artem> r*tree index is just a virtual table, mbr-cache is another, right ? 15:08:25 <kunitoki> yeah they are different kind of indexes. one is a virtual table, the other is in memory 15:08:56 <artem> i think it's spatialite restriction rather then sqlite 15:09:22 <kunitoki> yeah 15:09:26 <kunitoki> i think too 15:09:41 <artem> btw, r*tree index works quite well 15:09:55 <kunitoki> have you implemented something on my code to use it ? 15:10:08 <artem> I'm reading ~40,000 linestring features (Norway OSM) 15:10:08 <kunitoki> i'm curious := 15:10:24 <artem> yes, I added some hacks to your patch:) 15:10:37 <kunitoki> obviously. you welcome :D 15:11:10 <kunitoki> it's fast ? 15:11:22 <artem> we need a good query builder to merge client SQL with spatial index 15:11:37 <artem> yes, it is fast for this small data set 15:11:42 <kunitoki> mmmh that is one of my newer question for you 15:11:51 <kunitoki> but we will discuss about it 15:12:29 <kunitoki> cause most of the time i need to pass to the datasource (oracle) special queries with join and the use of more specialized where clauses 15:13:12 <artem> yes, sure . I really need to run now. I'll commit my hacks later on today and we can discuss how to take it forward. 15:13:23 *** artem has quit () 15:45:23 *** darragh (n=darragh@83.70.173.25) has joined #mapnik 15:49:20 *** darragh has parted #mapnik () 16:32:34 *** D3f0 (n=defo@190.176.194.209) has joined #mapnik 16:40:38 *** xcacou has quit (Remote closed the connection) 16:45:01 *** kunitoki has quit ("leaving") 17:56:59 *** kunitoki (n=kraken@host210-49-dynamic.7-79-r.retail.telecomitalia.it) has joined #mapnik 18:50:59 *** cmarqu has quit (Remote closed the connection) 18:54:56 *** rcoup (n=rcoup@ip-118-90-27-63.xdsl.xnet.co.nz) has joined #mapnik 19:10:25 <Mrfo> springmeyer, im running into some issues using that pointsymbolizer and text style you created before 19:10:46 <springmeyer> okay 19:11:02 <Mrfo> i think because the point icon is alot smaller than the text, i get times where i get only points 19:11:50 <Mrfo> lemmie take a quick snapshot 19:14:20 *** D3f0 has quit ("Konversation terminated!") 19:18:56 <Mrfo> http://img15.imageshack.us/img15/1006/mapwithoutny7.png -- this is the map without the points 19:19:32 <Mrfo> http://img509.imageshack.us/img509/1199/mapwithpointsbj8.png -- this is with them on 19:20:13 <Mrfo> the area to note is at the bottom centerish area. theres more dots than cities 19:22:08 <springmeyer> yes, I see that 19:22:39 <springmeyer> makes sense because, like you say, the collision avoidance affects the 'larger' text more than the points 19:23:03 <springmeyer> Mrfo: do you ideally/cartographically want more text or less points? 19:23:21 <springmeyer> nice maps btw! 19:23:46 <Mrfo> ummmm, less points would be good. im fine with fewer cities being on there as long as theres not extra dots 19:23:52 <Mrfo> thanks :) 19:26:17 <Mrfo> i tried the shieldsymbolizer, but the dx,dy for the shieldsymbolizer shifts the entire shield 19:26:48 <springmeyer> hmm, ya, this is an obvious need but I don't see an easy solution 19:28:56 <springmeyer> i think a 'min_distance' parameter on the PointSymbolizer would get you closer (if that were added) 19:29:17 <springmeyer> but would still lead to some points being placed where text was not (due to size differences) 19:30:50 <Mrfo> yeah. i can't think of much either 19:30:54 <Mrfo> its no biggie though 19:31:43 <springmeyer> This seems like a common usecase: some smart way of truly associating the point with the text is needed 19:32:15 <springmeyer> and ya, the control is not their in the ShieldSymbolizer either, even though that gets closer to this idea ^^^ 19:37:38 <Mrfo> yeah. not sure what the solution is 19:37:46 <Mrfo> but ill see if i can think of something 19:41:00 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 19:43:42 <springmeyer> ya, perhaps some kind of PointLabelSymbolizer that borrows from all the nice TextSymbolizer rules but enforces that a point will be places only if the text label is placed 19:43:58 <nikq> Mapnik Trac: Changeset [881]: + sqlite-input-plugin.patch (kunitoki) + wkb-sqlite.patch (kunitoki) + ... | http://trac.mapnik.org/changeset/881 19:44:06 <Mrfo> yeah that would be pretty cool 19:44:24 <springmeyer> and then it could have additional options to allow you to control what direction the label is placed in relation to the point 19:44:38 <Mrfo> yeah i was just about to mention that 19:44:54 <Mrfo> ideally you could get a better fit if you didn't care about directions either 19:45:03 <springmeyer> up/down , n/e/s/w or 'best fit' 19:45:10 <springmeyer> ya, right :) 19:46:07 <springmeyer> but in cluttered maps it is often nice for the eye/undstanding to be able to find a label then look for the point off of a predicable side 19:46:23 <springmeyer> or at least I try to achieve that effect when manually making labels 19:46:33 <Mrfo> thats a good point 19:46:51 <Mrfo> ideally they both have their uses 19:47:02 <springmeyer> Mrfo: maybe a ticket discribing this for the 1.0.0 milestone? 19:47:19 <Mrfo> sure i can do that 19:55:17 <springmeyer> Mrfo: how does your server search go? 19:56:16 <Mrfo> heh, not too good. costs a bit more than i figured 19:56:57 <springmeyer> oh, I mean your choice of tool to serve mapnik tiles.... 19:57:08 <CIA-23> mapnik-utils: dane.springmeyer * r548 /trunk/nik2img/ (CHANGELOG.txt nik2img.py): Add alpha support for rendering a map by pulling the map definition from a python script 'load_pymap()' 19:57:42 <springmeyer> but I'd be interested about what server hardware too 19:58:45 <Mrfo> ohh 19:58:46 <Mrfo> lol 19:59:04 <Mrfo> ummm, still using tilecache atm. i tried some stuff with modtiles 19:59:31 * crschmidt would not recommend tilecache if you have complex/slow tiles 19:59:36 <crschmidt> and lots of users 20:00:40 <Mrfo> i think mod tile is going to be the best solution, its just going to take a bit to set it up 20:01:39 <Mrfo> although given how often the tiles need to update, i dont know if theres any perfect solution really 20:03:20 <Mrfo> crschmidt, is tilecache not a good solution with complex tiles? 20:03:58 <Mrfo> it seems to render about as fast as mapnik viewer or nik2img 20:04:44 <crschmidt> TileCache renders inside the serving process 20:04:57 <crschmidt> so if you have many users all browsing areas they haven't seen before, they'll use up all your apache children 20:05:08 <crschmidt> mod_tile uses a single backend renderer 20:05:23 <crschmidt> So you don't have lots of different processes trying to render at the same time 20:05:36 <crschmidt> with TileCache, you can get 100 processes all fighting for the same couple CPUs 20:05:40 <crschmidt> with mod_tile, you don't have that 20:05:44 <Mrfo> ah 20:05:57 <crschmidt> If you have fast-to-render tiles, that's okay 20:06:09 <crschmidt> because the tiles render quick enough that you don't get a backlog 20:06:15 <crschmidt> (this is why it's not a problem for most other services) 20:06:24 <crschmidt> but if your tiles are slow, then you get that backlog 20:06:36 <Mrfo> makess ense 20:06:38 <Mrfo> *sense 20:06:47 <crschmidt> It might be possible to make a rendered tile source for TileCache 20:07:03 <crschmidt> but it's probably not worth it 20:16:49 <CIA-23> mapnik: artem * r881 /trunk/ (11 files in 5 dirs): 20:16:49 <CIA-23> mapnik: + sqlite-input-plugin.patch (kunitoki) 20:16:49 <CIA-23> mapnik: + wkb-sqlite.patch (kunitoki) 20:16:49 <CIA-23> mapnik: + very preliminary spatial index support (idx_<tablename>_<geometry_field>) 20:17:24 *** ser has quit (kubrick.freenode.net irc.freenode.net) 20:17:45 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik 20:24:35 <jburgess> Could we revert the use of the "-fast" gcc flag in r881? I believe it is only supported on the Apple version of gcc. 20:24:38 <nikq> http://trac.mapnik.org/changeset/881, at , by artem: + sqlite-input-plugin.patch (kunitoki)+ wkb-sqlite.patch (kunitoki)+ very preliminary spatial index support (idx_<tablename>_<geometry_field>) 20:27:51 *** D3f0 (n=defo@190.176.212.26) has joined #mapnik 20:41:47 <springmeyer> jburgess: +1 ya I bet that was just for testing 20:42:11 <artem> jburgess: my bad sorry, I'll revert that change 20:42:39 <jburgess> cheers :) 20:42:43 <springmeyer> I added the ability to set the OPTIMIZATION level, not sure if that is useful enought to keep or modify to accept an arbitrary flag like --fast ? 20:42:56 <springmeyer> up to you guys... 20:44:09 <nikq> Mapnik Trac: Changeset [882]: + reverting back accidental change | http://trac.mapnik.org/changeset/882 20:45:40 <artem> springmeyer : yes, OPTIMIZATION flag is good 20:46:46 <springmeyer> okay. I questioned it once I realized that -O3 wouldn't work 20:59:27 <CIA-23> mapnik: artem * r882 /trunk/SConstruct: + reverting back accidental change 21:05:47 <artem> springmeyer: -O3 works fine for me 21:06:51 <springmeyer> ah, okay, cool 21:06:58 <springmeyer> does cairo work? 21:07:15 <springmeyer> #193 is what happened to me with -O3 21:07:16 <nikq> Ticket #193: Bus Error during Image render at cairo extract_surface(), http://trac.mapnik.org/ticket/193 21:07:52 <springmeyer> but perhaps I assumed wrongly that it was the -O3 flag and it was actually a cairo install problem... 21:08:10 <artem> ah, ok. interesting 21:09:01 <artem> it works find with -fast which is just a shortcut to -O3 -fomit-frame-pointer ... 21:09:09 <artem> fine 21:09:17 <springmeyer> okay, great 21:41:13 <dukeku> urgh, mapnik box died 21:48:49 <artem> kunitoki: ping did you try using spatial index ? 22:22:21 *** artem has quit () 22:24:19 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik 23:18:30 *** weizhuo (n=chatzill@nat/yahoo/x-04358482f4ad2bbe) has joined #mapnik 23:46:37 *** artem has parted #mapnik ()