neue Kartenebene

Hallo zusammen!!!

OpenStreetMap kann bisher 5 verschiedene Kartenebenen anzeigen:

• Standard
• Radfahrerkarte
• Verkehrskarte
• MapQuest Open
• Humanitarian

Ich würde gerne mithelfen eine weitere Kartenebene zu erstellen.

Diese soll einen weltweiten detaillierten Überblick über Bodenschätze und Trinkwasservorräte geben.
Beispiel: http://agiw.fak1.tu-berlin.de/Auditorium/AntWiSys/WiKarte.GIF

Neben der Aufzählung und Visualisierung soll auch der momentane Verbrauch und der Zeitpunkt, wann diese Ressource aufgebraucht ist, angegeben werden.

Darüber soll die neue Kartenebene darstellen, wohin (Deutschland, China…), auf welchem Weg (Trajektorie) und mit welchem Mittel (Flugzeug oder Schiff) diese Ressourcen transportiert werden.
Beispiel: http://homepage.univie.ac.at/christian.sitte/PAkrems/karten/welthandel.jpg

Hat jemand hier vielleicht Lust dieses Projekt mit mir anzupacken?
Bin über jede Hilfe dankbar.

Viele Grüße
Zeitgeist14

Hallo Zeitgeist14,

herzlich willkommen im Forum.

Ich glaube, du hast die Intention hinter den Layern auf osm.org falsch verstanden. Die Layer sind ein Beispiel, was man mit OSM machen kann. Die Layer enthalten von Höhendaten für Schummerung/Höhenlinien [1] abgesehen nur OSM-Daten. OSM versteht sich als Projekt zur Datenerfassung und nicht als Kartendienst.

Die Daten, die du erfassen möchtest, sind in meinen Augen in OSM fehl am Platz. Es gibt den Grundsatz “We map what’s on the ground.” und den sehe ich bei der Klassifizierung Industrie-/Schwellen-/Entwicklungsland nicht gegeben. Um auf dein erstes Beispiel zurückzukommen, OSM ist nicht der richtige Platz für historische Daten. Objekte aus der Antike werden nur gemappt, wenn davon heute Reste vorhanden sind (meist als Ausgrabung o.ä.). Wir erfassen jedoch keine Wüstungen, solange da nicht eine Infotafel steht “Hier war Ransbach”. Solche eine Tafel würde dann als Tafel und nicht als Wüstung erfasst werden.

Oder verstehe ich dich falsch und du möchtest nur eine Spezialkarte aus OSM-Daten erzeugen, die alle Steinbrüche, Ölförderstellen, Weinberge usw. erfasst?

Neben dem inhaltlichen Problemen kommt noch ein weiteres Problem auf dich zu – Geld und Leistung. Layer, die auf osm.org angeboten werden, müssen eine weltweite Abdeckung haben. (Irgendwo gibt es bestimmt eine Richtlinie, wann neue Layer aufgenommen werden) Die weltweite Abdeckung erfordert, dass du einen starken Server als Tileserver betreibst. Willst du das? Kannst du das (Geld und Können)? Hälst du dem Traffic Stand?

Viele Grüße

Michael

[1] Ich bin mir nicht sicher, ob für niedrige Zoomstufen teilweise andere, vereinfachte Datensätze verwendet werden.

Dein Posting hört sich für mich so an, als wärst du eher auf der Suche nach Tools, mit denen man eigene Datenlayer visualisieren kann und im Hintergrund eine OpenStreetMap-Karte hat:

http://umap.openstreetmap.fr/de/
http://leafletjs.com/
http://openlayers.org/

http://www.netzwolf.info/kartografie/openlayers/

Nahmd,

Nein, willst Du nicht.

Du willst eine Themenkarte erstellen, indem Du über eine “normale” Karte ein paar Symbole und ein paar Linien pinselst. Ähnlich wie die Karte der Wanderwege, im Umfang aber weitaus darunter.

Dein Hauptarbeit besteht darin, die Daten in brauchbarer Form irgendwo zu erfassen und zu sammeln. Diese dann über die Karte drüber zu pinseln (nicht auf der Hauptseite, sondern auf Deiner eigenen Seite) und so aus den Daten eine Themenkarte zu erzeugen, ist im Vergleich dazu nur noch minimale Arbeit.

Hier gibts Unterstützung bei der Erstellung der Karte — sobald Du die Daten beisammen hast. Dass Du hier Helfer fürs Sammeln der Daten findest, hält meine Kristallkugel dagegen für eher unwahrscheinlich.

Gruß Wolf

Ist das der Zielmaßstab (ca. 1:20’000’000)?

Wo kriegt man denn die Daten dazu her? Vorallem, weil der Zeitpunkt, zu dem die Ressource aufgebraucht ist, ja kein Faktum sondern eine Projektion (und damit eine Interpretation) ist?

Ebenfalls: wo kriegt man die Daten her?

Zu den anderen Aspekten (also das die Daten nicht nach OSM passen) haben die anderen ja schon was gesagt.

Vermutlich bist du mit deinem Ansinnen bei Attac oder einer anderen NGO besser aufgehoben; die werden Ideen haben wie man an die Daten rankommt, und wie man solche thematischen Karten erstellt.

kann mir jemand in “We map what’s on the ground.” die stelle zeigen, wo steht das osm nicht der richtige platz für historische daten ist?

grüße von lutz

Das englische “what’s” ist eine Kurzform von “what is”. “is” ist die dritte Person Singular Präsens von “to be” (“sein”). “Präsens” ist hier das entscheidende - wir mappen, was da ist und nicht, was vielleicht mal da gewesen ist.

Gemeinhin wird akzeptiert, wenn historische Informationen zu bestehenden Dingen eingegeben werden (also: diese Kirche hier hiess früher mal anders, oder dieses Haus hatte früher mal eine andere Hausnummer). Idealerweise versuchen wir aber, nur vor Ort überprüfbare Dinge einzugeben, und was früher einmal war, ist meistens eben nicht mehr vor Ort überprüfbar.

Bye
Frederik

mmmm, ich lese da bloß was von überprüfbarkeit, kann es sein, das da jeder sich das so nimmt, wie er gern möchte?

grüße von lutz

Wie bei so vielem on OSM, nimmt das jeder so scharf wie er mag. Abgesehen davon, daß Überprüfbarkeit natürlich immer wünschenswert ist, muss aber die Frage erlaubt sein - von wem. Wenn nur der Anschein vor Ort und somit potentiell jeder Mapper vor Ort in der Lage sein soll, zu überprüfen, dann fällt ganz schnell alles raus, was nicht unmittelbar sichtbar ist: Also auch alle boundaries zum Beispiel. Niemand will das wirklich.

Es ist immer so, daß Spezialinformationen nur mit erhöhtem Aufwand zusammengetragen werden können und in gleichem Maße auch überprüfbar sein können. Das Recherchieren historischer Fakten zu einer Ruine, von der nur noch ein paar Steine stehen, kann sehr aufwendig sein und mit einer Menge Internet- und Archivrecherche verbunden sein. Man will deshalb aber nicht darauf verzichten. Man will eben nicht nur die Information: “Hier liegen ein paar alte Steine” sondern “dies sind die Überreste von blabla, erbaut anno Tobak von blabla”. Man sollte akzeptieren, daß die Überprüfung mit Aufwand verbunden sein kann. Außerdem basiert OSM in erster Linie auf Vertrauen - wie übrigens auch Wikipedia. Es muss und wird nicht alles überprüft werden.

Detaillierte source-tags helfen in jedem Fall bei der Überprüfbarkeit.

Das schöne an dieser Art der Recherche ist, daß Objekte wieder ins Bewusstsein gerufen werden, die für klassische Geschichtsbücher viel zu nebensächlich und unwichtig sind, um überhaupt erwähnt zu werden. Die klassische Geschichtsschreibung orientiert sich primär an (mehr oder weniger bedeutenden) Ereignissen, wir hingegen an Orten.

Gruß,
Zecke

Edit: Typo

Einmal eine unbedarfte Frage von einem “Nur Nutzer”:

Ist die Größe der Datenbank an etwas gebunden, um eventuell einmal an die Grenze der Datenerfassung zu kommen?
Sind nicht zur Zeit auch gelöschte Daten noch enthalten?
Warum nicht bekanntes (zumindest) in den Daten erhalten?

Bilder gibt es viele, aber die Lage vor Ort ist m.E. historisch wertvoll. Ich fände es schon wichtig frühere (abgerissene) Gebäude in den Daten zu finden ( früheres Ferienlager und Gasthof).

Hier sind die Gebäude (etwas nördlich) nicht eingetragen - obwohl sie bis 2009 als historische Mühle (Ruine seit der Flut 2002) vorhanden waren. Nach der “Einebnung” lässt sich nun nicht mehr die genau Lage feststellen.

Nahmd,

In der Hauptdatenbank werden Objekte nicht gelöscht, sondern es wird eine neue Version angelegt und diese als unsichtbar markiert. Die DB enthält also alle Versionen aller Objekte, auch der bereits gelöschten Objekte.

Wenn die Datenbank gut organisiert ist — und davon gehe ich aus — spielen die nicht aktuellen Versionen der sichtbaren Objekte und die gelöschten, also unsichtbaren Objekte keine Rolle für die Performance.

Der Gesamtinhalt der Datenbank wird in unregelmäßigen Abständen als History-File bereitgestellt. Diese Datei wächst mit jeder Version jedees Objektes, ja sie wächst auch beim Löschen eines Objektes, weil dazu eine neue Version angelegt (und als unsichtbar markiert) wird.

Die aktuellen Versionen der sichtbaren Objekte werden regelmäßig in den Planet-Dateien bereitgestellt, sowie die stündlichen, täglichen usw. Änderungen als Diff-Dateien. Die Größe dieser Dateien hängt ab von der Menge der sichtbaren Objekte.

Und hier liegt der Knackpunkt: die Planets, die Diffs, oder regionale Auszüge der Planets sind die Grundlagen für die verschiedenen Anwendungen der OSM-Daten. Je mehr Daten, umso mehr Aufwand bei der Verarbeitung. Umso mehr wird in das gleiche Fenster bei JOSM&Co geladen.

Ob eine Mühle beim Abriss gelöscht wird oder durch Umtaggen als historisch markiert wird, ist für die zentrale Datenbank von nur geringer, für den Historydump von äußerst marginaler Bedeutung. Aber von großer Bedeutung für Planet, Diffs & Co: denn beim Löschen verschwindet das Objekt, umgetaggte Objekte bleiben dagegen erhalten. Wenn ich diese Daten verarbeite, muss ich dazu jeden Eintrag einmal anschauen, auch den umgetaggten, und sei es nur, um ihn gleich zu verwerfen. Je mehr Daten, umso länger die Verarbeitung.

Damit sind alle Daten, die ich nicht brauche, nicht nur überflüssig, sondern störend. Denn sie verlängern meine Bearbeitungsdauer. Ich denke, das ist der eigentliche Grund für die Relevanzdiskussionen.

Eine Lösung könnte sein, die Daten anders zu strukturieren, z.B. in eine Art von Layern: Flächenwidmung, Flächennutzung, Wasserläufe, Straßen, Eisenbahn, Gebäude, was weiß ich, so dass ich nur die Layers herunterlade, die ich für mein Projekt brauche. Dito beim Bearbeiten mit JOSM&Co. Die Anzahl und Größe der übrigen Layer wird dadurch unbedeutend. Das ist aber (wie so vieles) deutlich leichter gesagt als getan.

Ich hoffe, ich habe nicht noch mehr verwirrt.

Gruß Wolf

Und dann ist es ja auch immer noch eine Frage der Pflege. Schon physisch vorhandene Objekte sind schwer zu pflegen, wenn es dann aber in den abstrakten Welten von irgendwelchen imaginären, temporalen oder sonstigen Dingen geht, wird es schwierig.

Nahmd,

mir erschließt sich der Wartungs- und Pflegebedarf eines Eintrages “hier stand von XXXX bis YYYY eine Mühle mit dem Namen ZZZZ” nicht.

Gruß Wolf

Dann betrachte mal die Frage im Ursprungsposting. Da geht es um Handelsrouten, Handelszahlen, Rohstoffreserver und -ressourcen… - da ist *riesiger *Pflegebedarf!

Eine Segmentierung der OSM-Daten, wie Netzwolf sie vorschlägt, halte ich für eine sehr gute Idee, die vermutlich mit erheblichem Aufwand - auch seitens der API-Entwicklung verbunden ist. Es würde aber die Datenvisualisierung und Zugriffe von Applikationen erleichtern, da das Pre-Processing vereinfacht werden könnte. Selten braucht eine Anwendung wirklich alle Daten (Ausnahme ist natürlich der Renderer).

Der Post ist ja sehr allgemein gehalten. Ist auch die Frage, ob und wie viel wirklich nach seiner Idee in die OSM-DB fließen soll. Es wird ja hauptsächlich von der Visualisierung gesprochen. Ich vermute, dass der Threadersteller den verbundenen Aufwand als Laie nicht einschätzen kann.

Du hast mindestens einen Aufwand dafür, solche Objekte aus allen Karten und Auswertungen für bestehende Objekte herauszuhalten. Eine versehentliche Vermischung von aktuellen und historischen Daten wäre auf jeden Fall schädlich, ebenso ein Pseudo-Tagging mit dem obigen Text im name-Tag.

bye, Nop

das ist eine frage des taggings, sowas läßt sich vermeiden.
zum glück gibt es da ein paar leute, die sich darüber gedanken machen,
als es von vorn herein abzulehnen, nur weil es ihre kreise stört…

grüße von lutz

Nahmd,

Ich gehe davon aus, dass es nicht um eine Bereicherung von OSM ging, sondern um die Darstellung einer Weltanschauung auf einer gut besuchten Seite. Einfachste Implementierung wäre die Einbindung eines Greenpeace&Co-Newstickers auf der Startseite.

Gruß Wolf

Nahmd,

Das ist Filteraufwand, aber kein Pflegeaufwand. Historische Objekte ändern sich nicht mehr, eben weil sie historisch sind; ergo braucht das Tagging nicht mehr aktualisiert zu werden, ergo kein pflegeaufwand.

Korrektes Tagging ist bei allen Objekten wichtig, nicht nur bei historischen.

Ausführliches Tagging: “historic:building=mill;start_date=XXXX;end_date=YYYY;name=ZZZZ”.

Über Details kann man sich trefflich streiten. Aber schon das “end_date=” sollte es nicht durch einen Non-History-Filter schaffen.

Gruß Wolf

Hallo,

ich möchte mich für Eure Antworten bedanken.
Dank Euch, habe ich nun einen ungefähren Plan wie ich weitermachen werde.

Viele Grüße
Zeitgeist