Read the OH-104 and C.R. 32 route forms - #171
Merged
Merged
Conversation
The two remaining defects in #168. ODRC writes the highway shield form "OH-104" and the period-separated "C.R. 32"; the reference data publishes 18,949 "SR <n>" and 4,960 "CR <n>" and neither source form, so both missed. "OH" and "C R" join CONST_ROUTE_PREFIX_ABBREV -- the second is what "C.R." becomes once normalize_street_name has turned the periods into spaces. Both are short enough to look risky and are not: a route prefix is read only at the start of a street name and only when a number follows it, so the "OH" of a postal tail and a street named "C Street" are left alone. Both are covered by tests. Only these two forms are added. The facility sources carry no "S.R." or "T.R." spelling, so mapping them would be speculation. CONST_GEOCODE_INDEX_VERSION goes to 3. The prefix map is applied to the reference data as well as the query, so the derivation has changed even though this reference contains no name either mapping affects -- leaving that to depend on the data rather than on the code is the drift this module exists to prevent. Against the 359 DODD, CMS and ODRC facility addresses used to validate morpc/morpc-addresspoints-standardize#7, matching goes from 330/359 (91.9%) to 334/359 (93.0%), and ODRC from 85.2% to 92.6%. The number_name and route_number tiers are unchanged, so nothing previously matched was displaced. Closes #168
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The two remaining defects in #168, which this closes. The postal-tail defect was fixed in #170.
ODRC writes the highway shield form
OH-104and the period-separatedC.R. 32. The reference data publishes 18,949SR <n>and 4,960CR <n>, and neither source form, so both missed:"OH": "SR"and"C R": "CR"joinCONST_ROUTE_PREFIX_ABBREV— the second is whatC.R.becomes oncenormalize_street_namehas turned the periods into spaces.Why two-character prefixes are safe here
A route prefix is read only at the start of a street name and only when a number follows it, so the short keys cannot capture ordinary names. Covered by tests:
15802 OH-104SR 10415802 OH 104SR 104284 C.R. 32 SouthCR 32, suffixS123 Ohio AveOHIO, typeAVE100 C StreetC, typeSTOnly these two forms are added. I checked all 359 facility addresses for other spellings — there is no
S.R.orT.R.in the data, so mapping them would be speculation.Index version
CONST_GEOCODE_INDEX_VERSIONgoes to 3. The prefix map is applied to the reference data as well as the query, so the derivation has changed. This reference happens to contain no name either mapping affects — zeroOH <n>and zeroC R <n>— so the rebuild is a no-op for the current data, but leaving correctness to depend on the data rather than the code is exactly the drift this module exists to prevent.Effect
Four new matches:
284 C.R. 32 South×3 and15802 OH-104. Thenumber_nameandroute_numbertiers are unchanged at 8 and 4, so nothing previously matched was displaced.All 42 tests in
test_geocode.pypass. Thetest_utils.pyfailures noted in #169 and #170 remain, unrelated and pre-existing onmain.What is left in the benchmark
25 unmatched of 359. Two are the geocoder correctly declining an ambiguous match, one carries no house number, and the rest are genuine coverage gaps or the two pre-existing parse quirks recorded in #170 — the
Route #38unit-designator misread and the multi-number4410,4412,…leak. None are route forms.🤖 Generated with Claude Code