[streetName] No way to indicate the type of the street

[GillesInnov35]

Problem description
streetName description recommends to not include the type of the street.

streetName:
type: string
description: Name of the street of the customer's address. It should not include the type of the street.

Th only way to specify the street type is to provide the full address

Possible evolution
Add a streetType attribute

[KevScarr]

@GillesInnov35 Assuming a type is (Road, Avenue, Lane, Way, Place?) is this suggesting a road name of 'Northfield Road' should be submitted as only 'Northfield' instead of it's full street name?

[GillesInnov35]

@KevScarr, that is what I understand in "It should not include the type of the street" but it is not so clear for us where indicating the type.
Currently at Orange France we only use the full address, including the street type. If it is the only way to specify th street Type, we should perhaps complete the address description with this information before adding a new streetType field.

What do you think about that ?

Thanks
Gilles

[HuubAppelboom]

@KevScarr @GillesInnov35 at KPN it will be very difficult to filter out the street type from the street name.

Sometimes the word for the type of street is concatenated with the street name. sometimes it is seperate.
For example you can have "Laan der Verenigde Naties", where "Laan" is the type of street, but you can also have "Vlaanderenlaan".

I don't know where this idea comes from, but I would not suggest to split it this way. You will get a long list of possible street types, depending on language, and which is difficult to maintain.

For the name of the street, just use the official way it is supposed the be written (and let the Telco decide on the local normalisation that should take place, if any).

[AxelNennker]

I suggest removing "It should not include the type of the street." and let the API producer decide what works.

---

There is a long history of standardization organizations trying to standardize addresses/location.
inetPerson, inetOrgPerson in LDAP and ActiveDirectory
VoIP emergency https://datatracker.ietf.org/doc/html/rfc6443 good discussion

OpenId Connect Core address claim https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim

German id card https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03130/TR-03130_TR-eID-Server_Part1.pdf?__blob=publicationFile&v=3

[GillesInnov35]

Thanks a lot all for your comments and advices.
I'm afraid in many cases match score result for address or street location may be low if we don't specify any recommendations (a minimum).
Regarding what has been described in the address description we could had something for street type.

address:
type: string
description: Complete address of the customer. For some countries, it is built following the usual concatenation of parameters in a country, but for other countries, this is not the case. For some countries, it can use streetName, streetNumber and/or houseNumberExtension. For example, in ESP, streetName+streetNumber; in NLD, it can be streetName+streetNumber or streetName+streetNumber+houseNumberExtension.

Last point: Should we have to add streetType field as it is in TMF geographic address API to be clear ?

BR
Gilles

[claraserranosolsona]

Hi all,

The "It should not include the type of the street" comes from Mobile Connect pilots in the different markets, where it was seen a very high ratio of false responses due to the street types introduced:

• Sometimes the street type is introduced by the customer sometimes not
• And there are multiple ways of writing the same street type i.e. street, st.

That is why it was proposed to remove street type as part of the normalization, and as in Mobile Connect the customer data was not usually normalized by the MNO, it was specified to the customer together with the other set of rules.

Now if in the CAMARA version we are normalizing both (MNO and customer data), this filtering could be handled internally in the MNOs.

Regards,
Clara

[HuubAppelboom]

@claraserranosolsona In the CAMARA version this can indeed be solved better by the MNO's, as part of the normalisation process, because probably what you need to do will differ per country.