User Tools

Site Tools


Navigation Menu

Flight-Control

<
Previous mounth
12/13/2024
>
Next mounth
SMTWFTS
50
08
08
09
09
10
10
11
11
12
12
13
13
14
5115161718192021
5222232425262728
0129303101020304
0205060708091011









Hot Projects

SEEDStack

SEEDStack - Open 3D printable seed/sprouting systemDIY Food Hacking

UCSSPM

UCSSPM - Unified Clear-Sky Solar Prediction ModelOpen Solar Power

picoReflow

picoReflow - DIY PID Reflow Oven Controller based on RaspberryPiDIY Reflow Soldering

PiGI

PiGI - DIY Geiger Counter based on RaspberryPiRasPi Geiger Counter

DIY ARA-2000

Active Wideband Receiver Antenna for SDR - ARA-2000Wideband Antenna

DSpace

DSPace - Map everythingMap everything!

Mission-Tags

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 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.

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.