title: Estimating size required for memory mapped boost rtree
body: <p>We have a scenario where we dynamically grow a memory mapped file used for boost's r-tree geometric index. We also make use of boost's interprocess memory mapped file api's.</p>
  
  <p>Mechanics are already sorted out in terms of unmapping the file, growing, and remapping - this all works.</p>
  
  <p>Thus far we've tried overestimating the size with a factor 10 of the inherent size of our coordinates, which works but is grossly over-estimated when inspecting with <code>du</code>. </p>
  
  <p>Is there some way to predict (worst-case or precise) what size we should require the mapped file to grow given the number of objects? Underestimating, for example with a factor 5, causes stack smashing eventually...</p>
  
  <p>Thanks</p>