Clean up NonHouseAddress

[jdmgoogle]

Remove duplicate elements that are part of the NonHouseAddress element within the StreetSegment. Right now we (Google) don't and have never done anything with the Prefix and Suffix parts of the HouseNumber in NonHouseAddress. Plus the Apartment and HouseNumber elements in NonHouseAddress duplicate (or have been replaced) by the Unit and StartHouseNumber and EndHouseNumber elements in StreetSegment.

[jungshadow]

@nomadaisy @pkoms Can you weigh in on the need for HouseNumber and its related prefix and suffix elements? If we have StartHouseNumber, EndHouseNumber, and UnitNumber is there a need for them? I'm thinking no, but it would great to have your input.

[jdmgoogle]

Closed by #161.

[afsmythe]

I'm working with Wisconsin on their 5.1 upgrade and we're running in to some issues with the (now deprecated) prefix and suffix fields for house number. These were fields which were used by Wisconsin in their 3.0 feed, and I keep seeing reference to these fields in these older Github issues (#161 (comment), #161 (comment)).

I'm assuming that those comments linked above are referring to Google's v5 ingestion process. If that's true, then were those prefix and suffix fields for House Number recognized in the 3.0 ingestion pipeline?

I have Wisconsin's 3.0 feed from 2018 awaiting ingestion to the 4102 EID so it can be reviewed. @jdmgoogle feel free to weigh in! I think this will be something we can discuss during the 5.2 meeting if we don't have any more clarity by then.

[afsmythe]

It is common is some parts of the US, including Fair Lawn, NJ; Queens, NY and Delafield, WI (below) where non-integer characters are included in the house number to accurately identify an address. In the 3.0 specification VIP supported these fields with a house number prefix and suffix, but these have been deprecated in 5.1. Without a character field for house number prefix and suffix Wisconsin and other states will be unable to provide a full address list that validates with the 5.1 specification.

N10W31330 YORKTOWN CT, DELAFIELD, WI 53018-2740
N10W31357 YORKTOWN CT, DELAFIELD, WI 53018-2741
N10W31384 YORKTOWN CT, DELAFIELD, WI 53018-2740
W313N1001 YORKTOWN CT, DELAFIELD, WI 53018-2710
W313N1076 YORKTOWN CT, DELAFIELD, WI 53018-2709
W314N1007 YORKTOWN CT, DELAFIELD, WI 53018-2710
W314N1035 YORKTOWN CT, DELAFIELD, WI 53018-2710
W314N1065 YORKTOWN CT, DELAFIELD, WI 53018-2710
W314N1111 YORKTOWN CT, DELAFIELD, WI 53018-2743

[jdmgoogle]

So we could potentially include this, but I'm not sure how we'd be able to use this in address ranges in any meaningful way. For example, is "W313N1076" between "W313N1001" and "W314N1111"? Is "N313W1075" between "W313N1001" and "W314N1111"? Is "N313W1076" odd or even?

How do we create meaningful street segments/ranges?

[afsmythe]

Wondering if we could include a requirement similar to what is done for StreetSegment.UnitNumber:

The apartment/unit number for a street segment. If this value is present then StartHouseNumber must be equal to EndHouseNumber. This field cannot be used if IncludesAllAddresses or IncludesAllStreets are true.

Wisconsin, which is most affected by these fields being removed in v5, is presently providing a point file rather than ranges and so would comply if the spec mandated address points when prefix and suffix are used.

[jdmgoogle]

Are there any other states which (a) would use prefix/suffix fields, and (b) is not currently providing a point file?

[jdmgoogle]

Gentle ping on the above question.

[afsmythe]

We should be able to find this by a review of the 3.0 2018 VIP data. Will report back.

[afsmythe]

In 2018 the following States and Counties provided 3.0 VIP feeds with either house_number_prefix or house_number_suffix.

• Maricopa County (Arizona)
• Delaware
• Florida
• Pennsylvania
• Wisconsin

Of these, only Florida and Pennsylvania provided non-point segments with house_number_prefix or house_number_suffix. Once these States upgrade, VIP should be capable of working with both of them to ensure they provide point segments if house_number_prefix or house_number_suffix are required.

[afsmythe]

We have returned house_number_prefix and house_number_suffix in this PR #388 for the 5.2 revision.