Multiple addresses for single owner-occupied houses with one entry

I am trying to determine how best to handle multiple addresses for single owner-occupied houses with one entry. Similar situations have cropped up in several other areas, but the specific location in question is the planned community of Sunriver, Oregon (USA).

Residential buildings (houses) in Sunriver were originally given house numbers that were equivalent to the lot (aka plot) number on which the building was constructed (hereafter “common” house number) and these remained the only house numbers for nearly 40 years. Today, residential buildings are still physically identified with these common house numbers mounted on the facade (as shown in the following examples) and are used by vacation rental, package delivery, and other service companies, residents, visitors, and trades-persons.

11 Tamarack Lane

7 Cypress Lane

Over a decade ago, Deschutes County began identifying residential buildings using a different house numbering system (e.g. that, it is assumed, is consistent with an addressing grid covering an area larger than the community of Sunriver. These typically five-digit numbers (hereafter “official” house number) are used for residential real estate sales, property tax assessments, utilities, and non-residential buildings.

OSM best practices ( call for people to “map what’s on the ground” or, as Mapscaping says (, “map what the physical world represents…” and “name it so people can go to that place in the real world and see that something is mapped in the right place, and the name and information are accurate”.

It is my opinion that because the common house number appears on buildings in the physical world, it should be placed in the addr:housenumber tag which seems most consistent with the charge to “map what’s on the ground”. Other mappers have placed the common house number in this tag and doing so has the added benefit of ensuring the house number displayed on the buildings appears on the OSM visual map (

However, mapper michael60634 argues the official house number should be placed in this tag “as people outside of Sunriver are not familiar with the local addresses” and that the common house number should be stored elsewhere. For those interested in viewing the entire discussion (along with links to resources and examples), a full copy of the exchange is provided at the end of this message.

Because OSM does not appear to have an adopted standard for dealing with the situation described above and the matter is in dispute, it seems appropriate to seek consensus from the greater OSM community as to how the matter should be handled. Please reply to this post and indicate your response to the following two questions:

1. Which house number should be placed in the residential building addr:housenumber tag (and be displayed on the OSM map)?

a. The common house number (e.g. 11 Tamarack Lane)

b. The official house number (e.g. 57528 Tamarack Lane)

2. How should the other house number be tagged?

a. Use an addr1:housenumber tag (with addr1:street, addr1:city, etc.) consistent with the proposed addrN feature (

b. Use an alt_addr:housenumber (with alt_addr:street, alt_addr:city, etc.) similar to the old_addr:housenumber tag (

c. If the common house number is stored in addr:housenumber, use an addr:official_housenumber tag similar to the official_name tag ( and

d. Add an address point at the same location as the residential building and use its addr_housenumber tag to store the alternate house number

e. Use an addr:alt_housenumber tag (only)

f. Use an alt_housenumber tag (only) similar to the alt_name tag (

Further mapping work in Sunriver is now dependent upon resolving these questions and your participation will help determine the OSM community’s consensus regarding how best to proceed. Your help and input is appreciated!

----- Original exchange (in reverse chronological order) -----

On 2021-09-13 00:08:00 UTC michael60634 wrote:

I still do hold the opinion that the official address should be used, as people outside of Sunriver are not familiar with the local addresses. I’m a perfect example of that. Until I started talking to you about this issue, I had no idea that the lot numbers were used as addresses. Also, I have contacted both the Sunriver Owners Association and Deschutes County and I have asked for their input on the matter. Please do ask the OSM community for their input. Please consider that the people that use OSM and its data come from a variety of places and will not be familiar with an address system that only Sunriver uses. What I mentioned before would still allow for finding houses if the person searches the address.

On 2021-09-13 07:06:35 UTC cgsm wrote:

You remain focused on the addresses used by businesses and, yes, the addresses they use are the official addresses. However, to the best of my knowledge, non-residential buildings never had a common address (it was a strictly residential thing). As a result, there is no question regarding what address to use for non-residential buildings because only one has been available. Use the official address for any and every non-residential building in Sunriver and you won’t hear a word from me.

But the issue here concerns residential buildings in Sunriver and there the common address is used (and displayed). In that case, my examples are entirely on point. The Sunriver Owners Association (SROA) may show the official address for the business, but it refers to residential properties using the common address and non-residential properties using the official address (for example: []( and []( where residential properties are listed as 51 Poplar Lane, 11 White Elm Lane, 12 Tokatee Lane, 6 Cypress Lane, 8 East Park Lane, 5 Fifteenth Tee Lane, 13 Fir Cone Lane, 4 Hoodoo Lane, 4 Redwood Lane, 6 Plover Lane, 19 Aspen Lane, 8 Siskin Lane, 8 Jay Lane, 6 Muskrat Lane, 8 Warbler West Lane, and 3 Towhee Lane while commercial properties are listed as 57850 West Cascade Rd and 57080 Abbot Dr). These are the approved and published minutes of the SROA Design Committee and the official address for residential properties does not appear anywhere in them (additional examples can be found at [](

As for Sunriver Resort ([meta][Community]=Sunriver), it also uses the official address for the business property, but as the link shows, it uses the common address for residential properties (e.g. 4 Topflite Lane, 7 Vista Lane, 6 Yellow Rail, 8 Cherrywood Lane, and 3 Colonial Lane).

The irony is that if I hadn’t been nosing around Deschutes County and found there was an "official" address, everything would be numbered like what is on the houses (the common address) and no one would know any different. In fact, if you go to Loon Lane (or several other streets in that vicinity), you’ll see one or more third parties mapped them and they used the common address with no mention of the official address. Walking down the street and looking at the houses is entirely consistent with that mapping.

OSM best practices ([]( calls for people to "map what's on the ground" or, as Mapscaping says ([](, "map what the physical world represents…" and "name it so people can go to that place in the real world and see that something is mapped in the right place, and the name and information are accurate".

In my opinion, use of the common address that is displayed on homes as the primary address for residential buildings in Sunriver is more consistent with the best practice of "map[ping] what is on the ground".

In fact, one could make the argument the official address shouldn’t be recorded at all (whether primary or alternate) for residential buildings as it is not "on the ground" and does not serve to assist someone in finding a residential location (since the latter is marked with the common address). I thought the official address might be useful at some future date if the data were available, but it may be more problem than it's worth.

    On 2021-09-13 00:21:09 UTC michael60634 wrote:

    I checked the links you provided and even there, the official addresses are used. For example, on the Sunriver Owners Association website, the official address is displayed at the bottom of the page. And Sunset Lodging also shows the official address when you click on the property page for more information.

    Additionally, I noticed that the unofficial local addresses are written differently from how address are usually written. For example, "56912 Vista Lane, Sunriver, OR 97707" vs "16 Vista". Notice how "Lane" is missing. Therefore, I think it is especially applicable to use the alternate address tag that we previously discussed for the unofficial addresses. The data will still be there and can be searched for and found easily, and the address would still be displayed correctly. So, for the tag "alt_addr:housenumber", we could enter "16 Vista", "Vista 16", or "16 Vista Lane" and modify it for individual requirements.

        On 2021-09-12 10:26:26 UTC cgsm wrote:

        Under more "normal" circumstances I would concur, but I think there is a fundamental question at stake–namely, what is the purpose of OSM? Is it intended to display a representation of what is supposed to be that is technically accurate or is it intended to display a representation of what actually is that helps people find where they want to go. Furthermore, when these conflict (as I believe they do here), is it more important to be technically accurate even when that makes finding where you want to go more difficult or is it more important to make it easier to find where you want to go even if it is not as technically accurate?

        Your position seems to favor the former, but I remain unconvinced as it subverts a real world identifier (what is actually on the house) in favor of a virtual identifier that only exists in cyberspace.

        You point to Sunriver Resort, stating that it uses the official address. Yet if you go to rent a house or condo from Sunriver Resort, they use the common address ([meta][Community]=Sunriver). This is true of other rental agencies such as Sunset Lodging ([](, Vacasa ([house]=1&place=/usa/Oregon/Sunriver/), Bennington Properties ([](, Meredith Lodging ([](, and Cascara Vacation Rentals ([](

        The Sunriver Owners Association also regularly uses the common address as illustrated by the use of common addresses by its Design Committee ([](

        Yes, realtors do use the official address, but this is likely due to the fact that all property sales are recorded with Deschutes County and, thus, it is logical (and possibly mandatory) that they use the current County addressing system. However, this is only one industry segment and there are far more service companies that continue to use the common address such as plumbers, electricians, and parcel delivery services. What good is a map that displays one number that doesn't match anything you see when you're actually driving down the street?

        I appreciate the desire for accuracy, but I can't shake the feeling the tail is wagging the dog if a virtual number is considered more important to display than the number that is actually tacked to the building. It seems to me a lot like having an acquaintance steal your car and telling the police to look for a blonde woman because her hair is naturally blonde even though it was dyed auburn at the time. Blonde is accurate as that is her actual hair color, it's what the state records for her, it is shown on her drivers' license, and the police will probably want to include it on her booking record. Yet in the context of looking for her at the time, isn't the fact that on-the-street it looks auburn is more important (even if it is technically less accurate)?

            On 2021-09-11 23:50:20 UTC michael60634 wrote:

            I read your previous message. I was able to find that you are correct regarding how house numbers are displayed within Sunriver. However, I still do hold the view that the displayed address should be the official address assigned by Deschutes County. I say this because most other services use the official address, such as Google Maps, most other online mapping services, any real estate website, the Sunriver Resort itself, and most businesses within Sunriver use the official addresses online. It must be considered that not everyone that is using OSM or its data will be familiar with a local address system that conflicts with most of what is available online and elsewhere. That being said, I think the local addresses should be tagged as the alternative address.

                On 2021-09-10 22:11:00 UTC michael60634 wrote:

                Some community members in the OSM Telegram group ([]( suggested I use "alt_housenumber", but I don’t see any reason why "alt_addr:housenumber" can't be used, and I do agree that it is more fitting than what I used. I don’t recommend modifying "addr:housenumber" as this would likely cause display issues with the official address on the OSM map viewer.

                    On 2021-09-11 22:01:44 UTC cgsm wrote:

                    There does not appear to be much (if any) discussion regarding the use of an "alt_housenumber" tag and there is no mention of it or any other alternative tags with respect to addresses ([]( There is some brief coverage of using an "alt" prefix to handle multiple values ([](, but it includes a cautionary note that while this is "very common and well supported by consumers for name=*, it is much rarer for other tags [where it is] likely not supported by consumers."

                    In fairness, I have been unable to find a better-supported alternative so I don't disagree with your position. However, it is worth noting the alt_name tag ([]( makes reference to an "official_name" tag which is described as containing an "official name that is not a commonly used name" and suggesting "alt_name" be used "if none of [the more specific tags] fit…." Applying the same logic (e.g. an official housenumber that is not a commonly used housenumber) suggests that, in this situation, the commonly used (original) number would go in the "addr:housenumber" tag and the official number would go in an "addr:official_housenumber" tag.

                    It is unfortunate standards do not appear to have been adopted to address various similar situations so each one seems to end up with a unique (and inconsistent) solution (a kind of mapping kludge).

                    I do have some reservations using just "alt_housenumber" as it seems to exist at a different level in the hierarchy. This would put it at the top level along with the building type, name, source, and address keys while the standard housenumber is one level down under/within the "addr" key (hence the use of "addr:housenumber" instead of just "housenumber"). It seems logical this would call for the use of an "addr:alt_housenumber" tag.

                    To complicate matters, addresses that are obsolete, but may still be known, appear to be identified using an "old_addr:housenumber" key ([]( Keeping similar form, this would suggest using an "alt_addr:housenumber" tag. Because this suggests an entire alternate address exists, I would think a full duplication of the "addr" tags would be necessary such as "alt_addr:street", "alt_addr:city", etc. A bit of overkill for this specific situation, but perhaps a better option from a how-to-solve-several-problems-with-one-solution perspective. By putting all of that information in, this would not only provide a resolution to the alternate house number issue, but also the alternate house number and street name issue as illustrated in the example of the corner building in San Francisco.

                    Given the above, I can understand why others seem to have thrown up their hands and opted to use the Common Name field (yes, I understand why that is not proper, but I can appreciate their frustration).

                    At any rate, can you describe the basis for your conclusion that alt_housenumber is a more consistent, accepted, and/or supported tag than addr:alt_housenumber, addr:official_housenumber, or alt_addr:housenumber (and the other tags that would go with the latter)–any of which seem to more closely mirror other, officially-adopted aspects of OSM? An authoritative reference source would be helpful.

                        On 2021-09-11 12:13:22 UTC michael60634 wrote:

                        If it is the case that the lot numbers are used as an alternative address, please use “alt_housenumber” instead of using the name tag. The name tag is for a name of a building, and not an alternative or previous address. For example, “SHARC” or “Sunriver Resort”.

                            On 2021-09-11 09:24:36 UTC cgsm wrote:

                            To clarify, "8" the lot number (for example) should not be confused with "8" the common address. The "8" appearing in the common name refers to an address that is commonly used, not "the lot number…already present as a name in the land use feature". While they do coincide, they are not the same thing. Homes in Sunriver were originally given addresses that were equivalent to the lot number and these remained the only addresses for nearly 40 years. Homes are still physically identified using these original addresses with the number mounted on the facade and they remain in use today.

                            In the 2000's (if memory serves), Deschutes County assigned address numbers to each home consistent with what is assumed to be a larger addressing grid covering an area larger than the community of Sunriver. These (typically) five-digit numbers became the official address, but the use of the original addresses did not stop. The latter became a commonly used address and homes remain marked with them. Thus, homes now have an "official" address and a (second) "common" address. Residents, delivery companies, and others still use, refer to, and rely on these "common" addresses.

                            The Common Name field has been used by others to hold a common address and I have found no best practice for handling buildings that have two addresses simultaneously. Though not exactly the same circumstance, San Francisco also has buildings with two distinct addresses (typically buildings on a corner with facades on two streets and an address number for one street and a different one for the cross street…no, they are not tied to different entrances). This appears to be an ongoing issue with OSM to the point it prompted a proposed feature to allow multiple addresses ([](

                            The Common Name field is described as being used when a building has a common name in place of, or in addition to, an address number and its use for a second house number is not perfectly consistent with that definition. However, it does denote a common use (which is accurate) and results in the display of the Common Name (which is more widely recognized and used) for people who use OpenStreetMap ([]( Having a second address field would be the ideal solution, but until that is accepted I will use an address point for the alternate address.

                                On 2021-09-10 19:52:37 UTC michael60634 wrote:

                                You shouldn't add names to the houses as the lot number is already present as a name in the land use feature.

This is all very interesting, but I’d suggest that the simple on-the-ground rule applies. Map what is visible on the ground, which another mapper can verify. In this case this seems straightforward, you say it yourself, the original numbers are what is visible and most people use. (There are similar cases but without the direct clash, my Uncle’s house now has a number, but no-one uses them; authorities assign house numbers to houses with names, no-one uses them). Check out wikipages on Conscription Number (many houses in areas of the former Austrian-Hungarian Empire have 2 official house numbers), or how residential & business properties in Italy have different sequences of numbering on the same street.

Thank you SK53. I hope others will respond. I’m looking for at least a half-dozen replies to reach a consensus.

The issue was resolved through agreement that the “common” address be stored in the standard addr:* tags and the “formal” address be stored in a set of addr2:* tags pursuant to the proposed “addrN” feature (see

As stated in the proposed feature, “the addr2:* tags etc. are independent from the addr:* tags. That means: addr:postcode=12345 does not imply addr2:postcode=12345 or addr3:postcode=12345.” To be consistent with this provision, all of the addr:* tags are being used for both addresses.

Nevertheless, there is reason to question the practical need for duplicate city, state, postcode, and country tags for additional addresses. In the absence of a real world example of a location with multiple addresses where the city, state, postcode, or country are NOT the same for each address, the proposed requirement that all of the addr: tags be used for each address should be reconsidered.

I’d probably prefer something like addr:official_housenumber or addr:formal_housenumber (along the lines of those other schemes I mentioned) which would allow reusing all the other addr:* tags. Things like addrN are largely frowned upon now, the iD editor created a lot at one time, but they have no obvious semantics so I dont think many apps consume them as data (they may be useful for other mappers, but that is a slightly different thing).

In the UK our more normal problems are to do with multiple street names for a property (which is well-known but there are alternative ideas of the best tag).

I can’t speak to whether addrN is “largely frowned upon now”, but I’d be happy to review any corroborating information indicating addrN is broadly eschewed. The benefit to addrN is that it (figuratively) kills several birds with one stone. In short, it can be used to handle multiple addresses in the following circumstances:

  1. A building with two or more house numbers on a street with one name (e.g. 111 Acme Street and 555 Acme Street);
  2. A building with one house number on a street with two street names (e.g. 111 Acme Street and 111 185th Street); and
  3. A building on a corner with one house number on one street and one house number on a cross street (e.g. 111 Acme Street and 999 Main Street).

I know of buildings that exist in the real world with each of the above issues and I have been unable to find a proposed standard that resolves them other than addrN. In my opinion, I would prefer to see a standard adopted that allows the use of addr:alt_housenumber and addr:alt_street which would resolve the above circumstances. Whether addr:alt_housenumber would require use of addr:alt_street in all cases and vice-versa or whether each would stand alone I’d leave to others more intimately familiar with the database, but I’d think code could implement the logic that if an addr:alt_housenumber exists and an addr:alt_street is absent the addr:street should be used and vice-versa while the other addr:* tags are used in all cases.