Ich habe angefangen die Kathedrale in Siena zu modellieren.
Das Nachzeichnen der Rosettenöffnung bzw Bögen mit dem bisherigen S3DB Schema ist sehr anstrengend und die Ergebnisse nicht gerade zufrieden stellend.
Ich habe überlegt, wie man dieses Problem mit möglichst wenig Programmieraufwand umgehen kann und möchte Euch folgenden Gedanken unterbreiten:
zum einen könnten die Dächer eine negative Höhe haben, zum zweiten wenn man zusätzlich den Tag roof:position=down verwendete, würde die Dachfläche nicht oben, sondern unten erscheinen.
@Marek Möchtest du mit deinem Vorschlag das Ziel erreichen Rundbögen zu definieren, oder alle Dächer “auf den Kopf” zu stellen?
Grundsätzlich ist die Idee nicht schlecht, aber es wird dem Renderer vor einer schweren Aufgabe stellen. Weil ja erstmal jede Dachform gemeint ist; und das kann nicht funktionieren. Außerdem muss berücksichtigt werden das der Abschnitt über dem Bogen nicht unbedingt flach ist, sondern wiederum eine Dachform haben kann.
Die Kathedrale Sienna kenne ich persönlich, grundsätzlich geht es dir sicherlich um die gotischen Bögen ( Eingänge sowie dem südlichem Seitenteil ). Hast du Überlegungen, die Eingangsportale zu taggen? Wenn ja, mit welchem Schema? Im Prinzip würde es ja wahnsinnig viele schöne Bauwerke betreffen.
Lieber Rogehm,
ich habe Antworten auf Deine Fragen, in Kürze sind sie in der Wiki Seite drin.
Nur im Vorab: Man bräuchte nach diesem Schema für Bereiche die sowohl oben, wie auch unten einen “Dach” haben zwei roof:shape Elemente.
Eine Alternative wäre ein anderes Wort etwa bottom:shape=* , bottom:height usw. Dann hätte man ein Element mit mehr Tagging und keine zwei.
Was wäre besser?
Meine Meinung kennst Du ja
Eindeutig bottom, weil das Ganze dann übersichtlicher wäre, wenn man Dach und Unterfläche am gleichen Objekt modelllieren wollte. Auch ist der Bezug mit roof/bottom:height dann einfacher. Bei “roof:down” nebst normalen roof wäre mir unklar, wie man die beiden Höhen unterscheiden würde.
Von der Begrifflichkeit würde ich für die Gebäudeunterseite auch nicht den Begriff “Dach” verwenden wollen. Es soll doch KISS bleiben (=Simple3D).
Deine Argumentation ist überzeugend. Ich werde den Proposal dahingehend überarbeiten. Es blieibt die Frage, wie wir die Höhen für bottom=* definieren wollen. bottom:height=* ist klar. Es ist genau so wie bei roof:height=. Uns fehlt dann der Tag der dem min_height= entspricht.
Für was jetzt? Den unteren Teil eines Gebäudes abschneiden macht ja Sinn, weil ein Gebäude erst mal immer auf dem Boden steht. Min:height beschreibt den Sonderfall, dass für ein Gebäudeteil genau diese Definition nicht gilt. Andersrum ist ein Gebäude nach oben durch height/roof grundsätzlich begrenzt. Da braucht es keine weitere Beschränkung, weil es keine Entsprechung gibt.
“bottom” wäre somit identisch mit “min_height” und wird neben “bottom:height” nicht benötigt.
Anders ausgedrückt: Ein Gebäude ist im einfachsten Fall ein Quader, der auf dem Boden steht. Von diesem wird oben mittels roof etwas weggeschnipselt. Unten >kann< mit min_height etwas Waagerechtes weggeschnitten werden. Das angedachte “bottom” schnipselt jetzt analog unten etwas weg. bottom:height bezieht sich immer auf den untersten Teil des Quaders - und schneidet dort die entsprechende Form weg. Wenn mittels min_height der Quader unten schon verkürzt wurde, dann liegt der “unterste Tei” halt entsprechend höher.
Ich hoffe, das war jetzt ohne Bild verständlich - ansonsten bastle ich Dir mal ein Bild.
Das einzige, was uns fehlt, ist eine Einigung über die Definition der Vorzeichen für die Neigungen bzw. den Höhen bei “inversen” Dachformen. Das sollten aber die 3D-Programmierer besser wissen, was programmiertechnisch sinnvoller ist bzw. intuitiv sein. Tordanik (liest vielleicht mit) und Cactusbone (müsste man auf französich/englisch ansprechen, weil der hier kaum mitliest) oder Kendzi (machst Du wahrscheinlich ohnehin) müsste man da ansprechen.
Kendzi hat sich den rechten Arm gebrochen und ist erst in einigen Wochen in der Lage die Entwicklung zu integrieren.
Ich hoffe, die F4 Leute machen da mit.
Die Idee ist sehr einfach, also denke ich, dass wir in Kürze mit der Abstimmung starten können. Oder?
Fast. Jedoch müssen roof und bottom in der Draufsicht >immer< deckungsgleich sein. Das relativ komplexe Beispielobjekt würde demnach leider in vier building:parts aufgeteilt werden müssen. Links und rechts vom Durchgang jeweils ein Quader, der Durchgang mit Flachdach in Höhe der Nachbarquader nebst “bottom:shape=round” und “min_height” und obendrauf das Satteldach mit eigenem min_height in Höhe der unteren drei Objekte.
Momentan würde man so etwas mit drei Parts abbilden und bekäme einen rechtwinkligen Gebäudedurchgang. Mit dem angedachten vierten Teil, könnte man dann auch nachträglich das Bogenelement hinzufügen.
So, wie es in Proposal dargestellt ist (Variant 2), könnte der “Gebäudetunnel” im Grunde einfacher mit etwas, wie “bulding:part=no” mit den “normalen” roof-Tags" erfasst werden. Soweit ich Cactusbone verstanden habe ist das seitens der 3D-Programmierer eher nicht umsetzbar bzw. sehr komplex, weil die yes/no-Parts sich erst programmtechnisch finden müssten - oder zwingend in eine Gebäuderelation zusammengefasst sein müssen.
Die Grundidee (Variant 2) mit einem Gebäudeteil, das beschreibt, dass genau da kein Gebäudeteil ist (“bulding:part=no”), hat natürlich seinen Reiz
Wenn das von den 3D-Renderern so umsetzbar wäre, dann wäre das natürlich für den Mapper viel einfacher und sehr leistungsstark. Es löst aber auch nicht alle Probleme, die bei verschachtelten Gebäuden auftreten können. Zum Beispiel gäbe es bei zwei überlappenden building:part=yes und einem building:part=no die Frage, auf welches Part sich Letzteres bezieht (das Eine, das Andere oder gar Beide).
Also die Einführung von "bottom:shape"s fände ich gut, da gibts noch ein großes Betätigungsfeld. Hätte aber zur bisherigen Diskussion mal ein paar Anmerkungen.
Erstens bin ich mir nicht sicher, ob man die Werte von den Dächern dort sinnvoll wieder verwenden kann. Ich gehe davon aus, dass diese Elemente in der Architektur eigene Namen haben, die nicht identisch mit dem Namen des ähnlich aussehenden Dachtyps sind?
Zweitens noch mal ein Kommentar zu den “negativen” Gebäudeteilen. Ich muss da leider die Annahme bestätigen, die bei pyram schon angeklungen ist: Das ist fürs Programmieren sehr unangenehm. Ich könnte mir höchstens vorstellen, das als Sonderfall bei Gebäudedurchgängen zu unterstützen (d.h. tunnel=building_passage), dann aber als Tag am Weg der durch das Gebäude führt.
Von daher sehe ich vor einer Abstimmung schon noch einigen Diskussionsbedarf. Ich würde mich aber an der Umsetzung beteiligen, wenn wir gemeinsam einen guten Entwurf gestalten können.
" Ich gehe davon aus, dass diese Elemente in der Architektur eigene Namen haben, die nicht identisch mit dem Namen des ähnlich aussehenden Dachtyps sind?"
Die einzige “reine” Form ist ein Tonnengewölbe oder english: https://en.wikipedia.org/wiki/Barrel_vault. Barrel roof haben wir fälschlicherweise als “round” bezeichnet, nun ist zu spät, es wird verwendet.
da würde ich bottom=round verwenden
Wichtig wäre m.m.n. das gotische Gewölbe
man findet allerdings nicht allzu viel zu dem Thema.
Verschiedene Subtypen gotischer Gewülbe wären, denke ich, sehr schwer umsetzbar, da ist mein OSM4D Schema noch harmlos dagegen.
Ich sehe daher, aus der früheren beruflichen Erfahrung als Architekt, nur folgende bottom Formen als notwendig:
Man sollte schon beim “Simple” bleiben und nicht irgendwelche Architekturbezeichnungen verwenden, die dann nur Fachleute ohne Bild richtig zuordnen können
Als Unfall sehe ich daher “round” eher nicht, sondern begrifflich näher am KISS-Prinzip
Praktisch ist hauptsächlich skillion, dome und round vonnöten. Die empfohlenen Fensterformen sind als Unterseite von Gebäuden im S3DB wohl eher Exoten. Solches Detailmapping wird wohl kaum jemand machen und kaum ein Renderer unterstützen.
“Als Unfall sehe ich daher “round” eher nicht, sondern begrifflich näher am KISS-Prinzip”
+1.
“Die empfohlenen Fensterformen sind als Unterseite von Gebäuden im S3DB wohl eher Exoten.”
Bitte denke Mal an alle alte Arcadenformen. Die für uns exotischen “Horsehoe” , “Stilted” und “Trefoil” sind in der mauretanischen und arabisch - islamischen Architektur die grundlegende Form. Mir ist lieber, wir sehen es im Standard vom Anfang an vor, statt im nachhinein den Standard aufzubohren.
Genau dies hatten wir mit S3DB: Am Anfang nur 7 Formen, jetzt 11.
Was die Namen angeht da stimme ich nur zu, keiner kann sich das zunächt merken. Dafür aber haben wir Wiki.
