Is there a "layer" for postcodes/ZIP codes?

[stevevance]

I believe that postcodes and ZIP codes are not open source boundaries in some jurisdictions, but are they searchable in Pelias?

[riordan]

Not at this time. Our data team is looking into how we might be able to
augment the data for postcodes (from beyond extracting them from addresses).

Also Zip Codes are weird, in that they're actually postal routes, not
boundaries.

On Fri, Sep 25, 2015 at 2:06 PM, Steven Vance notifications@github.com
wrote:

I believe that postcodes and ZIP codes are not open source boundaries in
some jurisdictions, but are they searchable in Pelias?

—
Reply to this email directly or view it on GitHub
#312.

David Riordan | Product Manager - Search | dave.riordan@mapzen.com |
@riordan https://twitter.com/riordan | gpg 235D9DC95EF6277C
https://keybase.io/riordan
Mapzen | https://mapzen.com | @mapzen https://twitter.com/search

[missinglink]

The postcodes themselves are not, but specifying the postcode will boost the position of matching venues.

eg.

"130 west 26th street"
 1) 130 West 26th Street, Bloom, IL
 2) 130 West 26th Street, Manhattan, NY
 3) 130 West 26th Street, Hamilton, Ontario
 4) 130 West 26th Street, Merced, CA
 5) 130 West 26th Street, Buena Vista, VA

"130 west 26th street, 10001"
 1) 130 West 26th Street, Manhattan, NY
 2) 130 West 26th Street, Bloom, IL
 3) 130 West 26th Street, Hamilton, Ontario
 4) 130 West 26th Street, Merced, CA
 5) 130 West 26th Street, Buena Vista, VA

The /v1/search endpoint will try to match postcode data from fully specified address inputs.

You can test this out by sending a fully specified address and then looking in the meta data of the response object. If the address parser produces something like parsed_text.postalcode then we will attempt to match that against postcode fields where we have them.

eg.

"130 west 26th street"
      "parsed_text": {
        "number": 130,
        "street": "west 26th street",
        "regions": []
      },

"130 west 26th street, 10001"
      "parsed_text": {
        "name": "130 west 26th street",
        "number": 130,
        "street": "west 26th street",
        "postalcode": 10001,
        "regions": [],
        "admin_parts": "10001"
      },

At this time address parsing is disabled for /v1/autocomplete, because 1) autocomplete entries are rarely fully specified, 2) it adds a little latency 3) the address parser is not perfect, eg. the search above returns "admin_parts": "10001" which is incorrect, we have a plan for improving this.

This parsing logic is actually super hard to get right internationally; because addresses. Our current solution is based on https://github.com/DamonOehlman/addressit

What you'll find is that postcode coverage is not amazing, and we are always looking for how to improve that, postal polygons would be a massive help.

I also have a post-it note on my monitor to fix that analysis to account for spaces and oddness in the postcodes themselves.

[stevevance]

Thanks.

@riordan I know - it's odd. Do other countries do it like the United States Postal Service?

[missinglink]

ref: pelias/schema#77

[riordan]

blast from the past!

@stevevance I don't know of any other countries that treat their postal codes as linear routes, but that doesn't mean they don't exist. I imagine systems like UK Postcodes with small, targeted areas, but they're not routes, per se.