Add Postal Code as a type of Area

[jlurien]

Postal codes are a common user friendly denominations for known areas.

Proposal is to add a new type of Area PostalCode

PostalCode:
  type: object
  required:
    - type
    - postalCode
  properties:
    type:
      type: string
      enum:
        - PostalCode
      description: Type of this area
    postalCode:
      type: string
      description: Postal Code (aka Zip code or Postcode), according to the local format. 
    countryCode:
      type: string
      pattern: '^[A-Z]{2}$' 
      description: ISO 3166-1 alpha-2 code for the country. Uppercase. If not specified, each implementation may apply a default value.

Optionally a country code may be needed in some global scenarios. Otherwise, each implementation may assume its own country.
There is no global pattern for postal codes. We could define some limits minLength , maxLength, apparently longest one is 10, but it may be better to leave all format verification to implementations.

[bigludo7]

To provide my feedback.... in France we have postalCode but another code is used for geographic purpose: the INSEE code (the postal code is more an administrative one).
Perhaps same situation could occur in other country.
We have several options to accommodate this:

1. make a model more generic with for example a code attribute (to provide code value) and a codeType (to provide the ype of code provided).

GeoCode:
  type: object
  required:
    - type
    - code
    - codeType
  properties:
    type:
      type: string
      enum:
        - GeoCode
      description: Type of this area
    code:
      type: string
      description: Code (aka Zip code or Postcode), according to the code type. 
    codeType:
      type: string
      description: Type of code (could be Postcode, INSEE Code, etc...), 
    countryCode:
      type: string
      pattern: '^[A-Z]{2}$' 
      description: ISO 3166-1 alpha-2 code for the country. Uppercase. If not specified, each implementation may apply a default value.

2/ leverage the polymorphic model and provide explicit specialization. In this case we keep your proposal and for example I add a structure for inseeCode.

I think that for a developer, option 2 is probably better as more explicit, but we need to find a way to expose by code the model managed by an implementation (If Telefonica managed Circle & postalCode while Orange manage Circle & insee code and then DT Circle & polygon ...developer should be able to get this information on the fly).

[JoachimDahlgren]

There is no global standard for postal codes and it does not always point to a geographical area (and in cases it does point to a geographical area the size thereof can vary a lot depending on if it is a rural or urban area).

As for user friendly. In which scenarios would you benefit from using a postal code? If it is an app on a device I assume it would retrieve the GPS data. If it is a person to enter the information is not the city/part of city/address more commonly known?

[jlurien]

For location verification, the idea is to provide the customer with options, and they will decide which area they want to verify. Postal codes are an option in addition to Circles, or other supported areas. The logic to match certain post code with certain geographic polygon must reside on the server, and there may be scenarios where the provided input is not a valid postal code and an error should be responded.

In some countries the postal code is commonly used for localization purposes. For example, some companies serve only certain areas delimited by postal codes. As said, in the end it will be up to a customer to chose the type of area, among the available ones, that fits their needs better.

[bigludo7]

Hi @jlurien @JoachimDahlgren
On additional thought on this topic... From an app developer perspective having multiple way to represent geo zone could be confusing. Should we "enforce" that all telco server implementation must provide at least the "circle" zone ?
This is not something that we can define in the OAS but that we can explicitly state this in the documentation.
Thoughts?

[jlurien]

@bigludo7 It makes sense that all implementations support at least the Circle, which is the simplest option. We can add that to the documentation.

[RogerJL]

On the edge between two postal code areas the accuracy requirement will be meters - one side or another side of a street.
But it will be even worse in the countryside where accuracy is limited but postal areas might be as sharp.
Might be OK if verification is a probability, but I feel this is unnecessary and very complex addition.

[jlurien]

Verification is always a matching between 2 areas, the one provided by the client and one known by the server. Postal codes are polygons instead of circles but the considerations are the same, as if you consider a very small circle vs a big circle as input .

[RogerJL]

I had not noticed the new "partial" response. But there are still problems.

Post number areas, at least in Sweden are for post delivery (like in France), other uses are not considered*.
This leads to frequent changes (recommended database is updated every week).
Swedish post number areas are not simple few polygon points areas but often looks like this
https://postnummer.info/18492/ city
https://postnummer.info/78050/ countryside

And "Postal codes are a common user friendly denominations for known areas", no they are not.
I only know the postal code for my home, in all other situations I would need to look them up.
There should be simpler ways to verify that you are at home...

The only use I see is when adding an object for sale on ebay if they want to verify the address given.
But in that case they could look up the complete address position and verify against that...

• "Postnummersystemets funktion är enbart att stödja en effektiv distribution av postförsändelser. All annan användning av postnummersystemet ansvarar respektive aktör för. Postnummersystemet kan inte anpassas för andra ändamål eller användningsområden än de rent postala."

[jlurien]

Postal codes are country dependent and the use cases are also country dependent. The API does not force clients to use certain type of area, so they will choose what fits better to their interest among the areas supported by the provider. Circles are the simplest type of area and it will be always supported.

[RogerJL]

The API forces the provider to at least consider adding it (provider unique database with polygons is the possible implementation).
The API forces operator to at least consider subscribe to postal number updates and building such a database.
The API forces clients to choose area type, if choosing postal code it will also need to evaluate if all operators in all countries it might be used implements it (now and forever) - if not, they need to provide circle as well...

Additions to APIs have costs.

[chrishowell]

I echo the points above about this not being practical.

Here's a document showing how difficult it would be to implement:
https://www.nrscotland.gov.uk/files/geography/Products/postcode-bkgrd-info.pdf

You couldn't even use the 'centre of a postcode' because that may not even be inside the postcode when postcodes include non-contiguous areas.

By all means any CSP could turn a postcode into a point reference and radius with some API, but I don't think it can be standardised in CAMARA.

[jlurien]

Reopen as issue #83, officially requested by GSMA Product Stream, moving discussion there