80n wrote: > On Wed, Feb 11, 2009 at 9:09 AM, Shaun McDonald > <sh...@shaunmcdonald.me.uk <mailto:sh...@shaunmcdonald.me.uk>> wrote: > >> > I fail to see why slower growth is a good thing? >> > >> Slower (perhaps "steady" is a better word) growth has its >> advantages for >> replication. Osmosis data extraction is fairly efficient and can >> extract data many times faster than it is currently added, but >> downstream systems can't always process it fast enough. So >> while it >> would be great to be able to import data faster, there >> probably should >> be an upper limit to import speed allow downstream systems to >> keep up. >> >> >> This is not a valid reason. >> >> Speaking as one of the downstream consumers of the Osmosis diffs >> we can take it as fast as you can make it. >> > > Thinking about it for a bit longer, wouldn't you like to be able > to predict when you need to increase the storage capacity, or > change an algorithm to be able to cope with the increased data. Or > what about being able to predict when we need to upscale the main > database server or run another donation drive for more servers? > > > In an ideal world I'd like to see as much data loaded as quickly as > possible. It's not the job of the data providers to shape their > supply to match the prediction of the data consumers. That would be > putting the cart before the horse. The current volumes are ~15MB of compressed data per day. From memory during the TIGER import we were seeing volumes of around 100MB per day. If the import speed is improved further this could conceivably increase well above this level as well. If everybody (ie. XAPI, ROMA, TRAPI, t...@h, Mapnik, etc) can handle it then bring it on :-)
Brett _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
