#mapnik log: Monday 29, March 2010

2010 | 03

previous | next
00:51:01 <hesco> I seem to be spinning wheels here.  I have mapnik and gdal installed, but am having trouble locating a tutorial which will tell me how to translate my geo-coded data into a new layer to compile with the TIGER data into a county map.  Can anyone here please point the way?
00:52:27 <hesco> I have code which will render a map from the county data census provides.  I can see in that code how to add a new layer.  What I'm missing a script which will take geocoded data and turn it into a shape file ready to read as a new layer on the map.
01:03:32 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
01:09:16 *** c_lopez (~ccaarloos@189.161.105.76) has joined #mapnik
01:10:17 <c_lopez> hello everyone, hi Mr. Springmeyer
01:10:32 <springmeyer> hello c_lopez!
01:10:46 <springmeyer> how are you?
01:12:01 <c_lopez> fine and you?  :)
01:12:29 <springmeyer> very good :)
01:12:52 <springmeyer> just back from traveling
01:15:18 <springmeyer> c_lopez: tomorrow I travel again to http://en.oreilly.com/where2010 where I will see Tom Carden and Mike Migurski
01:15:43 <springmeyer> who are other potential great mentors for the "better printing" project
01:16:03 <springmeyer> and I can ask them any questions you might have...
01:16:58 <c_lopez> oh right, you told us you were going to travel this past week. Thanks for replying to my comment on ticket 343.
01:16:59 <nikq> Ticket #343: Add a resolution parameter to Map object, http://trac.mapnik.org/ticket/343
01:17:55 <springmeyer> c_lopez: no, problem!
01:18:00 <springmeyer> what errors did you run into?
01:18:12 <c_lopez> thanks, I've got a couple of questions, I submitted some of them on friday, in the discussion thread of the mailing list.
01:18:36 <springmeyer> great, I'll take a look at that thread and respond now
01:19:22 <c_lopez> well, I had to change some of the external entities in the osm.xml from & to %.
01:19:48 <springmeyer> hmm, interesting
01:20:00 <springmeyer> are you sure you had the latest version?
01:20:17 <c_lopez> of mapnik_utils?
01:20:30 <springmeyer> no, of the 'osm.xml' and related files...
01:20:44 <c_lopez> let me check
01:21:02 <springmeyer> also, c_lopez re: mapnik_utils python module...
01:21:10 <springmeyer> I updated today to be compatible with Mapnik2:
01:21:11 <springmeyer> http://code.google.com/p/mapnik-utils/source/detail?r=917
01:21:20 <springmeyer> so you should update that from trunk too
01:21:56 <springmeyer> but as I said in my ticket comment, the use of the 'mapnik_utils' python code is optional
01:23:49 <c_lopez> right, the version of mapnik utils I have still imports mapnik.
01:24:22 <springmeyer> yes, sorry about that, just fixed if you update
01:24:33 <springmeyer> it now defaults to using Mapnik2, if available
01:34:56 <c_lopez> sorry, I think I have an old version of osm. I don't know where I got it from  : \
01:35:46 <c_lopez> that's great, I download that version of mapnik_utils too
01:36:12 <c_lopez> sorry, I'll download it
01:37:33 <springmeyer> c_lopez: for osm.xml just check out from svn
01:38:21 <springmeyer> svn co http://svn.openstreetmap.org/applications/rendering/mapnik osm-mapnik
01:39:22 <springmeyer> good idea to use both osm.xml from latest svn trunk and osm2pgsql from latest svn trunk
01:39:46 <springmeyer> c_lopez: see http://svn.openstreetmap.org/applications/rendering/mapnik/README for basics
01:42:55 *** ultrus has quit (Quit: happy new year)
01:50:42 <c_lopez> thanks, I'll start with the readme then.
01:58:26 <springmeyer> c_lopez: I got distracted, but just responded to mapnik-users/devel email
01:58:38 <springmeyer> I think you are understanding Robert's idea very well
02:03:30 <c_lopez> I was confused at first because I started reading the thread backwards. I thought that Tom Hughes' cairo renderer had those features already.
02:04:32 <springmeyer> ah
02:04:36 <springmeyer> no it does not
02:04:50 <springmeyer> ya, tracking threads can be tricky :)
02:05:09 <springmeyer> pretty much Ben Moores work came first
02:05:27 <springmeyer> and while it added some key features (as discussed)
02:05:34 <springmeyer> it did not make it into trunk
02:05:54 <springmeyer> while the Cairo renderer was added to trunk and was a more generic solution
02:06:02 <springmeyer> and it able to be built upon
02:06:08 <springmeyer> it/is
02:06:29 <hesco> any recipe available on creating a shape file from geocoded data?
02:06:47 <springmeyer> but adding legend/scale/grid, etc perhaps may not actually be done in cairo_renderer.cpp
02:07:14 <springmeyer> but rather in a separate classes that interact with it and use the Cairo API
02:07:39 <springmeyer> hesco: what do you have, points (eg. lat lon)?
02:09:30 <hesco> yes, points with lat and longitude
02:09:59 <springmeyer> hesco: well, lots of potential ways, but if you grok python then using GDAL/OGR python bindings would be a solid route
02:10:25 <hesco> I grok perl and flounder a bit with python, but not too terribly.
02:10:41 <springmeyer> okay, well there are perl bindings to gdal too
02:10:46 <springmeyer> I've not used them though
02:10:52 <springmeyer> hesco: perhaps even easier then...
02:11:01 <springmeyer> would be to simply write out a text file of...
02:11:10 <springmeyer> lon,lat,id,etc
02:11:11 <hesco> I have heard that gdal and ogr are the way to go, what I have been unable to find is any docs or recipe which might show me the way
02:11:25 <c_lopez> mr springmeyer: so it would not be an extension to Tom Hughes' work, but a separate component?
02:11:25 <springmeyer> and then use gdal to conver that to a shapefile using gdal_translate
02:11:50 <hesco> gdal_translate will convert a csv file into a shape file?
02:11:54 <springmeyer> c_lopez: good question :)
02:11:57 <springmeyer> hesco: yes
02:12:07 <springmeyer> .g 'gdal vrt/csv'
02:12:08 <nikq> springmeyer: http://www.gdal.org/ogr/drv_csv.html
02:12:38 *** haoyu (~bhy@cm26.delta25.maxonline.com.sg) has joined #mapnik
02:13:08 <hesco> thanks, pursuing that now
02:14:05 <springmeyer> hesco: ya that should work well
02:14:21 <springmeyer> VRT files take a little getting used to, but they are brilliant
02:14:32 <springmeyer> so basically you would go
02:14:54 <springmeyer> geocoded info --> csv --> shp (through VRT description)
02:16:46 <c_lopez> mr springmeyer:  I'll read through Tom Hughes' code to see which approach would be better.
02:17:29 <springmeyer> c_lopez: my first thought is that "map adornments" like scale/grid/legend  would be rendered after the map features
02:18:05 <springmeyer> and ideally could be drawn on top of map either rendered with Cairo or Agg
02:19:36 <springmeyer> c_lopez: I am sure that artem and tom hughes would have more ideas on whether separate component is needed
02:20:22 <springmeyer> Ben Hughes I think used new symbolizers in the wxpdfdoc branch, but honestly I have not take a close look
02:23:56 <rweait> springmeyer: welcome back.  Hope you had a great time.
02:24:31 <springmeyer> hey rweait :) yes, did have a great time
02:25:18 <springmeyer> driving into montana was like returning into winter (as Seattle is in full bloom), but the skiiing was great
02:27:12 <c_lopez> mr springmeyer: he says that the only symbolizer that was left is the marker symbolizer, and that the line pattern simbolizer is implemented partially.
02:27:34 <hesco> so, springmeyer: I read that link, and tested its sample code, and ogrinfo recognized my file.
02:28:01 <hesco> now how would I use that to either create a shape file, or to access it directly as a new datasource for my composited map?
02:28:08 <springmeyer> c_lopez: are you talking about cairo_renderer.cpp ?
02:28:51 <springmeyer> hesco: if ogrinfo can understand the VRT then you can use ogr2ogr to convert into a shapefile
02:29:24 <hesco> thanks, looking into that now
02:29:49 <springmeyer> ogr2ogr output.shp input.vrt
02:33:33 <hesco> thank you, I've been searching for just that advise for going on three days now (although I was away from my desk nearly all of Saturday).
02:34:00 <springmeyer> hesco: ah, good good, so that worked?
02:34:01 <hesco> With those two clues, I think I'm fairly close to completing two of today's three deadlines !!!
02:34:09 <springmeyer> cool :)
02:34:26 <hesco> haven't see the promised land yet, but I suspect this may be the River Jordan
02:34:46 <hesco> I'll know in about ten or thirty minutes
02:38:07 <c_lopez> mr springmeyer: no, about the wxpdfdoc branch. Sorry, I hadn't understood what you mentioned about the symbolizer when I said that.
02:38:18 <springmeyer> ah, okay
02:38:40 <springmeyer> yes, I should try to look at the wxpdfdoc branch myself to understand the implementation more
02:46:45 <hesco> ok, applying that new one point layer rendered the entire map as the background color.
02:47:07 <springmeyer> hesco: http://dpaste.com your XML?
02:47:24 <hesco> somehow I need to make it transparent.  I suspect I also need to somehow create a style for my point(s) to render with
02:47:32 <hesco> coming your way
02:47:40 <springmeyer> yes you do need a style
02:47:59 <springmeyer> but if can be as simple as
02:48:38 <springmeyer> <Style name=
02:48:41 <springmeyer> er
02:49:09 <springmeyer> <Style name="foo"><Rule><PointSymbolizer /></Rule></Style>
02:49:37 <hesco> http://dpaste.com/177197/
02:49:55 <hesco> does it also go in the xml .vrt file ???
02:50:52 <springmeyer> no
02:51:06 <springmeyer> hesco: I meant the XML for your mapnik map....
02:51:13 <hesco> ok, where should I hide it then?
02:51:25 <springmeyer> huh?
02:51:54 <springmeyer> hesco: maybe step back for a moment and tell me how you are currently using Mapnik and rendering your map?
02:51:55 <hesco> ah, what I have is a python script which builds a bunch of layers with TIGER shape files
02:52:10 <hesco> I'll paste the py script in a moment
02:52:33 <springmeyer> ah okay, so not using XML, that is fine
02:53:45 <hesco> http://dpaste.com/177199/
02:54:38 <hesco> I have not really sorted out which order these layers ought to be applied in.
02:55:15 <hesco> I seem to get better results commenting out those last few lines, which I suspect ought to be rendered earlier in the process.
02:55:57 <springmeyer> ah, okay, I see what you are up to
02:56:03 <springmeyer> so, tiny problem
02:56:05 <hesco> my /root/alachua_county/members.csv is my only custom data.  The rest of it is straight from TIGER.
02:56:10 <hesco> yes?
02:56:11 <springmeyer> okay
02:56:28 <springmeyer> so lyr.datasource = foo
02:56:44 <springmeyer> each time you use that you are re-setting the datasource
02:56:57 <springmeyer> rather than adding them together, which I'd guess you want to do
02:57:01 <hesco> not building on them?
02:57:05 <springmeyer> right
02:57:08 <hesco> yes, right
02:57:15 <springmeyer> each shapefile needs to be its own layer
02:57:33 <springmeyer> Mapnik does not have a way to combine them
02:57:40 <hesco> what if I ran m.layers.append(lyr) between each of those lines?
02:58:01 <springmeyer> yes, that would be closer
02:58:15 <hesco> or do I need to define a bunch of lyr's and then .append them all at the end?
02:58:31 <springmeyer> that would be the safest
02:58:41 <hesco> ok, rewriting now.
02:58:57 <springmeyer> although I think once you have added a layer to the Map object anything newly added will be a new object
02:59:07 <springmeyer> hesco: you can do...
02:59:17 <springmeyer> print m.save_map_to_string()
02:59:34 <springmeyer> at anytime in that script to see the XML representation of the Map that Mapnik knows about
02:59:40 <hesco> each lyr? would have the same definition right?  = mapnik.Layer('world',"+proj=latlong +datum=WGS84")
02:59:41 <springmeyer> which will help you see whether:
02:59:46 <springmeyer> 1) you have added new layers
02:59:46 <springmeyer> and
02:59:55 <springmeyer> 2) whether you have properly associated the styles
03:00:02 <springmeyer> hesco: yes
03:00:11 <hesco> ok, back in a moment
03:00:14 <springmeyer> sure
03:02:00 <springmeyer> hesco: just so you know, http://bitbucket.org/springmeyer/quantumnik/ is a plugin to a Graphical GIS that can help with authoring the XML
03:02:23 <springmeyer> then from python you can just do `mapnik.load_map(m,'your.xml')`
03:02:34 <springmeyer> to attach styles and layers
03:06:17 <hesco> so how do I handle the lyr.styles.append('My Style') line.
03:06:26 <hesco> do I also need to replicate it for each layer?
03:07:29 <springmeyer> hesco: yes
03:08:17 <hesco> ok, one more moment and I'll run a test and report back then.
03:08:24 <springmeyer> hesco: python has a mechanism to copy objects
03:08:32 <springmeyer> from copy import copy,deepcopy
03:08:52 <springmeyer> and you could potentially use that to keep your code more consice
03:09:05 <springmeyer> although copy support in Mapnik is a work-in-progress
03:11:18 <hesco> I assume I also need to replicate this through the code, as well: m.zoom_to_box(lyr.envelope()) ???
03:11:58 <springmeyer> no
03:12:12 <springmeyer> just for now do at the end of your script:
03:12:17 <springmeyer> m.zoom_all()
03:16:20 *** mperry has quit (Quit: mperry)
03:16:52 <hesco> ok, thanks, just tested that. and I see the county map again.
03:17:25 <springmeyer> ya, what was likely happening before is you were zooming only to the last layer added
03:17:30 <springmeyer> and that layer was not showing up
03:17:32 <hesco> I'm thinking that when I saw the bg color, it probably surrounded my single point in my test file
03:17:39 <springmeyer> because you need to apply a PointSymbolizer to it
03:17:48 <springmeyer> perhaps yes
03:17:50 <hesco> ok, so where would I do that?
03:18:00 <springmeyer> zooming to just one point will not make for a great map :)
03:18:11 <springmeyer> in the Style
03:18:14 <hesco> not in the vrt file, but where?
03:18:56 <springmeyer> hesco: check this link:
03:19:00 <springmeyer> `GettingStarted
03:19:01 <nikq> http://trac.mapnik.org/wiki/GettingStarted
03:20:18 <springmeyer> so:
03:20:27 <hesco> yes, that is the code I started with, which has grown into what I had posted earlier
03:20:27 <springmeyer> r.symbols.append(mapnik.PointSymbolizer())
03:20:53 <hesco> before the s.rules.append() line, I imagine
03:21:09 *** haoyu has quit (Read error: Connection reset by peer)
03:21:17 <springmeyer> yep
03:22:29 <hesco> so the final tweak, which I suspect will make it far easier to see the new point I added (confirming for me that I will be able to complete this project) is to have this map render only the city of Alachua, not the entire county of Alachua.
03:22:52 <hesco> Any clues how to set the bounding box to look at only a subset of the data?
03:23:52 <springmeyer> m.zoom_to_box(mapnik.Envelope(xmin,ymin,xmax,ymax))
03:24:07 <springmeyer> just have to figure out the bounds of Alachua
03:24:08 <hesco> perfect, thanks
03:24:36 <hesco> that I have already harvested off of one of the online services
03:25:20 <hesco> does that replace or supplement the zoom_all invocation?
03:26:25 <springmeyer> yep
03:26:31 <hesco> well, maybe I had not harvested those
03:26:47 <hesco> yep which?
03:27:03 <hesco> replace ??? or add to ???
03:27:05 <springmeyer> yes, it replaces m.zoom_all()
03:27:10 <hesco> ok, thanks
03:27:13 <springmeyer> try this for getting bounding box
03:27:13 <springmeyer> http://dbsgeo.googlecode.com/svn/trunk/openlayers/extents_tool.html
03:27:19 <springmeyer> ignore gmaps warning
03:31:03 <hesco> sweet, and closer yet !!!
03:33:28 <hesco> so, a large number of points which were previously hidden are now revealed (with the new style).  I would like to hide those and reveal only my custom points, along with the road network.
03:33:53 <hesco> alternately, I would want to style my own points so they can be distinguished.
03:34:21 <hesco> any idea how to accomplish that?
03:34:50 <springmeyer> customize your styles for particularly layers rather than applying the same style to each layer
03:35:24 <springmeyer> and potentially use filters to get sub-selections of data from certain layers that match certain criteria
03:35:30 <hesco> ok, I'll try that
03:35:51 <springmeyer> http://trac.mapnik.org/wiki/XMLGettingStarted
03:35:56 * springmeyer heads out for a bit
03:39:27 <hesco> thank you so much for your help
04:14:19 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
04:29:09 *** HounD has parted #mapnik (None)
04:38:42 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik
04:57:03 *** mikejs_ is now known as mikejs
05:39:23 *** c_lopez has parted #mapnik (None)
05:50:47 *** jbronn has quit (Remote host closed the connection)
05:51:03 *** jbronn (~jbronn@70-138-113-15.lightspeed.hstntx.sbcglobal.net) has joined #mapnik
05:58:54 *** josias (~d469dc41@gateway/web/freenode/x-hvdtnzrqzixebsio) has joined #mapnik
06:02:54 *** springmeyer has quit (Quit: springmeyer)
06:12:38 *** rulus has quit (*.net *.split)
06:12:38 *** blan has quit (*.net *.split)
06:12:38 *** jburgess_ has quit (*.net *.split)
06:12:39 *** BillK has quit (*.net *.split)
06:12:39 *** CIA-70 has quit (*.net *.split)
06:12:39 *** serek has quit (*.net *.split)
06:12:39 *** crust has quit (*.net *.split)
06:12:39 *** mikejs has quit (*.net *.split)
06:12:39 *** rweait has quit (*.net *.split)
06:12:40 *** twain47 has quit (*.net *.split)
06:12:40 *** cmarqu has quit (*.net *.split)
06:12:40 *** josias has quit (*.net *.split)
06:12:40 *** hesco has quit (*.net *.split)
06:12:40 *** HounD1 has quit (*.net *.split)
06:12:40 *** tomhughes has quit (*.net *.split)
06:12:40 *** sam` has quit (*.net *.split)
06:12:40 *** dodobas has quit (*.net *.split)
06:12:40 *** jctull has quit (*.net *.split)
06:12:40 *** mapnikbuild has quit (*.net *.split)
06:30:25 *** josias (~d469dc41@gateway/web/freenode/x-hvdtnzrqzixebsio) has joined #mapnik
06:30:25 *** HounD1 (~HounD@unics1.grfc.ru) has joined #mapnik
06:30:25 *** hesco (~hesco@c-24-99-160-121.hsd1.ga.comcast.net) has joined #mapnik
06:30:25 *** tomhughes (~tom@gosford.compton.nu) has joined #mapnik
06:30:25 *** blan (~blan@HSI-KBW-082-212-049-146.hsi.kabelbw.de) has joined #mapnik
06:30:25 *** cmarqu (colin@oemcomputer.oerks.de) has joined #mapnik
06:30:25 *** rulus (~rulus@xvm-19-63.ghst.net) has joined #mapnik
06:30:25 *** serek (~ser@house.metalab.unc.edu) has joined #mapnik
06:30:25 *** BillK (~BillK@124-148-220-8.dyn.iinet.net.au) has joined #mapnik
06:30:25 *** mikejs (~me@mikej.st) has joined #mapnik
06:30:25 *** CIA-70 (cia@208.69.182.149) has joined #mapnik
06:30:25 *** jburgess_ (~jburgess@15.92.187.81.in-addr.arpa) has joined #mapnik
06:30:25 *** rweait (~nerd@bas2-toronto47-1242436670.dsl.bell.ca) has joined #mapnik
06:30:25 *** jctull (~jctull@adsl-75-0-29-113.dsl.renocs.sbcglobal.net) has joined #mapnik
06:30:25 *** crust (~crust@vobster.nepharia.org) has joined #mapnik
06:30:25 *** twain47 (~twain47@cpc8-shef7-0-0-cust85.barn.cable.virginmedia.com) has joined #mapnik
06:30:25 *** sam` (~sam@glau.bulix.org) has joined #mapnik
06:30:25 *** dodobas (~dodobas@open.geof.hr) has joined #mapnik
06:30:25 *** mapnikbuild (~mapnikbui@miranda.nwcr.net) has joined #mapnik
07:16:10 *** c_lopez (~ccaarloos@189.169.35.195) has joined #mapnik
07:20:52 <josias> how i can specify a bounding box for rendering? i dont want to render the whole world...
08:25:54 *** tomhughes has quit (Ping timeout: 268 seconds)
08:25:56 *** tomhughes (~tom@gosford.compton.nu) has joined #mapnik
08:39:28 <josias> how i can cancel the generate-tiles.py?
09:30:17 *** mishok13 has quit (Ping timeout: 248 seconds)
09:43:10 *** mishok13 (~gdmfsob@smtp-kyiv.cogniance.com) has joined #mapnik
10:50:28 *** Genscher (~Richard@188.105.225.250) has joined #mapnik
11:17:05 *** rweait has parted #mapnik (None)
12:08:32 *** c_lopez has parted #mapnik (None)
12:11:15 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
12:11:56 *** HounD1 has parted #mapnik (None)
12:16:29 *** artem has quit (Quit: artem)
12:44:46 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
13:08:45 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
13:11:52 *** dkb1 (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
13:14:50 *** dkb has quit (Ping timeout: 265 seconds)
13:21:39 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
13:33:05 *** artem has quit (Quit: artem)
13:47:55 *** gavinf (~gavinf@196.211.2.133) has joined #mapnik
14:07:46 *** josias has quit (Quit: Page closed)
14:10:36 *** haoyu (~bhy@cm26.delta25.maxonline.com.sg) has joined #mapnik
14:12:03 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
14:13:15 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
14:14:02 *** dkb1 has quit (Remote host closed the connection)
14:35:23 *** artem has quit (Quit: artem)
14:41:31 *** rweait (~nerd@66.11.182.154) has joined #mapnik
14:42:15 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
14:42:21 *** HounD has quit (Client Quit)
14:42:50 *** jctull has quit (Quit: jctull)
14:48:06 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
14:48:14 *** jctull (~jctull@adsl-75-0-29-113.dsl.renocs.sbcglobal.net) has joined #mapnik
14:58:45 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
15:00:41 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik
15:18:21 *** wonderch_ (~wondercho@c-67-180-32-242.hsd1.ca.comcast.net) has joined #mapnik
16:10:43 *** cgs_bob_ has quit (Ping timeout: 260 seconds)
16:15:48 *** haoyu_ (~bhy@cm144.delta24.maxonline.com.sg) has joined #mapnik
16:17:47 *** haoyu has quit (Ping timeout: 258 seconds)
16:22:13 *** haoyu_ has quit (Ping timeout: 264 seconds)
16:28:06 *** ajturner has quit (Ping timeout: 276 seconds)
16:33:17 *** nevizem (~chatzilla@124.248.180.50) has joined #mapnik
16:36:30 *** waldemarq (~waldemarq@201.154.133.194) has joined #mapnik
16:39:15 *** tcarobruce (~tcarobruc@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
17:08:46 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
17:18:06 *** dkb has quit (Remote host closed the connection)
17:19:24 *** artem has quit (Quit: artem)
17:20:00 *** racicot (~chatzilla@dsl-66-228-218-217.dsl.fibercloud.net) has joined #mapnik
17:30:52 *** ajturner has quit (Quit: ajturner)
17:32:52 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
17:39:29 *** wonderch_ has quit (Remote host closed the connection)
17:45:35 *** waldemarq has quit (Ping timeout: 246 seconds)
18:05:49 *** waldemarq (~waldemarq@201.154.133.194) has joined #mapnik
18:08:09 *** cgs_bob_ (~bob@166.sub-75-208-203.myvzw.com) has joined #mapnik
18:08:15 *** cgs_bob_ is now known as cgs_bob
18:17:37 *** serek is now known as ser
18:17:46 *** ser has quit (Quit: leaving)
18:20:55 *** ser (~ser@house.metalab.unc.edu) has joined #mapnik
18:22:52 *** dkb has quit (Remote host closed the connection)
18:23:02 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
18:38:15 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
18:46:20 *** dkb has parted #mapnik (None)
18:53:05 *** nevizem has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819])
19:21:43 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
19:45:33 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik
20:05:12 *** wonderchook (~wondercho@c-98-210-153-80.hsd1.ca.comcast.net) has joined #mapnik
20:22:45 *** wonderch_ (~wondercho@dsl081-240-154.sfo1.dsl.speakeasy.net) has joined #mapnik
20:25:11 *** luneff (~yury@93.178.65.238) has joined #mapnik
20:26:16 *** wonderchook has quit (Ping timeout: 276 seconds)
20:32:42 *** waldemarq has quit (Ping timeout: 258 seconds)
20:32:52 *** artem has quit (Quit: artem)
20:34:59 *** dukeku is now known as lucasd
20:37:29 *** artem (~artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
21:20:07 *** celoyd (~char@74-93-184-218-Oregon.hfc.comcastbusiness.net) has joined #mapnik
21:21:25 *** springmeyer (~springmey@adsl-75-17-113-166.dsl.pltn13.sbcglobal.net) has joined #mapnik
22:01:22 <springmeyer> hey artem
22:01:30 <springmeyer> awesome job on the 0.7.1 release!
22:01:43 <artem> springmeyer: and you!
22:02:01 <springmeyer> :) thx
22:02:17 <artem> have a great time at where2.0 (assuming you're there?)
22:02:31 <springmeyer> yes, just arrived this afternoon
22:02:36 <Ldp__> I forgot: was there an issue with the OSM plugin for the Windows build?
22:02:41 <springmeyer> I'm actually in san fran now
22:02:49 <artem> cool
22:03:04 <springmeyer> as I'm meeting with migurski this afternoon, but will head down to san jose tomorrow (where the conference is)
22:03:23 <springmeyer> artem: i like your svg ideas :)
22:04:38 <artem> sounds like a good plan :), are you presenting ? /me likes his ideas too
22:05:10 <springmeyer> Ldp__: osm plugin requires libcurl, so I've yet to get around to adding that extra dep in osx at least
22:05:16 <springmeyer> not sure about windows
22:05:26 *** wonderch_ has quit (Remote host closed the connection)
22:05:37 <Ldp__> springmeyer: it's missing from the zip. Someone mentioned it a few days ago
22:05:38 <springmeyer> artem: nope, just enjoying
22:06:00 <springmeyer> Ldp__: I don't think the osm plugin has ever been available for the windows build...
22:06:22 <springmeyer> nope: http://trac.mapnik.org/wiki/WindowsInstallation#SupportedFeatures
22:06:45 <artem> osm.input compiles on os x no probs
22:07:29 <springmeyer> yes, I had a problem compiling libcurl 32+64 bit so I missed including in binaries - thats all
22:07:42 <artem> ok
22:08:02 <springmeyer> artem: have you considered providing it in the windows binaries?
22:08:44 * artem adds win32 osm.input to TODO list
22:09:29 <artem> if it all possible to build libcurl on win32 then should be no probs
22:09:39 <Ldp__> yet I'm not sure many people would use it. I think most expect they can throw osm.xml at it. :/
22:10:20 <Ldp__> which is impossible without hefty rewrites
22:10:37 <artem> yes, true
22:11:31 *** wonderchook (~wondercho@dsl081-240-154.sfo1.dsl.speakeasy.net) has joined #mapnik
22:11:36 <springmeyer> Ldp__: "hefty rewrites" ? osm plugin just reads the data
22:12:01 <Ldp__> osm.xml rewrites
22:12:20 <springmeyer> in what way?
22:12:25 <Ldp__> the main obstacle being the preprocessing I do in SQL
22:12:32 <Ldp__> which I wouldn't want to miss, really
22:13:07 <sam`> hi. is there a significant rendering time improvement between 0.6.1 and 0.7.1? if yes, do you have a few numbers?
22:13:30 <springmeyer> Ldp__: ah sorry, I'm tired I get it
22:13:45 <springmeyer> right, ya the layer sql would not work, surely
22:14:16 <Ldp__> springmeyer: the SQL brings me stuff I just cannot do in mapnik yet, or would be painful to do
22:15:05 <Ldp__> springmeyer: but you know that. More stuff to do for 0.9 :)
22:15:13 <springmeyer> Ldp__: surely. would require scripting to break osm file into many pieces likely to get near functionality of sql statements
22:15:18 <springmeyer> Ldp__:  :)
22:15:47 <springmeyer> sam`: I don't know of any reasons rendering time would improve between 0.6 and 0.7 series
22:18:02 <sam`> ok, thanks
22:18:43 <springmeyer> sam`: are you looking for speed increases or doing any profilings?
22:18:56 *** celoyd has parted #mapnik ("Mint!")
22:21:59 <sam`> springmeyer: speed increases yes, the faster it renders the better for us
22:22:15 <springmeyer> sam`: sounds good
22:22:25 <sam`> although we don't have enough traffic yet for it to really matter
22:22:29 <springmeyer> sam`: MapOSMatic uses Cairo for PNG output right?
22:22:44 <springmeyer> have you tried using AGG backend?
22:22:49 <sam`> yes, cairo
22:23:06 <sam`> what is it?
22:23:19 <springmeyer> `MapnikRenderers
22:23:19 <nikq> http://trac.mapnik.org/wiki/MapnikRenderers
22:23:45 <springmeyer> it is the default used when you do
22:23:55 <springmeyer> im = mapnik.Image(w,h)
22:24:06 <springmeyer> mapnik.render(m,im)
22:24:19 <springmeyer> rather than rendering to a cairo surface/context
22:24:28 <sam`> we're also rendering SVG maps, so we went with cairo since it supports all the formats we need
22:24:41 <springmeyer> right, which makes sense
22:24:51 <springmeyer> but for PNG AGG may be faster
22:25:05 <sam`> if we use both, does it mean it has to render twice ?
22:25:15 <springmeyer> and new PNG quantization in Mapnik 0.7.1 is nice
22:25:45 <springmeyer> sam`: good question. ideally no
22:27:46 <sam`> apparently not, it wouldn't
22:29:09 <springmeyer> hmm...
22:29:14 <springmeyer> looks like you could...
22:29:20 <sam`> (that actually depended on our code)
22:29:30 <springmeyer> render a mapnik.Map to a mapnik.Image
22:29:42 <springmeyer> draw all our grids, titles, etc in cairo
22:29:49 <sam`> but it would only accelerate the PNG rendering. it's a good start, but with PDF and SVG on the side, getting half time on the PNG output only saves 15% of the total rendering time
22:29:56 <springmeyer> then turn that into a mapnik.Image
22:30:00 <springmeyer> and blend the two
22:30:04 <springmeyer> fyi: http://trac.mapnik.org/browser/trunk/src/graphics.cpp#L48
22:30:30 <springmeyer> sam`: yes, I agree, it is the PDF/SVG formats that likely take longest
22:32:11 <springmeyer> sam`:  the symbol caching in mapnik trunk that artem added may offer a speed boost for maps heavy with shields
22:32:14 <springmeyer> but I've yet to test that
22:38:03 <dkb> springmeyer: you mentioned in the past that you skip osmosis and simply import entire planet with osm2pgsql.. could you tell me how much memory you have on your server and approximate time it takes to do the import?
22:38:51 <springmeyer> I think it took 2-3 days last time I ran it with 4GB ram
22:41:06 <dkb> I started mine on Sat Mar 27 19:22:25 CDT 2010, with 8GB RAM, quad core 2.4GHz system and its still going.. I'm having lot of difficulty finding information on what I should be expecting besides the pages that tell you how to tune PostgreSQL which I've done
22:42:44 <dkb> last line I have is "Completed planet_osm_line" and its really hitting the disk
22:43:17 *** Ldp__ has quit ()
22:44:31 <sam`> dkb: it takes a long, long, long time.
22:45:11 <sam`> it's also an extremely io-bound process, which can be impacted by your HD hardware, your filesystem, your scheduler(s), etc
22:46:36 <dkb> I was thinking of adding some "benchmark" page off of the osm2pgsql wiki page on osm.org where people add there stats on hardware/settings and how long it took.
22:47:49 <springmeyer> dkb: sounds great
22:48:54 <springmeyer> dkb: note, you can apply a bounding box restriction using osm2pgsql to limit the area to import
22:49:31 <dkb> It sounds like since I did not modify the default.style and I want to have hill shading displaying with mapnik rendering I'll have to reimport the entire thing again?
22:51:27 <springmeyer> huh?
22:52:16 <springmeyer> hillshading is usually done separately and I can't think of any relation it has to the default.style
22:53:40 <dkb> Was going by http://wiki.openstreetmap.org/wiki/HikingBikingMaps, where it says "way       network      text     linear", and "way       surface      text     linear" need to be added to default.style before the import
22:54:21 *** waldemarq (~waldemarq@187.133.54.21) has joined #mapnik
22:54:29 <rweait> dkb: I think TopOSM does hillshading as another tile layer. http://wiki.openstreetmap.org/wiki/TopOSM#Hillshading_and_contour_lines
22:54:40 <rweait> so separate data, separate style.
22:55:13 <rweait> But you may want to modify your style to eliminate the background color.
22:57:06 <dkb> Ok, thanks.  I will experiment more first before asking any further. :)
22:58:27 <springmeyer> dkb: cmarqu may know how critical those tags are
23:00:18 *** Genscher has quit (Quit: Leaving)
23:04:17 <dkb> rweait: thanks for the link on TopOSM, I hadn't seen that before and looks informative
23:04:32 <rweait> It's a beautiful project.
23:04:53 <rweait> I think he makes all of his style and code stuff available
23:05:11 <sam`> looks great
23:05:20 <rweait> I'm planning to copy it shamelessly.
23:05:25 <dkb> won't he have to switch to the SRTM data for other states?
23:05:46 <dkb> looked like he was using MassGIS for contours/hillshading
23:06:01 <rweait> Good question for Lars.  ;-)
23:10:15 <dkb> the MassGIS data is 3m interval, the better SRTM data or the US is only 30m..
23:10:26 <dkb> or/for
23:12:13 *** wonderchook has quit (Read error: Operation timed out)
23:12:49 *** artem has quit (Quit: artem)
23:19:02 *** wonderchook (~wondercho@c-98-210-153-80.hsd1.ca.comcast.net) has joined #mapnik
23:25:48 <springmeyer> later all
23:26:07 *** springmeyer has quit (Quit: springmeyer)
23:40:35 *** springmeyer (~springmey@adsl-76-200-190-65.dsl.pltn13.sbcglobal.net) has joined #mapnik