#mapnik log: Wednesday 18, March 2009

2009 | 03

previous | next
00:01:33 <cmarqu> Oh, and it's giving up watching way too early for me - Cascadenik takes maybe 20 sec for my to produce an XML file
00:02:42 <cmarqu> And after it did that, it renders grey. Didn't you change it so that it keeps the old style in memory
00:02:45 <cmarqu> ?
00:06:40 *** weizhuo has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.20/2008121709]")
00:07:07 *** weizhuo (n=chatzill@nat/yahoo/x-926d6826b34d2894) has joined #mapnik
00:18:38 * springmeyer back
00:18:43 * springmeyer reads
00:19:49 <nikq> Mapnik Trac: Ticket #259 (Hill Shading support) created | http://trac.mapnik.org/ticket/259
00:20:45 <springmeyer> interesting
00:21:11 <nikq> Mapnik Trac: marcin_rudowski_hill_shading.patch attached to Ticket #259 | http://trac.mapnik.org/attachment/ticket/259/marcin_rudowski_hill_shading.patch
00:22:24 <springmeyer> so what I did previously was 'lock' the rendering while the mapfile is being reloaded
00:22:44 <springmeyer> so if it is working as I intended (which it sounds like it may not be)...
00:23:19 <springmeyer> it *should* be forgetting/skipping tile requests made in the meantime
00:24:23 <springmeyer> but yes I can see why queing those requests would be a nicer behavior
00:24:30 <cmarqu> "it seems to have forgotten" - this means I'm seeing white (not grey as when it tried to load the style and failed)
00:25:02 <cmarqu> Well, not queueing is not a big deal.
00:25:23 <springmeyer> hmmm, right so I'm trying to understand that difference (between grey and white)
00:26:05 <springmeyer> so by 'white' you mean no tile returned right?
00:26:19 <cmarqu> I suupose so, yes.
00:26:28 <springmeyer> (likely what Mozillia firefox looks like)
00:26:59 <springmeyer> ya, so that is what should be happening while the new xml is being loaded
00:27:06 <cmarqu> Good.
00:27:19 <springmeyer> but that behavior can be changed to return a blank tile too -easy either way
00:27:54 <springmeyer> we could even spit back a tile with a 'loading...' icon :)
00:28:02 <cmarqu> The grey is the same color as my map background when I'm not using raster images, probably #eeeeee
00:28:16 <springmeyer> okay, so that is fishy
00:28:41 <springmeyer> so the renderer start allowing requests before the layers and styles are fully in memory it seems then
00:28:50 <springmeyer> start/starts
00:28:51 <cmarqu> I have a "Map { map-bgcolor: #eeeeee; }" in my style which it will not have seen though - is the same color some built-in default in Mapnik?
00:29:21 <springmeyer> mapnik has no background color default
00:29:48 <springmeyer> ya, so it is probably coming from your styles
00:30:11 <cmarqu> I'll change the #eeeeee to seomthing else then and check
00:30:24 <springmeyer> so cmarqu: you get these grey tiles for another 20 seconds or so and then the layers start rendering?
00:30:49 <springmeyer> oh oh, wait
00:30:58 <cmarqu> No, it has given up.
00:31:06 <springmeyer> ya, what it does is clear all the styles and layers from memory
00:31:10 <cmarqu> Oh, the color is from the old style it has seen.
00:31:13 <springmeyer> but the background color stays
00:31:18 <cmarqu> Ah.
00:31:19 <springmeyer> right.
00:31:32 <springmeyer> I'd have to clear that manually as well (but did not think of it)
00:31:48 <springmeyer> okay, so ...
00:32:12 <springmeyer> to recap: 1) the locking works (but should likely support queing) and...
00:32:24 <springmeyer> 2) your map reloading is failing
00:32:38 <springmeyer> and 3) I should reset the map background probably
00:33:02 <springmeyer> or just carve off a new map object
00:33:50 <springmeyer> mmmm, maybe that is the problem with the raster layers
00:33:52 <cmarqu> Well, there is a 2a) and a 2b). 2a) is the segfault with raster images. 2b) is the fact that it gives up completely after 4 seconds, while I need maybe 20 seconds.
00:34:05 <springmeyer> something about them is also not getting properly 'cleared out'
00:34:36 <springmeyer> ah, okay
00:34:52 <springmeyer> right 2a is __the__ issue for sure :)
00:35:08 <springmeyer> now I understand 2b
00:35:30 <springmeyer> so it 'gives up', okay I'll go look into that
00:36:05 <cmarqu> As another test, I had re-enabled just 1 out of my 7 raster layers and it worked ok, but this raster image was not used in the area I was requesting tiles from, so your theory can still stand. It may only fail when the raster image is actually *used*, not just present.
00:36:24 <springmeyer> facinating
00:36:29 <springmeyer> okay, that helps a ton
00:36:41 <cmarqu> Great.
00:36:51 <springmeyer> I have tested with a gdal layer but it may not have been being 'used' in the map port
00:37:34 <springmeyer> so cmarqu: are you getting 'Failed to reload mapfile,...' output?
00:38:42 <cmarqu> Yes. Before it is giving up.
00:38:59 <springmeyer> okay.
00:39:32 <springmeyer> so if the code is working as intended it *should* fail only if the mapfile parsing failed
00:40:15 <springmeyer> in other words, can you confirm that you can call load_map() on your file in general?
00:40:36 <cmarqu> Maybe cascadenik is writing the file piece by piece?
00:40:46 <springmeyer> oh, perhaps
00:40:49 *** D3f0 (n=defo@190.176.196.130) has joined #mapnik
00:41:22 <springmeyer> maybe TileLite is reading the file in before/between your sed scripting thing?
00:41:33 <springmeyer> before it is valid XML?
00:42:05 <cmarqu> It is valid XML before sed too, it just won't match the strings I want
00:42:13 <springmeyer> okay
00:42:37 <cmarqu> But in the 20 seconds it takes to compile, maybe it starts writing some opening tag already
00:43:23 <springmeyer> ya, so how are you doing this? pointing TileLite at the resultant xml or the mml?
00:43:54 <cmarqu> I don't call load_map() normally (at least not by hand), but if that means that the XML file is producing good tiles when all is done, then yes.
00:44:06 <cmarqu> I'm pointing it at the XML
00:44:17 <springmeyer> if you are pointing TileLite at the xml then surely this makes sense.... cascadenik starts writing the xml bit by bit and TileLite keeps failing thinking it is complete XML
00:44:31 <cmarqu> Aha...
00:44:36 <springmeyer> (a hunch based on what you said...)
00:44:57 <springmeyer> great. so I've only been loading xml or mml directly
00:45:16 <cmarqu> So maybe just loop trying to re-load, maybe with a capped increasing waiting time?
00:45:28 <springmeyer> so know I can go create a big mml and then point TileLite at the xml and then hit cascadenik-compile.py
00:45:32 <springmeyer> know/now
00:45:39 <springmeyer> and I should see this...
00:45:44 <cmarqu> Yes, that's my flow.
00:45:46 <springmeyer> k
00:46:31 <springmeyer> ack
00:46:46 * springmeyer looks at the changeset and realized for testing he had
00:46:56 <springmeyer> max_failures = 0
00:47:26 <springmeyer> which partly explains why I was confused why this was happening
00:48:03 <springmeyer> since I meant to leave the default at something more reasonable like 4-5 which (considering wait times would be == 20-30 seconds)
00:48:24 <springmeyer> http://bitbucket.org/springmeyer/tilelite/changeset/01a41a5784c5/#chg-tilelite.py_newline102
00:48:30 <cmarqu> Right, I'm using max_failures = 0 unchanged too.
00:48:32 * springmeyer goes to fix that default
00:48:34 <springmeyer> sorry
00:48:42 <cmarqu> No problem :)
00:49:57 * springmeyer goes with 6 times for now...
00:50:14 <cmarqu> Fix the "successfuly" in line 131 while you are at it :)
00:51:14 <springmeyer> crappy spellcheck :0
00:55:44 <springmeyer> hey cmarqu: make another copy of your openlayers.html before hg pulling
00:56:11 <cmarqu> :) Got it already.
00:56:11 <springmeyer> I'm new to hg and I keep on forgetting to limit the commit to just certain files
00:56:22 <springmeyer> cool, going back to push now...
00:56:53 <cmarqu> Ok. I only have time for a very short check though; bedtime.
00:59:03 <springmeyer> of course
00:59:06 <springmeyer> okay, ready
01:01:40 <cmarqu> max_failures could be watch_max_failures to follow the style of the other watch parameters
01:02:06 <springmeyer> good idea
01:02:27 <cmarqu> Hmm, segfault again.
01:02:28 <springmeyer> whoops, segfault here...
01:02:32 <springmeyer> :)
01:02:46 <springmeyer> well, at least I have something to debug now
01:03:36 <springmeyer> python on mac os prints a nice traceback
01:03:37 <springmeyer> http://dpaste.com/15852/
01:04:08 <springmeyer> bus error I guess here
01:06:21 <cmarqu> Cascadenik might have written the raster layers at that point, but not all the rest for me
01:07:46 <cmarqu> Since I have reinstated them in the meantime
01:08:31 <springmeyer> okay.
01:08:53 <springmeyer> my hunch now is that the locking in not working properly
01:09:24 <springmeyer> rasters may exacerbate the problem, but I just hit it without anything by an sqlite db and a shapefile
01:10:17 <cmarqu> Good in a sense, you'll find it much quicker now.
01:10:25 <springmeyer> so, I'll see what I can suss out
01:10:27 <springmeyer> ya :)
01:11:02 <springmeyer> I might need to have the load_map() return something indicated full load
01:11:27 <springmeyer> indicated/indicating
01:11:43 <cmarqu> I'll find the bed quickly now. Thanks for supporting my innocent feature request which led to all this :)
01:11:50 <springmeyer> :)
01:12:02 <cmarqu> Night.
01:12:03 <springmeyer> enjoyable so far
01:12:04 <springmeyer> night
05:52:36 <w0lfie_> hola
05:53:02 <springmeyer> buenas
05:54:48 <w0lfie_> hey
05:55:09 <w0lfie_> do you know of an open source arcims client
05:55:13 <w0lfie_> or lib
05:55:18 <w0lfie_> i just need to pull an image
05:56:06 <springmeyer> I don't know a thing about arcims, sorry
05:56:10 <w0lfie_> hm okay
05:56:12 <w0lfie_> what's new
05:57:34 <springmeyer> fully re-writing nik2img in a spare moment based primarily around boost metaclasses and class injectors
05:57:41 <w0lfie_> i don't know what that means
05:58:10 <springmeyer> nik2img is essentially a convience wrapping around mapnik python
05:58:41 <w0lfie_> why? it's already convenient
05:58:48 <springmeyer> and boost python allows you to inject new class methods easily
05:59:06 <springmeyer> essentially a way to extend the python bindings in place
05:59:26 <springmeyer> ya, I agree the python bindings are convienient already
06:00:05 <springmeyer> but for map production from the command line they can still use a bit of 'wrapping'
06:00:14 <w0lfie_> i guess
06:00:26 <w0lfie_> i dunno it seems that in order to make it useful you have to add so much
06:00:31 <w0lfie_> that it just ends up like the python *shrug*
06:01:06 <springmeyer> what do you mean?
06:01:30 <w0lfie_> well you still need to specify things like fonts and symbology
06:01:37 <w0lfie_> so don't you just end up reinventing all of those parameters
06:02:53 <springmeyer> oh, no I'm talking about symbology
06:03:23 <springmeyer> er, the layers, styles, fonts, etc
06:03:41 <springmeyer> nik2img reads in the xml for all that
06:03:41 *** dukeku has quit (Remote closed the connection)
06:03:56 <w0lfie_> guess i just don't see the point
06:04:03 <w0lfie_> since you can already read xml w/python
06:04:05 <w0lfie_> to set up that
06:04:55 <springmeyer> idea is a commandline tool for folks that don't know python or otherwise don't want to dive into an interpreter
06:05:04 <w0lfie_> i see
06:05:43 <springmeyer> which describes very few current mapnik users, but that's the problem
06:05:59 <w0lfie_> unless you build a GUI, imo you don't extend your market much
06:06:31 <w0lfie_> it's a question of customer
06:06:49 <springmeyer> I agree with that as well :)
06:06:52 <w0lfie_> The set of people that like a CLI
06:06:58 <w0lfie_> but don't want to learn a scripting language..
06:07:03 <w0lfie_> I'm just not really understanding the customer base
06:08:19 <springmeyer> I'm not writing nik2img for a customer base :)
06:08:37 <w0lfie_> just bored? :P
06:09:16 *** rcoup has quit (Read error: 110 (Connection timed out))
06:09:57 <springmeyer> I originally wrote it since I found shp2img a useful tool for debugging/developing mapfiles
06:10:25 <springmeyer> thats for the mapserver project, and wanted the ease of the same thing for mapnik
06:10:50 *** dukeku (i=dukeku@adhd.irule.net) has joined #mapnik
06:11:14 <springmeyer> I never find anything related to mapping boring :)
06:11:30 <w0lfie_> i get frustrated a lot
06:11:32 <w0lfie_> but not bored
06:13:02 <w0lfie_> just trying to figure out how to help this museum
06:13:25 <springmeyer> you work for a museum?
06:13:27 <w0lfie_> no
06:13:39 <springmeyer> ah you calling us a museum?
06:13:45 <w0lfie_> no
06:13:51 * springmeyer chuckles
06:14:39 <w0lfie_> they have this science on a sphere exhibit
06:14:58 <w0lfie_> it's a bunch of wish tying 4 projectors together
06:15:05 <w0lfie_> there's a server and a tcl/tk front-end
06:15:12 <w0lfie_> projecting onto a carbon fiber sphere
06:15:25 <w0lfie_> just trying to figure out the best way to hook up some gis inputs to it
06:15:42 <w0lfie_> its kinda cool
06:16:02 <springmeyer> sounds it
06:16:18 <w0lfie_> i was thinking it'd be cool to pull in wms feeds
06:16:28 <w0lfie_> and be able to create animations too
06:17:02 <w0lfie_> and do maybe a flex frontend
06:17:04 <w0lfie_> for a kiosk
06:17:08 <w0lfie_> so visitors can drive it
06:17:16 <w0lfie_> so you'd go to some thing that tells you about say.. global warming
06:17:29 <w0lfie_> and then you can click a button and it pulls it up onto the big sphere
06:17:32 <w0lfie_> stuff like that
06:18:12 <springmeyer> sounds like an adventure
06:18:43 * springmeyer heads to crash, catch ya later w0lfie_
06:18:49 <w0lfie_> late
07:33:06 *** weizhuo has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.20/2008121709]")
07:41:54 *** FR^2 (n=frzwo@frquadrat.de) has joined #mapnik
07:41:58 <FR^2> Ahoi
07:44:41 <w0lfie_> lo
08:00:40 *** D3f0 has quit (Remote closed the connection)
08:01:59 *** rcoup (n=rcoup@ip-118-90-3-165.xdsl.xnet.co.nz) has joined #mapnik
08:26:18 *** rcoup has quit ()
09:16:24 *** xcacou (n=aga@vel78-2-82-243-106-36.fbx.proxad.net) has joined #mapnik
10:47:51 *** rcoup (n=rcoup@ip-118-90-3-165.xdsl.xnet.co.nz) has joined #mapnik
11:01:36 *** rcoup has quit ()
12:12:43 *** darragh (n=darragh@83.70.173.25) has joined #mapnik
13:57:43 *** ninja_ (n=pankur@nat/yahoo/x-661d171fd3927114) has joined #mapnik
14:09:48 <ninja_> hey springmeyer
14:10:01 <ninja_> just looking at this ticket http://trac.mapnik.org/ticket/160
14:10:40 <ninja_> hmm is this about just building a 64 bit mapnik binary ?
14:14:46 <ninja_> anyways will talk to you about it tomorrow i am out a here see ya :)
14:14:49 *** ninja_ has parted #mapnik ()
15:21:14 *** Foriskak has quit (brown.freenode.net irc.freenode.net)
15:21:21 *** Foriskak (n=default@c-67-164-57-179.hsd1.ca.comcast.net) has joined #mapnik
16:01:59 *** keroseno (i=984add19@gateway/web/ajax/mibbit.com/x-3018d64dd74172ca) has joined #mapnik
16:07:54 <keroseno> hi, i need to know, if i can make a map with mapnik using openlayers that let me click on map an select the streets?
16:09:59 <springmeyer> if you mean select the street as in 'highlight the street as a clickable object'
16:10:03 <springmeyer> not really
16:11:04 <springmeyer> OpenLayers can do that on its own, you would just read in a datasource as WKT,GeoJSON, KML, or something like that
16:12:00 <springmeyer> and those formats could be served from shapefiles or postgis using something like featureserver or geodjango
16:12:22 <keroseno> actually i use mapserver (and i want to migrate to mapnik) doing QUERYs to a shp file with GetFeatureInfo
16:12:34 <springmeyer> oh oh
16:12:55 <keroseno> but i dont know if this QUERYs can do it in Mapnik
16:13:04 <springmeyer> sure, the mapnik OGCServer supports GetFeatureInfo, and Mapnik supports Queries
16:13:15 <keroseno> cool!
16:13:55 <keroseno> i use "mapnikserv.py" in my local server, working like CGI
16:14:45 <springmeyer> okay, sure I wrote that a while back
16:14:52 <springmeyer> "mapnikserv.py" does not support GetFeatureInfo at this time
16:15:03 <keroseno> oh
16:15:34 <springmeyer> is there a reason you are using "mapnikserv.py" and not the OGCServer?
16:16:54 <keroseno> i use "mapnikserv.py" because was the only option that i found to display images in my Local Server, (intranet, without access to internet)
16:17:35 <keroseno> i don't know if i can mount a OGCServer in my server
16:17:52 <springmeyer> okay, well the OGCServer can run as cgi too, just a bit more setup
16:18:07 <keroseno> oh great!
16:20:34 <keroseno> i'll look OCG Server documentation, if i have any doubt i ask here, thanks
16:21:07 <springmeyer> sounds good
16:21:22 <springmeyer> ogcserver docs need an update - note any changes needed
16:25:59 <keroseno> another question, if i use PostGIS, could i get the info of "polylines" like street to select them? (like alternative to GetFeatureInfo)
16:28:54 *** keroseno has quit (Read error: 104 (Connection reset by peer))
16:31:52 *** keroseno (i=984add19@gateway/web/ajax/mibbit.com/x-e729504025ee862b) has joined #mapnik
16:32:57 <keroseno> my connection was reset, i repeat my last line (sorry) : another question, if i use PostGIS, could i get the info of "polylines" like street to select them? (like alternative to GetFeatureInfo)
16:37:00 <springmeyer> I'm not sure what you are asking
16:37:04 <springmeyer> maybe explain more?
16:38:46 <keroseno> to "select" a street, i actually, draw a line feature over the map, to do this, i need all coordenates of each point of polyline
16:39:04 <dukeku> ugh, my osm import never works
16:39:43 <keroseno> to get is, i transform shp  to osm
16:39:55 <keroseno> and use the osm file like xml
16:40:42 <keroseno> to make this querys, because, the osm (xml) file, details all polyline in its points
16:41:07 <keroseno> (shp Querys doesn't returns that information )
16:42:51 <keroseno> and i was thinking wich would be the advantage, using PostGIS (replacing SHP) to get the points of polylines
16:43:05 <keroseno> :\
16:47:39 *** D3f0 (n=defo@190.176.196.130) has joined #mapnik
17:00:32 <springmeyer> keroseno: yes PostGIS sounds more appropriate for that
17:00:35 *** FR^2 has quit ("Connection reset by peer")
17:00:48 <springmeyer> since you can extract all sorts of geometrical representations
17:01:12 <springmeyer> again though I would consider using geodjango or featureserver to interact/send queries over the wire to postgis
17:01:23 <springmeyer> or perhaps use PHP
17:01:36 <springmeyer> dukeku: ya I've seen those errors too in the past
17:03:59 <keroseno> i'll look geodjango and feature server, as i said before, i need a local solution, because is for intranet and there is no internet connection, thanks!
17:04:43 <dukeku> springmeyer: i feel so...behind when using ubuntu's packages
17:05:00 <springmeyer> I only use osm2pgsql from svn
17:05:09 <dukeku> i feel like setting up a launchpad repo with weekly builds but i'm afraid i'll fuck it up
17:05:27 <dukeku> plus i dunno anyone who would want to use trunk mapnik all of the time :)
17:05:42 <springmeyer> oh you are talking about mapnik?
17:05:51 <dukeku> mapnik/osm2pgsql/etc
17:05:55 <springmeyer> ah ya
17:05:56 <dukeku> tools i use on a regular basis
17:06:05 <springmeyer> I think it would be cool
17:06:09 <dukeku> just automate it with a cron job and apt-get upgrade on my system so i wouldn't have to worry about it
17:06:20 <springmeyer> sure, nice
17:07:13 <springmeyer> rcoup has been working on a deb packaging of trunk
17:07:45 <dukeku> i've only used checkinstall before, and never done the proper way with fakeroot
17:07:56 <dukeku> as that's what you're really supposed to do to nail down dependencies
17:08:10 <springmeyer> yes, I think he's a fakeroot master :)
17:08:27 <dukeku> checkinstall is _great_ for individual use :)
17:09:27 <dukeku> springmeyer: do you extract anything from osm data?
17:09:35 <dukeku> ie polygon extractions
17:10:12 <springmeyer> ah, I've just used the basic style, nothing fancy yet no
17:10:38 <dukeku> my attempt at making a polygon didn't go so well
17:10:53 <dukeku> but i didn't put too much effort into it
17:11:07 <dukeku> all of the polygons in osm trunk are all from europe
17:14:51 <springmeyer> there are some great polygons in boston
17:14:52 <springmeyer> http://www.openstreetmap.org/?lat=42.35964&lon=-71.06428&zoom=15&layers=B000FTF
17:15:40 <dukeku> oh jeez
17:16:04 <dukeku> a guy i work with found some weird negative polygons around the sf bay, housing developments that were built inside of a park
17:17:59 <springmeyer> interesting
17:45:00 *** D3f0 has quit (Remote closed the connection)
17:46:34 *** darragh has quit (Remote closed the connection)
18:11:52 *** xcacou has quit (Remote closed the connection)
18:11:59 *** D3f0 (n=defo@190.176.196.8) has joined #mapnik
19:24:54 *** rcoup (n=rcoup@ip-118-90-3-165.xdsl.xnet.co.nz) has joined #mapnik
19:29:17 *** rcoup has quit (Client Quit)
20:07:41 *** D3f0 has quit (Read error: 104 (Connection reset by peer))
20:11:43 *** rcoup (n=rcoup@ip-58-28-159-166.static-xdsl.xnet.co.nz) has joined #mapnik
20:29:57 *** rcoup has quit (Read error: 54 (Connection reset by peer))
20:30:01 *** rcoup (n=rcoup@ip-58-28-159-166.static-xdsl.xnet.co.nz) has joined #mapnik
21:29:57 <rcoup> quick one - SRID for continental US thats in meters?
21:30:02 <rcoup> doesn't have to be accurate at all
21:30:16 * rcoup isn't there, i could tell you lots about NZ/Australia :P
21:30:47 <rcoup> just need to do a few rough buffer calculations
21:36:31 <rcoup> s/buffer/distance
21:38:11 <springmeyer> http://spatialreference.org/ref/esri/102008/
21:38:35 <springmeyer> or http://spatialreference.org/ref/esri/102003/
21:40:29 <rcoup> do they have equv EPSG codes?
21:41:11 <springmeyer> no, so unless you are using gdal...
21:41:28 <springmeyer> hmmm
21:45:02 <springmeyer> ya, I know of no US-wide projections that actually have a formal epsg code besides those added by ESRI
21:45:31 <springmeyer> the US must have hit peak oil before epsg got organized ;)
21:47:17 <rcoup> springmeyer: thanks, 102008 will probly do the trick
21:48:25 <racicot> cant you just use the Google Mercator projection ... it is in meters and if you dont care to much about accuracy...
21:49:03 <racicot> although I guess it does not have an "official" epsg either
21:50:22 <rcoup> racicot: was after something mildly not wrong :) but yeah, thanks
21:50:36 <rcoup> it does have an official epsg code as of late last year
21:51:52 <racicot> ;-) was not sure how wrong was acceptable
23:19:55 <cmarqu> springmeyer: Cool, tilelite seems to be working fine now!
23:20:14 <springmeyer> ah brilliant
23:20:49 <springmeyer> ya, I needed to contain the load_map() call inside the thread watcher loop
23:21:25 <springmeyer> otherwise the thread could potentially launch another load_map (without waiting for it to finish) and clobber itself
23:21:55 <springmeyer> do your rasters work now?
23:22:14 <cmarqu> Yes.
23:22:19 <springmeyer> cool!
23:23:46 <cmarqu> Though... I now had the case where it would not generate tiles for almost 2 minutes (the system was pretty loaded).
23:23:59 <cmarqu> Then, apparently there was a timeout.
23:24:22 <springmeyer> wow, your mapfile is huge huh?
23:24:59 <springmeyer> let me know if the default watcher settings could be improved
23:25:04 <cmarqu> Dragging the map around didn't change much, even when the CPU and IO was down again, but pressing Ctrl-C once on tilelite made it responsve again
23:25:18 <springmeyer> oh, i see, interesting
23:25:29 <cmarqu> Actually, no, this wasn't with a new mapfile, I was just panning the map
23:25:37 <springmeyer> so maybe a memory limit perhaps
23:25:45 <cmarqu> That could be.
23:25:46 <springmeyer> hmmm
23:26:12 <springmeyer> or simply that the python wsgref server can't handle long waits
23:26:53 <springmeyer> which is indepedent of the tilelite.py code and related to the local server used in the liteserv.py script
23:27:04 <springmeyer> have you tried deploying with mod_wsgi yet?
23:27:24 <springmeyer> I need to test that again (now) with this watching code
23:27:39 <cmarqu> No, not yet.
23:28:28 <springmeyer> okay. well I'm sure the local httpd server can be tweaked but mod_wsgi is really the way to go
23:28:38 <cmarqu> About this st_difference question...
23:28:44 <springmeyer> sure
23:29:06 <cmarqu> I initially filled my PostGIS DB with data in a certain bounding box
23:29:41 <cmarqu> I now get the hourly/minutely updates for the DB, but these cover the whole world.
23:29:59 <cmarqu> So gradually, my DB fills up with "uninteresting" data
23:30:29 <cmarqu> And I would like to remove this other stuff.
23:30:43 <springmeyer> okay
23:31:34 <cmarqu> Is there some way to play it safe and use a GUI for that? I don't want to accidentally blow away my DB just now :)
23:32:18 <springmeyer> um, not sure about a GUI. Quantum GIS keeps adding more postgis support, but I'm not aware of how many operations it support
23:32:33 <springmeyer> why not just copy your db? or is it too big?
23:32:43 <springmeyer> then play around with deleting stuff in that copy?
23:33:00 <cmarqu> Probably not. I just don't know any SQL
23:33:22 <springmeyer> okay.
23:33:36 <springmeyer> #postgis would be a good place to ask for sql query tips
23:33:56 <springmeyer> createdb -T <your_current_db> <new_copy>
23:34:03 <springmeyer> thats how I would make a copy
23:34:47 <cmarqu> Thanks, I'm letting that run now.
23:36:53 <cmarqu> To get a geometry for st_difference, I would use e.g. st_makebox2d(st_makepoint(lat1,lon1),st_makepoint(lat2,lon2)) ?
23:37:31 <cmarqu> And wrap that in st_setsrid(...,4326); ?
23:40:36 <springmeyer> hmm. I think the idea would be to generate the 'mask' of the area to delete
23:40:49 *** D3f0 (n=defo@190.176.196.8) has joined #mapnik
23:41:20 <springmeyer> by using ST_difference to remove out the area you care about from a global extent polygon
23:42:12 <springmeyer> so I would make your global area with something like ST_GeometryFromEWKT()
23:42:48 <springmeyer> er actually nevermind ya st_makebox and setsrid would work fine
23:56:32 <cmarqu> I should probably start reading the basics. The more I read about people using st_difference etc., the more confused I get.
23:56:41 *** D3f0 has quit (Remote closed the connection)
23:57:05 <springmeyer> okay, well perhaps take a simplier approach
23:57:35 <springmeyer> load up your layers in quantum gis and draw a big box of the areas you want to delete
23:57:38 <springmeyer> :)
23:58:42 <cmarqu> That sounds good. :)