[OSM-dev] Rantings about API 0.6

Brett Henderson brett at bretth.com
Wed Feb 11 10:11:41 GMT 2009


80n wrote:
> On Wed, Feb 11, 2009 at 9:09 AM, Shaun McDonald 
> <shaun at shaunmcdonald.me.uk <mailto:shaun at 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 at H, Mapnik, etc) can handle it then bring it on :-)

Brett





More information about the dev mailing list