Proposal talk:House numbers

getting out if hand

I'm waiting with my implementation in TravelingSalesman since early november.

If we cannot agree on a solution soon, I'm going to implement the proposal voted in "2c" and am going to tag in that style. The navigation-software is far enough that it needs house-numbers. now.

Old proposals from the article page

First suggestion (Key name: first_number, last_number)

This information should apply to segments that map roads/streets with numbered houses.

first_number should be the house number that is encountered at the starting node of the segment, and last_number the one at the ending node.

With this system, obviously segment direction is important.

Either first_number, last_number or both can be left out if a street is composed of more segments (with no junctions), but the house numbering information for each segment is not known.

This system wouldn't usually render all house numbers in their precise positions; however, if enough segments are used (for example, a segment for each junction, in city streets) I think the "missing" numbers can be interpolated accurately enough.

A system for actually specifying every single number could probably be made, but I don't think it would be feasible in practice, because of the large amount of information to be recorded in GPS tracklogs.

LjL 10:46, 30 Aug 2006 (BST)

Can it cope with (e.g.) "#1-30 on the left and #31-60 on the right" (maybe in opposite directions too) - numbering schemes can get quite weird. Ojw 12:34, 30 Aug 2006 (BST)

Another numbering scheme common in Vienna would be #1-31 (only odd numbers) on the left and #2-32 (only even numbers) on the right. BTW even if it would take a lot of data to be entered, mapping every single number is the only option in regions where house numbers are seemingly random (e.g. because they're cadastral identifiers) -- i.e. 7 next to 112. --GabrielEbner 20:12, 30 Aug 2006 (BST)

This is applicable to Berlin too, as for some streets in every German. scoid 20:25, 30 Aug 2006 (BST)

I suspected that some issues like these could arise. In the case on "random" numbering, well, I don't think it's a valid reason to trash my scheme (or something like my scheme): in that case, as you said, the only possibility would be entering numbers one by one (and a specific tag for that would be used, like house_number applied to the single nodes - meaning that you'd have to create a node for each number). In the case of numbers "flowing" from left to right rather than being interleaved between left and right, I suppose a tag like interleaved_numbers=yes/no could be used. LjL 20:35, 30 Aug 2006 (BST)

How about defining a street number on the street_numbers_left=first,last,step of the linear feature having a start number, and end number and a step increment, and another key for street_numbers_right=first,last,increment. ? Welshie 15:51, 19 November 2006 (UTC)

You definitely need to have the left vs right distinction. There IS a danger that editors will damage it (by changing the direction of the segment) but that applies to several other properties that are already in use, e.g. one_way. We could certainly add a warning to JOSM (or a plugin that automatically flips these properties as necessary) when someone tries to change the direction of a segment with directional properties attached. TIGER has house numbering information, it's worth taking a look at their implementation (not necessarily copying it, but at least seeing what they did and did not try to achieve and how) before trying to standardise this for OSM. Tialaramex 00:53, 14 May 2007 (BST)

Second suggestion

For Houses

I would suggest two tag for a Node

• k="street_name" v="Kings Road"
• k="house_number" v="12"

(You should use street_name here, because there are houses that are nearer to an other road, than to that road from where they got the number)

if you want to enter a house for its own.

Why using here "street_name" instead of "name"? The tag for streets is "name". Two new ideas:

* k="name" v="Kings Road" or

* k="is_in" v="Kings Road"

We should avoid to much different tags.

--audifahrer 21:06, 9 February 2007 (UTC)

My house has no number, in combination with most others in the historic parts of this village. Should the tag be house_id or business_id?

What about something like building:id=12;facing=123;length=20;width=5;street=foo;street=bar

For a building that fits in a rectangle 20*5m with the longest side pointing ESE, and can be accessed from foo or bar street. --SpeedEvil 14:10, 11 September 2007 (BST)

I dislike the idea of using the street's name to link both together. If a street got renamed, you'd loose the link. Additionally, you'll have problems with superstreets which are built by a relation. SlowRider 18:11, 24 December 2007 (UTC)

For Roads

• k="name" v="Kings Road"
• k="highway" v="secondary"
• k="house_numbers" v="1-9"

for a segment of a road (if you don't want to be so exact), means near this segment are house_numbers from 1 to 9. Also it should be allowed to specify the house numbers separated like this:

• k="house_numbers" v="1,3,5,9"

I would suggest not to use the direction of the segments and left,right cause this could be very problematic. (someone change segments because of a new oneway ....) Sven Anders 18:27, 4 January 2007 (UTC)

There are occasions where the house is far recessed from the road. A router then will lead you to the point nearest on the road, but it will fail miserably if the house only can be accessed via another road. I vote for extra nodes. SlowRider 18:14, 24 December 2007 (UTC)

Key name: numbers

• number contains one or more ranges, separated by ,
• a range can be:
  • a single number
  • an interval: <begin>-<end>
  • a sequence of odd or even numbers: <begin>--<end>, which is a sequence of even numbers if begin is even, otherwise a sequence of odd numbers

Examples

numbers = 1,3-5    // means numbers 1,3,4,5
numbers = 2--8,12  // means numbers 2,4,6,8,12
numbers = 1--5     // means numbers 1,3,5

Tag could be applied to nodes as well as to segments

-- Eckhart 20:11, 4 January 2007 (UTC)

Would suggest house_numbers. There are many numbers in the world ..... Sven Anders 15:59, 8 January 2007 (UTC)

I'd suggest using something like building_number instead... a number on a street doesn't always refer to a house, but, then again, it doesn't always refer to a single building either, or to a whole building... Erm... Maybe going a bit further and extending this to something like address:number = ... then could also have address:name = ... where a house or building has a name and/or number or where multiple numbers are in a single named building etc... But all that said, place_numbers in Key:place includes provision for numbers... Dtucny 19:05, 7 March 2007 (UTC)

And if you have something like this Street <-Segment-> Node (number=42) <- Segment-> Other Street you have to tell the node for which street the number is for Sven Anders 16:01, 8 January 2007 (UTC)

This could be done with a links_to=<segment_id>. -- Eckhart 14:34, 21 January 2007 (UTC)

Yes, but if this segment is deleted or changed (by putting another node into it), no one would know what street referes. Sven Anders 15:28, 4 February 2007 (UTC)

Numbers are very important as they help us locate our final destination. Remember house/buildings include numbers and letters (e.g. 2A). The only way to record house/building numbers is with a node because you need to say at that node what the house/building number is. A road has 2 sides and the numbers don't have to be anywhere near each other. From my experience one side of the road has odd numbers and the other has even, so I would separate the two sides of the street where the number across the street is no where near the other side. You can either use segment_id or street name for reference of which connection the numbers refer to. Then you have to relate the number to the right segment/street which could be done in brackets or with a space separator. Therefore I would propose at an intersection node something like:

odd_highway_num=5(111111111)

odd_highway_num_side=North

even_highway_num=10(22222222)

odd_highway_num=2033(33333333)

odd_highway_num_side=East

even_highway_num=1044(444444444)

Now whether you use brackets or spaces or something else is semantics and it needs to be done in mind of simplicity but overall it needs to be flexible enough to support any number of roads into one intersection with a full range of numbers. Ultimately as long as it is designed to handle both sides of the road and multiple streets then a standard just needs to be made so we can start making use of it.

As far as house/building with names, they would be added on a node such as which side and their name (similarly as above). 1guess 22:15, 18 April 2007 (UD)

Old Votings

Voting 1 (not accepted)

We can add new (could we) and (maybe we also could) as long as we want but we should start actually getting somewhere. Since nothing much has happened and I'd simply like to start implementing house-to-house -navigation, I propose the following for voting:

vote-end-date: 2007-11-15

proposal: For single houses:

<relation id="??">
  <member type="node|closed-way" ref="553" role="building" />  (the node or way should be tagged as building)
  <member type="way" ref="104" role="street" />
  <tag k="street_number" v="10" />
</relation>

For ways:

<relation id="??">
  [optional:
    <member type="node" ref="??" role="from" />
    <member type="node" ref="??" role="to" />
    if not given, refer to the whole way.
  ]
  <member type="way" ref="??" role="street" />
  <tag k="street_number_left_start" v="1" />
  <tag k="street_number_right_start" v="11" />
  <tag k="street_number_left_stop" v="2" />
  <tag k="street_number_right_stop" v="12" />
  <tag k="street_number_left_step" v="2" />
  <tag k="street_number_right_step" v="2" />
</relation>

I am against this proposal for several reasons

- it doesn't deal with the situation where a house is named, it doesn't deal with the situation where house numbers are not simple numbers, it doesn't deal well with situation where a lot of house numbers are at the same location (think apartments), ... Just from my personal experience I can name so many situations where this proposal is not well suited and this is just from the Netherlands and Belgium. I dare not to think about house numbering in some Asian or Latin American countries.

- anything that relies (partly) on nodes is impractical because it would make manipulating ways a lot harder. For example I live in a straight street of 200 meters. It is now represented as just two nodes and easy to work with. But the house numbers are totally random (First house has numbers 1-30, then a few houses 30-60, then a gap, then a few houses each numbered 230A-F, 232A-F, 234A-F) Just for this 200m stretch it would need 5 additional nodes! --Bartv

It does deal with named houses and non-simple-numbers by applying the "single-house"-case. Can you come up with a better idea how to tag your special cases without loading more work on the volunteer who tag the usual roads? How different is the house-numbering in the countries you named?--MarcusWolschon 12:41, 16 November 2007 (UTC)

I am against the proposal to use a relationship to associate house numbers (which is a composite attribute) to a way. A relationship can be used to say that a building belongs to a way, but it is IMO inappropriate to make a relationship between attributes and ways. I am for the proposal to use a simple scheme (house number structure: no/even/odd/even+odd/irregular, house number first left + right, house number last left + right) which will cover a majority of ways with house numbers, is conforming to the composite attribute defined by GDF, and I assume that a simple scheme will be used by more mapping persons. If necessary the simple house number scheme can be extended by a more elaborated scheme to represent all the irregular real world situations described by Bartv. --BerndR 5 Nov 2007

Okay, same schema but adapted to use attributes on a way instead. Would 1 attribute be better or 6-7 attributes? Do we have to care about the case of people splitting/combining ways?

The problem is that buildings/houses can be far away from the way/street. House numbers on just the way or way-nodes won't help here. --Onion 08:49, 5 November 2007 (UTC)

Please propose a better way to do it. For the special case of houses far away from their road I would assume a foot-way to lead to the (single) house. How could we tag that case while still keeping the house related to the road? --MarcusWolschon 12:41, 16 November 2007 (UTC)

votes:

PRO

• --MarcusWolschon 06:28, 30 October 2007 (UTC)
• ...

CONTRA

• --Bartv 11:31, 2 November 2007 (UTC)
• --BerndR 08:16, 5 November 2007 (UTC)
• --PhilippeP 09:31, 5 November 2007 (UTC) (way too complicated)

Voting result: not accepted. We need a new proposal.

Voting 2 (not accepted)

We need a new proposal.

Ultimately to take every condition into account you will need to allow the system to mark every single number, hence a node is the best point to mark one spot. If you decide to mark a long place you could use two nodes. Based on this I propose a system of nodes to record the street numbers. This also allows pathways/tracks to be given the same street name for houses further distance off the street. Furthermore the nodes will need to allow a system/computer to estimate approximately a house number given between two nodes of a house number, this will have to be assisted with a systematic flag which can equal odd, even, irregular, etc.. so a system can calculate the distance between two nodes and their numbers and make an estimate based on the information. Each node can have many ways connected to it and each way has two sides. Therefore each node would have values like this:

street_number_1_way_reference="123"
street_number_1_side_A_type="odd"
street_number_1_side_A_number="33"
street_number_1_side_B_type="irregular"
street_number_1_side_B_number="2357B"

and this would be repeated for each way incrementing the street_number, i.e.

street_number_2_way_reference="128"
street_number_2_side_A_type="even"
street_number_2_side_A_number="2"
street_number_2_side_B_type="odd"
street_number_2_side_B_number="145"

This has been created to accommodate all options allowing those to plot in a few numbers and others to plot each individual building, but feel free to correct me. The only question would be which side is side A and which side is side B, but that can be easily solved by adding another value, or by making it standard that side A is the most north side and side B is the most South side and if it travels perfectly north to south then side A is East and side B is West, and because the way is straight between two nodes there is no issue of the way turning and changing on points. Furthermore this could be integrated into a editing GUI to allow additions without having to know references or the difference between side A and B.

Votes

PRO

• --

CONTRA

• --

This should be using relations, not encoding ids of ways into a tag on a way. Also, please use 'left' and 'right' rather than defining A and B in an ad-hoc manner. 'left' and 'right' depend upon the direction of the street drawn and are not at all ambiguous - tags such as natural=coastline and oneway=yes already depend upon the direction of the way/street. Morwen 12:48, 23 November 2007 (UTC)

• --

I agree, we should use a relation instead of manually typing way_reference="1238263" --MarcusWolschon 13:39, 23 November 2007 (UTC)

• Another +1 for using relations instead of directly tagging nodes. Also, this has to use left/right instead of some directional-based A/B--what happens with a rural road that winds in every direction? Then there is no "north-most". Too vague. --SiliconFiend 17:34, 26 November 2007 (UTC)

Voting result: not accepted.

Voting 2b

Ok Relations in OSM are new and powerful. I think it's too easy to try and integrate alot of features into one relationship, which means more attributes to clarify so in the idea of keeping it simple it will be based on the same method above but within a relationship (Please review details explaining above). Also we are now using terms left and right which is based on the direction of the way. (these are two things I have quickly learnt)

 <relation id="??">
  <member type="node" ref="??"> 
  <member type="way" ref="??">
  <tag k="street_number_side_left_type" v="even" />
  <tag k="street_number_side_left_number" v="2" />
  <tag k="street_number_side_right_type" v="odd" />
  <tag k="street_number_side_right_number" v="145" />
 </relation>

This can be enhanced in the future so the node is optional making the reference point in the middle of the way, and other such enhancements, but i think we need a solid starting point. Feel free to provide feedback and I can improve it to do a voting 2c, otherwise vote this one in or out. 1GUESS 10:34, 29 November 2007 (UTC)

Votes

vote-end-date: 2007-12-08

PRO

• -- 1GUESS 10:34, 08 December 2007 (UTC)

CONTRA

• -- Needs clarification what the node is, and what street_number_side_left/right_number are (first number or series? if so, what is the last number?). With besser names it would be agreeable. Also needs some kind of k="type" v="house_numbers" to tell what kind of relation it is. --MarcusWolschon 15:21, 8 December 2007 (UTC)
• --I'm okay with the structure of these tags, but I think the key names are too long. I think it could be as simple as number_left, number_right, number_left_type, number_right_type. Maybe if it's shortened to this it might need a k="type" v="street_number" tag. --SiliconFiend 16:49, 8 December 2007 (UTC)
• I think that the number should (at least optionally) be a series, and that the relation should (at least optionally) take two nodes, a start and an end node. The range could perhaps be specified in the way proposed in the "second proposal" above. This way, it would be possible to specify a certain range of street numbers that apply in a block (between street X and street Y); under the proposal above, this would not be possible. Andrewpmk 23:59, 10 December 2007 (UTC)

• I don't think that's necessary. The range is implied, and requires less data entry. If you have a long street and you tag one node with the numbers on one end, and another node with the numbers at the other end, then assuming the numbers fall regularly along the street, numbering is complete for that street. If the numbers don't quite line up, then more numbering nodes can be added in between to refine it. The information is sufficient, and this keeps with the principle of minimal burden on mappers. The renderers/routers can get a list of street number relations for a particular way and sort them accordingly. --SiliconFiend 18:08, 12 December 2007 (UTC)

Voting result: not accepted.

I think it's very close! I think we just need to refine the tag names and consider cases where numbers are not a contiguous range. --SiliconFiend 18:08, 12 December 2007 (UTC)

Routing for the visually impaired

Hi,

please have in mind that exact positions of house entrances are of high interest for routing software for the blind. Please make sure that the model fits the needs that will ocure for that use. --Lulu-Ann 14:25, 25 February 2009 (UTC)

As much as I'd like to do that but I fear neither 99% of the mapped house-numbers nor any gps-positioning of the person are nearly as accurate as is required for this kind of usage. I`ve never seen a mapper with anything more accurate then either an off-the-shelv gps-device or an aerial image that may well be 100m off. --MarcusWolschon 19:26, 25 February 2009 (UTC)

True, but the fact that accuracy is not given at the moment does not mean that we shall not have the data model ready for more accuracy. The "Trekker" GPS for the blind does not offer more accuracy than the devices we use, but the combination of correct relative information of the map with the information a blindman's stick gives you helps a lot to navigate already, even with the data that system offers. WE are the only project that is able to offer such micro mapping at all soon, so let's prepare. Maybe we will even have a portal to have the visually impaired as contributors in the future - Why not ?! --Lulu-Ann 11:22, 27 February 2009 (UTC)

So you propose to advertise this map as way more accurate then what 99% of the mappers added to it? Of cause everyone tries to work as accurately as possible but if the result is not nearly accurate enough we cannot simply declare it as being so. BTW, could you please clarify the requirements you refer to when saying "the needs that will ocure for that use"? Thank you. --MarcusWolschon 11:29, 27 February 2009 (UTC)

I guess what was meant was that when you're adding a building, it's quite easy to estimate that "staircase B entrance is one third of the wall's length from that corner" and add a node there. If the surrounding streets look right they're likely reasonably accurate relative to each other and since the building fits nicely in between, its dimensions are likely of comparably accurate length. Alv 12:59, 27 February 2009 (UTC)

Marcus, I try to leave a note whereever I become aware of a need. What are you missing?--Lulu-Ann 16:02, 2 March 2009 (UTC)

Alv, no, the world is not square and dimensions are difficult to predict, but we have to start with the data accuracy we have. Soon after the routing software for the blind will be available, I predict the blind will want to correct the maps and make them fit their needs, and we might have an editor for the blind. (VoiceEditor: "Entrance Streetname, Streetnumber is now to the right". Blindman: Presses button "correct", walks with his stick to the place where he finds the entrance, presses button "move node to here", "save".) --Lulu-Ann 16:08, 2 March 2009 (UTC)

Besides the rural houses with open yards and a surveyor with time to stop for some time at the door, any single measurement with current consumer equipment is as accurate as that approximation (especially so near building walls) - could be, say, three meters either way along the wall and is likely to appear as such when the next traveler searches for the same door. Either way, the data can not yet be trusted enough for the users to trust, (err...) blindly (no pun intended). source=survey is naturally a welcome addition to any such "individually positioned" feature, such as the door. Once some more accurate devices come available, their users can and should be encouraged to add some other suitable source=* tag to tell others that that node is likely to be more accurate than the older nodes. With some practice at approximating distances the distance from a building corner is more accurate than the position of the building itself; "The door is 10 meters from the building corner on your right, but the corner might be 5 meters away or within your reach." And yet it is better to add the approximate node; searching 6 to 10 meters along wall is easier than going around the whole building. To date I've added some three hundred nodes with a building=entrance and surveyed some of them several times. In urban environments the most accurate positioning (such that an ideal navigator, able to measure positions with errors in the 10 cm range, would direct you in the exact right spot) requires suitable photos of the area and several traces of the surrounding streets - with current equipment. Alv 17:47, 2 March 2009 (UTC)

Just a note, my handheld GPS receiver when no SBAS (WAAS/EGNOS etc) coverage is available (such as Brazil where I do most of my mapping), and I am in a narrow street surrounded by high buildings (in a densely built urban area), the accuracy of my unit is generally around 27m, that means the position fix I get of the entrance of a building can actually fit with the next entrance. The only solution to bypass this is to do trigonometric survey from known locations with higher accuracy on the position, such survey is not possible to do for a volunteer surveyor that haven't bought all of this expensive high-class land survey equipment used by ordinance survey and other similar organizations. --Skippern 19:00, 2 March 2009 (UTC)

Post Note: When tracking on open roads the accuracy of my unit is generally in the area of 1-2 meters, with EGNOS in a town in Norway I was generally on 7-11 meters, and in open landscape around 1 meter. --Skippern 19:17, 2 March 2009 (UTC)

Note: When evaluating the accuracy experimentally, use the difference between the same points at different days. The relative accuracy of 2 meassurements taked shortly after each other is much better then the absolute accuracy. --MarcusWolschon 11:38, 3 March 2009 (UTC)

Or the method we use at work is to use several receivers with different configuration, and compare them towards each other, also when taking fixes of objects we maintain one position for a period of time and calculate the meridian position, that is after sampling positions for 15-20 minutes, discard the 5% positions further out, double the 5% position closest to center, and calculate the average of these values. With the equipment we use at work, we can have position fixes with accuracy of about 1cm or maybe even better. --Skippern 12:39, 3 March 2009 (UTC)

Why do you calculate the position of the meridian? I guess you mean the median position. Note that in your aproach does not take athmospheric effects into account. All receivers get the same signal with the same errors. --MarcusWolschon 06:44, 4 March 2009 (UTC)

That is not entirely correct. If you have two equal receivers (same setup) and antenna positions are close, than you will have the same set of errors (while calculations might result in position jumps in different directions within same circle), but if the setup is different (i.e., one use SBAS while the other doesn't) than the results will be very different, as one of them get information about atmospherics somewhere in the remote vicinity. Best result is when your receivers get these corrections from different sources. It will be very technical if I describe it in detail here, but this is one of the reasons that the 3 GPS receivers I use at work have different setup. Of course, returning to the same position and record the position a few days later will have better effect than working with several receivers, and you get to survey the same area more than once :) And yeah, I meant median, not meridian position. --Skippern 18:41, 4 March 2009 (UTC)