DE:OSM-4D
.svg){kind=icon}
For first results see Simple 3D Buildings.
Das ist ein Entwurf für ein Projekt um:
- gemeinsam 3D Modelle von Objekten der Welt zu erstellen und mit Openstreetmap-Daten zu verlinken.
- ein schlüssiges Taggingkonzept für komplexe 3D Strukturen zu schaffen, welche jedoch in der 2D Karte ohne speziellen 3D Viewer eingetragen werden können.
Grundidee
Gemeinsames Erstellen der 3D Modelle vom Gelände, Gebäuden und anderen Strukturen in Verbindung mit Openstreetmap Daten. Die Arbeit geschieht in der OSM Hauptdatenbank und dort werden ebenfalls die Objekte abgelegt. Die Mehrheit der Objekte wird als sog. 2,5 D beschrieben. Neben dieser Art der Beschreibung werden auch sog. parametrische Objekte (sich oft wiederholdende Standard-Objekte) eingegeben und verändert werden können (z.B. Bäume: Baumart, Grundform, Höhe, Kronendurchmesser, Alter, etc.). Diese Objekte werden eine Bibliothek bilden, die mit der Zeit immer umfangreicher wird.
Ausser einzelnen 3D-Objekten wird auch ein 3D Geländemodell angestrebt, sowie eine kollektive Material- und Texturdatenbank verwendet, deren Inhalt in das Modell verlinkt werden kann.
Es ist davon auszugehen, dass OSM nicht nur in die "Breite", sprich, Datenabdeckung , sondern auch in die "Tiefe", d.h. Detailreichtum wachsen wird. Diesem Gedanken trägt die folgende Beschreibung die Rechnung.
Schon jetzt ist die existierende Grundstruktur der OSM Datenbank nicht auf alle Aspekte der 3D Modellierung vorbereitet, so dass in Zukunft wünschenswert wäre in der nächsten API die Datenbankstruktur der OSM den Bedürfnissen der 3D Modellierung anzupassen.
Grob gesagt "versteht" OSM momentan attributtierte Elemente: Punkt, Polylinie (bzw. geschlossene Polylinie) und Relation. Allen diesen Elementen werden in OSM-4D neue Eigenschaften zugewiesen. Der bisherige Ansatz [OSM-3D] sieht für die 3D Modellierung lediglich Höhen einzelner Elemente als Attributte. Der OSM-4D Ansatz ist an dieser Stelle wesentlich komplexer, sieht sich aber nicht als Konkurrenzkonzept sondern als eine Ergänzung.
Bedenken
- Warum überhaupt 3D Daten?
Die Welt in der wir leben, ist dreidimensional. Zum einen können viele Probleme der OSM nur in einem 3D Modell zufriedenstellend gelöst werden (etwa die Darstellung verschiedener Fahrspuren die übereinander liegen) zum anderen werden 3D Modelle nur im Auge von Laien zum Spaß und Spiel erzeugt: Verschiedene wissenschaftliche Simulationen kommen ohne 3D Modelle der Erdoberfläche (inklusive Gebäude) nicht aus.
- Viele erfahrene OSM User wehren sich gegen eine Erweiterung des Grundkonzeptes der OSM mit dem Einwand, dass jegliche Verkomplizierung des Datenmodells einerseits keine Akzeptanz der aktiven User findet und andererseits zur Entstehung einer Potenzzahl an Fehler führen kann:
Dem Einwand muß man entgegnen, mit dem Hinweis, dass OSM von seiner Geburt an mit der Zeit immer mehr aktive User trotz immer höheren Komplexität hat, woraus man schliessen kann, dass gerade das Anspruchsvolle in Verbindung mit sehr einfach gehaltenen Anforderungen an "Newbies" zu dem Erfolg des Projektes führen.
Nur "sehr einfach" wäre langweilig, nur "sehr kompliziert" ist abschreckend. Daher schlägt das "4D" Konzept, basierend auf aufsteigend komplexen Parametern eine Möglichkeit, die Umwelt dreidimensional abzubilden, indem man mit sehr einfacher, nachvollziehbaren Parametrisierung mit der 3D Erfassung beginnt.
- Es gibt Vorschläge, 3D in ein anders Projekt auszugliedern und OSM in der klassischer Form zu behalten:
Dagegen spricht die komplizierte Rückkopplung der Verbesserungen die in dem 3D Modell gemacht werden in die 2D Datenbank: In einem räumlichen Modell sind viele Ungenauigkeiten der 2D Daten viel schneller sichtbar und präziser korrigierbar, etwa bei dem Verlauf von Treppen und Rampen. Verlässt man mit dem 3D Projekt die "klassische" OSM wird die Reintegration dieser Änderungen in die "alte" OSM mühsam.
Erfassungstechnik
Die terrestrische Technik der schnellen Erfassung der 3D Modelle wird auf der Wiki Seite [1] beschrieben. Präzisere 3D Modelle lassen sich per handelsübliches Lasermessgerät in Kombination mit Frontalaufnahmen (sog. einfache Architekturphotogrammetrie) und Luftbildauswertung bauen. Für die wenigen Objekte, bei denen die Dachform vom Boden aus unsichtbar ist, kann man für die Dachflächen Flachdach annehmen.
Am einfachsten ist die Fassadenhöhe zu erfassen, wenn man direkt vor der Fassade die Höhe vom NIEDRIGSTEN möglichen Punkt im Gelände entlang der Fassade bis zur Regenrinne messen kann. Der Grund dieser Herangehensweise ist die zukunftige Texturierung der Modelle. Eine Fassadentextur muß rechteckig sein und verschwindet gewöhnlich teilweise in dem Gelände.
Fassadenhöhe: building:cullis:height=*
Die Gesamthöhe einer Fassade kann aus der Frontal bzw. Schrägaufnahme der Giebelseite gewonnen werden.
Warum 4D?
Die "vierte" Dimension bezieht sich auf den zeitlichen Aspekt.
- Wenn ein Bauwerk oder Gebäudeteil modelliert wird, kann man zusätzlich angeben, von wann bis wann welche Darstellung Gültigkeit haben soll. So wird in der Datenbank Bestehendes im Falle von (realen) Umbauten und Erweiterungen des Objekts nicht einfach weggeworfen, sondern als "gültig von bis" gekennzeichnet. Dies erlaubt die Integration von bereits bestehenden historischen Rekonstruktionen, wie sie beispielsweise Archäologen erstellen. (Siehe Abschnitt: Zeit)
- Die Natur erlebt Lebenszyklen, die in der Visualisierung dargestellt werden können
- Ein zukünftiger Echtzeitviewer soll die Sonne und Beschattung darstellen
- Die Darstellung temporärer Wetterverhältnisse soll möglich sein
- Der zeitabhängige Lärm und Smogpegel soll dargestellt weden können
- Die Öffnungszeiten sollen in dem 3D Modell ersichtlich sein
- Die Straßenbeleuchtung mit bekannten ein-Ausschaltzyklen soll in dem 3D Modell dargestellt werden
- Temporär gesperrte Straßen (z.B. Wochenmarkt) sollen dargestellt werden.
Konzepte
Hybride Datenstruktur
- Einfache und wiederholbare Strukturen werden als parametrisierbare Bibilothekselemente erfasst
- Komplexe 3D Modelle (Kölner Dom) werden aus einzelnen Elementen ("Wand", "Decke", "Dach" usw.) modelliert.
Kompatibilität und Komplementarität der Ansätze
Ein einfaches Konzept für die 3D Darstellung der Realität gibt es nicht. Viele existierende Ansätze ergänzen sich mit diesem Proposal. Beispiele:
indoor mapping - Die Outlines der Einzelräume werden zusätzlich als "Wände" getaggt.
Roof Lines - Die Technik ergänzt den Ansatz mit einer Bibliothek der Dächer. Beide Konzepte erleichtern die Modellierung verschiedener Dachlandschaften.
4D Editor
Der Editor befindet sich in Entwicklung. Die ersten Schritte werden in dem Computer Engineering Department der TU- Lodz entwickelt. Mit ersten Ergebnissen ist im Mai 2012 zu rechnen.
Komponenten, die auf dem Bild in roter Farbe dargestellt sind, sind zu realisieren.
Die Unterstützung für die Umsetzung des Konzeptes ist ständig gesucht.
Level of Detail für 3D Stadtmodelle
3D Modelle werden für sehr verschiedene Zwecke gebaut. Daher gibt es verschiedene Anforderungen an die Detailtiefe der Modelle. Das Konzept Level of Detail erleichtert den mehrstufigen Aufbau der 3D Modelle. Dieses Konzept soll unter Anderem auch die Einstiegsschwelle in 3D Modellierung für einen unerfahrenen User erleichtern.
OSM-4D sieht 5 verschiedene Detailstufen für die Modelle vor: (Achtung, Abschnitt in Bearbeitung!)
LOD 1
- Grobes DTM (Digital Terrain Model) auf 250m Raster (Import)
- Straßenbreiten in dem Geländemodell anhand der Generalisierung: Je nach Straßenkategorie wird der Straße eine Breite zugewiesen, falls keine andere Information vorliegt. Ist die Anzahl der Fahrspuren bekannt, wird diese Breite verwendet unter Annahme: eine Fahrspur = 2,5m Breite.
Falls exakte Straßenbreite bekannt, wird diese verwendet.
- Gebäude als Volumenmodelle mit einer Höhe. Für die Höhenangabe wird verwendet
- Texturierung von dem Gelände anhand der Flächennutzung
LOD 2
Zusätzlich zu LOD 1:
- Verbesserungen von DTM per automatisierter Generalisierung der Strassenverläufe (Plausibilitätsprüfung)
- DTM beinhaltet Treppen als parametrisierbare 3D Elemente.
- Dachformen der Gebäude
- 3D Bäume aus Library
- 3D Brücken aus Library
- Texturierung der Gebäude anhand der Nutzung
- Texturierung der Bäume anhand der Baumart
LOD 3
Zusätzlich zu LOD 2:
- Falls vorhanden:Straßenbreiten anhand der Straßenflächen
- Falls vorhanden: Luftbilder als Geländetextur
- Verschneidung und Optimierung des Geländes anhand von Straßenflächen und Kreuzungsflächen.
- Manuelle Verbesserungen von DTM
- Texturen der Gebäude, Bäume, Brücken
- Andere 3D Library Elemente (Wände, Zäune, Laternen)
LOD 4
Zusätzlich zu LOD 3:
- 3D Gebäude bestehend aus Wänden, Dächer und Decken mit Öffnungen.
- Dachgauben
- Innenräume und Stufen innerhalb der Gebäude
In dem LOD 4 ist die Visualiserung der Indoor Navigation in 3D möglich.
LOD 5
Zusätzlich zu LOD 4:
- 3D Gebäude mit Türen und Fenster
- Tunnel im Gelände (Sichtbar im Modus DTM Wireframe)
- Falls bekannt: Unterirdische Leitungen (Sichtbar im Modus DTM Wireframe)
- Geländeschichten (Sichtbar im Modus DTM Wireframe)
Höhenannahmen für 3D Darstellung anhand der Geschoßigkeit der Gebäude
Ist nur die Anzahl der Geschoße bekannt, können entsprechend der Gebäudenutzung
folgende Annahmen für die Berechnung der Gebäudehöhen in 3D Darstellung gemacht werden:
| Key | Description | Geschoßhöhe in Meter | Kommentar |
|---|---|---|---|
| Wohngebäude | nach 1945 gebaut | 2.80 (a.) | |
| Wohngebäude | vor 1945 gebaut | 3.20 (b.) | Stärkerer Differenzierung
der Wohngebäudetypen fehlt |
| Krankenhaus | nach 1900 gebaut | 3.80 | |
| Bürogebäude | 3.20 | ||
| Hotel, Gaststätte, Herberge | 3.80 | ||
| Warenhaus, Verkaufsstätte | 4.00 | ||
| Schule, Hochschule | 3.80 | ||
| Kindergarten | 3.20 | ||
| Flughafen, Bahnhofshalle | i | 12.00 | |
| Schwimmhalle, Sportstätte, | i | 10.00 | |
| Mehrzweckhalle | i | 8.00 | |
| Kirche | i | 20 | |
| Fabrikhalle | i | 10 | |
| Museum, Schloß | i | 4.50 | |
| Bürgerhaus, Rathaus, Gemeindehaus | i | 4.00 |
i) nur in Ausnahmefällen - wenn selbst die geschätzte Höhe unbekannt ist - verwenden!
a. -Resultiert aus dem in der Bauordnung festgesetztem lichten Maß für Raumhöhe im Wohnungsbau:2,50 m plus 0,30 m für Deckenaufbau. Für Dachgeschoß ist die Raumhöhe von 2.30m zugelassen, für Kellerräume 2.20m
b. -Resultiert aus dem damals üblichen Maß für Raumhöhe im Wohnungsbau:3,00 m plus 0,20 m für Deckenaufbau
Grundelemente 3D
Punkt als 3D Symbol
Punkt kann als 3D Symbol beliebiger Art benutzt werden. Die Nutzungsmöglichkeiten werden in weiteren Abschnitten beschrieben. Die bisherige Verwendung beschränkte sich eher auf die räumliche Anzeige der POI´s [3]
Gelände
definiert durch 3D Punkte im Raum.
- Pi Geländepunkte mit den Werten Xi, Yi, Zi (davon x und y nicht direkt sichtbar, da Bestandteil der Karte) sowie optional
- Geländedicke; Höhe der Geländeschicht. Sie beschreibt die Dicke der Erdschicht und soll die Darstellung mehreren Bodenschichten für Geologie ermöglichen
- Bodenart (Landwirtschaftlich, geologisch)
Achtung: Es kann mehrere 3D Geländepunkte mit der gleichen x,y Koordinate und unterschiedlichen Höhenkoordinaten geben. Dies ermöglicht z.B. die Modellierung senkrechter Hänge.
Wand
Der Inhalt zu diesem Abschnitt befindet sich, analog dem Abschnitt zu DE:3D building, der besseren Übersicht dieser Seite halber im Artikel DE:Wall.
Decke
definiert im Grundriß ( Klassische OSM 2D Ansicht) durch einen Linienverlauf. Tagging:
- roof: yes
- Deckenhöhe H2, height=*
- Materialbeschaffenheit der Oben und Unterseite, surface=*
- Höhe über Gelände, Taggingvorschlag height over DTM: value
Das Element kann Bolean minus Elemente beinhalten.
Decke. "Bolean minus" Elemente
(Öffnungen):
2D Ansicht des Elementes in der klassischen OSM Karte:
Die dreidimensionale Öffnung wird in 2D als eine Relation gespeichert: P1-P2-P3-P4 ist ein Multipolygon:outer, A-B-C ein Multipolygon:inner
Dach
definiert im Grundriß ( Klassische OSM 2D Ansicht) durch einen Linienverlauf. Parameter:
- Dachstärke (H2 auf der Zeichnung),
- Materialbeschaffenheit der Oben und Unterseite sowie der Randflächen des Daches,
- Höhe über Terrain (H1 auf der Zeichnung) definiert über den niedrigsten 3D Punkt des Umrisses,
- Neigung des Daches, Alpha; wird definiert durch die Höhen 3 bekannten Punkte.
In dem Dach können Öffnungen gezeichnet werden;
- Bolean minus Elemente: Definition wie im Abschnitt "Decke"
Tagging für die Parameter: die Syntax muß gemeinsam definiert werden, bitte Vorschläge unterbreiten.
Profiler
3D-Profiler Elemente sind 3D Volumenkörper die durch einen Verlauf (z.B. klassische 2D OSM highway:<value>)und eine Querschnittdefinition entlang des Verlaufes entstehen.
Die Querschnittdefinition entlang eines Verlaufes muß stets die gleiche Anzahl der Punkte haben. Ein "Profiler" Element besteht aus einer Polylinie an der an jedem Knotenpunkt ein Querschnittsprofil mit n-Punkten zugewiesen ist. Die Profile können an jedem Knotenpunkt variieren. Auch die Drehung des Profils kann an jedem Punkt anders sein.
Profiler werden meistens zum Modellieren von 3D Brücken und schwebenden Autobahnabschnitten verwendet, um zum Beispiel eine S-Bahn Plattform mit kompliziertem Querschnitt zu zeichnen.
Ein Negativbeispiel für 3D-Profiler Elemente sind Tunnels und Durchfahrten
Pictures and detailed description: comming soon
Texturen
OSM-4D verwendet die Texturbibliothek für die Texturierung einzelner Oberflächen.
Parametrische 3D Symbole
Gebäude
Einfache, in der Regel allein stehende Bauwerke bei denen man nur grobe Volumenform und ungefähre Dachgeometrie kennt, und bei denen indoor mapping nicht in Frage kommt, werden parametrisch gespeichert.
Vorläufige Liste und Definition der Parameter siehe Wiki Seite: DE:3D building
Brücke
Einfachere Brücken werden als parametrische Objekte gespeichert.
Tagging:
- Genauere Bezeichnung z.B. nach nach http://wiki.openstreetmap.org/wiki/Bridge
- Breite , width=*
- Höhe , height=*
- Höhe "öffnung" , height_min=*
- Materialbeschaffenheit seitlich surface=* präziser: surface_left, surface_right
- Materialbeschaffenheit oben surface=* präziser: surface_top
- Materialbeschaffenheit Unterseite surface=* präziser: surface_bottom
Noch genauer: Brückentypbezeichnung aus einer Library architektonischer Elemente. Vorläufige Liste siehe Wiki Seite: Bridge_table
Hat die Brücke Pfeiler werden sie als Punkte auf dem Brückenverlauf eingetragen mit:
column=yes
Für die Pfeiler gelten:
- Breite , width=*
- Höhe , height=*
- Materialbeschaffenheit surface=*
- Typ type= <rectangular,circle,adjusted>
Treppe
Definiert unter Anderem durch:
- Anzahl der Stufen
- Treppenbreite
- Gesamthöhe
- Stufentyp aus der Library
- Materialbeschaffenheit
volle Liste der Parameter mit der Detailerklärung sehe: Stairs_modelling
Baum
Definiert durch:
- Baumtyp aus der Library
- Höhe Stamm
- Breite Stamm
- Höhe Krone
- Breite Krone
Die Liste siehe Wiki Seite: Tree_table
Stadtmöblierung
Elemente wie Laternen, Bänke, Fahhradständer usw. aus der Library definiert u.a.durch:
- Breite
- Tiefe
- Höhe
- Rotation
Landschaftsmöblierung
Elemente, die eine räumliche Orientierung in dem Gelände bzw. entlang der Küste für Seekarten erleichtern:
- Strommäste,
- Windräder,
- Schornsteine,
- Leuchttürme,
- Große Werbtafeln (z.B.:Ikea etc)
Räumlicher Profilverlauf
tube:yes profile:description
Hilfselemente / Parameter 3D
Um eine gewünschte 3D Darstellung bestimmter Elemente zu erreichen braucht man neue Tags:
- resolution3D:value (Ganzzahl >2) - entscheidet darüber, wie die 3D Elemente die auf einem Kreis oder einer Oberfläche des höheren Grades in der 3D Darstellung als ebene Flächen aufgelöst werden.
- point3D
- level3D:value (Wert 1 bis 4, entscheidet welche Elemente in der 3D Ansicht entfernungsabhängig dargestellt werden)
- invisible3D:yes (Unsichtbare Bolean Primitive können verwendet werden um von sichtbaren 3D Objekten elemente abzuziehen)
- Cirlcle3D:yes
- Ball3D:yes
- Bolean-minus:yes
- gravity:yes Parameter verursacht automatische Orientierung des Elementes auf dem Gelände, so dass die Eingabe des Parameters Höhe für ein Element überflüssig ist.
Der Abschnitt wird noch genauer beschrieben und mit Bilder versehen.
Beispiel 3D Gebäude
Tagging
- Schwarze Punkte
- Grüne Punkte
- Rote Punkte
- Gelbe Punkte
Ergebnis Drahtmodell
Ergebnis Volumenmodell
(zur Veranschaulichung wurden hier die Wände und Decken ohne Parameter Breite gezeichnet)
Features
- Ermöglicht Erstellung und Bearbeitung der Geometrie sowie das Verlinken von Materialien auf diese.
- Verlinkt die 3D-Daten mit den OSM-Daten. Die aktuelle OSM-Version wird diejenige sein, gegen die verlinkt werden muss (z.B. im Falle, dass bereits verschiedene Zustände (für verschiedene Zeiten) eines Objekts in der Datenbank vorhanden sind).
Arbeitsablauf
Der Arbeitsablauf im geplanten 3D Editor wird ähnlich dem von JOSM sein:
- Herunterladen eines Teils der Daten
- Bearbeitung der Daten
- Hochladen der Daten (und ggf. Konflikte bereinigen). Alternativ zur Konfliktbereinigung ist auch ein blocking-Modus denkbar.
Hinweise zum Arbeitsablauf
Bei 3D Modellierung ist die unsaubere Arbeit sofort sichtbar. Besonders störend im Echtzeit-Rendering sind kleine Lücken und Überschneidungen der 3D Objekte. Derartige Artefakte führen zu einem Flimmereffekt bei 3D Visualisierung und sollten unbedingt vermieden werden. Die Probleme entstehen meistens bei der Modellierung der 3D Gebäude. Dies kann nur dann effektiv vermieden werden wenn man alle benachbarte Gebäude herunterlädt, bearbeitet und wieder hochlädt; auch wenn nur ein Gebäude bearbeitet wird.
Wesentlich einfacher ist hingegen die Bearbeitung frei stehender Objekte. Diese können als Einzelobjekte bearbeitet werden.
Library Elemente
Geometrie-Datenbank
Hier werden die Objekte sowie das Geländemodell gespeichert.
- Wird mit OSM-Daten auf Erdbodenhöhe verknüpft
- Speichert die Geometrie und die folgenden Material-Parameter:
- Material-Bezug (ID aus der Material-Datenbank)
- Material-Projektionsart (planar, zylindrisch, sphärisch, ...)
- Ursprung
- Skalierung (Vergrößerungsfaktor)
- Ausrichtung (Drehung um die 3 Raumachsen)
Bauteil-Datenbank und modulares System
Um eine möglichst universelle Verwendbarkeit der Modelle zu garantieren, werden diese idealerweise modular aufgebaut. Typische Bauteile wie Fassaden, Fenster, Türen, Schornsteine werden in einer Bauteil-Datenbank abgelegt. Dort finden sich auch Elemente wie Parkbänke, Bäume, Mülleimer, Straßenlaternen, Briefkästen und was sonst zur Wiedererkennbarkeit eines Ortes beiträgt. Diese Bauteile sind nach Möglichkeit parametrisiert, so dass sie in anderem Kontext mit leicht modifizierten Parametern (wie z.B. Breite, Höhe, Profilbreite, etc.) weiterverwendet werden können.
So wird der Modellieraufwand reduziert und der Speicherbedarf minimiert, indem die Eigenschaften von Objekten vererbt werden können, und nur die geänderten Parameter extra gespeichert werden müssen.
Anders als der Name vermuten lässt ist die Bauteil-Datenbank keine unabhängige Datenbank. Vielmehr können alle Objekte jederzeit wiederverwendet werden - nach Bedarf auch mit veränderten Parametern oder Materialien.
Material-Datenbank
- Beschreibt die Materialien, die der Geometrie zugeordnet werden können.
- Verknüpft Texturen (fotografische Repräsentationen) und Shader (algorithmische Beschreibungen) mit der Geometrie und integriert dazu Angaben wie Transparenz und Reflektionseigenschaften.
- Ermöglicht die Kombination verschiedener Texturen und Shader.
Textur-Datenbank
Texturen sind Bitmap-repräsentationen (Fotos). Sie werden von der Materialdatenbank aus eingebunden. Die Texturdatenbank besteht aus 2 Grundtypen:
- Texturen für individuelle Gebäude [4], (ganze Fassaden oder Fassadenteile eines spezifischen Gebäudes)
- Standard-Texturen, die ähnlich einem Baukastensystem universell verwendet werden können, z.B.:
- Dacheindeckungen
- Mauern
- Fassadentypen
- Fenster und Glasfassaden
- Bodenbeläge
- "Grundmaterialien" wie Metall (in verschiedener Oberflächenausgestaltung), Naturstein, Sand, ...
- alle Texturen können getaggt werden, um sie auffindbar zu machen.
- das System ist mehrsprachig: Tags können in verschiedenen Sprachen eingegeben werden
Shader-Datenbank
Die Shader-Datenbank ist ähnlich aufgebaut wie die Texturdatenbank. Der Hauptunterschied ist, dass algorithmische Ausdrücke (Formeln) und Parameter anstatt Fotos enthalten sind. Tags sind auch hier mehrsprachig hinterlegbar.
Zeit
Saisonal
Die Welt ändert sich ständig, die Kartendarstellungen sind bisher aber statisch. Die konsequente Einführung des Zeitparameters wird der OSM Karte ungeahnte Möglichkeiten eröffnen. Straßen die normalerweise passierbar sind, aber für eine bestimmte Veranstaltung gesperrt werden können genauso gut dargestellt werden wie die Veränderungen der Natur. Zwar lassen sich bestimmte Ereignisse nicht exakt voraussagen, (Anfang der Kirschblütezeit) man kann sie jedoch mit einer schätzbarer Genauigkeit in die Karte eintragen.
Beispielsweise kann der Anfang der Monsunzeit in einem Gebiet dazu führen, dass die Befahrbarkeit bestimmeter Straßen eingeschränkt wird.
Der Echtzeitviewer soll die Parameter wie:
- Öffnungszeiten,
- Start und
- End
- construction:start_date
- construction:end_date
- Wachstumskurven der Bäume
für Elemente der Karte berücksichtigen, und diese abhängig vom Zeitpunkt der Abfrage anders in der Karte darstellen bzw. überhaupt anzeigen (oder nicht).
Als Zeitpunkt der Abfrage ist gemeint die lokale Uhrzeit in einem Kartenabschnitt.
Da dieses Konzept noch nirgendwo mit allen denkbaren Optionen durchdacht wurde kann dieser Abschnitt ( momentan im Aufbau begriffen) lediglich einige Nutzungsmöglichkeiten nennen aus denen weitere Taggingkonzepte enstehen müssen.
Historisch
Ein 4D Viewer soll die Fähigkeit besitzen, historische Daten auf einer Karte darzustellen.
Datenbank
In der OSM-Datenbank werden bisher hauptsächlich aktuell in der Realität vorhandene Objekte gespeichert. Deren Entstehungszeitpunkt ist zum Teil bereits mit start_date festgehalten. Um die Erstellung historischer Karten zu ermöglichen ist aber auch die Speicherung der Daten von Objekten notwendig die in der Realität nichtmehr vorhanden sind. Zur Speicherung dieser Daten werden im deutschen Forum folgende Möglichkeiten diskutiert:
Nutzung der OSM-Datenbank
Pro
-erweiterte Auswertungsmöglichkeiten durch gemeinsame node-Nutzung aktueller und historischer Objekte
-Bearbeitung aktueller und historischer Objekte gleichzeitig und ohne großen Aufwand (Server-/Nutzerseitig)
-Für OSM freigegebene Datenquellen (z.B. Luftbilder) können unproblematisch genutzt werden
Contra
-Umarbeitung aller Editoren (Standardmäßiges ausblenden aller historischen Objekte)
-Einführung neuer Schlüssel (Filterung nach end_date wäre für Anbieter herkömmlicher Karten notwendig aber kurzfristig nicht zumutbar)
Eigene OHM-Datenbank
Pro
-Taggingschema kann komplett beibehalten werden
-keine zusätzliche Last auf dem OSM-Server
Contra
-Verknüpfung zu OSM-Daten problematisch
-eigener Server notwendig
-Splitterprojekt findet weniger Beachtung als Integration in OSM
Editoren
Wenn Objekte, die aktuell nicht in der Realität vorhanden sind mit in der OSM-Datenbank gespeichert werden, scheint es sinnvoll diese in den Editoren standardmäßig auszublenden. So wird weiterhin ein übersichtliches Arbeiten an den bisherigen Daten ermöglicht.
Für das Arbeiten an den historischen und zukünftigen Daten könnte mittels Schieberegler (Zeitstrahl) ein Zeitpunkt gewählt und die Daten entsprechend gefiltert dargestellt werden. Eine zusätzliche Anzeige der übrigen Daten (Unterschieden in vorherige und zukünftige), ausgehend vom gewählten Zeitpunkt kann in einigen Situationen von Voteil sein, in anderen aber die Übersichtlichkeit beeinträchtigen und die Unterscheidung von Objekttypen erschweren.
Weitere Ideen
Bot
Ein Bot könnte Objekte deren end_date in der Vergangenheit liegt automatisiert als in der Realität nichtmehr vorhanden markieren. Dieser Bot ist evtl. nur in einer Übergangsphase nötig da die Auswerter selbst nach start_date bzw. end_date filtern könnten.
Tagging
Alle aufgeführten Varianten sind Überlegungen die sich beim ersten Testen und Durchdenken als günstig erwiesen haben. Insbesondere die Tags können und sollen noch verbessert und ergänzt werden.
Objekt mit einer Nutzung
Ein Objekt von dem nur eine Nutzung und keine Änderung am Grundriss bekannt ist. (Vorgänger-/Nachfolgebauten mit komplett eigenen Mauern werden mit einem anderen way erfasst)
Allgemein: Alle Tags kommen direkt an den Weg.
Beispiel: Gebäude (Gebaut:1834 Abgerissen:1920)
- way1
- historic:building=yes
- start_date=1834-12-31
- end_date=1920-01-01
Objekt mit mehreren Nutzungen
Ein Objekt von dem keine Änderungen am Grundriss aber unterschiedliche Nutzungen bekannt sind.
Allgemein: Wenn ein Tag für alle Nutzungen gilt kommt er an den Weg, sonst in die Relation. Zwischen den Nutzungen dürfen Lücken bestehen.
Beispiel1: Gebäude (Gebaut:24.11.1863; 01.12.1863-31.09.1993 Bäckerei, ab 01.01.1994 Fleischerei)
- way1
- building=yes
- start_date=1863-11-24
- relation1
- type=usage
- historic:shop=bakery
- start_date=1863-12-01
- end_date=1993-09-31
- Mitglieder:
- way1
- relation2
- type=usage
- shop=butcher
- start_date=1994-01-01
- Mitglieder:
- way1
Beispiel2: Straße (1603-1812 Pfad; 1812-1956 Feldweg; seit 1956 Bundesstraße)
- way1
- start_date=1603
- relation1
- type=usage
- historic:highway=path
- historic:width=0.5
- start_date=1603
- end_date=1812
- Mitglieder:
- way1
- relation2
- type=usage
- historic:highway=track
- historic:surface=ground
- start_date=1812
- end_date=1956
- Mitglieder:
- way1
- relation3
- type=usage
- highway=primary
- surface=asphalt
- maxspeed=100
- start_date=1956
- Mitglieder:
- way1
Umgebautes Objekt
Umgebautes Objekt das Teile eines Vorgängers nutzt. Die Nutzung des Vorgänger-/Nachfolgebaues kann identisch oder unterschiedlich sein.
Allgemein: Mehrere ways (Teilobjekte) sowie mehrere Relationen die die Teilobjekte und sämtliche Tags für das Gesamtobjekt enthalten.
Beispiel: Gebäude (Gebaut: 1970; Erweitert: 1994)
- wayA
- start_date=1970
- wayB
- start_date=1970
- end_date=1994
- wayC
- start_date=1970
- end_date=1994
- wayD
- start_date=1970
- wayE
- start_date=1994
- wayF
- start_date=1994
- wayG
- start_date=1994
- wayH
- start_date=1994
- relation1
- type=usage
- historic:building=yes
- start_date=1970
- end_date=1994
- Mitglieder:
- wayA
- wayB
- wayC
- wayD
- relation2
- type=usage
- building=yes
- start_date=1994
- Mitglieder:
- wayA
- wayE
- wayF
- wayG
- wayH
- wayD
Offene Fragen
- Es ist nur bekannt das ein Weg 1855 vorhanden war und 1873 nicht mehr. Welches start_date und welches end_date ist zu wählen?
- tendenziell eher kein start_date, und eher auch kein end_date, letzteres könnte man evtl. angeben mit end_date=1855-1872. Am besten einen Tag mit note setzen, bzw. note:de falls auf Deutsch. --Dieterdreist 10:19, 15 May 2012 (BST)
Was gibt es schon?
Ein paar Seiten mit Inhalten, was bereits existiert:
- DE:OSM-3D
- Tree_table (auf englisch)
- Roof_table
- DE:Stairs_modelling
- DE:X-Plane
- Bridge_table (Seite in Bearbeitung)
- Indoor
- Texture_table
- Google_Sketchup_Plugin (Foto mit Geometrie matchen, ...)
- Comparison_of_life_cycle_concepts (auf englisch)