Out-of-state row files: blank `state` silently becomes CA

[mighkel]

Out-of-state rows: state silently defaults to CA, and name-based placement is California-only

Working up an Idaho row file and hit a few things that are fine for CA data but get
in the way of the "any state, any public safety agency" case. All small, all in
tools/build_comms_catalog.py. Nothing here blocks me — I have coordinates for
every row, which sidesteps all of it — but the next person who tries a state file
will hit them in this order.

Filing as one issue since they're the same theme; happy to split.

1. A blank state silently becomes California

Line 804:

r["_st"] = (r.get("state") or "CA").upper()

A row that forgets state is filed in California. No warning, no error.

It survives the correction pass too. For a blank-state, blank-county Idaho row:
county_of() resolves the county correctly (TIGER is nationwide), returns FIPS
16, and then line 1025:

if fips in STATE_FIPS and s["st"] != STATE_FIPS[fips]:

STATE_FIPS holds {"06": "CA", "32": "NV", "41": "OR", "04": "AZ"}, so 16 is not
in it and st stays "CA". Net result is a site labelled Boise County, CA —
wrong, and plausible enough to survive review.

Two directions, either works:

• Make state required for row files and fail the row without it, rather than
  defaulting.
• Trust the FIPS lookup over the row: it already has the authoritative answer, so
  set st from it whenever they disagree. Needs the full 50-state table instead
  of the four.

The silent part is the real problem — a hard error on a missing state would have
been fine.

2. The USFS site layer is fetched CA-only

Line 766:

usfs = arcgis_all(USFS_SITES, where="state='CA'", ...)

EDW_SpecialUsesCommunicationsSites_01 is a national layer, so this is the one
place where a small change buys the most: without it, a row naming a real USFS
communications site in Idaho, Montana or Colorado can't be placed by name even
though the authoritative record exists.

Guessing the filter is there for fetch size. If so, taking the states actually
present in the row files would keep that benefit:

where="state IN ('CA','ID',...)"   # states seen across row_files

3. area=CO:<county> hardcodes California's FIPS

Line 511:

where="NAME='%s County' AND STATE='06'" % name.replace("'", "''")

06 is California. So area=CO:Boise looks for Boise County, CA, finds nothing,
and the row falls through to "no boundary" handling.

The row already carries state, so the FIPS could come from there. Worth noting
that the comments around the GNIS passes make a strong case that a county is the
single most valuable constraint for placing a named site — this is the column that
delivers it, and outside CA it's inert.

USFS: and NPS: are fine; both hit national services.

4. Four columns the parser reads aren't in the sites.csv header

area, net_name, net_rx_tone, net_tx_tone are all read from row files but
absent from the template header and its comment block. net_name in particular
matters outside California: with no MACS 441-1 designator to use as an id, net
ends up carrying a local string and net_name is what makes it readable.

The net_rx_tone / net_tx_tone versus rx_tone / tx_tone distinction is
genuinely easy to get wrong from the header alone — the code comment explaining it
("a repeater net has one pair and a different tone at every site") is the thing a
contributor needs and it's only visible in the source.

Not a request, just a note

Elevation and county filling are already nationwide (EPQS, TIGER) and worked
without any changes. That is most of what I expected to have to supply by hand, so
the CA-specific parts are a narrower set than they first looked.

---

Drafted with AI assistance against a read of build_comms_catalog.py at
05b5dd0; line numbers are from that commit.

[takwerx]

Thanks — this is an unusually good report, and all four are real. I read each line you
cite; confirming them one at a time, with what I found beyond what was visible from
the outside.

1. Blank state becomes CA

Confirmed, and your read of why the correction pass doesn't catch it is exactly right.

We'll take both of your directions rather than one: state becomes required and a row
without it fails loudly, and STATE_FIPS grows to all 50 plus DC so the FIPS
lookup has an authoritative answer everywhere. Where the row and the FIPS disagree
we'll report it the way tone conflicts are already reported, rather than quietly
picking a winner — a row that says ID against a coordinate landing in MT is a fact one
of them has wrong, and that is a person's call, not the builder's.

You're right that the silence is the real defect. That's the part being fixed first.

2. The USFS layer is fetched CA-only

Confirmed, and the fetch-size guess doesn't hold. I counted it:

where=1=1            1424
where=state='CA'      257

1,424 features at resultRecordCount=1000 is two requests instead of one. So the
filter just comes off — no state list needed, and the national layer places named
sites in every state rather than the ones we happen to have rows for.

One thing you couldn't see from the line you quoted: the fix is two changes, not one.
Line 780
hardcodes the state as well:

sites.add(title_case(name), float(lat), float(lon), "CA", county=..., ...)

Drop the where without that and every Idaho USFS site is still filed in California —
the same bug as item 1, one layer down.

3. area=CO:<county> hardcodes California's FIPS

Confirmed; the row's state is the right source for it. Two traps in the fix worth
knowing before you start:

• area_cache is keyed on the area string alone. Once the FIPS varies by row,
  CO:Washington cached for one state is returned for another — thirty states have a
  Washington County. The cache key has to carry the state.
• NAME='<x> County' is itself a California assumption. TIGER spells Louisiana
  parishes, Alaska boroughs and census areas, and Virginia independent cities
  differently, so the where needs the candidate forms rather than a bare County.

4. Four columns the parser reads aren't in the header

Confirmed and agreed, including the point about net_name — outside California net
carries a local string and net_name is the only thing that makes it readable. The
net_rx_tone versus rx_tone explanation is going into the template comment block
where a contributor reads it, not left in the source.

One you didn't hit, because you have coordinates for every row

The tone number is California too, and it's in the plugin rather than the builder.
Tones.describe() maps any Hz to the MACS 441-1 standard 32 with no state awareness,
so an Idaho repeater on 100.0 Hz renders as 100.0 (Tone 9) — a California plan
number printed on an Idaho site. The catalog has the same problem at
line 995,
where TONE_NUMBER is applied to every row-file channel.

Nothing a row file can do about it; the display has to be gated on whether the site
belongs to a plan that numbers its tones. Tracked separately.

Splitting: yes please

One issue per item is how we'd like to take these — they're independent, and 1, 2 and
4 are each small. If you'd rather send patches than issues, that's very welcome; one
pull request per item so they can land as they're ready.

What we owe you first

This repo had no LICENSE file, which meant there was nothing under which you could
send a patch at all. That's on us, and it's now written: AGPL-3.0-or-later, with
an additional permission under §7 for the TAK Software so that a plugin can be built
against the SDK, loaded into ATAK and distributed without the AGPL reaching into ATAK
itself. There's a CONTRIBUTING.md alongside it covering the row-file format and a
standard CLA. They're committed and land here with the next push — I'll comment when
they're up.

Thanks again for filing it as one issue with the reasoning attached rather than four
bare reports. Idaho is exactly the case this needs to work for.

[takwerx]

It's up: LICENSE —
AGPL-3.0-or-later, with the TAK Software permission and the provenance list in
LICENSE-EXCEPTION.md,
plus CONTRIBUTING.md
and a CLA (a git commit -s
sign-off, nothing to sign separately).

So there's something to send a patch against now. All four items are yours if you
want them — one PR each so they can land as they're ready, and no obligation to
take any of them: the report on its own was worth filing.

Worth repeating the two traps from my last comment, since they're the parts that
would waste your time:

• Item 2 is two changes. Dropping the where without also fixing the hardcoded
  "CA" at line 780 leaves Idaho sites filed in California anyway.
• Item 3 needs the area_cache key to carry the state, or CO:Washington in one
  state returns another's cached bounding box.

No release was cut for this — the plugin didn't change, so it's still 0.7 and the
signed APKs are untouched. That turned out to need new tooling on our side: there
was no way to publish a file to a plugin repo without inventing a version number.
Your issue is what surfaced it.

[mighkel]

Reply — the tone-number item (tracked separately?)

One correction to the framing on the tone-number issue, and it makes it worse rather
than better.

Idaho isn't a place with no tone numbers. Boise RUG numbers its tones too — the
2025 Interagency Tone Pick List is exactly parallel to MACS 441-1, and the channel
sheet writes those numbers rather than frequencies (2,3,9-12,14,15,16 against BOD
BLM REPEATER, and so on). So the plugin isn't printing a meaningless number on an
Idaho site; it's printing a number that exists in the local plan and means a
different frequency.

The two schemes agree for the first eight, then diverge:

No.	MACS 441-1	Boise RUG
1–8	110.9, 123.0, 131.8, 136.5, 146.2, 156.7, 167.9, 103.5	identical
9	100.0	179.9	differs
10	107.2	141.3	differs
11	114.8	100.0	differs
12	127.3	114.8	differs
13	141.3	127.3	differs
14	151.4	151.4
15	162.2	162.2
16	192.8	107.2/88.5	differs

Agree: 1–8, 14, 15. Differ: 9–13, 16. (RUG stops at 16; there is no 17–32.)

Why the example in the write-up is the worst case

an Idaho repeater on 100.0 Hz renders as 100.0 (Tone 9)

In the Boise plan, 100.0 Hz is Tone 11. And Tone 9 is 179.9 Hz — a real tone
on a real site in the same plan.

So a user reading Tone 9 off the plugin and selecting position 9 on a radio
programmed to the RUG list gets 179.9 Hz instead of 100.0 Hz, and the repeater does
not open. The number is wrong in the one way that can't be caught by eye: it is
plausible, in range, and collides with a different real entry.

The partial agreement makes it worse, not better. Tones 1–8 render correctly, so the
first several a user checks build confidence before 9 through 13 break it.

What this implies beyond gating

Gating the display on "does this site belong to a plan that numbers its tones" is
necessary but not sufficient, because Idaho is such a plan and would pass the gate
while still being renumbered against California's table.

The underlying problem is that TONE_NUMBER is a reverse lookup from Hz to a number.
That inverts a relation that isn't invertible across plans: the number is a property
of the plan, not of the frequency. 100.0 Hz is Tone 9 in California and Tone 11 in
Boise, and no amount of state-awareness in the lookup fixes that — the catalog has to
carry the plan's own number, or print none at all.

RUG tone 16 is 107.2/88.5, two frequencies in one entry, which also has no single-Hz
representation to reverse-look-up in the first place.

A related hazard in the builder, for row files

Same root cause, other end of the pipeline. tone_value() reads a bare integer 1–32
as a MACS 441-1 tone number, so a row file that writes its own plan's numbers gets
them silently converted through California's table:

RUG tone 9  = 179.9        -> builder records 100.0 Hz
RUG tone 10 = 141.3        -> builder records 107.2 Hz
RUG tone 11 = 100.0        -> builder records 114.8 Hz
RUG tone 12 = 114.8        -> builder records 127.3 Hz
RUG tone 13 = 127.3        -> builder records 141.3 Hz
RUG tone 16 = 107.2/88.5   -> builder records 192.8 Hz

Wrong frequency, no warning, six times out of sixteen. I'm resolving every number to
Hz against the RUG pick list before it reaches the CSV, so my rows aren't affected.

To be fair to the docs: both tools/sites.csv ("Tones are Hz") and CONTRIBUTING.md's
column table ("This site's tones, in Hz") already say the right thing. The gap is
that the guard is documentation only — tone_value() silently accepts a bare integer
anyway and converts it through the California table. A contributor transcribing a plan
that prints tone numbers, which is most of them, gets a plausible wrong frequency and
no error.

Might be worth refusing bare integers in row files outright rather than interpreting
them, given the failure is silent and the correct input is already documented.

[mighkel]

Comment to add — field report from building an Idaho row file

Thanks for the LICENSE, CONTRIBUTING and CLA — and for taking all four.

I went and built an actual Idaho row file against 05b5dd0 rather than just
reporting from a read, and it turned up three things worth adding here. Two are new
failure modes in the same family as item 1; one is evidence that item 2 is worth
more than it looked.

Item 2 is worth more than "a filter comes off"

You counted 1,424 features nationally against 257 for CA. The Idaho slice is 129,
and 12 of the 53 sites in my row file are in it — Cold Springs, Cow Mountain,
Dog Mountain, Grape Mountain, Indian Mountain, Jackson Peak, Miners Peak, Nick Peak,
Pilot Peak, Snowbank, Trinity and War Eagle, all with authoritative USFS coordinates.

Six of those also appear in a separate NIFC repeater list I was working from, and the
two sources agree to within 2–114 m on five of the six. So the layer is not just
present out of state, it is good.

With the filter off, those twelve would place by name and would not need to be
carried in a row file at all. Confirming your line-780 trap is real, too: I checked,
and dropping the where without it would file every one of them in California.

New: ALL-CAPS site names never match the names database

The workbook I transcribed prints site names in caps. With names written as the
source has them — SNOWBANK, LUCKY PEAK, EAST MTN — a --dry-run anchored
nothing: 76 rows unplaced, no GNIS match for any of them.

Title-casing the same names to Snowbank, Lucky Peak, East Mountain made eleven
of them resolve immediately. Two causes, both silent:

• the GNIS gaz_name LIKE query appears to be case-sensitive, and
• the abbreviations a plan uses (MTN, PK, CR, PT) fail the GENERICS tail
  check — MEADOW CR against Meadow Creek leaves a tail of eek, which is not a
  generic, so the candidate is discarded.

Neither says anything. A contributor whose source is a radio plan — which is most of
them, and plans print in caps and abbreviate — gets zero name resolution and no
indication why. Same shape as item 1: it does not fail, it just quietly does nothing.

New: the pass-3a bootstrap misfired out of state, exactly as your comments fear

Once the names matched, the anchored <net> on <name>, the one place in ID by that name rule placed eleven sites. One was wrong:

anchored WILDERNESS-RANCH on Wilderness Peak

The site is Wilderness Ranch, a subdivision in Boise County with its own fire
district. The names database matched Wilderness Peak, a different place. Real
coordinates, no warning — the Soda Ridge/Plumas case from your comments, in Idaho.

A related wrinkle for the same rule: the NIFC list names a site the names database no
longer carries at all. GNIS has no "Squaw Butte" anywhere in Idaho since the 2022
federal renaming; the only summit at that point is now Sehewoki'i Newenee'an Katete.
Agency lists and GNIS can disagree because the official name changed underneath them,
which is one more reason a name alone is thin.

I am not suggesting the rule goes away — it clearly earns its place in California.
Only that it is a guess, and out of state it currently has less to check itself
against. For what it is worth, every one of these disappeared as I filled in
coordinates: a net with any placed site never needs bootstrapping.

Small: the template did not get item 4's fix

CONTRIBUTING.md's column table is excellent and covers all four, including the
net_rx_tone versus rx_tone distinction spelled out properly. But
tools/sites.csv still has the original comment block and the original 17-column
header — a contributor who starts from the template rather than the doc still will
not know net_name exists.

One question

tools/rows/<st>-<what>.csv — for a file covering the Boise Radio User's Group
interagency plan, is id-boise-rug.csv the naming you would want, or do you prefer
the agency rather than the coordinating body?

---

Built with AI assistance against 05b5dd0; every claim above is from a --dry-run
on that commit or a query against the named layer.