Release v2018.12.28.001
Per the discussion below, you can now retrieve the actual USPS carrier routes and display them as highlights on the map. This should be more accurate for determining the mailing address city when compared to ZIP Code area boundaries (aka Zip Code Tabulation Areas, or ZCTA's) that are also displayed by this script.

NOTE: this script can only display the "recommended" USPS Zip Code city. There may be other cities for a given ZIP Code that locals are familiar with and could use when searching for an address. At a minimum, the recommended city should typically be used but if you have local knowledge you may want/need to add alternate cities. Also note that city guidance may vary from state to state or region to region, so please consult the Wazeopedia and/or your SM or RC if you are unsure, before updating the city (or alt city) on any road segments.

Instructions
The script adds a couple new buttons to the side panel: Hover over the "Get USPS Routes" button and you'll see a yellow circle with a 1-mile diameter at the center of the screen. Click the button to retrieve all USPS carrier routes that intersect that circle: The ZIP Code and the "recommended city" for the ZIP Code will be displayed beneath the buttons, color-coded to match the carrier routes.

Note that some routes may cross ZCTA boundaries and/or end abruptly midway on a segment, often for no apparent reason. In these cases, you may want to do some more research to make sure the displayed route is correct. e.g. look up specific addresses on the USPS site, look up business addresses on their websites, etc. In most cases I've studied so far, the displayed routes have been correct. However, there have been a couple reported cases in beta testing of a route being incorrect at the end where it meets another. I've also run across at least one case where routes overlap (two cities may apply?), and the script doesn't currently make it easy to see that. So as with any external data, do your research if you have doubts.

Release v2018.12.30.002
Added a new time zones layer. Please note that the boundaries are very rough approximations. Also, they may not display properly (or at all) at zoom levels above 5. Something to do with a limitation of OpenLayers and how long the line segments are.

dfortney wrote:Thanks MapOMatic for the awesome ability to pull in USPS routes!

I'm seeing some instances where it is pulling in alternate cities rather than the default / recommended city. Here's an example in Menlo Park, CA - zip 94025. The script is pulling back West Menlo Park, which is evidently an allowed alternate name, but it is not the common name, and it's also not the recommended name using the USPS Zip Code locator searching for an address (I used 1185 Noel Dr, 94025 for my testing)

https://www.waze.com/en-US/editor/?env= ... ts=6008874

Hmmm, that's odd. Have you seen more instances of that? I'd like to see if there's any pattern. Unfortunately that's the only city name provided in the data so I'm not sure what I could do to fix it. I don't know why they'd list West Menlo Park, unless it has something to do with the facility being located in West Menlo Park (or it's just a mistake). Both Atherton and West Menlo Park routes list "MENLO PARK" as the facility name.

dfortney wrote:Here's another address giving an incorrect result: 25501 Chapin Rd, Los Altos Hills, CA
The script is using Los Altos instead of Los Altos Hills.

That one is at least returning the "recommended" city for 94022. I believe that's a good example where local editor knowledge would have to prevail (unfortunately).

Understood. I just meant that if you go to the search for city by ZIP code lookup, the recommended city is Los Altos (but Los Altos Hills is also recognized). I can't explain why it's returning West Menlo Park as the recommended city.

I think this is good evidence that we shouldn't blindly trust this tool. Still need to do some research when things don't seem to make sense.

Sorry, I probably wasn't clear. I was referring to the search results from this page:
https://tools.usps.com/zip-code-lookup. ... ybyzipcode People seem to be finding cases of inconsistent data fairly regularly, unfortunately. I was really hoping this would be more reliable and allow us to update city names with some confidence. But it's looking more and more like it should be treated with a healthy dose of skepticism. I've been finding it very helpful in (most) rural areas of KY I've been looking at, but I've also found a couple head-scratching scenarios. I guess, as seems to be the case with most large collections of data like this, YMMV.

Release 2019.07.04.001

Clicking the Zip Code in the WME map header will now give you instant details about the cities that the USPS officially recognizes for that ZIP Code. You can click the link in the popup to go to the USPS site.

To be honest, I'm not 100% sure there's a "right" answer that applies to every situation. I think it could be used to help determine if one or more alt cities could be applied, but don't just blindly assume it's correct and fits with region/state guidelines. I'd use it as one piece of evidence in a wider investigation I know... clear as mud.

Sorry about that. I screwed up the version # a few months ago (used 2021.08.01 instead of 2021.01.08) so updates haven't been pushing automatically for a lot of people. I just now returned the version # to the wrong format so it should update now.

If anyone needs to make any code fixes, just keep incrementing the last digit (don't update the date portion) until we're past August 1. Then we can get back to using the correct dated versions.

russblau wrote: ↑Tue Aug 09, 2022 1:55 pm ZIP Codes don't appear for me yesterday or today. Is this a problem with the external data source?

 

Check that you have the latest version (2022.08.05.001).  Let me know if you still have problems.