data trove large meteorites 10kg

Overview

Source: /home/coolhand/html/datavis/data_trove/data/wild/nasa_meteorites.csv

Saturn profiled 45,716 rows across 20 columns. The stats below are deterministic and machine-readable; the prose is a language-model interpretation of those stats (opt-in, added after the fact, never sees raw rows).

sid text identifier

This column is a Socrata-style row identifier, recognizable from the 'row-XXXX.XXXX-XXXX' format visible in all sampled values. Every value is exactly 18 characters long (len_min = len_max = len_mean = 18.0), and all 45,716 rows are unique with a duplicate_rate of 0.0 and null_rate of 0.0 — a perfect surrogate key. No surprises in the data; it is entirely consistent with an auto-generated system identifier from a Socrata open-data platform.

Treatment: Drop before modelling; retain only if row-level traceability back to the source platform is needed.

id text identifier

This column contains UUIDs (universally unique identifiers) serving as a primary key, with all 45,716 values being exactly 36 characters long and fully unique — zero duplicates, zero nulls. Notably, all sampled top values share the prefix '00000000-0000-0000-', suggesting the UUID version/variant fields are zeroed out, which is atypical of standard UUID v4 generation and may indicate a custom or synthetic ID scheme. The allcaps_rate of 1.0 is consistent with hex characters but worth noting if downstream systems are case-sensitive.

Treatment: Use as primary key for joins; do not encode or transform for modelling — drop or pass through as-is.

position numeric other

This column, named 'position', is a numeric field that is entirely constant — every one of its 45,716 non-null values is exactly 0.0 (zero_rate = 1.0, n_unique = 1). It carries zero information and would contribute nothing to any model or analysis. This is flagged as a constant alert, confirming it is safe to drop.

Treatment: Drop immediately; constant value across all 45,716 rows provides no signal.

created_at numeric timestamp

This column is a Unix timestamp named 'created_at', but every single one of its 45,716 non-null rows holds the identical value 1446143734 (approximately 2015-10-29 UTC), triggering a 'constant' alert. With n_unique of 1, std of 0.0, and IQR of 0.0, the column carries zero information variance — strongly suggesting a bulk-load default, a data pipeline bug, or a one-time snapshot import where timestamps were not properly captured. This is a critical data quality issue that renders the column useless as a temporal signal.

Treatment: Drop or flag as corrupted; investigate ETL pipeline for the source of the constant value before using as a temporal feature.

created_meta unknown metadata

The column 'created_meta' is likely a creation timestamp or metadata field associated with record provenance, but saturn classified it as 'unknown' kind and skipped all profiling, yielding zero stats and no uniqueness count. With 45,716 rows, zero nulls, and no further signal available, its actual dtype, distribution, and content cannot be assessed from this evidence alone.

Treatment: Inspect raw values to determine dtype (timestamp, JSON blob, string) before deciding on parsing, dropping, or feature extraction.

updated_at numeric timestamp

This column is a Unix epoch timestamp named `updated_at`, representing a last-modified datetime for each row. Every single one of the 45,716 non-null records holds the identical value 1446143734 (approximately 2015-10-29 UTC), meaning the column is a constant — it carries zero information variance. This strongly suggests a bulk data load or migration event where all rows were stamped with the same timestamp rather than tracking real update times.

Treatment: Drop from modelling; flag to data owner as a likely ETL artefact — all 45,716 rows share the single value 1446143734.

updated_meta unknown other

The column 'updated_meta' was skipped by the profiler, yielding no stats, no uniqueness count, and no type resolution beyond 'unknown'. With 45,716 non-null rows and a null rate of 0.0, the column is fully populated, but its content, structure, and distribution are entirely opaque from the available evidence. The name suggests it may hold metadata update timestamps or serialized metadata objects (e.g., JSON blobs), but nothing in the evidence confirms this.

Treatment: Manually inspect raw values to determine type (timestamp, JSON, free text); re-profile after parsing or casting appropriately.

meta categorical metadata

This column is a metadata field that contains exclusively the empty object literal '{ }' across all 45,716 rows, with zero nulls and a cardinality of 1. It carries no information whatsoever — entropy is 0.0 and top_rate is 1.0, meaning every single record is identical. This is almost certainly an unfilled placeholder or a defaulted JSON field that was never populated.

Treatment: Drop before modelling; zero-variance column with no predictive or descriptive value.

name text label

This column contains proper names of geographic features — the top words ('range', 'hills', 'mountains', 'northwest', 'africa', 'grove', 'yamato', 'Queen Alexandra') are all typical components of named landforms or place names. Every one of the 45,716 rows has a distinct value (duplicate_rate 0.0, n_unique = 45,716) with zero nulls, making it a perfect natural identifier. The mean word count of 2.77 and median of 3.0 confirm multi-token names rather than single labels, while 'yamato' appearing 3,317 times as the top individual word suggests a large Antarctic or Japanese geographic sub-corpus driving partial lexical repetition even though full names are unique.

Treatment: Use as a display label or natural key; tokenize on whitespace for gazetteer/NLP tasks, but drop before any ML feature matrix.

id_1 numeric identifier

This column is almost certainly a row or entity identifier: it has 45,716 unique values across 45,716 rows with zero nulls and zero duplicates, indicating a perfect 1-to-1 mapping. Values run from 1 to 57,458, suggesting either a sparse sequential ID (gaps exist since max > n) or a pre-filtered subset of a larger table. The near-uniform distribution (kurtosis −1.16, skew 0.27, zero outliers) is consistent with a sequential or pseudo-random integer key rather than a meaningful numeric feature.

Treatment: Retain as a join/lookup key; exclude from any modelling feature set.

nametype categorical label

This column is a meteorite name-type classification flag, distinguishing between currently valid meteorite names ('Valid') and relict/superseded ones ('Relict'). The distribution is extremely imbalanced: 45,641 of 45,716 records (99.84%) are 'Valid', with only 75 'Relict' entries. The near-zero entropy (0.018) confirms this column carries almost no information variance, which triggered the imbalance alert.

Treatment: Exclude from predictive features due to near-zero variance; retain only as a filter to subset valid records if analysis should exclude relict entries.

recclass categorical label

This column contains meteorite classification codes, identifying the mineralogical and petrologic type of each recovered meteorite specimen. The top 7 values (L6, H5, L5, H6, H4, LL5, LL6) are all ordinary chondrite classes and together account for the vast majority of records, with L6 alone representing 18.1% of the 45,716 rows. Despite 466 unique classes, the entropy ratio of 0.51 indicates moderate concentration — the long tail of rare classes (e.g., CM2 with only 416 occurrences) will create sparse dummy variables if one-hot encoded naively.

Treatment: Group rare classes (below a frequency threshold) into an 'Other' bucket before encoding, or use target/frequency encoding to handle the 466-cardinality tail.

mass (g) numeric feature

This column records the physical mass of objects in grams, almost certainly meteorite or asteroid specimen weights given the scale and distribution. The median is just 32.6 g while the mean explodes to 13,278 g and the maximum reaches 60,000,000 g (60 tonnes), indicating a tiny fraction of massive outliers dragging the distribution — skew of 76.9 and kurtosis of 6,796 confirm an extreme long tail. Fully 15.5% of rows (7,086) are flagged as outliers, meaning the bulk of specimens are small rocks while a handful of giants dominate the aggregate statistics.

Treatment: log-transform (log1p) before modelling to compress the extreme right tail; consider capping or flagging the ~7,086 outliers separately.

fall categorical label

This column captures whether a meteorite was discovered on the ground ('Found') versus observed falling ('Fell'), making it a binary classification label for meteorite recovery type. The distribution is severely imbalanced: 'Found' accounts for 97.6% of 45,716 records (44,609), while 'Fell' represents only 2.4% (1,107). The entropy ratio of 0.164 confirms near-minimum uncertainty, flagged explicitly as an imbalance alert. Any model using this as a target will require class-balancing techniques.

Treatment: Apply class-balancing (e.g., SMOTE or class weights) before using as a classification target.

year categorical timestamp

This column represents a calendar year, stored as full ISO-8601 timestamps normalised to January 1st of each year (e.g. '2003-01-01T00:00:00'), confirming the time component carries no information. Despite being profiled as categorical, it is effectively an annual time dimension spanning at least the range visible in the top values (1979–2006). Surprising: cardinality is 266 distinct values against only ~45 years visible in top values, suggesting either a much wider date range or some malformed/unexpected entries worth inspecting. The top year (2003) accounts for just 7.3% of rows, indicating a reasonably spread distribution rather than heavy concentration.

Treatment: Parse to date/integer year, investigate the 266 distinct values vs expected ~45-year span for anomalies, then use as a time feature or group-by dimension.

reclat numeric feature

This column represents the recorded latitude of meteorite find/fall locations, with values ranging from -87.37° to +81.17° consistent with geographic latitude bounds. Surprising signals: the median of -71.5° indicates the majority of records are concentrated in high southern latitudes (likely Antarctic recovery sites), yet the Q3 is exactly 0.0°, suggesting a notable cluster at the equator or a placeholder zero — reinforced by a zero_rate of 16.8% that almost exactly matches the null_rate of 16%, implying zeros may be encoding missing coordinates rather than true equatorial finds. Kurtosis of -1.48 confirms a flat, bimodal-like distribution rather than a normal one.

Treatment: Treat zero values as missing (mask alongside existing nulls before modelling); use as-is for geospatial analysis or pair with longitude for coordinate-based features.

reclong numeric feature

This column represents the recorded longitude of meteorite landing or find locations, covering a range from -165.43° to 354.47°. The maximum value of 354.47 is surprising — valid WGS84 longitude should cap at 180°, suggesting some records use a 0–360° convention rather than the standard -180 to 180° range, which will cause mapping errors if not normalised. The zero_rate of ~16% mirrors the null_rate of 16%, strongly implying that zero-filled values are placeholder/missing entries rather than genuine equatorial coordinates at the prime meridian. Distribution is near-symmetric (skew -0.17, kurtosis -0.73) with a large IQR of 157.17, consistent with a globally spread geographic variable.

Treatment: Normalise values > 180 to the -180–180 range (subtract 360), then treat zero values matching the null_rate as missing and impute or exclude before spatial analysis.

GeoLocation text feature

GeoLocation stores geographic coordinates as serialized Python list strings in the format [None, '', '', None, False], representing what appears to be a structured geo-point object flattened to text. The most common value — '[None, '0.0', '0.0', None, False]' appearing 6,214 times — is almost certainly a null/unknown sentinel rather than a genuine equatorial location, masking true missingness beyond the 16% null rate. Duplicate rate is high at 55.5% (21,301 duplicates across 17,100 unique values), consistent with many records sharing the same geographic coordinates. The column should be parsed to extract numeric longitude and latitude fields rather than used as raw text.

Treatment: Parse the serialized list string to extract longitude (index 1) and latitude (index 2) as separate numeric columns, treating '0.0', '0.0' as missing.

States numeric

Counties numeric