Our checkout page had an address autocomplete widget that relied on a third-party API. For French addresses, it worked fine until we started getting complaints from users in rural areas. The widget would suggest the correct street, but when the user selected it, the house number and street name got swapped in the form submission. This only happened with addresses where the street name contained a number, like “Rue du 8 Mai 1945”. The API returned the address components in a different order for these cases, and our parser assumed a fixed order.
We fixed it by switching to a more robust parsing approach. Instead of relying on the order of components, we used the types array from the Google Maps Geocoding API response to identify each part. Here’s the core of the change:
function parseAddressComponents(components) {
const result = {};
components.forEach(component => {
const type = component.types[0];
if (type === 'street_number') result.houseNumber = component.long_name;
if (type === 'route') result.street = component.long_name;
if (type === 'locality') result.city = component.long_name;
if (type === 'postal_code') result.postalCode = component.long_name;
});
return result;
}
This works because the API guarantees that each component has at least one type, and the types are consistent across countries. The trade-off is that we now depend on the API’s type taxonomy, which could change (though it’s been stable for years). Also, some French addresses have additional components like administrative_area_level_1 for the region, which we ignore for now.
But this approach fails for addresses where the street name itself is ambiguous. For example, “Place de l’Église” might be parsed as a route, but in some small villages, the place name is the only identifier and there’s no street number. We had to add a fallback: if no street_number is found, we display the full formatted_address and let the user edit it manually. That increased the drop-off rate slightly, but it was better than wrong data.
One more thing: the API sometimes returns long_name with abbreviations (e.g., “Rue” vs “R.”), and we had to normalize those for display. We ended up using the short_name for the street type and long_name for the rest.
What’s your experience with address parsing in France? Have you found a reliable way to handle the “Rue du 8 Mai 1945” case without hardcoding exceptions?
0 条评论
还没有评论,写下第一条。