Consider Writer to take a FileBuffer

[cmahnke]

For symmetry reason (Reader also does it) I would like to propose that a Writer might also take FileBuffer to operate directly in memory. This can certainly crash the application for huge data sets, but might speed up operations on small to medium data sets, especially when there are multiple passes needed.

[cmahnke]

The same applies to osmium.MergeInputReader(), the add_file() method doesn't take a FileBuffer. To make matters worse the FileBuffer is missing a method to get the underlying buffer...

[lonvia]

This is somewhere on my TODO list. Unfortunately it is not quite as trivial to implement as a buffer for the reader. The Reader buffer has a static size and is read-only, so you can just hand it to libosmium. The Writer buffer on the other hand ideally has to grow with the data. That makes implementing the interface between Python and libosmium interesting.

Regarding saving data for multiple passes, I was thinking to expose libosmium's buffers for temporary storage. Not only would it be super-fast to reread, it would also be possible to create indexes over them for direct access. But that would be a different issue.