wild nyc 311 sample

Overview

Source: /home/coolhand/html/datavis/data_trove/cache/wild/nyc_311_sample.json

Saturn profiled 1,000 rows across 47 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).

unique_key categorical identifier

This column is a unique row identifier: all 1000 values are distinct (n_unique=1000, entropy_ratio=1.0) with no nulls and a top_rate of just 0.001. Sample values like '67519092' are 8-digit numeric strings, consistent with a primary key from a source system. There is no predictive signal here; the long_tail alert simply reflects perfect uniqueness.

Treatment: Drop from modelling; retain only as a join key or row reference.

created_date categorical timestamp

This is a record creation timestamp stored as an ISO-8601 string, with 939 unique values across 1000 rows and no nulls. Entropy ratio of 0.995 confirms it is essentially a per-row timestamp; the most frequent value appears only 9 times (0.9%). All visible top values fall within a narrow window on 2026-01-17 to 2026-01-18, suggesting the sample covers only a short ingestion period rather than a broad history.

Treatment: Parse to datetime and derive features (hour, day, delta) rather than using as a categorical.

agency categorical feature

This is the responding NYC agency code for each record, with 11 distinct values and no nulls. The distribution is severely concentrated: NYPD accounts for 880 of 1000 rows (top_rate 0.88), followed by HPD at 74, leaving the remaining 9 agencies with at most 13 rows each. Entropy ratio of 0.22 confirms the column carries little information beyond 'NYPD vs. not'.

Treatment: Collapse rare agencies into an 'Other' bucket before encoding.

agency_name categorical feature

This column names the NYC agency handling each record, with 11 distinct agencies and no nulls. The distribution is heavily concentrated: the New York City Police Department accounts for 880 of 1000 rows (88%), and entropy ratio is just 0.22, meaning the field carries little information beyond 'NYPD or not'. Secondary agencies like Housing Preservation and Development (74) and Health and Mental Hygiene (13) trail far behind.

Treatment: Collapse rare agencies into an 'Other' bucket or binarize as NYPD vs non-NYPD before modelling.

complaint_type categorical label

This is a categorical complaint-type label, almost certainly from a 311-style service request feed, with 45 distinct categories across 1000 rows and no nulls. The distribution is heavily concentrated: "Noise - Residential" alone accounts for 39.3% of records, and the top three values (all noise or parking complaints) cover roughly 74% of the column. Casing is inconsistent across categories (e.g., "HEAT/HOT WATER" and "UNSANITARY CONDITION" in upper case versus title-cased noise variants), which suggests the source merges multiple agency taxonomies.

Treatment: Normalise casing and group the long tail before one-hot or target encoding.

descriptor categorical feature

Categorical descriptor field enumerating specific complaint subtypes (e.g., 'Loud Music/Party', 'Blocked Hydrant', 'Posted Parking Sign Violation'), likely a secondary classification under a parent complaint type. Distribution is heavily skewed: 'Loud Music/Party' alone covers 42.7% of 1000 rows, and the top 3 values account for the majority, leaving 71 distinct categories with a long thin tail. Note the inconsistent casing ('ENTIRE BUILDING', 'APARTMENT ONLY' vs. title-case entries), suggesting upstream data-entry from multiple systems.

Treatment: Normalize casing, then group rare levels into 'Other' before one-hot or target encoding.

location_type categorical feature

Categorical location descriptor with 20 distinct values and only 1.4% nulls; 'Residential Building/House' dominates at 40.2% followed by 'Street/Sidewalk' at 32.4%. The vocabulary is inconsistent: 'RESIDENTIAL BUILDING' (74), 'Residential Building' (7), and 'Residential Building/House' (396) are clearly the same concept stored three ways, and 'Street' (8) overlaps with 'Street/Sidewalk' (324). Entropy ratio of 0.52 confirms heavy concentration in the top two buckets.

Treatment: Normalize casing and merge synonym variants (e.g., collapse the three 'Residential Building' forms) before encoding.

incident_zip categorical feature

Holds NYC ZIP codes tied to incidents, with 146 distinct values across 1000 rows and only 0.3% missing. Distribution is diffuse — entropy ratio 0.93 and the top ZIP '10011' captures just 4.2% — so no single neighborhood dominates. The top 10 ZIPs span Manhattan, Brooklyn, Queens, and the Bronx, indicating broad five-borough coverage.

Treatment: Treat as categorical; group by borough or target-encode before modelling rather than one-hot across 146 levels.

incident_address categorical metadata

Street addresses for incident locations, with 776 unique values across 1000 rows and only 0.5% nulls. Entropy ratio of 0.97 confirms a long tail — most addresses appear once — but a few hotspots stand out, notably '126 WEST 13 STREET' with 31 occurrences (3.1% of rows), far above the next most frequent. Note inconsistent whitespace formatting (e.g., '60 EAST 93 STREET') suggesting unnormalized input.

Treatment: Normalize whitespace/casing and geocode rather than using raw strings as a feature.

street_name categorical metadata

Street name field, almost certainly a NYC address component given entries like WEST 13 STREET, JAMAICA AVENUE, and BRUCKNER BOULEVARD. Extremely high-cardinality (569 unique across 1000 rows, entropy ratio 0.955) with a long tail and no dominant value — the top entry only covers 3.1% of rows. Watch for inconsistent whitespace (e.g. "EAST 93 STREET" has multiple spaces) which will fragment otherwise-equal values.

Treatment: Normalise whitespace and casing, then either group by borough/zip or drop for modelling — too high-cardinality to one-hot.

cross_street_1 categorical metadata

This column captures the name of one cross street, almost certainly part of a NYC location reference (entries like 'AVENUE OF THE AMERICAS', 'BLEECKER STREET', and 'BROADWAY' are giveaways). Cardinality is extreme: 511 unique values across 1000 rows with entropy ratio 0.95, and the most common street accounts for only 3.8% of rows. 8% of values are null, and the long tail alert means most streets appear only once or twice.

Treatment: Standardize casing and group rare streets into an 'OTHER' bucket before any encoding; do not one-hot raw.

cross_street_2 categorical feature

Free-form NYC street names serving as the second cross street in a location pair, with 504 distinct values across 921 non-null rows and a 7.9% null rate. Distribution is long-tailed and high-entropy (entropy ratio 0.948); the most common value '7 AVENUE' covers only 3.9%, and 'DEAD END' appearing 10 times suggests non-street sentinel values mixed in.

Treatment: Treat as high-cardinality categorical: hash or target-encode rather than one-hot, and normalise sentinels like 'DEAD END' before modelling.

intersection_street_1 categorical metadata

Street-name field, almost certainly the first cross street of an NYC intersection given values like AVENUE OF THE AMERICAS, BROADWAY, and AMSTERDAM AVENUE. Cardinality is extreme: 506 distinct names across 1000 rows with entropy ratio 0.95, and the most frequent value covers only 3.8% of records. Null rate is 8.5%, and the long tail means most names appear only once or twice.

Treatment: Group rare streets into an 'OTHER' bucket or geocode to borough/zone before using as a feature.

intersection_street_2 categorical feature

This is the second street name of an intersection, almost certainly NYC street geography given entries like '7 AVENUE', 'BROADWAY', and 'EAST 171 STREET'. Cardinality is extreme (499 unique values across 1000 rows, entropy ratio 0.95) with no dominant value — the top entry '7 AVENUE' covers only 3.9% and 8.4% of rows are null. Notably, 'DEAD END' appears 10 times as a sentinel rather than a real street, which will distort any join on street name.

Treatment: Treat as high-cardinality location text: normalize sentinels like 'DEAD END' and target-encode or geocode rather than one-hot.

address_type categorical feature

Categorical descriptor of how a location is specified, with four values: ADDRESS, INTERSECTION, BLOCKFACE, and PLACE. The distribution is severely imbalanced — ADDRESS accounts for 97.2% of 1000 rows, leaving only 28 non-ADDRESS records and an entropy ratio of 0.108. Null rate is negligible at 0.2%.

Treatment: Collapse to a binary ADDRESS-vs-other flag or drop, since the minority levels carry little signal.

city categorical feature

This is a NYC-centric city field with 36 distinct uppercase values and a 2.1% null rate. The distribution is dominated by Brooklyn (25.5%), New York, and Bronx, which together account for roughly 70% of the 1000 rows; entropy ratio of 0.63 reflects this concentration on a few boroughs while the long tail covers Queens neighborhoods like Woodhaven, Jamaica, and Astoria. Note the values mix borough names with neighborhood names rather than a consistent geographic level.

Treatment: Group rare neighborhoods into an 'other' bucket and one-hot or target-encode the top categories.

landmark categorical metadata

This column holds NYC street names used as landmark references, with 515 unique values across 895 non-null rows and a 10.5% null rate. The distribution is extremely flat (entropy ratio 0.955) — the most common value, 'WEST 13 STREET', accounts for only 3.5% of records, and a long tail alert is raised. No single landmark dominates, so this behaves more like a high-cardinality location descriptor than a categorical feature.

Treatment: Treat as high-cardinality text; group rare values or geocode rather than one-hot encode.

status categorical feature

This is a ticket/case lifecycle status field with three states: Closed, In Progress, and Open. The distribution is heavily weighted toward Closed (610 of 1000, 61%), with Open being notably rare at just 85 records, suggesting most cases reach resolution. No nulls and clean cardinality of 3 make this a tidy categorical signal.

Treatment: One-hot or ordinal encode (Open < In Progress < Closed) before modelling.

community_board categorical metadata

This column encodes NYC community board identifiers as a numeric prefix plus borough name (e.g., '02 MANHATTAN'), with 65 distinct values across 1000 rows and no nulls. The distribution is fairly flat — entropy ratio is 0.93 and the top value accounts for only 5.6% — suggesting wide geographic coverage rather than concentration in one district. Manhattan and Queens boards dominate the top of the leaderboard, with '02 MANHATTAN' (56) and '09 QUEENS' (48) leading.

Treatment: Split into borough and board-number components, then one-hot or target-encode for modelling.

council_district categorical feature

Categorical codes representing council districts, stored as zero-padded two-digit strings across 51 distinct values with a 0.9% null rate. The distribution is nearly uniform (entropy ratio 0.954), with the top district '03' accounting for only 5.65% of rows, suggesting broad geographic coverage rather than concentration. No single district dominates, which is consistent with a city/region-wide sample.

Treatment: One-hot or target-encode for modelling; impute the small null share with an explicit 'unknown' category.

police_precinct categorical feature

This is a categorical column tagging each record with one of 76 NYPD-style police precincts, with no nulls across 1000 rows. The distribution is remarkably flat — entropy ratio 0.9358 and the modal value 'Precinct 6' covering just 5% — meaning no precinct dominates and counts decay slowly from 50 down to the mid-20s among the top 10.

Treatment: Treat as a high-cardinality categorical: target- or frequency-encode rather than one-hot before modelling.

bbl categorical foreign_key

This is the NYC BBL (Borough-Block-Lot) parcel identifier, stored as a 10-digit string where the leading digit encodes the borough (1-5). Cardinality is very high (719 unique across 945 non-null rows, entropy ratio 0.968), but a long tail is flagged: one parcel '1006080026' accounts for 31 rows (3.3%) and several others recur 5-13 times, so rows are not one-per-parcel. Null rate is 5.5%.

Treatment: Treat as a parcel key for left-joining to PLUTO/property tables; do not one-hot encode.

borough categorical feature

This column lists one of the five NYC boroughs for each of the 1000 rows, with no nulls and only 5 unique values. The distribution is fairly even across QUEENS (274), MANHATTAN (258), BROOKLYN (254), and BRONX (203), but STATEN ISLAND is sharply underrepresented at just 11 rows. High entropy ratio (0.886) confirms the top four categories are well balanced.

Treatment: One-hot encode; consider grouping or monitoring STATEN ISLAND given its low support.

x_coordinate_state_plane categorical feature

This column holds X-coordinates in a state plane projection, stored as strings rather than numbers. With 763 unique values across 993 non-null rows and entropy ratio 0.97, it is near-unique; the most frequent value '984721' appears only 31 times (3.1%). The long_tail alert is consistent with a near-continuous spatial measurement that has been categorically encoded.

Treatment: Cast to numeric and pair with the Y-coordinate as a 2D spatial feature.

y_coordinate_state_plane categorical feature

Column holds State Plane y-coordinates (northings) stored as strings rather than numerics, with 768 unique values across 1000 rows and a 0.7% null rate. Entropy ratio of 0.97 and a top_rate of just 3.1% confirm a near-uniform long tail typical of geographic coordinates, though the modal value '207809' repeating 31 times suggests a default or geocoder fallback location worth investigating.

Treatment: Cast to numeric and treat as a continuous spatial coordinate; inspect the repeated 207809 value for geocoding artifacts.

open_data_channel_type categorical feature

Categorical channel indicating how a record was opened, with 4 distinct values and no nulls across 1000 rows. ONLINE leads at 466, followed by MOBILE (288) and PHONE (236), while UNKNOWN appears only 10 times. Distribution is fairly balanced (entropy ratio 0.79) with no dominant single class beyond 46.6%.

Treatment: one-hot encode; consider folding UNKNOWN into a missing/other bucket.

park_facility_name categorical metadata

This column nominally records a park facility name but is effectively a constant: 999 of 1000 rows are "Unspecified" and only one row names "Flushing Meadows Corona Park". Entropy ratio is 0.011, confirming there is virtually no information content here. The column adds no discriminative signal as-is.

Treatment: Drop; single dominant value carries no signal.

park_borough categorical feature

Categorical column listing the NYC borough associated with a park, with all five boroughs present and no nulls across 1000 rows. Distribution is fairly balanced (entropy ratio 0.8858) among Queens (274), Manhattan (258), Brooklyn (254), and Bronx (203), but Staten Island is severely under-represented at just 11 records.

Treatment: One-hot encode; consider grouping or stratifying given the Staten Island sparsity.

latitude categorical feature

Latitude values stored as strings, with 770 unique points across 1000 rows clustered around 40.6-40.8 (NYC range). Entropy ratio of 0.97 and top_rate of just 0.031 confirm a long tail of near-unique coordinates, though the modal value 40.73706433046593 repeating 31 times suggests some snapped or default-pinned locations. Null rate is low at 0.7%.

Treatment: cast to float and pair with longitude for geospatial features rather than treating as categorical.

longitude categorical feature

Geographic longitude coordinates, almost certainly NYC-area given the -73.8 to -74.0 range. The column was profiled as categorical despite being continuous numeric: 770 unique values across 1000 rows with entropy ratio 0.97 and a top value repeating only 31 times (3.1%). Null rate is low at 0.7%.

Treatment: Cast to float and pair with latitude as a geospatial feature rather than treating as categorical.

location unknown other

The column is named "location" but saturn skipped profiling, so no type, cardinality, or value statistics are available. The only confirmed facts are 1000 rows with a 0.0 null rate; uniqueness and content remain unknown.

Treatment: Re-profile or manually inspect before use; saturn skipped this column.

:@computed_region_f5dn_yrer categorical metadata

This is a Socrata-style computed region column (`:@computed_region_f5dn_yrer`), almost certainly a numeric region/zone code attached automatically by a spatial join. It has 62 unique values across 1000 rows with a near-uniform spread (entropy ratio 0.94, top value '57' at only 5.6%) and a 0.7% null rate. No single region dominates, suggesting the underlying records are well-distributed across the joined geography.

Treatment: Treat as a categorical region code; one-hot or target-encode if used as a feature, otherwise drop as join artifact.

:@computed_region_yeji_bk3q categorical metadata

This is a Socrata-style computed region column (`:@computed_region_yeji_bk3q`), almost certainly a spatial-join lookup mapping each row to one of 5 region codes. The distribution is fairly balanced across codes 2-5 (193-269 each) but code 1 appears only 11 times, and 0.7% of rows are null. Entropy ratio 0.88 confirms near-uniform spread except for the sparse '1' bucket.

Treatment: Treat as a categorical region key; one-hot encode or drop if the spatial join isn't relevant.

:@computed_region_sbqj_enih categorical foreign_key

This is a Socrata-style computed region column (`:@computed_region_sbqj_enih`), holding a small integer code that geocodes each row into one of 75 regions. The distribution is nearly uniform across categories — entropy ratio is 0.94 and the top value '3' covers only 5.0% of rows — so no single region dominates. Nulls are negligible at 0.7%.

Treatment: Treat as a categorical region id; left-join to the corresponding Socrata boundary lookup or one-hot encode for modelling.

:@computed_region_92fq_4b7q categorical foreign_key

This is a Socrata-style computed region column (`:@computed_region_92fq_4b7q`) holding 51 distinct integer codes, almost certainly a spatial join key (e.g., a precinct, district, or zone id) appended by the platform. Distribution is fairly flat — entropy ratio 0.9477 and the top value '10' covers only 6.4% of rows — with very few nulls (0.7%). No single region dominates, suggesting broad geographic coverage rather than a hot spot.

Treatment: Treat as a categorical region id; left-join to the region lookup or one-hot encode if used as a feature.

descriptor_2 categorical feature

Secondary complaint descriptor that further qualifies a primary complaint type, with values like 'NO HEAT', 'NO HEAT AND NO HOT WATER', and 'ROACHES'. It is null 88.2% of the time, so only 118 rows carry a value, and among those 'NO HEAT' alone covers 27.97%. Cardinality is 43 with entropy ratio 0.807, indicating a long tail across the populated rows and a mix of casing conventions ('ROACHES' vs 'Cannabis Smoking or Vaping') that suggests inconsistent upstream sources.

Treatment: Normalize casing and treat missing as its own category before one-hot or target encoding.

resolution_description categorical label

This is the canned 311 resolution narrative attached to each complaint, describing the agency's disposition (NYPD found no violation, summons issued, HPD inspection pending, etc.). Cardinality is just 16 templates over 1000 rows, with the top NYPD 'no criminal violation' boilerplate covering 35.4% and 30.7% of rows null — likely complaints still open. Entropy ratio of 0.69 shows the distribution is skewed toward a few NYPD templates, with DOT and HPD templates appearing only in the long tail.

Treatment: Map the 16 templates to a categorical disposition code (e.g., 'no_violation', 'summons_issued', 'no_entry', 'pending') rather than treating as free text.

resolution_action_updated_date categorical timestamp

ISO-8601 timestamps recording when a resolution action was last updated, stored as strings rather than a native datetime. 30.6% of rows are null, and a single midnight value '2026-01-17T00:00:00.000' accounts for 74 of the non-null entries (top_rate 10.66%) while the remaining values are millisecond-precise and nearly all unique (585 distinct over 694 non-null, entropy_ratio 0.94). The mix of one date-only spike with otherwise sub-second timestamps suggests two ingestion paths or a backfill default colliding with live event logging.

Treatment: Parse to datetime, treat the 2026-01-17 midnight spike as a sentinel/backfill, and derive recency or duration features rather than using raw values.

closed_date categorical timestamp

This is a closure timestamp captured at second-level precision, stored as strings rather than parsed datetimes. 39% of rows are null, consistent with records that have not yet been closed, and among the 610 populated rows there are 585 unique values with the most common appearing only 3 times (top_rate 0.0049, entropy_ratio 0.998). All visible top values cluster on 2026-01-18, suggesting the populated closures concentrate in a narrow window.

Treatment: Parse to datetime, treat nulls as 'still open', and derive duration features rather than using raw values.

taxi_pick_up_location categorical free_text

Free-text taxi pickup addresses (street, borough, state, ZIP) for NYC trips. The column is almost entirely empty at a 99.4% null rate, leaving only 6 non-null rows that are all unique, so cardinality equals the populated count and entropy is maximal (entropy_ratio 1.0). With so little signal, this column carries effectively no analytical value as-is.

Treatment: Drop the column or geocode the rare populated addresses if pickup location is needed.

vehicle_type categorical feature

Categorical vehicle classification with just 4 levels (Car, Other, SUV, Van), but it is almost entirely missing — 96.5% null, leaving only 35 populated rows out of 1000. Among those present, Car dominates at 77.1%, giving an entropy ratio of 0.55. With so few observations, the distribution is unreliable as a feature.

Treatment: Drop or treat missingness as its own category; too sparse to model directly.

facility_type categorical metadata

This column is a categorical facility_type field that is effectively empty: 99% of the 1000 rows are null, and the only 10 non-null values are all the placeholder 'N/A'. With cardinality of 1 and entropy of 0, it carries no information.

Treatment: Drop the column; it is 99% null with a single placeholder value.

taxi_company_borough categorical metadata

Categorical column intended to record the borough of a taxi company, but it is effectively empty: 99.9% of rows are null and the single non-null value is 'BROOKLYN'. With cardinality 1 and entropy 0, the column carries no information as-is.

Treatment: Drop; near-entirely null with only one observed level.

bridge_highway_name categorical metadata

A categorical field flagging bridge or highway names, but it's effectively empty: 99.7% null with only 3 non-null records across 1000 rows. The two distinct values observed ('E' and 'Kosciuszko Br - BQE') are inconsistent in form, suggesting either a free-text field or an abbreviation code mixed with full names.

Treatment: Drop; null rate of 99.7% leaves no usable signal.

bridge_highway_direction categorical metadata

This is a near-empty categorical field describing bridge or highway direction, with a 99.7% null rate leaving only 3 non-null observations across 2 distinct values ('C E Local Downtown & Brooklyn' and 'Queens Bound'). The values resemble transit route/direction labels rather than simple compass directions, suggesting inconsistent coding. With only 3 populated rows out of 1000, no reliable distribution can be inferred.

Treatment: Drop; null rate of 0.997 leaves too little signal to use.

road_ramp categorical metadata

This column is a binary-style flag indicating whether a road segment is a ramp, but it carries virtually no information here. With a null_rate of 0.999 and only 1 non-null value ("Ramp") across 1000 rows, cardinality is 1 and entropy is 0.

Treatment: Drop; effectively constant with 99.9% nulls.

bridge_highway_segment categorical metadata

A categorical flag describing a bridge/highway segment type, with only two observed values ('Platform' and 'Ramp'). It is almost entirely missing — 99.7% null, leaving just 3 non-null rows out of 1000 — so the apparent top_rate of 0.667 reflects 2 observations and is not meaningful.

Treatment: Drop or treat as a rare-event indicator; too sparse (3/1000 populated) to model directly.