Hello TM Forum Community,
We are currently working on the implementation of TMF673 - Geographic Address Management and TMF675 - Geographic Location Management in two Latin American countries: Chile and Peru. During our analysis and initial discussions, a few important questions have emerged that we would appreciate your guidance on.
1. Mismatch between TMF concepts and local geopolitical divisions
The hierarchical administrative divisions used in TMF673 - such as city, locality, and province - do not align with the real geopolitical structure in either Chile or Peru.
In Chile, the correct terms are: Región, Provincia, and Comuna (with Región being the highest level and Comuna being the most commonly used in addresses).
In Peru, the structure is more complex: Departamento, Provincia, Distrito, and even more granular terms like Centro Poblado.
Given this mismatch, we are concerned that this could lead to confusion for the consumers of the APIs, especially external systems or frontend channels.
Our question is:
What is TM Forum's recommendation in this scenario?
Should we try to map these local geopolitical levels to the closest existing attributes in GeographicAddress, even if they do not strictly match?
Or would it be more appropriate to add these local concepts as custom characteristics?
2. Support for CAN and CPN address components in Chile
In Chile, we also have two additional elements that provide precision in addressing:
CAN: A numeric prefix that complements the municipal street number.
CPN: A suffix used to distinguish between buildings at the same address (e.g., "Building A" and "Building B").
We noticed that the GeographicAddress entity includes fields like streetNrSuffix and streetNrLastSuffix, but they appear to be intended for ranged addresses, and do not fulfill the same function as CAN and CPN.
Our question is:
Would you recommend modeling CAN and CPN as characteristics on the GeographicAddress entity?
Or is there a more appropriate way to represent these elements within the standard?
3. Understanding the reference from GeographicAddress to GeographicLocation
Lastly, the team had a question regarding the purpose of the reference from GeographicAddress to GeographicLocation.
Specifically:
What is the intent of this reference?
Should we use it to associate the GeographicAddress with the corresponding GeographicLocation (e.g., a geospatial point or polygon)?
Should the coordinates (lat/lon) also be populated in the GeographicLocation reference, within GeographicAddress?
We appreciate any insights or best practices you can provide, especially from others who may have worked with these APIs in regions with non-standard address hierarchies.
Thank you in advance for your support.
Best regards,
------------------------------
Camila Ahumada
Entel Chile
------------------------------