00:48:40 <ser> when i am trying to access a wms layer in qgis
00:49:18 <ser> i am receiving a black rectangle only
00:49:38 <ser> i mean e.g. roads from osm
00:50:03 <ser> but e.g. world layer looks OK
03:26:00 *** kets has quit (Remote closed the connection)
04:43:50 *** rcoup (n=rcoup@60.234.198.86) has joined #mapnik
04:49:18 *** rcoup_ has quit (Read error: 110 (Connection timed out))
05:22:32 *** rcoup has quit ()
06:15:23 *** xcacou (n=aga@28.54.86-79.rev.gaoland.net) has joined #mapnik
09:17:06 *** rcoup (n=rcoup@ip-118-90-53-55.xdsl.xnet.co.nz) has joined #mapnik
09:35:49 <nikq> Mapnik Trac: OCCI edited | http://trac.mapnik.org/wiki/OCCI?version=2
11:14:40 *** rjmunro (n=chatzill@87.127.91.51) has joined #mapnik
11:24:24 *** synax (n=synax@24.222.57.182) has joined #mapnik
11:31:23 <rjmunro> Are there any howtos anywhere about setting up a Mapnik server with VMAP0 data?
12:18:37 <ser> i have the same question with arcinfo adf files
13:10:00 *** rcoup has quit ()
14:10:40 <springmeyer> ser: black rectangles huh? I think I've seen that before
14:11:05 <springmeyer> something to do with the way QGis handles PNG's via Mapnik
14:11:51 <springmeyer> generally more commonly seen color render differently in QGis after georeferencing nik2img.py output with a worldfile
14:15:26 <nikq> Mapnik Trac: Ticket #308 (Doesn't display feature if another (possibly invalid) feature is present) updated | http://trac.mapnik.org/ticket/308#comment:3
14:16:07 <nikq> Mapnik Trac: ctrans.diff attached to Ticket #308 | http://trac.mapnik.org/attachment/ticket/308/ctrans.diff
14:27:10 <springmeyer> rjmunro: remind me, VMAP0 data is simply vectors shapefiles right?
14:27:32 <springmeyer> or are they arcinfo coverages as distributed?
14:57:06 *** sanjiv (n=sanjiv@59.180.130.26) has joined #mapnik
15:00:38 <nikq> Mapnik Trac: Ticket #308 (Doesn't display feature if another (possibly invalid) feature is present) updated | http://trac.mapnik.org/ticket/308#comment:4
15:09:37 <nikq> Mapnik Trac: messed_up_bbox.png attached to Ticket #308 | http://trac.mapnik.org/attachment/ticket/308/messed_up_bbox.png
15:09:47 <nikq> Mapnik Trac: borked_shape.png attached to Ticket #308 | http://trac.mapnik.org/attachment/ticket/308/borked_shape.png
15:10:45 <rjmunro> springmeyer: AFAIK it's all vectors. I think There are versions converted to shapefiles around on the net.
15:11:42 <springmeyer> okay, then what do you need to get going?
15:12:05 <rjmunro> That's kind of what I was asking... :-)
15:12:10 <springmeyer> rjmunro: there are lots of tutorials around on rendering OSM global data. generally those will be quite good guides
15:12:21 <springmeyer> the principles apply:
15:12:42 <springmeyer> 1) big vector dataset so storing in postgres/postgis will be key
15:13:24 <springmeyer> 2) to make a pretty map you'll need to learn about the attributes of VMAP0 and therefore will need to learn about Mapnik's XML styles
15:14:06 <springmeyer> 3) I recommend getting rendering going locally first, then figuring out how you want to serve the data after that
15:16:46 <springmeyer> rjmunro: that help at all? :)
15:18:44 <nikq> Mapnik Trac: Ticket #308 (Doesn't display feature if another (possibly invalid) feature is present) updated | http://trac.mapnik.org/ticket/308#comment:5
15:21:55 *** racicot has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.21pre/2009020912]")
15:22:55 *** racicot (n=chatzill@dsl-209-166-85-189.whidbey.net) has joined #mapnik
15:30:16 <springmeyer> rjmunro: this is a nice recent writeup on osm rendering start to finish:
15:30:17 <springmeyer> http://www.weait.com/content/build-your-own-openstreetmap-server
15:31:38 *** racicot has quit ("ChatZilla 0.9.84 [Firefox 2.0.0.21pre/2009020912]")
15:35:06 *** racicot (n=chatzill@dsl-209-166-85-189.whidbey.net) has joined #mapnik
15:39:07 <rjmunro> springmeyer: Thanks. I was hoping that someone would have styles I can use as a basis, but I guess I'll just have to do the work myself. :-)
15:41:24 <springmeyer> ya, I've never heard of anyone rendering VMAP0 with mapnik
15:41:28 <springmeyer> but good try :)
15:41:56 <springmeyer> rjmunro: if you post styles I'm sure folks will get into it :)
16:03:45 <nikq> Mapnik Trac: Ticket #93 (Allow for fractional/double 'halo_radius' values) updated | http://trac.mapnik.org/ticket/93#comment:5
16:04:46 <nikq> Mapnik Trac: fractional_halo_radius.patch attached to Ticket #93 | http://trac.mapnik.org/attachment/ticket/93/fractional_halo_radius.patch
16:08:34 <nikq> Mapnik Trac: Ticket #93 (Allow for fractional/double 'halo_radius' values) updated | http://trac.mapnik.org/ticket/93#comment:6
16:12:04 *** sanjiv is now known as sanjiv_away
16:30:41 *** sanjiv_away is now known as sanjiv
16:32:40 *** xcacou has quit (Remote closed the connection)
16:45:44 *** kets (n=fear@87.251.152.50) has joined #mapnik
17:02:15 *** schmiddis_world_ (n=schmiddi@91-64-22-88-dynip.superkabel.de) has joined #mapnik
17:02:16 <ser> i have the same question with arcinfo adf files (coverages?)
17:02:27 <schmiddis_world_> hallo
17:02:28 <ser> i cannot see any examples on mapnik webpage
17:02:38 *** schmiddis_world_ has quit (Client Quit)
17:02:57 <springmeyer> ser: the ogr plugin should be able to read them
17:03:07 <ser> springmeyer: thanks, i will check
17:03:25 <springmeyer> ser: but you would likely be better off using ogr2ogr to convert them to something else first
17:05:45 <ser> ok, thanks
17:07:42 <springmeyer> reason is that coverages are composed for both polylines and polygons and nodes
17:08:14 <springmeyer> so you either pull out one of those sublayers and write to a new file using ogr2ogr
17:08:47 <springmeyer> or you need to specify the layer name using the layer parameter of the ogr datasource
17:14:25 <ser> thnaks
17:36:48 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik
17:46:18 *** sanjiv has quit (Read error: 110 (Connection timed out))
17:49:12 *** sanjiv (n=sanjiv@59.180.132.213) has joined #mapnik
17:50:01 *** rjmunro has quit ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032608]")
18:21:11 *** sanjiv has quit (Connection timed out)
18:21:42 *** sanjiv (n=sanjiv@59.180.131.57) has joined #mapnik
18:57:17 *** sanjiv has quit (Connection timed out)
18:59:20 *** sanjiv (n=sanjiv@59.180.158.63) has joined #mapnik
19:35:03 *** synax has quit ()
19:37:50 *** wonxly (i=9e931426@gateway/web/ajax/mibbit.com/x-abe44fa7f3468376) has joined #mapnik
19:40:05 <wonxly> hey guys, i'm still stuck :(  the last thing i had going on was this error when trying to read the shoreline data with the postgis plugin http://dpaste.com/33203/
19:40:24 <wonxly> some people recommended trying to set the cursor_size parameter
19:40:39 <wonxly> so after setting it as low as 10 i am seeing this http://dpaste.com/34067/
19:43:02 <springmeyer> wonxly: how much memory do you have on your machine?
19:43:08 <springmeyer> and what os again? spark?
19:43:15 <wonxly> 4GB
19:43:41 <wonxly> yeah this is solaris 10 on sparc
19:44:31 <springmeyer> huh. okay
19:44:36 <springmeyer> can you replication on linux?
19:44:46 <springmeyer> ( I assume not? )
19:45:04 <wonxly> correct, it is even working on solaris 10 X68 :(
19:45:14 <wonxly> is there any good way to try to debug it?
19:45:35 <springmeyer> um, well the tools depend on your system of course
19:45:44 <springmeyer> and I know nothing about solaris
19:46:11 <springmeyer> gdb or valgrind available on solaris?
19:46:22 <wonxly> any linux tools you would suggest?  i can get most things from linux working on solaris
19:47:02 <springmeyer> wonxly: and this is when rendering that shapefile?
19:47:29 <springmeyer> it borks when read as a shapefile directly and when read from postgres, right?
19:48:17 <springmeyer> maybe you need to tune your postgres settings - postgres on solaris may have too small of shared memory limits?
19:48:22 <wonxly> correct, it would not render from the shapefile correctly so i used shp2pgsql to put the data in postgres and now it fails there, it is rendering the osm data from postgres correctly though
19:48:35 <wonxly> which confuses me :(
19:48:42 <springmeyer> ya.
19:48:49 <springmeyer> can you try to render with the ogr plugin?
19:48:57 <springmeyer> do you have gdal/ogr installed?
19:49:37 <wonxly> unfortunately no :( what is required to build the ogr plugin?  gdal?
19:50:02 <springmeyer> ya, gdal build with ogr enabled
19:50:23 <springmeyer> then compile mapnik and point mapnik at the gdal-config program installed with gdal
19:50:35 <springmeyer> you could build gdal in debug mode as well
19:50:45 <springmeyer> and perhaps see the point it fails a bit more clearly
19:51:10 <springmeyer> try to deduce if it is a memory issue or some invalid geometry or a library conflict, etc ,etc
19:51:11 <wonxly> how do i convert the shapefile data into ogr data?
19:51:22 <springmeyer> ogr will read the shapefile directly
19:51:28 <wonxly> oh ok
19:51:47 <springmeyer> and you can convert to dozens of other formats as well and still read directly via the ogr plugin
19:53:28 <wonxly> ok i will try that..thanks for your help springmeyer
19:54:33 <springmeyer> no problem. I don't know if that will help but I just guess it might lead to more clues
19:54:45 <springmeyer> wonxly: I assume you've googled that error a good bit?
19:55:13 <wonxly> yeah, it looks like that error is related to failing when trying to allocate more memory
20:01:54 *** rcoup (n=rcoup@ip-58-28-159-166.static-xdsl.xnet.co.nz) has joined #mapnik
20:06:46 <jburgess> another idea might be to copy a simplified version of the data to another table and use that for lower zoom tiles. This is what the OSM mapnik rendering does
20:17:43 <Ldp__> could the inability to process the shape files on sparc have anything to do with the big-endianness of the platform?
20:22:30 <jburgess> looking at that dpaste output it looks like the query was fetching the coastline data for the entire world. It isn't surprising this takes needs lots of RAM if the coastline is highly detailed.
20:22:56 <Ldp__> I also seem to recall him deleting the shape index files... is that true wonxly?
20:23:11 <jburgess> how large was the original shapefile?
20:23:32 *** sanjiv has quit ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032711]")
20:24:40 <Ldp__> [20:45] <wonxly> yes springmeyer...the other day you recommended me removing the .index files...i tried that but then it just ran forever at 100% CPU
20:24:58 <Ldp__> and he was using the OSM shapefiles, so probably processed_p and shorelines_300 ?
20:25:22 <wonxly> yes Ldp, i did do that, but then i extracted the shoreline_300 back to its original before executing the shp2pgsql
20:26:19 <wonxly> the other thing i was confused about is while monitoring the system while it was processing i still had over 3GB of RAM free when i get the error
20:26:26 <wonxly> it is even exhausting all of the system RAM
20:26:38 <wonxly> *it isn't even,
20:27:02 <jburgess> I'd be tempted to attach to the rendering process with gdb, then you should be able to set a breakpoint on the abort. That should give you a chance to see how big the process is when the error occurs
20:27:26 <jburgess> Is it a 32 or 64 bit process? The limits on 32 bit processes are often quite low
20:28:02 <wonxly> it is a 32 bit process
20:28:18 <jburgess> I think using the shpaefiles should use less memory than going via postgres, but you may also need to set the NUM_THREADS to 1
20:28:42 <jburgess> I think mapnik attempts to mmap() the shapefile for each rendering thread
20:28:54 <wonxly> yes i would like to use the shapefiles but for some reason the shape plugin doesn't work on sparc :(
20:29:13 <jburgess> since the files is ~800MB in size this very quickly uses up your address space
20:29:32 <jburgess> perhaps the large mmap for the shapefile is failing?
20:30:30 <jburgess> are you sure that you only have a 32 bit capable machine? The sparc CPUs have been 64 bit for a long time
20:31:50 <wonxly> how do i tell if it is a 64 bit process?  here is the output i get from running the file command on renderd (which is the process that is using mapnik to render the tiles) ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
20:33:47 <jburgess> are you compiling with gcc? if so, try adding -m64 to the CFLAGS in the makefile
20:37:33 <jburgess> with -m64, you should get an executable which says something like: ELF 64-bit MSB executable SPARCV9 Version 1 ...
20:38:03 <wonxly> ok, thanks jburgess i will try that
20:38:57 <jburgess> I just tried using -m64 on a simple hello world program on a solaris box and it worked for me (but I have not tried it with the renderd code)
20:39:43 <jburgess> I think you'll need to add -m64 to the RENDER_CPPFLAGS in the Makefile & rebuild the renderd
20:40:25 <jburgess> oh... the bigger problem you'll face is that you'll also need 64 bit versions of Mapnik, boost etc too.... those could be a lengthy recompile
20:40:31 <Ldp__> jburgess: any chance of getting autotools on mod_tile? :)
20:41:05 <wonxly> yeah i was just thinking that ;)
20:41:08 <jburgess> possibly, though I'm not quite convinced the code is complex enough to make it worthwhile.
20:41:20 <jburgess> I'm not sure how well autotools works for Apache modules
20:41:31 <Ldp__> well, even for this 'simple' code, I had to edit the config to get it going
20:41:47 <Ldp__> a way to detect the font directory would be a plus
20:42:19 <wonxly> does anyone have a rough idea how big the whole data set would be for all the tiles for the entire world of the open street map data?  i am thinking it would be easier to do the rendering on a linux box and transfer the data over afterwards
20:44:00 <wonxly> are we talking less than a DVD?
20:44:10 <Ldp__> I'd guess not
20:44:17 <Ldp__> do you need z17/z18?
20:44:25 <jburgess> for the whole world I think the current estimate is 10TB+ , with several months worth of CPU time
20:44:34 <wonxly> wow
20:44:56 <jburgess> 2^18 * 2^18 tiles is a lot
20:46:01 <wonxly> yeah, maybe i could get away with only up to about z14 or 15
20:46:13 <wonxly> but that is still a lot of data :(
20:47:05 <Ldp__> and mod_tile doesn't play nice if you use OL with a small extent
20:47:28 <Ldp__> do you need the whole world?
20:47:42 <wonxly> yeah i need the whole world :(
20:48:36 <Ldp__> and you're stuck with the sparc box?
20:49:23 <wonxly> yeah :( i will have to talk to some people here at work and see if they can just buy me a linux server...i think things would be so much easier
20:49:37 <Ldp__> linux runs on sparc too
20:49:51 <Ldp__> you're really not stuck with Solaris, technically
20:50:16 <Ldp__> althoug if it's an endianness problem in the shapefile code, that still doesn't help
21:06:35 <jburgess> wonxly: what error were you seeing with the shapefile plugin?
21:26:47 <wonxly> no error messages, but i was getting query size=0 0 features in the debugging output
21:27:34 <wonxly> i saw a post in a forum about invalid index files so i ran shapeindex to regenerate a .index   Then i got a query size but still 0 features
21:42:35 <nikq> Mapnik Trac: Changeset [1101]: Add run_tests.py, a utility for running the test framework (useful for  ... | http://trac.mapnik.org/changeset/1101
22:05:48 *** wonxly has quit ("http://www.mibbit.com ajax IRC Client")
22:45:40 *** Ldp__ has quit ()
23:06:24 <nikq> Mapnik Trac: Changeset [1102]: Adding tests for common mapnik classes. | http://trac.mapnik.org/changeset/1102