You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now each address format has a subdivision_depth, used to determine whether to attempt to load subdivisions of a specific level.
The depth is an integer, which is imprecise, as it requires us to also look up the used fields. For example, "AD" has a subdivision_depth of 1, but the predefined subdivisions are localities, not administrative areas.
Let's replace subdivision_depth with subdivision_data_fields, which is an array of field names.
So, before:
The matching getter (getSubdivisionDataFields) could also replace getUsedSubdivisionFields().
The benefit of this, other than explicitness, is to enable future subdivision data opt-in. For example, we could define administrative areas for Hungary (as PR 208 does), define subdivision_data_fields, but keep administrativeArea out of the format itself. Then, anyone who wants to have these administrative areas (even though they're not required for addressing) could simply alter the format itself (or we could have an opt-in setting on our side), without the need to touch subdivision_depth.
The text was updated successfully, but these errors were encountered:
Right now each address format has a subdivision_depth, used to determine whether to attempt to load subdivisions of a specific level.
The depth is an integer, which is imprecise, as it requires us to also look up the used fields. For example, "AD" has a subdivision_depth of 1, but the predefined subdivisions are localities, not administrative areas.
Let's replace subdivision_depth with subdivision_data_fields, which is an array of field names.
So, before:
After:
The matching getter (getSubdivisionDataFields) could also replace getUsedSubdivisionFields().
The benefit of this, other than explicitness, is to enable future subdivision data opt-in. For example, we could define administrative areas for Hungary (as PR 208 does), define subdivision_data_fields, but keep administrativeArea out of the format itself. Then, anyone who wants to have these administrative areas (even though they're not required for addressing) could simply alter the format itself (or we could have an opt-in setting on our side), without the need to touch subdivision_depth.
The text was updated successfully, but these errors were encountered: