Length of street substring crucial for quality of Response

[metin.kahraman]

Hello everybody,

I discovered an "unexpected" behaviour when calling findAddress() with incomplete street names (i.e. only a substring/subsequence of the real street name is provided).

Depending on the length of the substring the desired result is either found or not. Although I already opened two support cases I am still unsure whether it is a bug or a feature (would be a weird one). I therefore open this post hoping to get a good insight on what xLocate is doing.

I provide the following two scenarios:

Scenario 1.

Country: Austria
Postcode: 1110
City: Wien
Street: "KAISEREBER"

(SOAP fragment): <Address_1 houseNumber="" street="KAISEREBER" city2="" city="Wien" postCode="1110" country="A"/>

Desired address:

(SOAP fragment): <ns0:ResultAddress classificationDescription="HIGH" detailLevelDescription="STREET" totalScore="87" countryCapital="Wien" appendix="" adminRegion="Wien" houseNumber="" street="Kaiser-Ebersdorfer-Straße" city2="11. Bezirk-Simmering" city="Wien" postCode="1110" state="Wien" country="A">

Scenario 2.

Country: Germany
Postcode: 94330
City: Aiterhofen
Street: "HAUPTSTRA E" (seems an import programs swallowed the german special character "ß")

(SOAP fragment): <Address_1 houseNumber="" street="HAUPTSTRA E" city2="" city="Aiterhofen" postCode="94330" country="D"/>

Desired address:

(SOAP fragment): <ns0:ResultAddress classificationDescription="UNIQUE" detailLevelDescription="STREET" totalScore="100" countryCapital="Berlin" appendix="" adminRegion="Aiterhofen" houseNumber="" street="Hauptstraße" city2="" city="Aiterhofen" postCode="94330" state="Bayern" country="D">

Step 1: I submitted the requests as above to xLocate and what I recieved is to my surprise :

Result 1.

<ns0:ResultAddress classificationDescription="MEDIUM" detailLevelDescription="POSTCODE" totalScore="61" countryCapital="Wien" appendix="" adminRegion="Wien" houseNumber="" street="" city2="11. Bezirk-Simmering" city="Wien" postCode="1110" state="Wien" country="A">

Result 2.

<ns0:ResultAddress classificationDescription="LOW" detailLevelDescription="STREET" totalScore="74" countryCapital="Berlin" appendix="" adminRegion="Aiterhofen" houseNumber="" street="Enggasse" city2="" city="Aiterhofen" postCode="94330" state="Bayern" country="D">
<ns0:ResultAddress classificationDescription="LOW" detailLevelDescription="STREET" totalScore="74" countryCapital="Berlin" appendix="" adminRegion="Aiterhofen" houseNumber="" street="Espermühle" city2="" city="Aiterhofen" postCode="94330" state="Bayern" country="D">
<ns0:ResultAddress classificationDescription="LOW" detailLevelDescription="STREET" totalScore="74" countryCapital="Berlin" appendix="" adminRegion="Aiterhofen" houseNumber="" street="Europaring" city2="" city="Aiterhofen" postCode="94330" state="Bayern" country="D">

=> question marks on my face

Step 2: I modified the input to the street field as follows and re-submitted the requests:

1. (SOAP fragment): <Address_1 houseNumber="" street="KAISEREB" city2="" city="Wien" postCode="1110" country="A"/>
2. (SOAP fragment): <Address_1 houseNumber="" street="HAUPTSTR E" city2="" city="Aiterhofen" postCode="94330" country="D"/>

Result 1.
<ns0:ResultAddress classificationDescription="HIGH" detailLevelDescription="STREET" totalScore="87" countryCapital="Wien" appendix="" adminRegion="Wien" houseNumber="" street="Kaiser-Ebersdorfer-Straße" city2="11. Bezirk-Simmering" city="Wien" postCode="1110" state="Wien" country="A">
<ns0:ResultAddress classificationDescription="HIGH" detailLevelDescription="STREET" totalScore="87" countryCapital="Wien" appendix="" adminRegion="Wien" houseNumber="" street="Kaiser-Ebersdorferstraße" city2="11. Bezirk-Simmering" city="Wien" postCode="1110" state="Wien" country="A">

Result 2.
<ns0:ResultAddress classificationDescription="HIGH" detailLevelDescription="STREET" totalScore="87" countryCapital="Berlin" appendix="" adminRegion="Aiterhofen" houseNumber="" street="Hauptstraße" city2="" city="Aiterhofen" postCode="94330" state="Bayern" country="D">

=> pleasant surprise, here they are , BUT still question marks on my face

1. What on earth is it doing ?

2. Why are the correct addresses found although I provide less information on the street name ?
(or the other way round: Why are the correct addresses not found although I provide more information on the street name ?)

3. Why are there no longer results having street names starting with "E" (as in step 1)?


In scenario 2 things get even funnier when I keep removing characters

street="HAUPTSTRA E" => wrong
street="HAUPTSTR E" => correct
street="HAUPTST E" => wrong
street="HAUPTS E" => wrong
street="HAUPT E" => correct

=> total confusion . Words fail me for further questions ...

Support tried to explains the behaviour (PTV169721,PTV195902) but I somehow don't get the logic behind this.

PLEASE HELP !!!


Regards

Metin Kahraman
Hermes Germany GmbH

[MISTERX]

Dear Metin,

as far as I know:

xLocate (V. 1) handles words like "Straße" as affix. That means this part is considered as not very significant and will by removed from the significant part (e.g. "Hauptstraße" will be reduced to "Haupt". By looking up the index with "Haupt" and the affix "straße" xLocate gets a perfect match).

An input like "Hauptstraß" is bad, because the xLocate can't find the affix "straße" any more! Looking up the index with (now) "Hauptstraß" there will be no match. In this case you have to use FUZZY-Search!

Does this help to understand your results?

If you have received similar answers from PTV-Helpdesk - ignore my post, but keep us (the community) informed if you get additional or other explanations.

[bocajo]

It's absolutly right what Mr. X has written. And additionally str is abbreviation of straße so this explains why Hauptstr and Hauptstraße will be found but not Haupts, Hauptst, Hauptstra or Hauptstraß.