Thanks Gerry for joining the conversation. I agree that a well parsed address is better for matching. But I assume parsing out a street prefix or suffix directional would hinder that matching process instead of help.
For example if you wanted to match 321 E 91st St New York, NY, 10028 matching to 91st St alone may return a candidate for W 91st ST, 10024. Therefore you would want to keep the directional appended. In this situation the zips are different and therefore it might not make much difference whether the directional was parsed or not. It just becomes an operational inefficiency (in my opinion) to have to maintain a parsed street name at that level. I wonder if all streets with opposing directionals fall within different zips?
------------------------------
Amy Metz, PMP, PMC-III
Product Manager - Address Data
Pitney Bowes
White River Junction, VT
802-698-3571
https://www.linkedin.com/feed/?trk=------------------------------
Original Message:
Sent: 01-02-2020 18:28
From: Gerry Stanley
Subject: Parsing Street Name Components
Hi Amy
The parsing outlined is further than what is used in Australia, however the purpose of accurate parsing is probably similar. I am far from an expert in the area, but I suspect the use case is around accuracy of matching.
A well parsed address works far better in most address verification tools and reduces the likelihood of incorrect matching. This matching of course provides location elements that are critical in emergency response. I imagine that @Mike Ashmore or @Nathan Pinder may be able to provide additional insight.
------------------------------
Gerry Stanley
Pitney Bowes Australia Pty Ltd
Macquarie Park
Original Message:
Sent: 12-26-2019 10:43
From: Amy Metz
Subject: Parsing Street Name Components
I was recently reviewing the US Department of Transportation's National Address Database schema and noticed that there are many fields to parse out individual components of a street name. The proposed schema is based on the National Emergency Number Association (NENA) Civic Location Data Exchange Format (CLDXF).
I feel like this type of thinking is somewhat antiquated and might have been useful in the past for companies building free-text search engines (also known as type-ahead or auto-complete) in an effort to increase response times. But now it feels like this level of parsing for a street name is completely ineffective. Don't get me wrong, I understand parsing out the house number from the street name, but I am not convinced of the benefit to parse individual components of the street name.
The proposed schema from NENA is directed at supporting one use case, the next generation of emergency response (NG9-1-1). I am starting to see local governments requesting help from 3rd party data vendors and GIS consultants to move their data to this format. Here is one example that was recently posted to GISCafé: https://www.giscafe.com/nbc/articles/view_article.php?section=CorpNews&articleid=1721802 . But I still am trying to figure out the benefit of this level of parsing for an emergency response use case.
Can anyone enlighten me?
------------------------------
Amy Metz, PMP, PMC-III
Product Manager - Address Data
Pitney Bowes
White River Junction, VT
802-698-3571
https://www.linkedin.com/feed/?trk=
------------------------------