Attendees
| IRC nick
|
Real name
|
| apmon_ |
Kai Krueger
|
| zere |
Matt Amos
|
Summary
- apmon_ reported on the progress of loading a shared / development copy of the rendering database on the dev server.
IRC Log
18:02:11 <zere> minutes of the last meeting: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-01-14 let me know if there's anything that needs changing
18:02:57 <zere> we were talking last time about the (lack of) effectiveness of EWG, and what we could do to improve it for this year
18:03:29 <zere> we're already halfway through Jan, so we'd better get cracking.
18:03:55 <zere> apmon_ raised a good point last meeting - what examples are there of when EWG was effective?
18:05:21 <apmon_> I will likely be out for most of this meeting.
18:05:55 <apmon_> Wanted to mention though that I have now imported an osm2pgsql db on errol and it is currently catching up
18:08:05 <apmon_> We'll have to see if it can handle the load or if it negatively effects other projects
18:10:03 <zere> apmon_: nice - how far behind is it, at the moment?
18:10:34 <apmon_> probably a bit over a week
18:10:57 <apmon_> I imported the 010913 planet and have updated a bit over 24 hours so far
18:11:23 <apmon_> The last 24 hours update only took 5 hours though, so it might catch up reasonably quickly
18:13:00 <zere> nice... 5x real rate is pretty good. what options did you end up using? (e.g: parallel workers, nodes file, etc...)
18:14:07 <apmon_> --slim --append -C 1000 -j -x -S $STYLE -P 5433 -d osm2pgsql --number-processes 6 --flat-nodes ~/flatnodes.cache --tablespace-index home --tablespace-main-data home --tablespace-slim-data home are the options for the diff import
18:15:16 <apmon_> Still need to add extra indexes for the hstore to be flexible for other purposes
18:18:09 <zere> cool. worth having those parameters sitting around in case anyone is interested - i assume they'd be a good place to start for anyone wanting to have the fastest set of options
18:19:48 <apmon_> I suspect most won't want to use -x option, but for a more general purpose osm database having changeset and mapper details in the db seemed appropriate