Watchline NYC — Discovery · Ramon Escobar Node Fragmentation

One Operator, Five Nodes — How Address Noise Fragments a Landlord

landlords_with_connections holds one node per distinct (name, standardized business address). WoW standardizes each owner filing (via Geosupport) before grouping. Ramon Escobar's owner address resolves to exactly five standardized values, so he becomes five nodes — and three of them are the same real office, split only by a blanked ZIP and a street misspelling.

The crux — standardized, not raw, ZIP The split turns on WoW's standardized ZIP (column bizzip in wow_landlords), not the ZIP as filed. Geosupport blanks any ZIP it can't validate, so four of the five nodes carry a blank standardized ZIP; only the clean 10458 filing keeps one. Those blanks — not the raw digits — are what key the nodes and gate WoW's edges.

◆ The five nodes, at a glance

Nodes for one landlord name

Buildings split across them

Nodes that are the same Grand Concourse office

Grand Concourse buildings that should be one node

4 / 5

Nodes WoW left with a blank standardized ZIP

3 → 1

City spellings folded (Bronx / BRONX / BX)

node	Standardized address	ZIP (WoW)	Buildings	Why separate
93015	2432 GRAND CONCOURSE #504, Bronx	10458	24	the real office — the one valid ZIP
93018	PO BOX 370, New York	blank	4	distinct address (P.O. box)
93014	2432 GRAND CONCOURSE #504, Bronx	blank	1	ZIP blanked (raw 10607 rejected) — same office
93016	2432 GRAND COURSE #504, Bronx	blank	1	street misspelling (ZIP also blanked) — same office
93017	374 MCLEAN AVENUE, Yonkers	blank	1	distinct address

I. The fragmentation map

One person, one main office — scattered into five nodes. The three cards in the gold box are the same office at 2432 Grand Concourse; the two below are genuinely different addresses. Only node 93015 carries a valid standardized ZIP.

RAMON ESCOBAR

one operator · owner of 31 buildings

One real office — 2432 Grand Concourse #504 — fragmented into 3 nodes (26 buildings).
WoW re-links the two blank-ZIP nodes (93014 + 93016) into a 2-building portfolio by name, but the valid-ZIP node (93015) can't join them → two WoW portfolios, 24 + 2.

24 BLDGS

2432 Grand Concourse #504, Bronx

ZIP 10458 · node 93015

canonical node · valid ZIP

1 BLDG

2432 Grand Concourse #504, Bronx

blank ZIP · node 93014

raw 10607 rejected → split

1 BLDG

2432 Grand Course #504, Bronx

blank ZIP · node 93016

street misspelling → split

Genuinely separate addresses

4 BLDGS

PO BOX 370, New York

blank ZIP · node 93018

distinct address

1 BLDG

374 McLean Avenue, Yonkers

blank ZIP · node 93017

distinct address

II. How the node key works

Each row in landlords_with_connections is a landlord node — a distinct (name, standardized business address). WoW derives it from wow_landlords, which standardizes each owner contact's address before grouping. That standardized table (bizhousestreet · bizapt · bizzip) shows Ramon's owner address taking exactly five values — reproducing the five nodes and their building counts:

Standardized owner address (street · apt · ZIP)	Buildings	Raw filings folded in
2432 GRAND CONCOURSE · 504 · 10458	24	Bronx · BRONX · BX (city case)
PO BOX 370 · — · blank	4	—
2432 GRAND CONCOURSE · 504 · blank	1	filed under ZIP 10607 (rejected)
2432 GRAND COURSE · 504 · blank	1	"GRAND COURSE" typo (ungeocodable)
374 MCLEAN AVENUE · — · blank	1	Yonkers

Only the clean 10458 filing keeps a ZIP. Standardization blanks the other four — including the stray 10607 (a White Plains code on a Bronx street) and the ungeocodable GRAND COURSE typo. Because the ZIP is part of the node key, the blank-ZIP building at 2432 Grand Concourse (node 93014) can't share a key with the valid-ZIP node 93015 — even though their address strings are identical — so it strands into its own node.

III. What standardization folds — and doesn't

The raw HPD data is far messier than five addresses — dozens of variants. Standardization erases the cosmetic noise but not the substantive differences, and that split is exactly why the count lands at five:

Folded away — keeps it from being > 5 City case & abbreviation: Bronx / BRONX / BX all collapse into one node. General casing, too. Without this, Ramon would fragment into far more than five.

NOT folded — why it's 5, not fewer A blanked ZIP (10458 vs blank on the same street), a street misspelling (GRAND COURSE, a dropped substring standardization can't repair), and two genuinely different addresses (McLean Ave / Yonkers; the P.O. box).

IV. The display trap & why it matters

The display trap Nodes 93014 and 93015 print an identical bizaddr — “2432 GRAND CONCOURSE 504, BRONX NY” — because the display string drops the ZIP. They look like duplicates in the table but are keyed on different standardized ZIPs: 10458 vs blank (WoW blanked the stray 10607 that one building was filed under). That omission is the only reason two rows look the same.

Why it matters — and how WoW clusters it Three of these five nodes are the same person at the same office, split apart by data-entry noise. WoW then re-links the two blank-ZIP nodes (93014 + 93016) to each other by CONNECTED_BY_NAME — but that edge is ZIP-gated, so it can't reach the valid-ZIP node (93015): WoW ends up with two portfolios (24 + 2). This is the fragmentation the CONNECTED_BY_SPLINK edge exists to repair — identity edges that never read the ZIP fold all 26 Grand Concourse buildings into one owner. (This is the same case shown on the case-studies page.)

A live example of “ZIP is noisy” A single wrong ZIP — 10607, a White Plains code entered for a Bronx address — is rejected by standardization and blanked; that blank, no longer matching the valid 10458, manufactures a spurious node (and then links it to the other blank-ZIP node rather than the real office). Precisely why the Splink linkage keeps ZIP only as a weak feature and never inside a composite address key.

V. Method & provenance

table: landlords_with_connections standardized source: wow_landlords (bizzip) raw source: hpd_contacts + hpd_registrations nodes 93014–93018

Listed the 5 RAMON ESCOBAR rows in landlords_with_connections (nodeid, bizaddr, bbls, and the name_match_info edge that links 93014↔93016).
Read the standardized owner address per node from wow_landlords (bizhousestreet · bizapt · bizzip): only 93015 keeps ZIP 10458; the other four are blank.
Traced the raw filings back through hpd_registrations → hpd_contacts to confirm what standardization rejected (e.g. the stray 10607, the GRAND COURSE typo).

Counts reflect the current WoW dataset (a snapshot; they drift as HPD registrations update). “31 buildings” sums the five nodes' distinct BBLs; 26 of them sit at the single 2432 Grand Concourse office.

“ZIP (WoW)” is the standardized bizzip that keys the node and gates WoW's name edge — not the ZIP as filed. Several nodes were filed with a raw ZIP (10607, 10040, 10705) that standardization could not validate and therefore blanked.