Spectrum Technology Platform

Hi I am new to this group and PB suggested I ask this question in this user group. We currently use the PB Spectrum software to perform Geocoding. Sometimes we are asked to get a secondary validation. We previously used Google Earth for this function as it was easy to export an image from Map Professional and show both the Spectrum result and the Google Earth result together. Our company has recently decided against this as Google Earth is Open Source. I am curious what others use to perform a secondary check when they get a questionable result from Spectrum?

Hi Barry, the answer very much depends on the use case and what you are double checking:

If you are being asked for a "secondary validation" of the addresses existence, and it's a postally valid address, you might want to consider an address validation engine.

If the secondary validation request is because the match code (in the US) or result code (Rest-of-World) our geocoder gives you does not meet with certain validation requirements, then there are multiple techniques for tuning the geocoder and cleaning the address data, before re-running the address. Including, interactive address lookup. And if that doesn't work, then where you would try would very much depend on which country we are talking about.

If the secondary validation request is based on a good address match but poor positional accuracy, then I would recommend an online aerial imagery supplier, and who you choose depends on what dataset of our you are running. So for instance, if you are running with HERE data, then Bing would not be a good place to go, rather you would want to go to Google or MapQuest.

If you can give me more details, I can be more specific.

Thanks

Mike

Sorry I should have provided an example of the problem. When we pass and address through spectrum for standardization one of the processes is to assign the address to a representative based on the Lat/Long of the address. This is done by generating a point from the Lat/long and then seeing where that point exists in our coverage maps. The boundary can be for example a county line. Zip codes often exist in two or more counties and the City of the address is usually based off the Zip code. Take for example Zip code 66109 that exists in Leavenworth and Wyandotte Kansas. Everyone that exist in this Zip has a city name in their address of Kansas City, but the 2 counties belong to different reps. So when we get a new address in this Zip code the Wyandotte rep always thinks it is his because of the City name of the address. What I would do when we had Google earth was pass the address through our system get the Lat/Long create a point in MapiInfo pro, then export this to Google Earth search for the same address. If the address geocoded to the street level the point created by Google Earth and the point from spectrum would be very close together. I could then zoom out far enough to see a county line and prove to the rep that this was not their account. When I lost the use of Google Earth I lost the ability to provide this verification to the reps.

Barry,

If I understand your question, you just want to be sure of the county to differentiate which rep is assigned.

The US county is returned in all versions of geocoding that I know of. If that county was returned, would that solve the problem?  ? If the match is poor (like a fallback to zip) the google earth validation would not help anyway. So this assumes that the geocode result is pretty accurate. What version of Spectrum and US data are you using?

Currently we are running Spectrum V11 and I update the Tom Tom DB ever other month so ?12/2017 currently. You correct in my questioning about Zip fallback and the accuracy being my bigger concern. We do get the and store the county but Google earth has it's advantages. When you search for an address in Google earth it often can locate it and gives a comparison of the Spectrum result to the Google earth result. In the event of a Zip fallback result I can then get an idea of how far the two are off and adjust if needed.

Hi Barry, have you compared this against using our API's (locate.pitneybowes.com)? This environment has our MLD (Master Location Data) loaded into the Geocoder. This gets a significantly higher match rate than our TomTom sourced data.

If you don't get a good result from this dataset, then it is either a new construction we have not included yet, or we have a problem with our production process that needs to be fixed.

If you would prefer a visual demo, let me know and I will give you access to our internal demonstration environment.