Closed Nullmann closed 8 years ago
Ich bevorzuge die Version von Linh, da es schwer sein wird, ein Gebäude von 0,003 Höhe oder Fläche auszuwählen. Und in der Legende sieht man ja dann, dass die Fläche bzw diese Daten der Dimension 290mal größer sind. Unter 1 sollte es nicht skaliert werden meiner Meinung nach
Bei dem Datensatz "100.000 Länderdaten" ist der Unterschied sehr gut erkennbar. Wenn man den BIP als Fläche angibt und eine der beiden Prozentzahlen als Höhe, dann sieht das bei Linh so aus:
Während meine Variante so aussieht:
Im Vergleich zu einem BIP von 8509030 und ähnlichen Größen ist eine Prozentzahl, die sich im Bereich von 0 bis 100 erstreckt natürlich sehr gering, wodurch solche flachen Gebäude entstehen.
Weiß nicht, ob ich das Problem ganz verstanden habe.
Es klingt für mich komisch, alles durch die Fläche zu teilen. Werden da nicht Äpfel mit Birnen verglichen? Also Werte zur Normierung verwendet, die eigentlich nichts mit dem zu betrachtenden Wert zu tun haben? Würde ja auch nicht das Alter einer Person mit der durchschnittlichen Größe normieren? Oder werfe ich da etwas durcheinander?
Vielleicht kann @thuylinhluu nochmal argumentieren?
(Allerdings: Die Variante von @thuylinhluu sieht im gewählten Beispiel besser aus. Das untere kann man nicht mehr als Stadt verkaufen...)
Man muss auf jeden Fall die Dimension Fläche durch den Durchschnitt teilen, damit das Flackern aufhört.
Alle anderen Dimensionen zu teilen ist optional und wird eigentlich gar nicht benötigt. Aber da wir schon die Fläche durch etwas teilen, sollte die Höhe vielleicht auch durch etwas geteilt werden, um keine Verwirrung zu stiften.
=> Wir teilen auf jeden Fall durch irgendeinen Durchschnitt
Ich halte es für sinnvoll, die Höhe durch den Durchschnittswert der Höhe zu teilen und die Breite durch den Durchschnittswert der Breite.
Ich halte es nicht für sinnvoll, die Höhe durch den Durchschnittswert der Breite zu teilen. Denn bspw. Man hat als Höhe ein Boolean, also 0 oder 1, oder Prozentzahlen (zwischen 0 und 1). Als Fläche hat man meinetwegen den BIP in der Größenordnung von Mio. Dann werden alle Gebäude auf die Höhe 0 runtergebrochen und die Höhe ist nicht mehr zu unterscheiden und wird entsprechend nicht mehr dargestelllt.
Das Argument für das Teilen der Höhe durch die Durchschnittsbreite war soweit ich weiß, dass die Darstellung nicht verzerrt werden soll und alles "auf den gleichen Nenner gebracht werden soll". Das sehe ich so allerdings nicht, denn nach oberen Beispiel wird es verzerrt und zum anderen: Wenn die Werte für die Höhe denn so zusammengesetzt ist, dass es sinnvoll wäre, durch den Durchschnittswert der Breite zu teilen, um mit der Skalierung der Breite gleich zu kommen, dann würde sich das hoffentlich auch im Durchschnittswert der Höhe widerspiegeln, sodass man auch durch den Durchschnittswert der Höhe teilen kann.
Nach weiterer Überlegung: Linhs Version ist die Bessere. Das Hauptziel des Programmes ist es die Gebäude untereinander zu vergleichen. In meiner Version ist es wie oben in dem Beispiel gezeigt nur möglich die Fläche von zwei Gebäuden zu vergleichen. Ob nun ein Land 1% vom BIP ins Militärtbudget steckt oder 99% kann man mit meiner Ansicht überhaupt nicht erkennen. Die Werte in der Höhe sind dann zwar theoretisch 99 mal größer als die anderen Werte, aber bei diesen Größenverhältnissen ist das nunmal nicht zu erkennen und zu vergleichen, weshalb ich die Vergleichbarkeit zwischen den Gebäuden den Relationen zwischen der Höhe und Fläche vorziehe. Linhs Version ist bereits gepusht und wird mit der nächsten dist ausgeliefert. Schließe den Issue.
Linh und ich hatten die Diskussion, dass wir jeweils eine andere Arten der Skalierung bevorzugen.
Als Grundlage der Erklärung möchte ich das an dem Beispiel des SG57-Datensatzes durchexerzieren, hier ein Screenshot der Daten:
Linhs Version, wie im Commit 2a899ba0a93efc320dad1d279d7fba9549181b29 gepusht und nun über localhost verfügbar, teilt alle Dimensionen durch den jeweiligen Durchschnitt. D.h. alle Werte der Dimension "PGMDEPTH" werden durch den Durchschnitt von 5,983, alle Werte von "MCCABE" werden durch 303,593 und alle Werte von "TOTALVERB" durch 1740,802 geteilt. Dadurch verändert sich die Stadt in der Darstellung.
In meiner Version, wie es momentan in der Dist der Fall ist, werden alle Werte, gleich der Dimension, durch den Durchschnitt der Fläche (die im 5. Schritt ausgewählt wird), geteilt.
Nehmen wir einen Datensatz mit den Daten (6/303/1740), die Höhe ist 6 (PGMDEPTH) und die Breite ist 1740 (TOTALVERB). In Linhs Darstellung wird daraus (nahezu, weil gerundet) ein Würfel mit Länge-Höhe von 1-1 (Länge=Breite). Das finde ich verwirrend und komisch, weil es so aussieht, als ob alle Dimensionen der gleichen Größenordnung angehören. In meiner Darstellung würde daraus 6/1740-1740/1740 = 0,0034482 - 1, die Breite (Länge) ist also 290 mal größer als die Höhe, wie es auch der Datensatz hergibt. Dadurch wäre das Gebäude sehr sehr flach, aber informationsgerecht.
Zu erwähnen ist, dass in beiden Darstellungsvarianten die Verhältnisse zwischen den Gebäuden konstant bleiben. Wenn ein Datensatz in der Höhe 5 mal größer ist als ein anderer Datensatz, dann wird das auch genau so bei beiden Arten wiedergespiegelt. Hier geht es lediglich um die Relation zwischen der Höhe und der Fläche innerhalb eines Datensatzes (aber natürliche für jeden Datensatz / für jedes Gebäude seperat).
Ihr könnt die verschiedenen Versionen in der dist (meine Variante) und über den localhost (linhs Variante) ausprobieren.