Workshop 1 – Skalenniveaus Melbourne Housing Dataset

Klassifikation der Variablen

#	Spalte	Dtype	Skalenniveau	Bemerkung
0	Unnamed: 0	int64	nominal	CSV-Index, reine ID – für ML droppen
1	Suburb	object	nominal	hohe Kardinalität, Encoding-Strategie nötig
2	Address	object	nominal	Kardinalität ≈ n, für ML ungeeignet
3	Rooms	int64	metrisch	Zähldaten, Ratio-Skala
4	Type	object	nominal	h/u/t – wenige Kategorien, One-Hot
5	Price	float64	metrisch	Ratio-Skala, typische Zielvariable
6	Method	object	nominal	Verkaufsmethode
7	SellerG	object	nominal	hohe Kardinalität
8	Date	object	metrisch	formal Intervall, dtype sollte datetime sein
9	Distance	float64	metrisch	Distanz zum CBD, Ratio
10	Postcode	float64	nominal	trotz numerisch – keine sinnvolle Ordnung
11	Bedroom2	float64	metrisch	Zähldaten, alternative Quelle zu Rooms
12	Bathroom	float64	metrisch	Zähldaten
13	Car	float64	metrisch	Anzahl Parkplätze
14	Landsize	float64	metrisch	Ratio-Skala
15	BuildingArea	float64	metrisch	Ratio-Skala
16	YearBuilt	float64	metrisch	formal Intervall
17	CouncilArea	object	nominal	Verwaltungsbezirk
18	Lattitude	float64	metrisch	formal Intervall, mit Longitude als Paar behandeln
19	Longtitude	float64	metrisch	formal Intervall, mit Latitude als Paar behandeln
20	Regionname	object	nominal	wenige Kategorien
21	Propertycount	float64	metrisch	Anzahl Properties im Suburb

Date und YearBuilt sind formal Intervallskala (kein echter Nullpunkt), werden hier aber zu metrisch zusammengefasst, da die Klasse Intervall/Ratio nicht weiter unterscheidet.
Postcode ist trotz float64-dtype nominal – Postleitzahlen haben keine sinnvolle Ordnung. Float entsteht durch Missing Values.
Geokoordinaten passen streng genommen nicht ins Stevens-Schema (zyklisch, nicht-euklidisch), werden pragmatisch als metrisch geführt.
Address und SellerG haben sehr hohe Kardinalität → Kandidaten für die Liste ungeeigneter Variablen in Workshop 2.

Konsistenz-Check beim Workshop 2 ergänzen.