User Tools

Site Tools

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
lab:dspace:faq [2013/01/22 20:54] – chronolab:dspace:faq [2013/06/05 14:34] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== DSpace-FAQ ======
 +
 +===== Why? =====
 +
 +**Why not put all this information directly into OpenStreetMap and render new image tiles?**
 +
 +==== Structural Integrity ====
 +
 +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 [[http://www.openstreetmap.org/|OSM]] as a //basemap// data-provider, or for example [[http://www.mundraub.org/|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//.
 +
 +==== Efficiency ====
 +
 +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. 
 +
 +
  
Trace:

Page Tools