How to use SearchOption STREET_HNRPOSITION

[metin.kahraman]

Hello everybody,

I am currently dealing with address infomation, which includes house numbers in the street field.

For instance like in the following SOAP call:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<findAddress xmlns="http://types.xlocate.xserver.ptvag.com" xmlns:ns2="http://xlocate.xserver.ptvag.com" xmlns:ns3="http://baseservices.service.jabba.ptvag.com" xmlns:ns4="http://wrappertypes.service.jabba.ptvag.com" xmlns:ns5="http://common.xserver.ptvag.com" xmlns:ns6="http://exception.core.jabba.ptvag.com">
<Address_1 houseNumber="" street="HAHNENFUSSWEG 26" city2="" city="BOCHUM" postCode="44797" country="D"/>
<ArrayOfSearchOptionBase_2>
<ns2:SearchOptionBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:SearchOption" param="STREET_HNRPOSITION" value="0"/>
</ArrayOfSearchOptionBase_2>
<ArrayOfSortOption_3/>
<ArrayOfResultField_4/>
<CallerContext_5>
<ns3:wrappedProperties>
<ns3:CallerContextProperty value="PTV_MERCATOR" key="CoordFormat"/>
<ns3:CallerContextProperty value="default" key="Profile"/>
</ns3:wrappedProperties>
</CallerContext_5>
</findAddress>
</soap:Body>
</soap:Envelope>

No matter which value I provide for STREET_HNRPOSITION I always get a response with house number 26.


<ns0:ResultAddress classificationDescription="HIGH" detailLevelDescription="HNRINTERPOLATED" totalScore="87" countryCapital="Berlin" appendix="" adminRegion="Bochum" houseNumber="26" street="Hahnenfußweg" city2="Stiepel" city="Bochum" postCode="44797" state="Nordrhein-Westfalecode" country="D">


I understand why this happens with values 2 and 3 but for values 0 or 1 I do not expect a house number in the response according to what is written in the API-description of the parameter.

Any idea why this is happening ?

Regards

Metin Kahraman
Hermes Germany GmbH

[Bernd Welter]

Hello Metin,

maybe the description of the parameter is a bit misleading. From my understanding it enables users to specify input addresses in various international styles and to successfully find results (and filter away some of them). While Germans usually provide the housenumber at the end of the string "Hahnenfussweg 26" a French or British user might specify a "221B Baker Street" with a leading house number.

Maybe it is a question of the perspective:
Searching for "Hahnenfussweg 26" could return two hits:
- Hahnenfussweg 26 (HOUSENUMBERINTERPOLATED)
- Hahnenfussweg (STREET)

If I specify the housenumber position "search at the end" with "Hahnenfussweg 26" I do not get the hit which is at STREET level. It is a bit like "The algorithm found two candidates but one seems to be matching the pattern better than the other one. This is why STREET is sorted."

Does this help?
Anyway I will forward the question to our experts...

Best regards,
Bernd

[metin.kahraman]

Hallo Bernd,

my actual problem occurs when I do NOT want xLocate to search for a HNR at all by specifiying the value 0 (0 - do not search for house numbers).

In this case Detaillevel is HNRINTERPOLATED and get a house number (where does he get that from ). That's what's beyond my grasp.

Regards
Metin

[bocajo]

Hi Metin

I ckecked the parameter STREET_HNRPOSITION and could reproduce your observation. No matter which value I have entered for STREET_HNRPOSITION the result is always the same. So it seams that this parameter depricated.
Do you really need this parameter? And the next question is why do you need it. Normally everyone likes to have a geocoding result as closely as possible.

Regards
Jochen

[metin.kahraman]

Hi Jochen,

according to the API-documentation this parameter is NOT marked as deprecated.
Can someone from PTV product management please confirm, if this is the case?

Concerning the question "why do you need it" ...

Data for the street field may contain intentional as well as unintentional numerical values (e.g. Strasse 3 , Berlin or typos made by the user) . I certainly do not want PTV to interpret 3 as the house number, when house number is explicitly passed as an argument.

Regards

Metin

[bocajo]

The xLocate should normally treat these automatically.
But in cases where you have a typo in the street name e.g. you are searching for Berlin, Strase 3 the xLocate will find a wrong street. In such a cases it could also be helpful to switch off the parameter SEARCH_PHONETIC. Because if the xLocate doesn't finds the complete input of Strase 3 with the binary search the phonetic search will be activated and than other streets can get a better rating and word 3 is used as house number.

[metin.kahraman]

Hi Jochen,

thanks for your reply.

The question remains, whether this is a bug or a deprecated feature.
Can we get a commitment on this please?

Regards

Metin

[bocajo]

I have to correct myself the parameter STREET_HNRPOSITION is working an has influence on the result. But only for certain requests
If you are searching for City=Berlin and Street=Strase 3 and set STREET_HNRPOSITION=0 you should get a result list with the street Straße 3 and Privatstraße 3. If you set STREET_HNRPOSITION=3 you should get a result list with the street Straßmannstraße and Straßburger Straße and the house number 3.
The xLocate is searching for the best result and is considering always all street house number combinations. If it finds a unambiguous result this will returned no matter what value the parameter STREET_HNRPOSITION has e.g. City=Bochum Street=Hahnenfussweg 26. For the xLocate it is a better result if one word can be matched with the street prefix and phonetic and the second word matches with the house number exact instead of only one word matches exact and the second word doesn't match at all. And in rare cases like Berlin Strase 3 it is better not to consider the addresses with the house number.
Hopefully I could make clear how the xLocate is working and why the parameter STREET_HNRPOSITION has only influence on certain inputs.