Accuracy of a request with a space in postCode

[otsjw]

When we integrated our system with the xLocate service, we wanted to try and get an 'EXACT' result (classificationDescription) by passing in the postCode & houseNumber (UK postcodes only), and if we receive anything else then we simply pass in the postCode alone (in a second request) and take the result (we have the full postcode table loaded on our xServer). At the time we found this to be the best way to get the most accurate result.

Interestingly we found that (due to a change in some of our middleware) %20 crept into our postCode field (replacing the space) and was affecting the result, but inconsistently, I couldn't find any similar problems already reported in the forum.

All testing with UK postCode of 'SS5 6BJ' and houseNumber 148

WITH %20 INSTEAD OF SPACE IN POSTCODE
A. Pass in the postCode & houseNumber, we receive HIGH classificationDescription (with ACCURATE coordinates)
B. Pass in the postCode alone, we receive HIGH classificationDescription (with MULTIPLE results, one matching the first 4x characters of the postcode (i.e. 'SS5 6' - coordinates about a mile out), some not even matching (i.e. 'SS5 4'), I don't know why these are being returned)

WITH SPACE (NO %20) IN POSTCODE
C. Pass in the postCode & houseNumber, we receive LOW classificationDescription (with ACCURATE coordinates)
D. Pass in the postCode alone, we receive UNIQUE classificationDescription (with ACCURATE coordinates)

CALLS
A:

Code: Select all

{
  "addr": {
    "country": "GB",
    "postCode": "SS5%206BJ",
    "city": "Hockley",
    "city2": "",
    "street": "Lower Road",
    "houseNumber": "148"
  },
  "options": [],
  "sorting": [],
  "additionalFields": [],
  "callerContext": {
    "properties": [
      {
        "key": "CoordFormat",
        "value": "PTV_MERCATOR"
      },
      {
        "key": "Profile",
        "value": "default"
      }
    ]
  }
}

B:

Code: Select all

{
  "addr": {
    "country": "",
    "postCode": "SS5%206BJ",
    "city": "",
    "city2": "",
    "street": "",
    "houseNumber": ""
  },
  "options": [],
  "sorting": [],
  "additionalFields": [],
  "callerContext": {
    "properties": [
      {
        "key": "CoordFormat",
        "value": "PTV_MERCATOR"
      },
      {
        "key": "Profile",
        "value": "default"
      }
    ]
  }
}

C:

Code: Select all

{
  "addr": {
    "country": "GB",
    "postCode": "SS5 6BJ",
    "city": "Hockley",
    "city2": "",
    "street": "Lower Road",
    "houseNumber": "148"
  },
  "options": [],
  "sorting": [],
  "additionalFields": [],
  "callerContext": {
    "properties": [
      {
        "key": "CoordFormat",
        "value": "PTV_MERCATOR"
      },
      {
        "key": "Profile",
        "value": "default"
      }
    ]
  }
}

D:

Code: Select all

{
  "addr": {
    "country": "",
    "postCode": "SS5 6BJ",
    "city": "",
    "city2": "",
    "street": "",
    "houseNumber": ""
  },
  "options": [],
  "sorting": [],
  "additionalFields": [],
  "callerContext": {
    "properties": [
      {
        "key": "CoordFormat",
        "value": "PTV_MERCATOR"
      },
      {
        "key": "Profile",
        "value": "default"
      }
    ]
  }
}

QUESTIONS
1. Why are we receiving LOW for test C (with space) and HIGH for test A (with %20)?
2. Why in test B are we receiving results which do not match the first part of the postcode?

We're trying to establish how to code the calls in order to get an accurate response, any advice or suggestions on the matter would be appreciated.

Thanks in advance

[Joost]

The map data we using for xLocate 1 does not have native support for full postal codes in the UK. So they are added in a later step using a different data provider. Unfortunately this data only contains postal code and centroid coordinate. So they can't be matched against the rest of the map. Our engine will look at a request to see if there is a full postal code and if it finds one it will match against the extended data. If this yields no result or no full postal code is detected in the request it will use the the native map data.

To comment on your examples:
A: Engine is using native map data, find an address based on the other fields with matches very good (only postal code string is not perfect)
B: Engine is using native map data, finds a shortened postal code centroid. Since the short postal code looks a lot like your input code it will classify this as high. Essentially the output is almost the same as the input.
C: full postal code is found in the extra data. Comparing the output against the input we see a lot of fields not the same so it will classify the result as LOW. Remember, the extended data does not have city, street and housenumber information.
D full postal code is found and output matched the input so UNIQUE classification.

To come back to your use case:

we wanted to try and get an 'EXACT' result (classificationDescription) by passing in the postCode & houseNumber (UK postcodes only)

This is not something we can do with xLocate 1 due to the data structures it is using. However we do have xLocate 2. xLocate 2 uses a different data structure from out map provider witch does support full postal codes natively. You can have a look at our showcase to get an idea of the xLocate 2 results: https://xserver2-eu-test.cloud.ptvgroup ... g%7C_____1 .

Screenshot of your example in the showcase:

[otsjw]

C: full postal code is found in the extra data. Comparing the output against the input we see a lot of fields not the same so it will classify the result as LOW. Remember, the extended data does not have city, street and housenumber information.
D full postal code is found and output matched the input so UNIQUE classification.

Are you saying we're wasting our time with the the first attempt?
Should we abandon the first attempt and just go with the second, passing in the postcode alone? What if the postcode is unknown in this scenario, would it then make more sense to switch the calls, to send in postcode alone as the first attempt (currently the second attempt) and then the full address as the second attempt (currently the first)?

For the xLocate 2 result, I assume this is included with xServer v2 only (on prem and with our current license, as well as the cloud service you provided the example from), the result is accurate enough but I'd say the result we're getting from xLocate 1 case C / D is closer. We were previously advised to stay with xServer v1 as the change involved significant changes to the calls (we're using xLocate, xRoute, xTour & the maps), if that's still the case we'll remain on v1 providing it'll continue to be supported.

[Joost]

Are you saying we're wasting our time with the the first attempt?

No, but you need an extra step in your evaluation: When you get a result, check the detailLevelDescription. If that is set to EXTPOSTCODE, it means the result has been found in the additional postal code data and you can take this into account when checking how good the result matches.

What if the postcode is unknown in this scenario

It will fall back on using the complete address to look through the normal map data.

For the xLocate 2 result, I assume this is included with xServer v2 only

Correct.

the result is accurate enough but I'd say the result we're getting from xLocate 1 case C / D is closer

Conceptually i would disagree. The postal code data of xLocate 1 can only go to postal code detail, while xLocate 2 can go to house number detail and still maintain full postal code.

We were previously advised to stay with xServer v1 as the change involved significant changes to the calls

Although that still holds up that are a few things to take into consideration:
- we have not been sitting still on xServer 2 and made much improvement since you where advised. I don't know the details of your exact use case (and that is something you should discuss with your consultant directly) but currently in a lot of use case we see that xserver 2 brings extra value over xServer 1.
- you do not have to move over your entire code base at once. You could opt for example only moving over xLocate and save the other services for later. In most cases where you use information from one services to call another service this information is based on coordinates. And a coordinate is a coordinate, not matter which version you use to determine the coordinate.