Zum Inhalt springen

Geländemodell und Geschossbasishöhen in Bezug auf Höhe ü. NN


hanswurst

Empfohlene Beiträge

Hallo Zusammen,

 

Ich habe als Planungsgrundlage eine Punktwolke vom Vermesser, aus der ich ein Geländemodell erstelle.

Jetzt stehe ich vor der Frage, wie ich die Geschossbasishöhen definiere.

Setze ich die Geschossbasishöhe auf die Höhe über Normalnull aus dem Geländemodell also z.B. 511,40 m

oder korrigiere ich den Z-Wert im Geländemodell auf -511,4 m und lege das EG auf 0,00?

 

Wie handhabt Ihr das, gibt es Vor- und Nachteile?

es grüßt der Hans

 

 

Windows 11 Pro 22H2, VW 2024 SP3.1 Architektur

Link zu diesem Kommentar

Arbeite bei den Geschossen lieber mit relativen Koten: d.H. EG auf ±0.00

Das Geländemodell legst du dann auf eine eigene Konstruktionsebene. Dieser Gibst du die negative absolute Höhe (Bsp.: -511.4).

Dies hat mehrere Vorteile:

  • Du kannst später die absolute Höhe mit kleinem Aufwand verändern ohne dass sich das Gebäude verschiebt. Dazu änderst du einfach die Höhe der Konstruktionsebene mit dem Geländemodell. Die absolute Höhe von ±0.00 bleibt so auch immer ablesbar.
  • Schnitte durch das Gebäude bleiben so auf der gleichen Höhe. Auch Ergänzungen in den Schnitten musst du so also nicht anpassen.
  • Du bist näher am Nullpunkt mit deinem Modell. So läuft VW flüssiger und zuverlässiger, da nicht mit grossen Zahlen gerechnet werden muss.
  • Die Ebenenbasishöhe deiner Konstruktionsebenen entsprechen den relativen Koten deiner Geschosse. Alle Z-Werte sind so viel übersichtlicher.

Die Ebene mit der Umgebung und den Geländemodifikatoren lege ich meist wieder auf ±0.00, da ich es einfacher finde mit den relativen Koten in Bezug zum Gebäude zu arbeiten.

  • Like 2

Vectorworks 2024 - Architektur - Win 10

Link zu diesem Kommentar

Generell sollte sich die Geometrie möglichst nah am Ursprung befinden.

(Bessere Genauigkeit)

 

Das kann nur zum Problem werden wenn man weiterhin regelmässig mit anderen Dateien

oder Geometrie austauschen muss und diese in Weltkoordinaten oder zu einem anderen

speziellen Ursprung angelegt sind.

 

Dann würde man eben das kleinere Übel wählen und den Nutzerurtsprung (gegenteilig)

verschieben so dass das Projekt für VW am Programmursprung liegt aber die Exporte

weiterhin and der richtigen entfernten Stelle ausgegeben werden.

Die Lineale zeigen dann weiterhin die entfernten Koordinaten an.

 

Bei richtigen Georeferenzing mit Projektionen geht das nicht. Die darf man gar nicht

verschieben sonst stimmt die Projektion nicht mehr.

Das ist aber selten und betrifft mehr Landschaftsarchitektur oder Städtebau.

 

Wenn man aber keinen Zwängen unterliegt möchte man natürlich den Ursprung an seinem

Projekt ausrichten bzw. schiebt sich die Geometrie und Referenzen passend hin, wie von

Marc beschrieben.

Z.B. an den Ursprung des Achsensystems oder einer Hausecke, Nulllevel auf OK FFB usw.

Das hat den Vorteil dass man bereits an den Koordinaten einzelner Objekte einfach ablesen

und überprüfen kann ob etwas leicht daneben liegt oder korrekt positioniert ist.

Wenn man nur den Benutzerursprung planlos versciebt und dann mit krummen Zahlen arbeitet

wäre das nicht möglich und Fehler werden leicht übersehen.

 

Z.B. wenn ich gerade eine Wand bearbeite und in der OIP lächelt mir ein X=10,0001478935 m

entgegen, dann weiss ich gleich dass da wohl was schief gelaufen sein muss.

  • Like 1

📦 Mac Mini M1 16 GB M1  macOS 14 Sonoma PB

🗑️ Mac Pro 6c 24 GB D700  macOS 12.5 Monterey, in Rente ...
📺 PC RYZEN 3950X 64 GB RX6800 16 GB  🐧 Manjaro + OpenSUSE Tumbleweed + ElementaryOS
VW 2023 ARCH US
🇪🇺 Europe

Link zu diesem Kommentar
  • 3 Monate später...

Arbeite bei den Geschossen lieber mit relativen Koten: d.H. EG auf ±0.00

Das Geländemodell legst du dann auf eine eigene Konstruktionsebene. Dieser Gibst du die negative absolute Höhe (Bsp.: -511.4).

Dies hat mehrere Vorteile:

 

 

WTF

Das haut nicht hin !

 

Wenn ich die Quelldatenhöhen ablesen will zeigt er mir die doppelte (?) Höhe an !

VW 2017 und 2018

Erlaubte Ebene ist ausschliesslich "Site Model Plane"

 

Ausserdem zeigt mir die Koordinatenanzeige (unten rechts am Bildschirmrand)

in der rechten Spalte für den Z-Wert mit Bezug auf lokale Höhe zur Ebenenhöhe

generell einen totalen Schmarrn an !

Da ist jeweils ein willkürlicher Offset drauf - wenn ich mit dem Cursor in einer

Seitenansicht ansnappe.

(Nur in einer wirklichen 3D Ansicht wie Isometrie funktioniert das richtig)

 

 

 

 

Die Ebene mit der Umgebung und den Geländemodifikatoren lege ich meist wieder auf ±0.00, da ich es einfacher finde mit den relativen Koten in Bezug zum Gebäude zu arbeiten.

 

Normalerweise ja,

aber ich habe folgende Voraussetzungen :

 

A

Gesamte Architektur ist, und soll auch, auf 0,00 = FFB EG bezogen werden.

Alle Angaben dazu bekomme ich in diesem Höhenbezug.

 

B

Geländemodell war früher mal passend hingeschoben was normalerweise ok ist

 

C

Alle Angaben fürs Geländemodell oder laufende Änderungen des LA bekomme ich

dagegen in Meereshöhe. (2D)

 

 

Deshalb wollte ich auch meiner Ebene für die gesamten Höhenmodelldaten in die

Gegenrichtung absenken. Also Ebenenhöhe -Meereshöhe, im Gegenzug 3D Polygone

im Geländemodellbearbeitungsmodus auf Meereshöhe anheben.

Damit ich alle Geländebearbeitungen und Soll-Modifizierungen in Meeresniveau

machen kann.

 

Für die Konturendarstellung und Höhenlabel passt das auch wunderbar.

Nur sobald ich in den Bearbeitungsmodus gehe bekomme ich falsche Höhenangaben,

So kann ich darin natürlich auch keine Vermessungspfähle (Stakes) oder Höhenpunkte

anhand der gelieferten Höhendaten in die bestehenden Quelldaten einfügen.

 

Und ob das mit den Soll-Pfählen als Modifikatoren, von ausserhalb des Modells, dann

wirklich klappt bin ich mir auch nicht sicher.

📦 Mac Mini M1 16 GB M1  macOS 14 Sonoma PB

🗑️ Mac Pro 6c 24 GB D700  macOS 12.5 Monterey, in Rente ...
📺 PC RYZEN 3950X 64 GB RX6800 16 GB  🐧 Manjaro + OpenSUSE Tumbleweed + ElementaryOS
VW 2023 ARCH US
🇪🇺 Europe

Link zu diesem Kommentar

Danke für die Bestätigung.

Finde auch das geht so nicht.

 

Mein Workaround ist derzeit,

solange ich an den Quelldaten arbeite, verschiebe ich nur den Z-Wert des DTMs.

Wenn ich damit fertig bin kommt das DTM wieder auf 0.00 und dafür die Ebene

mit ihrem Z auf -Meereshöhe.

Dann kann ich die Modifikatoren auch wieder in Meereshöhe eingeben.

📦 Mac Mini M1 16 GB M1  macOS 14 Sonoma PB

🗑️ Mac Pro 6c 24 GB D700  macOS 12.5 Monterey, in Rente ...
📺 PC RYZEN 3950X 64 GB RX6800 16 GB  🐧 Manjaro + OpenSUSE Tumbleweed + ElementaryOS
VW 2023 ARCH US
🇪🇺 Europe

Link zu diesem Kommentar

Ich habe mehrere DTM's in der Datei und arbeite gerade an einem Duplikat.

Deshalb nutze ich die Funktion die nur Modifier der selben Ebene verwendet.

📦 Mac Mini M1 16 GB M1  macOS 14 Sonoma PB

🗑️ Mac Pro 6c 24 GB D700  macOS 12.5 Monterey, in Rente ...
📺 PC RYZEN 3950X 64 GB RX6800 16 GB  🐧 Manjaro + OpenSUSE Tumbleweed + ElementaryOS
VW 2023 ARCH US
🇪🇺 Europe

Link zu diesem Kommentar

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
  • Forenstatistik

    • Themen insgesamt
      23,9Tsd
    • Beiträge insgesamt
      123,2Tsd
×
×
  • Neu erstellen...