Preface

See Proposed features/House numbers/Karlsruhe Schema for a variant that is actually being used and rendered.

Older suggestions and votings on them, ending in a rejection, have been moved to the discussion page to make it more likely that we'll come to some conclusion sooner than later.

Map_Features lists the tag place_numbers=* (see Key:place), which by the given example, contains only the range of numbers found on that node/way/area. Tagwatch shows currently very few uses for it.

From all the suggestions so far, following requirements for a successful numbering scheme have been raised:

• Be easy to use for mappers
  • Few exact numbers and interpolation is sufficient for many, if not most cases
• Be reasonably resilient against accidents (reversing way, splitting, merging, ...)
• Limit the amount of redundant information entered
  • nodespam, i.e. don't add 5 nodes for every intersection
  • doubling the numbers at connecting nodes of several consecutive ways of the same street (first number of one way is the same number as the last number of the "previous" way)
• Allow exotic numbering schemes (not only numbers but "3a,3b" etc.)
  • Access to a house can be from a way other than the one which the number belongs to
  • Preferably have some way to tell which side of the way each number resides. Consensus seems to be to use the values 'left' and 'right', yet they need to be defined:
    • relative to the direction of the way (editors need to be aware of the tags when reversing a way) or
    • relative to the direction of increasing numbers (apparently more preferred)
      • What about case 3 below? Direction of increasing numbers starting from the smallest value?
  1. odd/even on left/right
  2. 1 to n/2 on left/right, n/2+1 to n on the other side
  3. ascending on the other side and descending on the other side
  4. practically random
  5. Allow for tagging of blocks of flats. --Grumpylump 12:47, 20 July 2008 (UTC)
• Allow tagging individual address numbers where needed
• Be compatible with possible imports of house numbers from TIGER data or some other source
  • No information was easily found on the format for house numbers used in that data
• Most likely relations are needed, because the information on house numbers in most cases links multiple ways together. Some of the first proposals tried to encode the data in the tags only.

Third Suggestion (Using relations)

With the relations structure in the 0.5 API, this seems like a perfect application for it. You could associate house numbers with a way at a particular node. It would look something like this:

<relation id="42">
  <member type="node" ref="553" role="" />
  <member type="way" ref="104" role="" />
  <tag k="type" v="street_number" />
  <tag k="street_number_left" v="10" />
  <tag k="street_number_right" v="11" />
  <tag k="number_left_type" v="even" />
  <tag k="number_right_type" v="odd" />
</relation>

The way member could alternately be a superway relation which links multiple way sections of a longer street. The number_left_type or number_right_type could be odd, even, both, or single. The "single" type would be used to number single addresses which are not part of a series.

The advantage of numbering a single node on a way is that it only requires a few points to be numbered to give relatively good accuracy if the addresses are regularly spaced. The addresses between the points can be inferred by interpolation between the numbered points. Additional numbered points can be added in-between to refine the addresses. It also puts less of a burden on mappers--they only have to enter a number at a single point.

Left and Right are relative to the way direction, so this structure is sensitive to way reversal. Some refinement might be necessary (like making the left and right tags into a namespace instead, such as left:street_number) so the editors can detect direction-sensitive tags and prompt the user when switching the way direction.

--SiliconFiend 17:14, 22 December 2007 (UTC)

Sounds reasonable. But do we really need the left-right-tags? In the simplest case, we could place one node on each side of a street, tagging them as "even" and "odd". This would remove the dependency on the way direction. I dislike to use the latter one for indicating numbering directions and even for oneway directions. It potentially causes troubles. SlowRider 18:03, 24 December 2007 (UTC)

Yes, they are necessary. The node has to be part of the way in order for this to work, therefore you can't place the nodes on each side of the street because then they won't be part of the way. --SiliconFiend 06:53, 25 December 2007 (UTC)

But, if using relations, the node doesn't need to be part of the way and it'll still work, so SlowRider has a point... Dtucny 04:20, 26 December 2007 (UTC)

If they are not part of the way there is no longer a clean way to place the numbers on the way, thus no location to route to (finding the nearest node on the nearest part of the way before solving the regular number-placement for all ways of a map-rectangle in order to render it takes too much time.).

Fourth Suggestion (Buildings)

Another idea would be combining this with buildings. Use relations to tie the building/entrance to a way and put ref=xyz on entrance nodes. --Onion 11:46, 26 October 2007 (BST)

Fifth Suggestion : Simple by Nic

• Tag keys : address0, address1, ...
• Tag values : free format, for example address0="326 Edna Street", address1="Lynnwood Park", address2="0081"
• Applies to : nodes and areas

Implementation :

• The idea is to add one or more interpolation tools to JOSM so that users can rapidly create one node for each house / property.
• In the majority of cases those nodes will not need to be connected to the highway network, because routing programs can easily determine the nearest highway to an unconnected node. Only when there is ambiguity will a user need to add a short 'service' highway to indicate the entrance.

I dislike the idea of extra service ways for questionable house numbers. A house's entrance/access can be via road A only, while its number belongs to road B. SlowRider 18:20, 24 December 2007 (UTC)

Advantages :

• What you see is what you get. No messing with 'left / right' or relations.
• If we also allow 'plot_number', 'portion_number' and 'farm_name' tags, our database can be used for property registration / transfer research.
• Every situation can be modeled.

Disadvantages :

• Slightly more load on the database.
• To prevent clutter, we may need to change the other editors or the API to hide all nodes with only address tags and not forming part of any way.
• This is okay for giving an address to nodes or buildings, but it would be nigh impossible to make this work with the address finding function on navigation devices, which is a big reason for doing this in the first place. --SiliconFiend 04:37, 24 December 2007 (UTC)

Case Study: Albuquerque

Some cities (eg, Albuquerque NM USA) release street address information publicly (http://www.cabq.gov/gisshapes/README). The format Albuquerque uses (run though "ogrinfo -al") is:

OGRFeature(ptadd):73

 AREA (Real) =              0.00000
 PERIMETER (Real) =              0.00000
 PTADD_ (Integer) = 74
 PTADD_ID (Integer) = 74
 LOT (String) = 5-P1
 BLOCK (String) = 9
 SUBD (String) = PARK HILL UNIT 2
 ADDRESS (String) = 11101    MILKY WAY            ST   NW
 APT (String) = (null)
 PIN (String) = (null)
 HOUSE (Integer) = 11101
 STREET (String) = MILKY WAY
 DES (String) = ST
 QUAD (String) = NW
 ACRES (Real) =                 0.15
 POINT (1504147.628 1534660.343)

This suggests a simple node format (as the fifth suggestion above notes, no worrying about what side of the street the number is on, whether the street is close to the number, etc), with tags like street_number=11101, street_name="MILKY WAY", street_type="ST", street_quad="NW", street_full="11101 MILKY WAY ST NW".

Since much of this data should be available from city planning divisions, we don't have to worry about people entering these a few at a time: people can bulk upload from public domain data.

We could even use this as an "ad hoc" format and add relations later.

I think the most important thing is to get the data uploaded ASAP, and worry more about formatting issues later (we don't want to be omitting large amounts of publicly available data). We can always add a "adhoc_street_address=yes" tag to flag those nodes that are in this ad hoc format.

Issues

The following issues have come up so far:

• using nodes/shapes only

this make a LOT of work that many (most?) volunteers may not be willing to do. (20 street with >100 houses anyone?)

thus we need a simple enough "usual case" that does not lead to node-spam.

• referencing ways

ways are often edited by splitting, combining or reversing them

this may be an issue we simply have to live with

• special cases

houses may not be near the way their address is in. Thus in special cases they must be relatable to the way without being a part of the way.

house-numbers may not all be numbers (think "8b")

We need to support lots of special cases in a unified way. This need not be the default-case.

• relations or tags

there is no consensus yet whether we should use a relation or tags on ways+nodes to store this information yet

Voting

Voting 2c

To address the concerns of the last proposal, I propose a modified version.

The tags are more prescriptive and shorter.

The "type"-tag is consistent with other relations we already have.

A series is possible for very irregularly numbered streets.

Irregular single houses alone or in a regularly numbered street are possible with minimal effort.

To easily tag ways and parts of ways with house-numbers:

 <relation id="??">
  <tag k="type" v="house_numbers"/>

[optional  <member type="node" role="from" ref="??"> <member type="node" role="to" ref="??">  ]

[  <member type="way" ref="??"> or 
  <member type="relation" ref="?superway?">  "superway" must group consecutive ways without holes]

  <tag k="left_type" v="[even|odd|all|series]" />

[for "even" "odd" and "all":
  <tag k="left_first" v="2" />  if the given number is not odd(/even) the next higher one is used
  <tag k="left_last" v="5" />  if the given number is not odd(/even) the next lower one is used

   or

  <tag k="first" v="2" />
  <tag k="last" v="5" />
]
[for "series" or if no "left_type" given
  <tag k="left_numbers" v="2,3,7" />
]

  [same for right side]

 </relation>

As a special case to tag a single house on node HH standing alone:

 <relation id="??">
  <tag k="type" v="house_numbers"/>

  <member type="node" role="from" ref="HH">
  <member type="node" role="to" ref="HH">
  <member type="way" ref="??">

  <tag k="left_numbers" v="42b" /> or <tag k="right_numbers" v="42b" />
 </relation>

• HH may be a node of the way and it may be no node of the way if the house is off the side.

• Houses are considered to be equidistant segments of the way for the regular case.

• The same way can be tagged with multiple relations but the regular ones are not to overlap. Precedence is not defined in that case.

• If both are tagged then the single-houses are to be evaluated first and then the regular case is to be evaluated for all remaining houses (equidistant segments of the way).

incompletely tagged relations (a warning shall be displayed if possible, support for these cases is not mandatory)

• if "[left|right]_numbers" is given we assume "[left|right]_type" to be "series"

• if no "left_type" and "right_type" are given we assume even=left and odd=right

• if left_type is "series" and right_type is "even" all even numbers of the series are not considered to be part of the right side

• if the "to"-node does not exist, we assume the last one after "from" in the direction of the way to be the start (and vice versa)

• if both do not or no longer exist we threat them as not given at all.

• if no "first" is given we assume 1

• if no "last" is given we assume "first" + the number of nodes in the street (after but not including the start_node).

• if the start_node is the last node of the way, we assume a single house

• if multiple ways are given the parser shall try to find an ordering, such that the form one consecutive way.

example: (Numbers noted down by a mapper from the street-sign for a short way)

 <relation id="??">
  <tag k="type" v="house_numbers"/>

  <member type="way" ref="??">
  <tag k="left_type" v="even" />
  <tag k="right_type" v="odd" />

  <tag k="first" v="2" />
  <tag k="last" v="15" />
 </relation>

COMMENTS

Votes

vote-start-date: 2007-12-17 (to allow for comments and slightly modify the proposal by anyone before the vote starts)

vote-end-date: 2008-01-10

PRO

• --MarcusWolschon 08:56, 17 December 2007 (UTC)
• ...

CONTRA

• I don't have time right now to modify the proposal, but I'm strongly opposed to a making street numbers a range with "first number", "last number". It's unnecessary, causes data duplication (and therefore more potential for error) and puts more burden on the mappers. You can accomplish the same thing with two numbers at two nodes, and it also lends itself to more incremental refinement. I like the superway idea, though. --SiliconFiend 17:56, 16 December 2007 (UTC)

What do you mean with "two numbers at two nodes"? How would you go about finding these 2 nodes manually in an editor, given a way? Start- and end-node are often intersections. Which of the ways would they refer to? --MarcusWolschon 08:56, 17 December 2007 (UTC)

• I still recommend to use relations to tie it to a particular way. Look at my original proposal earlier. My point is, you could use this relation to indicate one number at one node on the end of a way (or superway), and another relation at the other end (which could be many miles/kilometers away). That's what I mean by two numbers at two nodes. If the street numbers fall in a very regular pattern, then you're done. If they are more irregular, then additional points can be numbered in between the endpoints, to refine the simple interpolation. It's very easy for mappers to do this--go to an intersection, see what house numbers are there, and add them at that point. They only need to know the number at that point and nowhere else. House numbers are primarily going to be used by machine parsers, so the simpler the scheme, the better.

Sounds like it could work. Where would you store the numbering-schema applied(even/odd, left-up+right-down, ...) How to find what way these 2 refer to? Can you find the way for a given number+street-name without loading all nodes and without recursion (limitation of SQL)? Should this proposal not be accepted too, please clarify all points and make a new complete and unambiguous proposal.--MarcusWolschon 17:46, 18 December 2007 (UTC)

Sixth suggestion

Well, here's my proposal.

First, let me observe the following:

• We need two different schemes: one to tag streets (where buildings are not yet mapped) and one to tag individual buildings.
• If the numbering scheme is irregular, every number has to be mapped. There's just no way around this. However, it is possible to use interpolation where the numbering scheme is sequential or sequential with even/odd numbers, which already works for most schemes described in [1].

• tags for streets

Key	Value	Element	Comment	Example
left_nr	house number		house number on the left hand side, as seen from the direction of increasing numbers. This attribute may contain multiple values if the corresponding buildings have access to the street at the same node, e. g. "1; 1a; 3; 3a"
right_nr	house number		same, but for the right hand side

The trick is to use the direction of increasing numbers instead of the direction of the way. This way, the ordering can't be damaged by reversing the way.

• The software automatically determines whether there's an even/odd numbering scheme or whether the numbers are just sequential: An even/odd numbering scheme is in place if all left_nr and right_nr values have the same remainder when divided by 2.
• The software automatically determines the side of the number by looking at the direction of the sequence and the name of the attributes.
• The proposal relies on the concept of a street, which is either a relation (good) or a group of interconnected ways sharing the same 'name' attribute (heuristic).
• You don't have to tag every number (if the numbering scheme is consistent) but you can.
• You can easily add intermediate numbers ('1a', '1.5', '1 1/2').
• House numbers should be compared like Debian version numbers (upstream_version part only), i.e. '1a' < '1b' < '2' < '2/1' < '2/2' < '2/10' < '10'.

The most common and interesting place to note house numbers is at an intersection. You can't use the intersection node to tag the house numbers in this scheme, since that node is by definition part of at least two streets. So for a simple crossroads you'd need three to five nodes in this scheme. These nodes need to be taken into account by any renderer/router/application, whether it is rendering the house numbers or not. IMHO that is not good. If you use relations in stead, they can just be ignored by any renderer/router/application that is not interested in house numbers. I do like the direction of increasing numbers part of this scheme though. --Cartinus 01:41, 29 December 2007 (UTC)

Well, I had not thought about that. However, noting house numbers at intersections also makes the process much more complicated: You have to specify which way the numbers belong to and you have to specify whether the number is before or after the intersection. This makes the tagging much more complex and harder to understand. It's usually better to make life easier for humans (who enter the data) than for machines (who render/use/compress the data).

Furthermore, there already are several occasions where an extra node is needed to indicate the exact location of a feature unused by many renderers/routers/applications. For example, a routing application might not care about bridges/embankments/cuts/... but it still has to take into account the nodes that specify where the bridges/... start/end. Then, house numbers are rendered on some maps.

If the long-term goal is to map the exact location of all house numbers (or to even map all the entrances to buildings), there's no way around having a node for every house number anyway.

-- 3247 00:32, 3 January 2008 (UTC)

How do you want to treat Squares? What to do with splitting Roads, that have both the same name but different numbers? Did you ever look on the Venice-System ?

-- dieterdreist 00:32, 17 April 2008 (UTC)

tags for buildings

Key	Value	Element	Comment	Example
highway	entrance		Marks the main entrance (or one of the main entrances) of a building. A way should connect a building to the street from which it is accessed. A node should be a common node of a building and a street. This type can also connect two buildings if they are accessible from each other (e.g. one has the main entrance, the other one is usually accessed from the other one). This type of highway is not used for routing purposes, except when the destination is the building.
street:name	street name		Used on buildings, gives the name of the street the building is assigned to. This is automatically inferred if the building is member of the street relation. Note: The street:name might be different from the building's name, hence the different key.
street:nr	street name		Used on buildings, gives the house number within the street the building has been assigned.

Well, that's it. Merry Christmas. -- 3247 13:12, 24 December 2007 (UTC)

I like the idea of using the direction of increasing numbers instead of the direction of the way. But, for the buildings, I still think that the best method is to use the relation (which is basically what you're indirectly doing with your tag street:name)- Pieren 14:55, 26 December 2007 (UTC)

Well, the proposal was intended to be a shortcut for easy cases. I should have made that more clear. (Well, this happens if you have little time because of the beginning of a holiday trip the next day...) -- 3247 12:34, 3 January 2008 (UTC)

I've written a proposal on the use of relations for postal addresses. It covers more than house numbers (i.e. includes streets, postal codes, etc.) but only deals with explicit taggging. It does not allow to tag ways with ranges of house numbers, the discussion of which should remain here. 3247 19:46, 12 January 2008 (UTC)

Start from scratch

Many of these suggestions still talk about segments, while other do not clearly indicate weather the tags are applicable to ways or nodes or both. So I suggest we start if an empty page and anyone who is serious will just have to re-add his idea. We should also ban comments on proposals, because it makes things very unclear. RATHER EDIT THE RELEVANT PROPOSAL or ADD A NEW ONE. -- Nic 11:09, 23 December 2007 (UTC)

This is probably a good idea. I think over at proposed-relations, would be a good place. And this time discuss things much longer before making a vote (there is a "talk"-page that would probably be better for comments.). This is getting completely out of hand here. --MarcusWolschon 11:52, 24 December 2007 (UTC)

What I would suggest is not restart from scratch because we loose a lot of interesting points/remarks. I would rather suggest to re-organize this page, splitting it in 3 parts (or pages):

- tags or relations, what is the best solution ?

- proposals with tags only

- proposals with relations

Pieren 14:55, 26 December 2007 (UTC)

This page is the right page as this is what we are talking about. The problem is this page is getting long and a little messy and we have a discussion page we aren't even making use of. I suggest we strip all discussions and voting into the discussion page, clean this page up and talk/discuss on the discussion page. Alternatively I suggest we leave this page and start a new page called "Proposed features/Street numbers" and we place links at the top and bottom of this page pointing users to the new page, and in the new page we use the discussion page more. 1GUESS 14:55, 6 January 2008 (UTC)

Better "Proposed features/Addresses" or "Proposed features/Postal addresses". 3247 22:02, 6 January 2008 (UTC)

Seventh Suggestion

From what I gather from the discussion, the proposal should have the following things:

• be easy to use for mappers
• allow exotic numbering schemes
• be reasonably resilient against accidents (reversing way, splitting, merging, ...)

Proposal

The basic of my proposal is also one using things. You'll notice I have included several optional parts, which would either be in/excluded based on discussion or voting. These are precedes by Optional:

Here's an example (assumes a way(id:1000) which consists of 3 nodes(id:1001-1003)):

<relation id="2000">
  <member type="way" ref="1000" role="" />
  <member type="node" ref="1001" role="from" />
  <member type="node" ref="1003" role="to" />
  <tag k="type" v="house_numbers" />
  <tag k="house_numbers=" v="1-10" />
</relation>

house_numbers="1--9;2--10"

Optional: instead of adding a single relation to the way, put the house_numbers tag directly on the way. This would be less robust, though.

house_numbers="1-5;10-6"

house_numbers="1-5,5a-5f,6-10"

The syntax of house_numbers basically matches the one from the second suggestion.

For even weirder sequential numbering, you can attach multiple relations to a single way, with different from/to nodes. This is also useful for longer ways where long distance interpolation would yield significant errors.

How does this proposal address the requirements above?

• If the numbering scheme is standard and simple, you only have to add a single relation, or even no relation if you add the tag directly to the way
• I can't think of any numbering scheme that can't be implemented using this. Completely random ones would have individual houses tagged (see section below)
• Reordering and merging of ways and adding of new nodes doesn't affect the house numbering. When splitting a way, a house numbers mismatch can easily be detected (the from and to nodes aren't on the same way).

Which side of the road?

It could potentially be useful to know on which side the the road the numbers are. Directions are relative to the from/to nodes. Possibilities:

• house_numbers:left="x" and house_numbers:right="x". Only a single relation is needed
• house_numbers="x" location="left". You'd need two relations, one for each side of the road
• You could add four values for each relation to solve this issue: Martijn van Exel 18:13, 8 March 2008 (UTC)

<relation id="2000">
  <member type="way" ref="1000" role="" />
  <member type="node" ref="1001" role="from" />
  <member type="node" ref="1003" role="to" />
  <tag k="type" v="house_numbers" />
  <tag k="house_numbers_left_from=" v="1" />
  <tag k="house_numbers_left_to=" v="19" />
  <tag k="house_numbers_right_from=" v="2" />
  <tag k="house_numbers_right_to=" v="20" />
</relation>

this is very important if it is not so easy to get from one side of the street to the other. Imagine a big motorway with 8 lanes and a separator in the middle. In big cities this is quite common. Now if you want to house number 4 and you are in front of house number 3, it might well be that you cannot reach number 4 from there. In small streets, it is not very important on which side the numbers are. --Jms 16:43, 18 May 2008 (UTC)

In this case, the road is generally split in two ways. You can then attach one range to each side. --Gyrbo 13:04, 19 May 2008 (UTC)

Single house numbers

Useful if a single house doesn't fit into the general scheme or for completely random numbering. There are several ways I see how this can be done:

• Have a relation with only the way, a node and a house_number="x" tag. Optional: the node doesn't have to be a part of the way, a simple projection is used to determine the location. Optional: Use house_numbers and allow a single node to have many house numbers (apartment complexes, ...)
• Add a node to the way and tag it with house_number="x".
• Use the Postal Addresses proposal

Open issues

• What do do if the from and to nodes aren't on the same way? Consider the two ways one when the first node of one way matches the last node of the other?
• Should missing numbers be explicitly excluded from the ranges?

• Yes: house_numbers="1-4,6-10". Here 5 is missing.
• No, makes it unnecessarily complicated and difficult to parse. Insert a node instead?

• What if a street is numbered randomly, but you don't want to tag individual houses? Could you use something like house_numbers="unordered:x-y" or house_numbers="x-y" unordered="yes"?
• Finding a specific number on a street is fairly complex: first search against individual houses, than generate the ranges with interpolation and calculate the approximate location. Is this possible on embedded devices?

• I don't think this is a big matter, as you would not render these all the time, only when wanting a specific number.

• Is this method compatible with external datasets (TIGER?, AND?, ...?) that contain this information?

• This is not too important, as this is not possible in many countries.

• How would house numbers be set after splitting a way without visiting the location of each split? Could JOSM/Potlatch do the interpolation and calculate approximate new ranges for each new way?

Discussion

sounds good to me --MarcusWolschon 16:39, 14 January 2008 (UTC)

I think it's getting pretty close and I don't think the scheme is a problem for any navigation devices, but I have few points to raise:

• Why limit the number of ways in the relation to one? Or maybe it wasn't your intention but the example made it look that way. The ways would only need to share a start/end node for interpolation to work. Then splitting a way would not break the relation and would not need anyone to enter the numbers at the node used for the split. Checking for unconnected to and from nodes is possible if someone codes it.

• That's a very good point indeed. Feel free to add it to the proposal --Gyrbo 14:42, 5 March 2008 (UTC)

• If interpolation yields numbers significantly offset from their real locations, would a tag ("place_numbers"? for both sides at that node) on some intermediate node be sufficient? Would it have to be added to the relation as well, with some other role such as middle (as in from - through/middle - to)? The relation could have as many middle nodes as deemed appropriate for accurate interpolation, each with the numbers at that location. These extra nodes would have to be outside of any junctions. Unnecessary nodes but there hasn't been a way around it even in the previous proposals. Unless the middle nodes are added with a role of their number explicitly defined in the tags of the relation: tag k="house_numbers" v="1--3--10" and then member type="node" role="3". If house_numbers contains something more complex like your example of v="1-5,5a-5f,6-10" we'd have have nodes with roles 5a and 5f or one with a role of "5a-5f"?

• I considered adding "middle nodes" for which you could specify a number between 0->1 to help interpolation, but thought it would be too cumbersome. Using the house numbers themselfs is a good idea. --Gyrbo 14:42, 5 March 2008 (UTC)
• I think this would complicate the implementation unnecessarily. If the interpolation is too far off in a specific case, you could just add more nodes and define more relations. Martijn van Exel 18:16, 8 March 2008 (UTC)

• Re: which side of the road: although bit redundant, would it make sense to have house_numbers list all numbers and then one of house_numbers:left/right just those on the defined side - all other numbers are on the other side?

• Not a big fan of that. Having either house_numbers or house_numbers:left/right but not both seems easier to understand, not to mention I think it would make navigation code easier. --Gyrbo 14:42, 5 March 2008 (UTC)
• I'd have to agree with Gyrbo here. Martijn van Exel 18:17, 8 March 2008 (UTC)

• Say an address of one street (A) is accessible only from some other street; if we include it (a node) in the relation of house numbers of the street A, it would need a role of outlier: it's part of the streets numbering but not of the interpolation in the sense that the driveway from that other street will not be used in interpolation - interpolation follows only the ways in the relation. Drawing maps probably one would not need to use that number but routing software could.
• Looking forward to some discussion to get things moving again regarding adding house numbering. --Alv 14:05, 3 March 2008 (UTC)

• Me too, I assumed this proposal was basically dead :-) --Gyrbo 14:42, 5 March 2008 (UTC)
• Me as well. We have a lot of house number range data in the AND data set it seems, I hope that could be used. We got together mapping pubs in Amsterdam earlier today and in some streets there are so many that it might make more sense to just note the house numbers and put them in a separate database which could then optionally be rendered on top of the OSM base layer. Martijn van Exel 18:19, 8 March 2008 (UTC)

I just made the following proposal on the Dutch mailing list:

* houseno:left-min

* houseno:left-max

* houseno:right-min

* houseno:right-max

What's left and right is determined by the direction of the way.

min is the first house number, looking in the direction of the way.

max is the last house number, looking in the direction of the way.

For an example, please see http://www.openstreetmap.org/edit.html?lat=52.351279&lon=4.89035&zoom=18 / http://api.openstreetmap.org/api/0.5/way/7369384

• A similar proposal was made, but not accepted because it wasn't flexible enough. --Gyrbo 10:46, 18 April 2008 (UTC)

Two Three comments:

• The range 1--7 is quite weird. What about an additional tag to the relation "(numbering_)schema=odd|even|whatever" (or maybe "schema:left" and "schema:right")?
• We could merge this proposal with Proposed features/House numbers/Karlsruhe Schema. So a house number would be searched the following way:
  1. A single node relation
  2. A from-to interpolation (this proposal)
  3. A node/area with a matching "addr" tag (SHOULD be connected by a relation, but may be not)
• What about naming the role of the main way(s) "street", to allow several ways and something different from a node (an area, for example) be numbered?

--jynus (discusión) 15:44, 4 June 2008 (UTC)

• I copied to 1--7 syntax from another proposal since it's simple and allows mixing of different schemes. Alternatively you could also make it a miniature scripting language: "odd(1-7),8-10". Other "functions/filters" could be added if someone finds a good use for them.
• That's a very interesting proposal, using a quite different approach from the other ones. The only concern is that there is no simple and reasonable exact automatic matching of streets and house number. This makes it somewhat harder to use for routing (and more computationally intensive). I think the goals are somewhat different. The Karlsruhe proposal tries to closely map reality, whereas my proposal is mainly intended for routing.
• Good point. This proposal considers a specific number as a single spot, not a range as is the case in reality. Again, I believe this makes routing easier.

--Gyrbo 10:59, 5 June 2008 (UTC)

Eighth Suggestion

I think specifying numbers in a street is something we should enable very quickly, so that OSM has the same "functionalities" as other maps, and people begin to use it. They would then contribute...

So the target of my suggestion is to enable us to set-up house numbers as quickly as possible and to adapt to people's needs. What do people want? Just to know in which segment of a street a house is located.

So the idea I propose here comes basically from the printed maps I've been using for years, and which have definitely enough information: the house numbers just appear on the crossings.

The target is to have a system:

• flexible: easy to use to enter rough information, but enabling to enter precise detailed information also if needed
• practicle: enabling to enter data very quickly.
• bullet-proof: adding a way, changing ways directions, slightly moving a node should not alter the numbering.
• light: don't add too many nodes. One node per house is definitely too much. This means that in most cases, only the numbers at the ends of segments should be specified.

Proposal

• Tag Nodes only, not Ways
• Imagine you are "on a Node", with some Ways around you: describe the ways' directions and give the value of first house numbers in the street on Left and Right sides.
• Between tags along a Way, we would assume the house numbers increase regularly, by interpolation. If it is not the case, you can add numbers on the Way to have different interpolations. At the very worst, you would have one node per house.
• Strange numbers are possible: 38b, ... For interpolated numbers, 38b would be the same as 38.

Example: you are on a crossing, with one way going North-East to South-West, and one going East to West; so you have 4 directions, and each of them has 2 sides of the street: Left and Right, when looking from the node. It gives:

<node id='270590736'>
<tag k='house_number:NE_L' v='38' />
<tag k='house_number:NE_R' v='41' />
<tag k='house_number:SW_R' v='36' />
<tag k='house_number:SW_L' v='39' />
<tag k='house_number:E_L' v='205' />
<tag k='house_number:E_R' v='206' />
<tag k='house_number:W_R' v='203' />
<tag k='house_number:W_L' v='204' />
</node>

Advantages

• This scheme is not too precise, so if ways are slightly moved, the North-East will remain North-East. This would not be the case with a value such as 45 deg.

• This scheme is precise enough to avoid ambiguities. If needed, "NE" can be fine-tuned to three-letters (NNE). Up to now, I found no case where it would not be precise enough.

• "Big" crossings, are already split in small ones by Roundabouts or other junctions. I saw very few Nodes with more than 6 ways linked to it.

• If there is any ambiguity, one can add nodes on the Ways and specify numbers there: nothing on the crossing node, but 4 nodes would be added on each road.

<node id='-1'>
<tag k='house_number:NE_L' v='38' />
<tag k='house_number:NE_R' v='41' />
</node>
... and so on

Practical aspect: entering data

• It can be very quick to enter data: when in "house number mode", ONE click NEAR a way can identify the Node, the Way and the Side (Left/right) to which to attribute a House_number. So you have just one click for identifying one number.

• A software trying to investigate a Way will very easily determine if there is a Odd Side and an Even Side, or if numbers are increasing on one side and decreasing on the other... All this is easy.

Remark, Special Cases

• In the city of mannheim/germany, the streets even do not have a name. House blocks have letters and the single houses have numbers. A house block is an area surrounded by 4 streets. So it is quite easy to find for example house B4. Just go around block B until you find number 4. But block B is connected to 4 roads. --Jms 16:27, 18 May 2008 (UTC)

• A similar system is used in Sapporo, Japan (I don't know about other cities). Each block has a coordinate such as N3W4. I think this is more of a "way" problem than a house_number problem, though. Once you have the streets laid down in OSM, the proposed house_number scheme should be able to deal with it. --Gyrbo 10:49, 7 May 2008 (UTC)

• In Scharnitz, Austria, the houses get their numbers in the order as they were build. In this case, no linear approach will be successful. Stefku 10:38, 26 August 2008 (UTC)

See also

• Proposed features/House numbers/Karlsruhe Schema
• Relations/Proposed/Postal Addresses

Voting

• Contra forcing the number on left and right side to start at the same place on the road is not acceptable. --MarcusWolschon 19:41, 13 July 2008 (UTC)
  • What is the problem with this? If you actually need more precise mapping, add a node for the place where house numbering changes. You would have to add a node anyway to mark this place so this won't be any extra data. I like the eight suggestion. Obelix 08:45, 28 July 2008 (UTC)

Suggestion for ease of use

• When there is a building, use tags to give housenumber and street for it

* addr:street for street name
* addr:housenumber for house number
* additional tags are optional

• When there is no building set a point with the two informations (intermediate solution until all houses are mapped as area).
• House number interpolation is subject to routers. A minimum of 3 numbers per road will help here (e.g. start end, mid). The more numbers are mapped, the better the interpolation will work.
• complicated cases must be solved by mapping all houses.

Advantages

• easy to map
• easy to use