addr:interpolation on closed ways and nodes
Proposal status: Proposed (under way)
Proposed by: IpswichMapper
Statistics:

Draft started: 2020-12-21
RFC start: 2020-12-21 & 2021-01-03

## Proposal

addr:interval=* indicates that the "addr:housenumber" tag is alternating in some form. It should only be used in conjunction with addresses that have hyphens or vertical bars ( | ) in them.

• addr:interval=no would indicate that the "housenumber" tag contains a single housenumber and not a range of numbers (e.g. 192-10). See "Queens, New York" for example of such addressing.
• addr:interval=even would indicate it contains every other number (i.e. 40, 42, 44, 46, 48) (you can use addr:interval=odd for ranges of odd numbers e.g. 41-18)
• addr:interval=4 would indicate it contains every 4th number (i.e. 40, 44, 48) (same way, if the value of addr:interval is a number, this indicates it increments up by that number each time)
• addr:interval=all would indicate every housenumber is contained (i.e. 40, 41, 42, ...)

#### What if addr:interval isn't specified?

If this proposal is accepted, it will take a while before a majority of housenumbers are tagged with addr:interval=*. This means that geocoders and renderers will need to find a way of interpreting housenumbers with hypens in it when there is no addr:interval value.

Here are some suggestions:

The geocoder or renderer could guess whether it is a range or not. It can be smart about this - a housenumber with value "190-10" is unlikely to be range, because the second number is lower than the first. Therefore, that is probably a single hyphenated housenumber.

In countries like the UK, a hyphenated address almost always means a range of housenumbers that go up in increments of 2 (e.g. 40, 42, 44 etc). Again a intelligent geocoder could guess this.

The other option is to not do ranges at all, and only return a result when the start or end housenumber is typed in (for example, typing in "42" will not return "40-48".) This is what Nominatim currently does, even though it isn't ideal.

What if you wanted to map a range of hypenated housenumbers (e.g. 192-10, 192-12, 192-14, 192-16, 192-18)?

Are there any ways of being more clear about ranges of housenumbers (than using a hypen)?

Here are some "mini-proposals". Discuss which one of these is the best (or if any of them are good) in the mailing list.

#### Option 1

Also, accept the usage of "vertical bars" ( | ) as alternatives to hyphens to more explicitly indicate that a housenumber is a range. (Note, hyphens for ranges will still be accepted, just simply vertical bars can be used as well.)

The problem is, if geocoders do not understand this type of syntax, then searching for addresses will become difficult. Addresses would also be displayed in a confusing manner (what does vertical bar mean?)

Using vertical bar is also uncomfortable to type. Adding a few addresses this way may not be a problem, but adding rows upon rows of flats using vertical bar syntax may be strenuous.

Geocoders and renderers need to be able to parse the vertical bar as an equivalent of a hypes (when searching). In a list of search results, it should use either a hypen or the "to" keyword (e.g "40|48" on "test street" can be shown as "40 to 48, test street"

This can record a range of hyphenated addresses.

This would indicate this range of housenumbers:

190-10, 190-12, 190-14, 190-16, 190-18, 190-20

Simple ranges can be still specified with hyphen, for example

would indicate range including 190, 191, 192, 193, 195, 195, 196

#### Option 2

Use tags addr:interval:from=* and addr:interval:to=* to indicate to lower bound and upper bound of a range of housenumbers, along with addr:interval=* to indicate the common difference (as explained above).

This can easily record a range of hyphenated addresses.

For example:

This would indicate this range of housenumbers:

190-10, 190-12, 190-14, 190-16, 190-18, 190-20

These are new tags (harder to get used to & accept within the community as well as for geocoders/renderers) as well as being relatively long.

Also, if housenumbers are only stored this way then they won't show up without geocoders being able to understand this syntax. (So if would also be a good idea to use addr:housenumber as well, although one may want to discourage such usage to nudge geocoders and renderers to support this new format.).

#### Option 3

Use addr:housenumber:range=* to indicate that you are referring to a range of housenumbers, no a single hypenated address.

The problem with this is that you can no longer specify a range of hyphenated housenumbers (as shown above). It is also a new tag (harder to get used to) as well as being quite long.

Use

## Rationale

Currently, if a housenumber is a range is unclear. Even if we consider addresses with hyphens as ranges of housenumbers (not always true: see "Queens, New York"), no one knows if the range includes every other number (e.g. 40, 42, 44 etc) or every single number (40, 41, 42, ...). addr:interval would clarify that.

This proposal would also introduce a clearer way of mapping housenumber ranges.

Note that this proposal is not replacing addr:interpolation=* in use for temporary tagging before proper survey of house numbers.

Right now it is unclear is addr:housenumber=1-31 used in meaning "addresses 1, 2, 3, 4, 5, ... to 31" or "single address '1-31'". There is no way to specify this, and both meanings are in use.

Proper tagging scheme would allow to fix some related longstanding issues in address searching.

## Applies to

closed ways (ideally buildings) or nodes.

## Changes needed

• Clarification on the wiki
• Probably a new wiki page specifically for the tag addr:interval=* to explain how it is used in different contexts.

After the proposal is accepted, this needs to happen (otherwise this proposal doesn't serve much use):

• Nominatim, osm-carto need to be able to understand addr:interval as well as whatever housenumber tagging scheme from the three options are accepted
• Notify mappers of this tagging scheme.
• Get other software (e.g. photon, OSMand etc.) to support this.
• Possibly StreetComplete support?