Der Unterbau linksrheinisch kommt überhaupt nicht klar mit den Gleisen. Hier werden die einfach unterdrückt, obwohl Dachwärts das Gleisgelände ist zum Hbhf.
Es braucht daher ein “Übergangselement” um den Gleisen ( oder andere ways ) die Möglichkeit zu geben, sich dort auch einzufinden.
Alle “layer” und “level” tags bringen hier nichts.
OK, dies ist wieder ein 3D Problem, aber ich hoffe, das sich doch manch ein 3D Mapper sich auch solche Gedanken macht.
Ich hab jetzt das Problem mal besonders herausgestellt, weil das weltweit noch nicht gelöst wurde und ich denke, mit einer Lösung des Problems ist das echt ein Durchbruch.
Auch dafür habe ich einen Vorschlag, jemand müßte aber ein Josm PlugiIn dafür schreiben und die Open source Tools (Kendzi, OSM2World, opensciencemap) müßten die Lösung untestützen.
Grob gesagt wäre die tragende Fläche der Brücke auch ein Area. Zusätzlich müßte man sie so taggen, dass diese Fläche auch eine gewisse Stärke bekommt.
Die tragenden Säulen sind schon in F3DB vorhanden, einfache Barrieren bhaben wirauch. Was fehlt, ist eine Idee wie man Tragwerk baut,so dass es gut aussieht.
Dafür habe ich eine Lösung und werde diese nächste Woche aufskizzieren.
Eigentlich ist es dringend notwendig in OSM , ein Brückenlager zu definieren. http://de.wikipedia.org/wiki/Lager_(Bauwesen)
Die aufliegende “eigentliche” Brücke ist ja eigentlich nichts anderes als eine grosse Platte ( Metall > Zwischenschichten > Teer > Schienen etc. )
Das tagging über building einer solchen Platte wird hierzulande nicht gemacht und ist auch nicht gewünscht. Jedoch in Frankreich und England oft im Gebrauch.
Aber auch ist ein building nicht geeignet, ways obendrauf zu legen.
Eine Brücke als Area geht, sogar mit surface tags. Siehe meine Grünbrücken. http://demo.f4map.com/#lat=50.9098744&lon=7.1222837&zoom=16
Aber auch hier ist eine “Höhe” noch nicht definiert.
Wichtig zu wissen, wäre, wie man Brückenpfeiler taggen kann.
Gebt zu. Schiffe in F4, die über der 2D Brücke fahren, ist doch doof, oder?
Das ist das größte Problem überhaupt. Solange die Erde in OSM3D eine Scheibe ist, spielt das keine Rolle: Man geht davon aus, dass derHöhenwert der Oberfläche der Straße gleich 0.00 ist. Man kann diese Fläche auch mit dem ele=* beschreiben, wenn man es kennt. Der Renderer der die tatsächliche Höhe des Geländes ignoriert, würde die Straßenfläche der flachen Geländefläche gleich setzen. Die Konstruktionsstärke,sagen wir Mal, 1, 25m um eine Zahl zu nennen, geht dann bei dem Renderer nach unten. Die Unterkante Brücke ist dann -1.25m. Die durchschnittliche Unterfahrtshöhe der Brücken an dieser Stelle, Wasserpegel also, müßte als eine Zahl mit einem speziellen Tag definiert werden. Sind das z.B 8.80 Meter, dann müßte der “vereinfachende” 3D Renderer an dieser Stelle die Wasseroberfläche mit -(1.25+8.80)= -9.05m annehmen.Natürlich müssen sie die Annahmen trefen, wie die Uferkante links und rechts aussieht. Dazu male ich einige lockere Gedanken zusammen.
Wollte ich schon längst gemacht haben, angefangen bei der Hohenzollern… in Köln. Das Problem: Wird nicht akzeptiert. Außerdem das angesprochene Übergangsproblem auf den roof eines buildings bzw. anderen areas.
Wirhaben leider zu Anfang kein Unterschied zwischen Gebäude und Bauwerk gemacht. Das richtige Wort fehlte im Englischen ja auch.
Das englische “construction” bedeutet in OSM bereits Etwas völlig anderes. Man könnte vielleicht neue Tags analogisch zu **building **bilden und stattdessen **bridge **nehmen also bridge:part=yes.
Die meisten Renderer unterstützen aber noch nicht mal die einfacheren der o.g. Dinge wie mehrere Gleise/Straßen über dieselbe Brücke oder als Punkt getaggte Pfeiler. Mit der Komplettlösung aller Brückenprobleme wird es also so schnell wohl nichts werden.
Alles bekannt,auch die Links
Nun, wir haben ein typisches Henne-Ei Problem. Gehen wir es nicht an, wird auch nichts geschehen.
Die ersten Skizzen sind bereits fertig. Ich hoffe, bis Freitag erste Arbeitsversion veröffentlichen zu können.
Gerade wollte ich noch ein paar links dazusteuern, denke, das bringt nichts.
Wir haben jetzt soviel “Material” zusammen, das man daraus doch was “handfestes” zusammenschustern kann, oder?
Hab heut morgen noch überlegt, ist doch traurig, mit 4 Jahren mit “Lego” gespielt ( Bauplatten, schräge Anpassungsstücke, alle möglichen 3D Klötze darunter)
Das ist ein halbes Jahrhundert her? Und das soll nicht virtuell gehen. OK, die 2D Plane mit 3D zu verbinden, ist schwierig. Und das Hauptproblem ist wohl, den way darauf zu packen.
Für den Anfang mag ja auch erst mal ein eigenes Bridge tag reichen, der anfänglich 3D Attribute erhalten sollte quasi wie ein building nur als eigenes Ding.
Merkwürdigerweise dürfen auch alle anderen Bauwerke als building getaggt werden ( Türme, Staumauern… ), nur die Brücke soll nicht.
Kann man an der 2D Plane der OSM nicht layer-Stücke “ausschneiden” oder kopieren und das quasi auf der Brücken-Relation legen. Ich glaub, damit liege ich sicher ganz falsch.
Hier sollten sich doch ein paar Experten zusammentun. Wäre doch auch eine Arbeit für deine Studenten, Marek, oder?
Wir werden was handfestes haben, und die Taggingdiskussion die kommt, ist aus meiner Sicht völlig ok.
Building oder bridge: Wir stimmen einfach über zwei Taggingvarianten ab und die Sache ist erledigt.
Ich glaube zwar nicht, dass ich das die Sache mit den Studenten aus dem 6 Semester erledigt werden kann,
dafür aber eine Spezifikation die dem Modellieransatz von Google Earth überlegen ist und Probleme im Bereichen Gelände / Brücke löst. (Ist mir völlig bewußt, was ich schreibe. Bitte einfach südlich von Hauptbahhof Hamburg in Gogle Earth einen Blick werfen, Katastrophenfilme lassen grüssen)
Haben wir ein Konzept, bin ich mir auch sicher, dass wir via OSMF oder andere Kanäle dieses umsetzen können.
Sehe die Geschichte von iD.
Es gibt bei einer mehr oder weniger direkten Übertragung des Building-(Part-)Konzepts aus meiner Sicht mindestens zwei Probleme. Erstens gehen wir beim Haus in S3DB ja von einer gleichmäßigen Grundhöhe (quasi die Lego-Basisplatte ;)) aus, bei Brücken wird es schwerer, dafür ein Äquivalent zu finden. Zweitens sind viele Bestandteile von Brücken, z.B. eine klischeehafte Hängebrücke, nicht flach, sondern geschwungen. Da kann man nicht einfach ein quaderförmiges Building-Part-Äquivalent nehmen.
Der Vergleich hinkt doch etwas. Wahrscheinlich möchte niemand jeden Zentimeter einer Brücke in einem eigenen Objekt erfassen. Und wenn es doch so verrückte gibt, sollte man an diejenigen Denken die darüber in der Datenbank stolpern und das Ding nicht nur nicht kapput machen dürfen.
Das Problem mit der Ebenen Bodenfläche sehe ich noch nicht so verbissen wie Tordanik. Aber das liegt wahrscheinlich auch eher an der Region in der man sich aufhält. Hier im Flachland sind ist das Gelände meist eben wie eine Scheibe, so dass für eine Brücke immer Rampen erforderlich sind oder die Brücken irgendwelche Lücken in der Struktur überwinden.
Und die brückenreichste Stadt Europas (Hamburg) ist auch nicht reich an Bergen.
Noch eine schnelle Antwort für heute morgen. ( Bin mal wieder zu spät… ) Natürlich möchte ich keine “Klötzchen” bauen. Aber wie wär’s mit ganz flexiblen “Fertigteilen”, die in jeder Hinsicht ( H/W/L) formbar einsetzbar wären. ( Baukastenmethode ). Das würde bei den Großbrücken wahrscheinlich auch noch nichts bringen. Aber mit “Vorlagen” lässt sich doch was anstellen. Und ich´meine damit die ganze bridge ( Straßen/Zugweg-element, Brückenlager, Unterbau… ). Und mit dem Übergang bin ich gespannt auf Mareks Vorschlag… das ist nämlich das wichtigste.
erg.: Der “Oberbau” also die “komplizierte” z.B Seilverbauung dann erst zu einem späteren Zeitpunkt…
