search

votinginfoproject / vip-specification

The Voting Information Project XML specification.
http://vip-specification.readthedocs.io/en/release/
Other
75 stars 30 forks source link

Clean up NonHouseAddress #162

Closed jdmgoogle closed 4 years ago

jdmgoogle commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

Closed by #161.

afsmythe commented 5 years ago

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 (https://github.com/votinginfoproject/vip-specification/pull/161#issuecomment-102475376, https://github.com/votinginfoproject/vip-specification/pull/161#issuecomment-103154379).

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

jdmgoogle commented 5 years ago

Gentle ping on the above question.

afsmythe commented 5 years ago

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

afsmythe commented 4 years ago

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

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 commented 4 years ago

We have returned house_number_prefix and house_number_suffix in this PR https://github.com/votinginfoproject/vip-specification/pull/388 for the 5.2 revision.