Neues Tabellenrätsel

[Phrodus]

Hallo,

ich bin gerade auf ein seltsames Phänomen gestossen:

Wenn ich in einer Tabelle die Funktion '=Fläche' verwende, wird die Fläche mit 0 angezeigt, wenn es sich um eine Polylinie handelt, die nicht geschlossen ist.

Sobald ich die Polylinie schließe, wird die Fläche korrekt angezeigt.

 

In der Objekt Infopalette wird die Fläche korrekt angezeigt, egal, ob die Polylinie offen oder geschlossen ist.

 

Hat jemand eine Erklärung für das Phänmomen?

 

Danke für Hinweise

Phrodus

 

[Phrodus]

Es ist wirklich sehr seltsam:

In dieser einen Datei wird die Fläche von Polylinien mit 0 ausgegeben, wenn sie 'nicht geschlossen' sind. In anderen Dateien ist das nicht der Fall.

 

Wie ist das bei Euch? Möchte das mal jemand testen?

Anbei meine Testdatei (VW 2022), bei der offene Polylinien in der Tabelle mit einer Fläche von 0 ausgegeben werden.

 

Test 2.vwx

[KroVex]

Salü Phrodus

 

Ich kenne diese "Problematik" und kommt, so viel ich weiss davon, wie die Geometrie berechnet wird. Es fehlt quasi ein Teil, um die Rechnung vollständig durchzuführen. Genauer kann ich es leider nicht erklären, hatte einen Fensterplatz im Matheunterricht 
Auch wenn in der Info-Palette eine Flächenangaben bei offenen Geometrien abgebildet ist, kannst du nicht davon ausgehen dass sie auch stimmen:


Es gibt auch noch weitere Eigenheiten, die eine korrekte Berechnung stören können, wie z.B. mehrere Polypunkte aufeinander oder Schlaufen in der Polylinie. Wenn die Flächenangabe relevant ist, so ist penibel darauf zu achten, dass es eine saubere und geschlossene Geometrie ist. 

Gruss KroVex

[Phrodus]

 

Danke sehr KroVex - auch wenn das sehr erschreckend ist.

Ich finde, dass Flächenangaben fast immer relevant sind. Ich hoffe, dass die Entwickler dafür eine Lösung finden.

 

Im konkreten Fall muss es aber noch ein anderes mysteriöses Problem geben:

In der Datei 'Test2' die ich dem Beitrag oben angehängt habe, wird die Fläche von jeder neu angelegten Polylinie mit 0 angegeben, wenn man die Checkbox 'Schließen' deaktiviert.

 

Zum Vergleich habe ich eine andere neue Datei erzeugt namens 'Vergleichstest' (hier angehängt zusammen mit der Datei von oben 'Test2').

Hier werden die Flächen in der Tabelle IMMER korrekt angegeben. Egal ob die Checkbox 'Schließen' aktiviert ist oder nicht.

 

Mir ist es wirklich ein völliges Rätsel, wo der Unterschied der beiden Dateien ist.

 

Hat jemand eine Idee?

Phrodus

Vergleichstest.vwx Test 2.vwx

[Marc Wittwer]

Hallo Phrodus

 

Der Nullpunkt hat wieder mal zugeschlagen

 

Gruss, Marc

[Phrodus]

vor 4 Stunden schrieb Marc Wittwer:

Hallo Phrodus

 

Der Nullpunkt hat wieder mal zugeschlagen

 

Gruss, Marc

Wow - der Nullpunkt ist ja echt mächtig. War mir nicht aufgefallen, weil der Benutzernullpunkt verschoben war.

Aber nicht absichtlich - das ist offenbar beim Importieren des ursprünglichen DWGs passiert.

 

Eine Frage: wie bringe ich das denn am einfachsten in Ordnung?

Denn... die Beispieldatei ist der 'Abkömmling' einer großen Datei mit vielen Layouts und Konstruktionsebenen....

 

Ich kann auf den Nullpunkt der Lineale klicken und den Benutzernullpunkt zurücksetzen.

Dann könnte ich alles Klassen und alle Ebenen sichtbar und bearbeitbar machen und alles in Richtung Null verschieben.

 

Das Problem: wahrscheinlich zerstört das alle Ansichtsbereiche in den Layoutebenen?

 

Gibt's da einen hilfreichen Workflow?

Bearbeitet 20. März 2022 von Phrodus

[Marc Wittwer]

Hallo Phrodus

 

https://vectorworks-hilfe.computerworks.eu/2022/Vectorworks-Hilfe/Dokument_einrichten/Zeichnung_zum_Vectorworks-Nullpunkt_verschieben.htm?rhhlterm=zeichnung zum nullpunkt nullpunkte&rhsearch=Zeichnung zum nullpunkt

 

Gruss, Marc

[Phrodus]

Fantastisch. Danke sehr!

[zoom]

2 Fragen ....

 

1. Würde das per Georeferenzierenwerkzeug auch gehen oder sind die Ansichtsbereiche dann kaputt ?

 

2. @herbieherb hat mal gesagt dass durch die Entfernung die Koordinaten schon kaputt sind bzw.

in dem Format mit schlechter Genauigkeit und ggf. erhöhtem Speicherbedarf beibehalten werden.

(wegen floating point und so ?)

Gibt es da etwas zu beachten oder eine Lösung ?

(Ich glaube in leere Datei kopieren war die Notlösung ?)

[herbieherb]

Bei einer Georeferenzierung verortest du ja nur den Nullpunkt. D.h. du sagst wo und in welchem Winkel der Nullpunkt auf einem bestimmten Bezugssystem liegt. Ein georeferenziertes File hat also nur ein paar zusätzliche Angaben zur Verortung und ansonsten arbeitet man ganz normal am Nullpunkt.

 

Der Speicherbedarf ist für Fliesskommazahlen eines bestimmten Typs immer gleich. In Vectorworks 32bit für die Anzeige (zumindest zu OpenGL-Zeiten) und 64bit für Berechnungen. Wenn man also weiter weg vom Nullpunkt zeichnet, büsst man Genauigkeit ein, weil die Zahl generell immer gleich viel Speicherplatz einnimmt. Wenn der Hersteller wollte, könnte man mit höherer Genauigkeit rechnen, man bräuchte aber mehr Speicherplatz und vor Allem längere Berechnungszeiten.

 

Die weit weg gezeichneten Objekte verhalten sich ganz normal, wenn man sie man zurückgeschoben hat. Sie hatten nur bei der Erstellung ein paar Kommastellen weniger zur Verfügung, können die aber wieder benutzen, sobald sie zurück in die Nähe des Nullpunkt verschoben werden.

 

Dann sollten also auch alle Glitches verschwinden. Bei den Grafikglitches brauchts manchmal noch ein Neustart von Vectorworks um den Grafikspeicher zu leeren.

 

Die ganze Diskussion mit dem Zahlenraum betrifft den User selbst nur wegen den technischen Glitchtes. Um die Genauigkeit muss man sich wenig Sorgen machen. Man kann ein Objekt gut einmal durch die Galaxie und zurück schieben, ohne dass es eine Kommastelle verliert. (Vectorworks zeigt uns ja maximal 12 Kommastellen.)