There appears to be a bug that stops searches by address from returning any results when the street name field begins with "CNR". This applies to at least the ICP connection data API (and so also "My meter" page). No amount of fiddling with wildcard searching or similar seems to help and I haven't found any documentation that might explain this.
For one example: 0000022666WE053, 44,CNR HORSHAM DOWNS ROAD,Rototuna North,HAMILTON,Waikato
Due to other details I've observed (decommissioned ICPs on some particular networks where all have had their addresses stripped, *except* for the "CNR" cases) it looks to me that the underlying cause might be deeper than the API itself. Perhaps the underlying index has garbled info for these cases, or they have been excluded altogether, although I cannot even begin to imagine why that would the case.
Clive Gifford
- Retail
- Bugs in ICP connection data API (or deeper)
Bugs in ICP connection data API (or deeper)
- 924 Views
- Last post 19 July 2020
- #Permalink
- 0
- 0
- 0
Hi Clive,
We've taken a look and can sympathise. As you suggest it is deeper than the ICP connection data API and we'll be raising it with our market operation service provider for the registry to follow up on. I'll post something back here when I hear more. However, I do note that they are very busy implementing a range of changes at the moment so it may take some time to get some developer resource to investigate.
Regards,
Matthew
- #Permalink
- 0
- 0
- 0
Thanks for checking that out Matthew.
Here's another oddity. An example is given by searching for 46 A, Queen Street, Dunedin.
The initial list of matches on the "My meter" page currently shows three records, with the word "Unit" in front of the three unit numbers. For the first, like this:
Unit 4, 46 A Queen Street, Dunedin 0000002382DE965
However the API results for the same search parameters do not have the "Unit" prefix before the unit numbers. Instead, for the same ICP, I get this:
{"Address":{"PhysicalAddressUnit":"4","PhysicalAddressNumber":"46 A","PhysicalAddressStreet":"QUEEN STREET","PhysicalAddressSuburb":"","PhysicalAddressTown":"DUNEDIN","PhysicalAddressRegion":"Otago","PhysicalAddressPostCode":9016,"GPS_Easting":0.0,"GPS_Northing":0.0},"ICPIdentifier":"0000002382DE965","ICPStatus":2,"Messages":null}
What lies behind this? Are you able to provide all the logic/rules that could produce "anomalies" like this, and also explain the reason for them?
Thanks,
Clive
- #Permalink
- 1
- 0
- 0
- Liked by
-
Hi Clive,
The original issue you posted on above (the CNR issue) has been resolved in the registry so you should have more luck now.
Your second issue immediately above is simply due to the coding of the web application on the Authority website that consumes the API. They are trying to be more helpful to general users of the site and as such, aren't really anomalies at all. The API gives you the raw contents of the fields and all subscribers of the API are welcome to write your own code to process the data for their application or analysis.
I hope that's helpful.
Cheers,
Matthew
- #Permalink
- 0
- 0
- 0
Hi Matthew
Thanks - I will test the fixed CNR issue soon. Just out of curiosity, can you expand on how that came to be an issue?
I understand what you are saying with respect to the second item I raised, but the word "Unit" appears to not always be inserted, only (I guess) perhaps when the unit number field is purely numeric, and similarly perhaps also the street number field.
However this breaks the "what you see is what you should get principle" (maybe I just made that up!) and could cause confusion. It certainly confused me when I first noticed it.
Consider the following scenario, where a consumer is using the "my meter" page, and perhaps they live in unit 345 of some large apartment building in Queen Street, Auckland, lets says with a street number 666 (because the devil lives there also). They might start by only searching for 666 Queen Street, Auckland, leaving the unit number empty (perhaps because they are not sure how to enter it). What they could get back is a long list of ICPs that match on that street number, but because the results are also truncated (max 200 records) their own unit might not be included. So now they are possibly looking at a long list where each says something like "Unit 1, 666 Queen Street..., Unit 2, 666 Queen Street..." etc.. So now the consumer realises he needs to put in a unit number, and naturally tries "Unit 345" which will fail, because "Unit" is not actually in the real underlying unit number field. He has been misled by the added text.
Maybe not a common scenario, but certainly potentially confusing.
But then of course any consumer trying to find an address without a unit number or street number (and there are many thousands of those) can't find anything because the "my meter" page requires something in that input. I suggest that should be changed if the EA is serious about that page being more usable for all consumers trying to find their address.
Thanks again,
Clive
- #Permalink
- 1
- 0
- 0
- Liked by
-
Hi Clive,
Following up on these two items:
- I'll ask someone from our market operations team who work with our service providers to get back to you on the background of the CNR issue.
- I'll pass on your feedback about the unit to the team looking after the my meter page.
Cheers,
Matthew
- #Permalink
- 0
- 0
- 0
Hi Clive
With regard to the CNR issue, specific street name constructs are excluded when ICP’s are stored in the address search index as they are not valid street names (CNR, CORNER, etc).
Where an invalid first token is supplied the registry stores the street name in a top-most index using the 2nd token, for example “CNR Phillips street” is stored in a high level “Phillips Street” index, the actual address (which still includes the CNR portion) is stored in a secondary index and able to be retrieved during the lower level search.
The search agent was not recognising the CNR token when searching the secondary index. This error appears to have been introduced in a change made in November 2013 and has been corrected. We publish the registry UAT and Production release notes on our registry webpage.
cheers
Nicole
- #Permalink
- 1
- 0
- 0
- Liked by
-
Thanks for that explanation Nicole (and to Matthew earlier).
Again I have to wonder at the reason for introducing "irregularities" like this. I suppose the underlying motivation is some kind of performance improvement when searching but there are ugly side effects also.
At least one distributor (MainPower) seems to prefer to use "COR" instead of "CNR", possibly because of earlier problems with "CNR". "COR" appears to not not be handled differently from any other text and you can (for example) search only on "CO", or "COR", with some other details such as street number/region etc., and get a sensible result. On the other hand (and this was the very first thing I tried to do after Matthew said the issue was fixed, leading me to initially think it wasn't actually fixed!), searching on just "CNR" (with, say, 44 for the street number, "Hamilton" for town, still just returns "An error occurred" even though on the face of it the information provided should have been enough to get a match.
To get something sensible back the input seems to need to be CNR plus a bit more, but no documentation or message explains that. (Except your post above, which I doubt will be found by many.)
Can you please post a list of all such special "tokens" here, or point me to the location of the full list.
Thanks,
Clive
- #Permalink
- 1
- 0
- 0
- Liked by
-
Hi Clive
The tokens include the following:
CNR
CORNER
ROAD
RD
STREET
STRT
AVE
TCE
AND
TERRACE and AVENUE are both recognised as valid if a first street name e.g. Terrace Downs.
Reviewing the address quality in the registry is a roadmap item we are discussing with the registry manager. The registry manager will be performing analysis on the address accuracy in the registry - this will help us size the problem. Timeframe for this has not yet been formalised.
Regards
Nicole
- #Permalink
- 0
- 0
- 0
Hi Nicole,
Better late than never, so thank you.
You wrote (my emphasis) "The tokens include the following", but I asked for a list of all such special "tokens".
Just to be clear, is the list you provided above all of the tokens, or something less than all?
Thanks,
Clive
- #Permalink
- 0
- 0
- 0
Hi Clive
Good point. I've checked with the registry manager and the list includes all of the tokens.
Regards
Nicole
- #Permalink
- 0
- 0
- 0
Thank you very much for confirming that Nicole.
I must have a different issue then (as below), and would appreciate an explanation and fix for the following inconsistent behaviour.
If you search on the "my meter" page (or through the ICP Connection Data API - v1 or v2) for say "1 Rur" you get the following few records returned, and no more:
164 Rural Awahuri Road, Feilding, Manawatu (house) 0000054109CP8D4
178 Rural Awahuri Road, Feilding, Manawatu 0000054114CPD22
182 Rural Awahuri Road, Feilding, Manawatu (house) 0000054115CP167
192 Rural Awahuri Road, Feilding, Manawatu 0000054117CP1E2
However if you search for "1 Ruru" you get far MORE records returned which clearly is not expected, starting with...
12 Ruru Place, Tokoroa, Waikato 0000004718UNFDD
10 Ruru Place, Tokoroa, Waikato 0000004719UN398
1 Ruru Place, Tokoroa, Waikato 0000004724UNB3B
11 Ruru Place, Tokoroa, Waikato 0000004729UN460
13 Ruru Place, Tokoroa, Waikato 0000004730UN09C
10 Ruru Avenue, St Leonards, Dunedin, Otago (residence) 0000011858DEFB9
...
This really does have the smell of "Rural" having some kind of special handling.
- #Permalink
- 0
- 0
- 0
