Secondary address unit designators

Communities United States
21

What if the existing unit was kept undesignated, and with potentially nonstandard notation such as 1201 (Building 12 unit 01), 1LR (Unit 1 Left Rear), Rear (Rear), and so-on (ideally based on what on-the-ground signage like mailbox labels puts them as), and a new subkey addr:unit:full was added where the full designators could be spelled out. This allows the multi-value syntax to still remain for multiple addresses, and continues easy short labels for maps, at the cost of data duplication and less-structured data. It’s also fully incremental from existing practice.

Keep addr:unit the unprefixed, short form, in the manner signed on-the-ground for more complex entries (a la 12-01 or C20). In a new key addr:unit:full spell out the full specifier. So:

  • addr:unit:full=Apartment 3 addr:unit=3
  • addr:unit:full=Unit 2 Rear → addr:unit=2R or addr:unit=2 Rear depending on what signage indicates it as
  • addr:unit:full=Building A Unit 52 → addr:unit=A52 (or otherwise as signed)

The designators inside *:full might want to be standard abbreviations, but I put them spelled out on the principle that it’s easier to abbreviate than expand.

22

This approach neatly solves the issue of multiple secondary addresses, which as you note often take short and long forms. A renderer could use either addr:unit=* or addr:unit:full=* (abbreviated on the fly) depending on design decisions or available space. A geocoder would use only addr:unit:full=*, falling back to indexing “Unit” + addr:unit=* or “Suite” + addr:unit=* as a guess.

Would addr:floor=* still be tagged redundantly or would we avoid using that key, unlike in other countries?

The editor UI for addr:unit:full=* wouldn’t be quite as obvious. Editors like iD already lack a field for addr:full=*.

1 Like