Why not put all this information directly into OpenStreetMap and render new image tiles?

When you include the factor of social interaction on this large a scale, the number of PoI's & polygons will increase dramatically. OpenStreetMap would be overwhelmed with PoI's and areas, managing and sorting it out and in the end they would realize: 90% is not even closely related to streetmaps. OSM contributors aren't getting anything in return for hours of their personal live spent on considerable work, except an always increasing level of quality of the open streetmap. Let every group, being it OSM as a basemap data-provider, or for example Mundraub as an Overlay-Data provider, collect and organize only the data relevant to the group's particular interest to ensure they continue to have fun with it.

Simply combine all these different groups of social/scientific/economical/agricultural/[…] interests into one presentation layer, where we can pick any shared information collection (DSpace-Overlays), we're interested in and also provide new input to these information collections as well. In Realtime. And when something is missing, simply create a new Overlay.

In order to be able to switch between different Overlays, a complete new set of images would have to be rendered, only including the Area of Interest (AoI) and the specific list of PoI's for that area. With a look at the benchmark data of the tilemill rendertime of the munich-map we currently use, it seems that real-time rendering with that degree of Overlay-Flexibility would require an enormous amount of server power, which is in total contradiction to a federated, peer2peer and resilient system. Putting a high portion of the computing resources necessary to make the whole system work into the client will help to keep infrastructure build-up and maintenance low. By working with pre-rendered, topic-tailored basemaps and using javascript to create new layers above the basemap, called DSpace-Overlays most of the heavywork will be done by the client.