Refactor Address Suggestion Logic to Improve Readability and Align with Addressing Standards. Fixes #10541 #10561
Conversation
| : d.tags['name:en'] | ||
| ? d.tags['name:en'] // Fallback to English name |
There was a problem hiding this comment.
If I’m reading this code correctly, it doesn’t fall back to name:en, it prioritizes name:en over name. But not every region speaks English; that was just an example I gave. I gave some more details about how you might solve this problem in #10541 (comment). However, the simplest solution may just be to truncate on the first semicolon; we could leave #10541 open to address the linguistic problem separately.
| const value = resultProp && d.tags[resultProp] | ||
| ? d.tags[resultProp] | ||
| : d.tags['name:en'] | ||
| ? d.tags['name:en'] // Fallback to English name | ||
| : d.tags.name | ||
| ? d.tags.name.split(';')[0].trim() // Use the first part of name (split by delimiter `;`) | ||
| : null; // Default to null if no valid value exists |
There was a problem hiding this comment.
I think this code would be clearer if you first refactor the line to use if/else statements instead of a ternary. Nested ternaries are very difficult to reason about. (Besides, without parentheses, I wouldn’t know at a glance whether the order of precedence is actually what you’ve implied using whitespace.)
Fixes #10541
This PR refactors the logic for determining address suggestions to improve readability and ensure compliance with addressing standards. The updated logic falls back to
name:enfor English names, and truncates multi-value name tags at the first delimiter (;) to handle dual names appropriately.