Proposal talk:House numbers/Karlsruhe Schema

addr:full and multi-line -values

There is a practical issue with addr:full. JOSM as an editor does not support values with multiple lines. I'm not sure about potlatch but I think it too has this restriction in it's UI. --MarcusWolschon 12:26, 20 April 2008 (UTC)

• another point: what about the correct newline coding? see Wikipedia on Newline - i think it would be better either to insert some markup instead of newlines (<br/> for example), or to abstain completely from adding the full address. --Florianschmitt 16:06, 7 September 2008 (UTC)

Rendering

As for me, house numbers are render very small. May be you can make numbers bigger, as they are not clear even on the highest zoom level. --LEAn 00:46, 7 June 2008 (UTC)

Some considered them to be too prominent already.

From what I've seen the problem I find is that the numbers are a bit small to read, and I'm sure any one with even semi poor eye sight would find those house numbers to read. That being said, as it is, I find that they "detract" from the map, and clutter it up. Is it possible to have a separate overly lay that can be turned on or off?

If you add a street number for a building where the building has a name, both the name and the number render in the centre of the polygon (with the name overwriting the number). See a couple of buildings I numbered. [1] (Yes Suncorp was in the wrong place - now fixed.) --Ebenezer 9 Sep 2008

I'm not sure how the rendering-rules work but maybe we can add a vertical offset to the location of the house-number when a name is present. (e.g. display it below the name) --MarcusWolschon 12:14, 26 September 2008 (UTC)

Experiences

I've been tagging addresses with this scheme even if I'm not in Karlsruhe but in Finland. I have manually created the relations for quite many ways for which I have added the street numbers, for two reasons:

• I'm mostly mapping a city center, where address numbers are quite close to two roads at junctions, and
• Although not mentioned, I've been tagging the addr:interpolation=* on the way marking the road itself.
  • Pro: the interpolation lines aren't drawn above and through the buildings. (Most city center buildings in one quarter share some walls and haven't been drawn separately).
  • Pro: less ways. A dual carriageway road has two relations, one for each side.
  • Any house number is bound to be close to some road or be in a relation with the road it belongs to; finding the interpolated location on the street is already mentioned in the simplest case.
  • Con: Where the street is split into two ways, be it for a maxspeed change, I need two relations or the extra interpolation way on the same nodes for the full length of the street. Solutions:
    • Allow an associatedStreet relation to have not only one, but one or more consecutive ways making up the street. It could be even possible to skip the gaps when interpolating but a tool to search for those would be needed as they might be an error and lead to false interpolation results for a part of the way.

Any comments on how the already implemented software support (Traveling Salesman only?) for this Karlsruhe Schema copes with the "modifications" above? Alv 06:49, 13 June 2008 (UTC)

How do you put 2 addr:interpolation onto one way (left and right side) and how to link the interpolation to the house-numbers or do you use this only for dual-carriage ways? What semantics do you propose to define the ordering of ways if you allow multiple ways in an associatedStreet-relation? If there are no buildings drawn, then the line cannot be painted through it. Even if, this is something we can modify the layering in the renderer(s). --MarcusWolschon 04:59, 15 June 2008 (UTC)

If the numbering scheme is the common odd on the left/right and even on the other side and it's a single carriage way road, addr:interpolation=all with a total of four house numbers marked on both sides should be sufficient to define the sides for even/odd numbers unambiguously. I construct manually the relations as mentioned at "Case: Relations (easy for computers, difficult for humans)" and then the fixed points for interpolation would be as in "single house as a node next to the way" (nearest point on the way).

If the real numbers don't follow the odd/even schema for some part of the way, the interpolation ways would be split at several places already when using distinct interpolation ways. For these cases it might not be possible to tag the interpolation type on the road itself but separate interpolation ways might be needed.

For dual carriage way roads there's two relations. If a road changes between single and dual-carriage ways, likely the relation needed to be split but house numbers on both sides at that point might suffice. Working

Ordering of ways can be computed easily if the consecutive ways always share end nodes between the farthest house numbers. Even if they don't share nodes, say at some intersections with internal short ways that haven't been added to the relation, the shortest gaps will be clearly shortest on the "correctly" ordered set of ways. At least I haven't seen a road that would turn around to come almost back to itself.

A longer interpolation line spanning several quarters crosses (actually goes under any streets in its path) which seems silly, especially if the numbers on both sides of the crossed road are explicitly defined. And for longer countryside roads with multiple bends a distinct interpolation way alongside needs n extra nodes.Alv 10:11, 15 June 2008 (UTC)

postcode / postal_code / ZIP

In TALK-DE (German mailing list), Stefan Neufeind noted, it would make sense to change "addr:postcode" to "addr:postal_code".
He gave the reason, "postal_code" has already been intoduced to Map_Features. --TobWen 12:17, 18 July 2008 (UTC)

Blocks of Flats

Hi all

I live in an area of London that is dominated by blocks of flats, that are either dedicated to housing, or are split level between shops (ground) and then flats above.

In cases you can have the units on the bottom are numbered as per the road, so Number 20, A Street. And then the top would be 20 -> 30 A Court, A Street.

I've had a look at both http://wiki.openstreetmap.org/index.php/Proposed_features/Building_attributes and this current discussion, and I can't see any thing that really seems to cover basic flat numbering. Though Building_Attributes does cover the split nature of buildings.

I think the approach taken in these two proposals is interesting.

One seems to be heavily biased towards the house numbers being tied directly to the road (this one), and the Building_attributes having every thing tied to the building directly.

Would it make sense for these two proposals to be merged?

Liebe Karlsruher

könnt Ihr diese Seite bitte auch auf Deutsch übersetzen? Herzlichen Dank, --Markus 20:42, 23 July 2008 (UTC)

Anscheinend nicht, die können nur Baddisch oder ganz Ausländisch :-) --Nikodemus 16:16, 29 August 2008 (UTC)

Das ist sehr schade! Sven S.

Not topological

This scheme is not topological (except for the "temporary" interpolated version), so it's fine for making pretty maps with numbers, but it's basically useless for existing GPS receivers. It might be possible to transform it into a topological form, but it would take a lot of preprocessing, measuring the distance of the node to each way in the planet to find the street it belongs to, or attempting to do something clever with parsing the tags. Why not just store it in a topological form to begin with? We don't show the outlines of streets (only centerlines); why do we need to have the exact position of buildings in order to give them an address? —Preceding unsigned comment added by SiliconFiend (talk • contribs) 18:08, 25 July 2008

I agree that some sort of connectivity is needed for the maps, however I think by using relations or using addr:street=*, we can have a properly connected map. Rorym 22:17, 26 August 2008 (UTC)

To whoever wrote that comment: Sorry but this is nonsense. (Starting with your use of the word "topological" - as house numbers do not make up any kind of network, how should there be topology?) One of us has written a piece of software that does the interpolation while we had the workshop and it took a few hours only. If you have a GPS position and want to find out what road you are on, you have to do exactly the same computation - find out which road is nearest, and then find out the nearest point on that road - this is where the system will "plot the dot". The same mathematics have to be applied to the house number data. You do not have to transform the whole planet into something else. - That being said, if you are unable or unwilling to fill in individual addresses, then don't - it is that simple. --Frederik Ramm 14:25, 4 September 2008 (UTC)

Sorry, I forgot to leave my signature. I thought it important to leave this note to warn people that this is not an optimal scheme. My argument is not nonsense. It's how the TIGER and many other GIS data sets are organized, and it's how all current GPS navigation systems work (locating address numbers at a relative distance along a street using interpolation as necessary, not as individual points). In the best case, this will require a huge amount of preprocessing to transform it into a usable form for searching along a street. In the worst case, it's just unusable for creating GPS maps and other consumers which already use a standard format for addresses (hint: they're expecting a left/right and odd/even indication). The address numbers are associated with a street; they don't stand alone. You access an address via a street, therefore the address and house or building at that address is connected to the street, which makes it topological. There is nothing in the single-point scheme that ties the node to another OSM entity. Adding a tag with the street name does not make it topological. Adding a tag with the way ID would get you closer, but either method is prone to typos and other errors which will be hard to detect. e.g., someone mistyped the street name on one address, so that one is inexplicably missing when someone searches for it, even though all the neighbors are present. If you insist on this scheme, it should at least use a relation to tie the node to the associated way. It will still require a lot of preprocessing to locate the closest way node, but at least we won't have to search the entire dataset for the matching street by name and distance and hope that someone didn't make a typo. --Karl Newman 20:39, 4 September 2008 (UTC)

You access a house by one or more streets. The house can be quite a way off the street. We have Even/Odd-Interpolation but also the other schemas. There are more complex house-numbers like "11b". There are house-numbers for the thirs yard of a building-blocl (common in Berlin). You don't want to get the numbers wrong when a way is turned, split or merged. You are free to propose any of your "standard-formats". There IS such a relation in the spec to be used when needed, you should read it. Full address-searching workd fine here, thank you. --MarcusWolschon 04:39, 5 September 2008 (UTC)

I have proposed an alternative, long before this scheme existed. Another major problem with using nodes for house numbers is when slicing the planet into tiles, there will be cases where an address node falls in one tile but the street it's supposed to be associated with falls in the neighboring tile. This isn't a problem if you're just drawing pictures, but it makes the address node useless for both tiles if you want to actually use the address number data. --Karl Newman 18:13, 10 September 2008 (UTC)

I think this system would work just fine, especially in the interpolated case. It doesn't matter whether or not a way of interpolated housenumbers is directly associated with a way resembling the actual street. If someone searches for an address, they'll get a point (lat/lon). Isn't that geocoding? Why would any program then have to locate the actual street on the map, if it already has a point for the specific address? Seems to me, for routing purposes, you only need to locate the nearest point on any street to figure out how to get there. This may or may not be the same street named in the address, but that's fine, because most houses whose address is on one street, but is actually closer to another street, is on a corner and readily accessed from the other street anyway. Worst case scenario, the driver has to circle the block once he sees where the driveway actually is? If there really is a need to specify access points, isn't that also addressed in this proposal? Vid the Kid 14:33, 22 April 2009 (UTC)

associatedStreet vs. street

I would prefer if the relation type "associatedStreet" would be merged with Relation:street. Otherwise you have to add street segments to two relations, one for saying that several ways are the same logical street and one for relating the houses to this street. This might also touch on Relation:route with route=road. --Shepard 15:07, 31 August 2008 (UTC)

I don’t think merging these is necessarily the best option as a collection-type relation can be used on other things than streets (where a “house” role wouldn’t make sense) and because I’d expect that everything in a collection should be simply a part of the collection, i.e. be described by the collection’s tags – which wouldn’ŧ be the case for houses associated with a street.

In my opinion, the solution is to create an associatedStreet relation and add the street’s relation as a member with role “street”. I’d not be strictly opposed to merging either – adding segments to both ways, however, would be by far be the worst way to deal with this situation. --Tordanik 21:39, 31 August 2008 (UTC)

As I wrote on Talk:Relations/Proposed/Site, in my eyes all relations are collections. I don't really see the additional semantic in having a pure group/collection relation type. I think the real value lies in the finer defined relations. In this case this could still be a relation for general collected ways where one role value would say that something is a segment of this way (not as in the datatype "way" but as in street, river, ...) and another would say that some feature belongs to / is attached to this way (a house, a bus stop, ...).

Of course as you said I could use a relation as the member of the associatedStreet relation (how do I have relations as members of others in Potlatch?) but this seems to overcomplicate things. --Shepard 14:24, 1 September 2008 (UTC)

I think a combined relation would fit for both problems and is much easier to do for mappers. --Patzi 17:05, 18 September 2008 (UTC)

I agree a combined relation is probably better for a couple of reasons:

1) There seems to be a push to make 'generic' relations around the place (look at the boundary/multipolygon case for example). The very close similarities between a collected relation (all the ways making up a road) and the associatedStreet relation (all the houses that are addressed on the SAME street) really means 1 relation may serve better.

2) Calling it associatedStreet is very specific, in my local city I know of both foot malls and docks have addressing systems also, so making it street-specific isn't really appropriate.

3) Even the *house* or *addr:houselink* roles are not really right because there are more than just houses along many streets.

Really the solution is a generic 'collection' similar to the collected way suggestions then allow nodes in there with an 'address' role or something generic like that to link to *any* node that's adressable along that collected item. --Beldin 08:30, 25 February 2009 (who forgot to sign his entry)

Sounds reasonable. I would like to add support for this schema when improving house-number -searching in Traveling Salesman.

However this may fail on corners where an "associatedStreet" is explicitely given so as to avoid attaching the house-number to the side-way (that is a part of the type=street -relation in this case). If one of the 2 ways is oneway=true, then this becomes a seldom case but with a huge impact. --MarcusWolschon 08:13, 25 February 2009 (UTC)

More than one housenumber for a single node/house

How should we handle situations in which one building has more than one housenumber? For example many big companies have an adress like "Nicestreet 12-17" how should we tag this? addr:housenumber=12-17 (maybe another divider) or addr:housenumber=12,13,14,15,16,17? I think i would prefer the shorter one but the longer one should be also supported so that it is possible to have something like addr:housenumber=34,36,37,56 could also be possible. at the moment i use it like addr:housenumber=12-17. --Patzi 17:03, 18 September 2008 (UTC)

I also have a case where I need to map multiple addresses to a single node, but only even numbers. Could we use a syntax on top of the one you proposed, similar to the one found in crontab configuration files (if it's clearer), that be start-finish/step like this addr:housenumber=12-17/2 which could be expanded to addr:housenumber=12,15,17? Pov 23:29, 17 December 2008 (UTC)

I think "1,2,4,7" is much less likely to confuse mappers who cannot consult the wiki on every tag they see. --MarcusWolschon 07:12, 18 December 2008 (UTC)

Ok, I understand. Also, and more importantly, should we add a note or something on the article page or do we keep this feature in the talk page for now ? I'm afraid the discussions here kinda hit an agreement on most points but the article page didn't reflect any of that progress Pov 09:31, 18 December 2008 (UTC)

I guess we can safely add the "a,b,c,..."-notation to the description of the addr:housenumber -tag. (I just did so as "addr:housenumber" seems not to be present in any page except for an old and abadoned proposal.) --MarcusWolschon 12:56, 18 December 2008 (UTC)

I ran into a similar problem: The same house has two different adresses, but only one entry so it's not possible to put the node near the corresponding entries. Any idea on how to add two adresses? Xeen 12:49, 6 January 2009 (UTC)

Is 2 meters to the other node not near enough? Lulu-Ann

I'd really like to be able to support ranges for single nodes: when tagging appartment building entrances, this is necessary for my sanity and yours: I just added a tagged addr:housenumber=46,47,48,49, 50,51,52,53, 54,55,56,57, 58,59,60,61, 62,63,64,65, 66,67,68,69, 70,71,72,73, 74,75,76,77, 78,79,80,81, 82,83 (minus the extra spaces). Ouch! For one thing, speedy data entry on the road with something like Osm2go needs this: I'm not typing that sort of thing out every time with a PDA keyboard! Therefore, I make the following proposal --achadwick 22:04, 7 March 2009 (UTC)

Sub-proposal: ranges of numbers for individual nodes

1. Extend the syntax for addr:housenumber=* to allow hyphen-separated ranges as well as comma-separated numbers, e.g. addr:housenumber=46-83 or addr:housenumber=1,2,7-13,15,16. Currently only the comma-separated form is documented on the main page.
2. Permit addr:interpolation=* on those s or s which are also tagged addr:housenumber=*. Currently only is documented.

For those implementing a parser, hyphens bind tighter than commas; this is quite a common syntax. Interpolation for nodes should only be invoked for ranges specified with hyphens, thus:

Abbrevated form	Fully-enumerated form	Notes
addr:housenumber=1,2,7-13,15,16 addr:interpolation=odd	addr:housenumber=1,2,7,9,11,13,15,16	Choose only odd numbers when enumerating ranges.
addr:housenumber=1,2,7-13,15,16 addr:interpolation=even	addr:housenumber=1,2,8,10,12,15,16	Note that both 7 and 13 are dropped. This is a degenerate case, but enumerate according to the rules anyway.

I think this will be sufficient for most uses, and it's much faster to type. Any takers for this idea? --achadwick 22:04, 7 March 2009 (UTC)

In Ireland, we keep running into this issue all the time. House numbering in this country is very weird, inconsistent and leads to cases such as a single shop having multiple house numbers all the time. I very much like your proposal of allowing addr:interpolation=* on a single tagged with say addr:housenumber=1-8. I am proposing this as the standard solution for Ireland on IRC. Hopefully, others will agree and start tagging using this system. --undo 16:02, 16 November 2009 (UTC)

This page is getting quite full. Could create one under Proposed_features#Proposed_Features_-_Addresses? --MarcusWolschon 08:08, 17 November 2009 (UTC)

One building, two addresses, two countries

My problem is one building with two different addresses with two different street names in two different countries! [2] [3] I used addr:housenumber=* etc. for the US address and addr_ca:housenumber=* tags for the Canadian address. I'm open to any other ideas... -- Gridlock Joe 02:41, 17 June 2009 (UTC)

Ok, now THATs something nobody expected to exist on this planet. You could pick a node for one of the addresses and put the other one on the building-polygon itself. --MarcusWolschon 06:32, 17 June 2009 (UTC)

Baarle-Hertog (BE) and Baarle-Nassau (NL) are another example of a town split by an international border. [4] No buildings have been added there yet, so I couldn't claim a precedent. -- Gridlock Joe 14:51, 17 June 2009 (UTC)

I added two separate address-tags and removed the tags from the building. Non-standard-tags like addr:street_ca=* (which was on the building) are not good for POI-searches and other parsers. --Phobie 13:15, 17 June 2009 (UTC)

Thanks, Phobie. Agreed on the use of non-standard tags; I think your solution probably is the most workable. -- Gridlock Joe 14:45, 17 June 2009 (UTC)

Apartment complexes

In the US, it is common to have multiple buildings with the same street number but with apartment numbers on the units in individual buildings. Would it be possible to build a relation of all of the buildings at a given street number associated with a road and then tag the building with the range of apartment letters or numbers it contains?

You mean something like First house: addr:housenumber=12 addr:apartement=1 second: addr:housenumber=12 addr:apartement=2 and so on? I think addr:apartement=* would suit your needs and would be significant enough. --Patzi 06:38, 19 September 2008 (UTC)

I like this idea, albeit spelt as apartmentnumber. Better still, what bout flatnumber? It's shorter. Do we need interpolation ways for apartment ranges too? Alternatively we could state that a house is a building and an apartment/flat is an element within a building; and therefore there's a natural bilevel ordering. What about flat numbers doing the even/odd thing though, or incrementing alphanumerically when the house addresses doesn't? I think we *do* need to treat flat interpolations separately. Fortunately they're quite rare :) --achadwick 20:55, 7 March 2009 (UTC)

If the user wants to drive to a house-number but there are multiple places with that house-number, what do you suppose should be the lat+lon of the desination? What if these buildings are far apart? Does that case exits? --MarcusWolschon 06:58, 9 March 2009 (UTC)

Alphabet interpolation

While collecting data in Dresden, I came across a number of cases where a building (say housenumber 1) has several flats that are designated by letters after the house number, such as from 1 or 1a to 1z. I've tagged these with interpolation=alphabet for the moment. Is there a better way of doing that? --Bigbug21 12:36, 19 September 2008 (UTC)

Not yet but let's keep collecting such cases. No algorithm implementing this schema will evaluate this yet except for the single houses 1, 1a and 1z. We will need to know what strange things exist and how common they are to improve the schema later. --MarcusWolschon 16:56, 21 September 2008 (UTC)

Yet another issue: There are some villages around here which have house numbers like A3 or G25 (that roads go by letters, but the actual numbers always include the letter). Example: [5]. That should be considered as well when in comes to interpolation. --Bigbug21 15:46, 5 October 2008 (UTC)

Patch needs improvement

Currently, the patch display is unable to handle four-digit and higher house numbers without making them practically illegible. Given such numbers are the rule, not the exception in many, many areas, this is a big issue that needs to be fixed in the display before house numbering is really usable in any way. Circeus 00:03, 1 October 2008 (UTC)

The rendering has been changed in January 2009 (for the Mapnik and Osmarender layers): the numbers are now drawn without the background circle and as such show up properly even with 4 digits or more. Alv 08:17, 16 February 2009 (UTC)

The data is still usable for routing or other software, even if shown suboptimally on the default maps. Hopefully those with the knowhow get a better rendering for longer numbers. Likely it is some Canadian numbering convention which leads to numbers of that magnitude? Everywhere else I know the numbers start at 1 or thereabouts for every street and very few streets are so long as to have over one thousand houses (or a length of 10 km if it's one number per 10 meters). So do these cities assign numbers per distance from the street's end in feet? Alv 13:15, 1 October 2008 (UTC)

AFAICT, this is a situation found in every North American city of any decent size. It took me five minutes to find examples in Plattsburgh, NY: 3036 Rt. 22 Main Street, 1790 Main Street, 9631 Route 9. I'm not clear what the numbering scheme ARE, but I do know such numbers are common here. Circeus 17:12, 1 October 2008 (UTC)

Just to answer this: over here in Washington state, and likely for many other states/cities, the house numbers tend to be two digits longer than the street number. For example, the part of a road between 14th Street and 15th Street would be called "the 1400 block" and houses would be numbered between 1400 and 1499 (assuming the streets weren't "moved" and the designers weren't arbitrary -- there are cities where block numbers are at a 300 or 500 offset from numbered streets, which is very disconcerting). With 10 or 16 or 20 streets per mile, street numbers over 300 are common, thus house numbers over 30000 may be present. --goldfndr 04:08, 16 February 2009 (UTC)

It's not always a 100-per-block situation. Sometimes it's 1000-per-mile. And sometimes it's a somewhat arbitrary scale chosen so that house numbers approach a certain limit near the edge of the area (such as a county) over which the numbering scheme is relevant. But there's a big point that hasn't been mentioned yet: In the US, nearly all address systems have a common origin. (That's "origin" in the sense of Cartesian coordinates.) That means a very short street far from the city center can have a range of addresses such as 13002 to 13248. In fact, a street's housenumbers won't approach 0 unless that street intersects one of the axes of the address grid. Vid the Kid 15:12, 22 April 2009 (UTC)

Extra nodes when the building outlines are available

Sometimes we have city center houses (as per house numbers) that share a wall - most of these are likely or at least possibly drawn as a continuous single building. Then adding extra unconnected nodes for the house numbers seems reasonable. Likewise when one building in an intersection has different house numbers on both streets, extra nodes near the appropriate walls is how I've done it. But what's others' opinion, if a building is unambiguously near the one and correct street and the outline is available, should we keep the numbers tagged in the way making up the building (my opinion) or "allow" adding nodes. Alv 11:24, 23 October 2008 (UTC)

We have a problem here. This housenumber mapping seems to be done only for visual maps - Currently the nodes are set on estimated positions, that represent the middle of the building or just look good on the map.

What we need for OSM for the blind and the pedestrian navigation tool LoroDux is very exact nodes on entrances, that are no doubt on the outline of the building and are connected!

Please don't recommend to map house numbers as estimated positions any more.

If the rendering of housenumbers is to close to the road to look nice on a visual map, that shoud be corrected in the renderer, not by wrong mapping.

(If you wonder what a visual map is, see HaptoRender for the opposite, a haptic or tactile map.)

--Lulu-Ann 20:46, 17 June 2009 (UTC)

Which "this"? The extra nodes are inside the building outline, naturally. For example this entrance belongs to a building that has addresses on both nearby roads and has four distinct entrances. Alv 21:57, 17 June 2009 (UTC)

Usually the house numbers can be assigned to entrances. Why did you call the entrances A, B, C instead of using the node for the housenumber, too ? How shall a blind person find the right entrance, when the GPS position of the node is somewhere in the middle of the building instead of on the outline? --Lulu-Ann 23:02, 17 June 2009 (UTC)

Because In Finland the entrances are considered properties of the single building; there isn't a house 4 A and a house 4 B and 4 C, but a building with the housenumber 4 and that building has four staircases with the letter identifiers. (And it could even be that several physical buildings share the number where they're part of the same housing cooperative.) Just as I wouldn't cram 100 housenumbers (4 A 1, 4 A 2, ..., 4 D 100) inside a building when that building has several staircases and 100 apartments.

Node is inside a way with building=yes -> it's one of that building's numbers -> find a node with building=entrance on that way. Alv 23:34, 17 June 2009 (UTC)

You did not answer my question. How shall a blind user find the right entrance, if the house number is not a node at the entrance but a node in the middle. Working algorithm, please! (Or admit that is doesn't work.) The right way to do it in your case would be to have several house numbers on one entrance node, which should be no problem and can easily be routed. --Lulu-Ann 11:15, 21 June 2009 (UTC)

I did. If the building outlines are not available, there will be just a node and no information on the various entrances. If the address node is inside an area with building=*, check that way's nodes for entrances. So you'd add on every entrance node addr:housenumber=4 addr:staircaseletter=x addr:street=Vähänkyröntie addr:alternatestreet=Sofianlehdonkatu addr:alternatehousenumber=11. So someone searching for the building (as most do) would get four (or more) results. Searching just the addr:street+addr:housenumber combinations won't then find the address on the Sofianlehdonkatu street at all. Some houses have even three addresses on three streets. Alv 08:41, 2 July 2009 (UTC)

"Searching just the addr:street+addr:housenumber combinations won't then find the address on the Sofianlehdonkatu street at all" - I take that as you admit it won't work. --Lulu-Ann 10:09, 2 July 2009 (UTC)

No, it won't find if they're as some addr:alternatenumber and addr:alternatestreet... - your way. Alv 10:55, 2 July 2009 (UTC)

"skip"-part

Who removed the "House-numbers that are tagged as a single node always take pecedence over interpolated ones and are skipped in interpolation" from the page? You can't just change the documentation of an existing algorithm at will. --MarcusWolschon 08:01, 12 November 2008 (UTC)

Just have a look at the history: Joto did that. --bkr 12:07, 22 November 2008 (UTC)

I've just run into a situation where the current "skip" part showed some problems. Here's a link to [OSMI]'s take on the problem so I have to avoid some pretty heavy ASCII art lifting. As you can see, by skipping nodes with address information in the interpolation calculation we end up having numbers in that order: 51....39-35-37-33-31...27. We should redefine the algorithm part so that even though defined numbers are skipped, the interpolation is done on a per-segment basis, not a per-way basis so that we don't see stupid stuff like this. Pov 21:43, 23 December 2008 (UTC)

Just make the nodes a part of the interpolation-way or split it up if you want that behavior and you're set. If the interpolation is not equidistant that it was just mapped wrong. May happen. At one time all houses are mapped individually and this issue goes away all by itself. I do not particularly like the idea of complicating algorithms even more by required the estimation of a corresponding point on the interpolation-way of nodes that are not a part of that way. (My connection is too slow to load your example over the cell-phone during the holidays.) --MarcusWolschon 11:39, 25 December 2008 (UTC)

BTW: What do you suppose to do instead of skipping them? Have 2 or more locations for the same address when searching? How is the user to choose between them when we are the ones to tell the user where that address (s)he is searching for is located? --MarcusWolschon 11:49, 25 December 2008 (UTC)

Okay, I managed to load your example. The node tagges 37 should be a meember of the way going through it. Trivial mistake. --MarcusWolschon 11:55, 25 December 2008 (UTC)

Maybe my explanation wasn't clear, but the node is part of the way! And I certainly don't want dupes. What I was suggesting was that, with a node in the middle of a way, the interpolation is adjusted so as to avoid numbers going in reverse order around the node in the middle of the way because the interpolation isn't done on a per-segment basis. Pov 23:48, 25 December 2008 (UTC)

Then that script implemented it incompletely by looking only at the first and last node of the way. Look at the [[6]] to see how this is already covered. --MarcusWolschon 08:56, 26 December 2008 (UTC)

I haven't looked at the examples, but I only imagine two cases. First, the "defined" address is already part of the interpolation way. If that's the case, it should be used as a vertex in the interpolation process, and the process of interpolation should then find exactly that point when looking for the specified address. Or, the geocoder will notice that that specified address is already marked with a node, then it can skip the interpolation process altogether. Either way, the result will be the same. In the other case, the "defined" address is not part of the interpolation way. Then, the possibility exists that the geocoder might find two points for the same address: one defined by the node, and one found by interpolating on the way. If the geocoder is sure that the node and the way both refer to addresses on the same street (not two streets with the same name) then it should only report the node with the exact address. This doesn't have to be phrased as "skipping" the defined address, but simply reporting the better-defined result. (All this depends on the geocoding program being certain that the address defined on the node belongs to the same street as the addresses interpolated on the way. If the node is not part of the way, there can be a lot of problems with that, unless that AssociatedStreet relation is used...) And then there's reverse geocoding. If, given a point, a reverse geocoding program decides the point lies along an interpolation way, and there are other addresses for the same street defined on nodes that aren't part of that way, then it makes sense to talk about "skipping" the defined addresses. And if the node where the address is defined isn't very close to where that same address would be interpolated, then you can get some out-of-sequence results for reverse geocoding. And the same caveats about associating these things to the same street apply. I think the solution would be to make sure the node with the defined address is part of the interpolation way. If that's true, there shouldn't be a problem, as I pointed out at the beginning of the paragraph. Vid the Kid 15:09, 22 April 2009 (UTC)

Redundant tagging a problem

I think the current proposal with the following tags addr:street=*, addr:full=*, addr:postcode=*, addr:city=*, addr:country=* is a mistake. Sounds harsh; let me elaborate. As as computer engineer when I design a database, avoiding duplication of data is a no brainer. It may slightly complexify the storage of data, but there's a big reward and that may be summarized by this golden rule: modify once, apply everywhere. Those aforementioned tags only duplicate what's already stored somewhere else. Suppose the street's name change. Rare but possible. If there's a relation between the numbers and the street, you modify the street's name and boom! You're done. Getting the street's name of a house is easy, it's just a matter of following the other end of the relation. But if we were to use the addr:street, or worse addr:full, imagine the nightmare that would ensue to keep all those data consistent. I'll let you think of the consequences of a postcode modification as an exercice :) The argument that it helps humans to access the information is moot. Seriously, who uses OSM's data by directly looking at attributes of nodes? Pov 22:29, 15 November 2008 (UTC)

I don't like that part too. I'm a fan of polygons and relations for this. That's why I'm not using that part myself and tag the street's name on the street, the suburb- and city- names and the zip-code in a polygon. --MarcusWolschon 12:12, 17 November 2008 (UTC)

We could just remove the relation-less method from the list. IMHO it's anyway easier to add a relation than to write all the address information many times for every house. --bkr 00:27, 29 November 2008 (UTC)

Removing it from the list does not change anything about the fact that the relation-less version is prevalent in the database. And adding a relation is in fact more work, if only because JOSM has a "Paste Tags" feature, but not a "Paste Memberships" feature. Implementing the latter would help relation usability more than wiki politics. --Tordanik 20:22, 29 November 2008 (UTC)

Ok, I see your point. The fact that the relation-less version is prevalent is not that important, it wouldn't be overly complicated to mass process most of the data to make it compliant to the new spec. Data that would fail to be processed would be problematic anyway. As far as JOSM's limitations goes, I guess the real problem is the lack of relations templates and I'm sure that house numbers are not the only feature that would benefit from adding this to JOSM. Of course this goes beyond house numbers' scope and should be discussed someplace else. Pov 23:14, 29 November 2008 (UTC)

I agree that duplicating data is bad. I believe that they allowed this duplication, in order to make house numbering easy for mappers (rather than for users), which should not be disregarded as a main goal: the map will be there, only if it's easy to do it also for non DB experts. One possible improvement could be like the following:

• I create a point which is a new building, and add its number
• Then I can click on the road it belongs to, and the editing tool automatically creates the required relation, without duplicating data (nor bothering me with relation details)

This approach requires to patch existing tools to add specific support for numbering, still I believe it's worth it: numbering is so useful. Of course it can easily be extended to interpolated numbers and the like. Alfredio 18:00, 1 February 2009 (GMT)

example-algorithm

we could just remove the relation-less method from the list above. imho it's anyway easier to add a relation than to write all the address information many times for every house. --bkr ..11:49, 22 November 2008 (UTC)

If there is no relation (the usual case) then the algorithm needs to deal with that. If you removed that part then it would only work at all for a fraction of the data we have. If that's how people map it, then that's what an implementation gets as input. --MarcusWolschon 20:01, 23 November 2008 (UTC)

Can't we set for a good way of doing it (using relations) and just process the existing data to clean it according to the new version of the spec. That would considerably simplify the algorithm and avoid problems of the current spec too. Deciding this now would also prevent useless work and further "bad" data to be input the system ASAP. Pov 22:29, 23 November 2008 (UTC)

Requiring (huge numbers of inexperienced) mappers to add the relations for all house-numbers (lots and lots of them) in the future is no option. Who is willing to write an osmosis-task to do that step as a pre-computation before using this data in an application? --MarcusWolschon 08:18, 25 February 2009 (UTC)

Apartment Blocks, Blocks of Flats, Communities, Business Parks, Campuses etc...

Something that's been mentioned a few times in here and in building discussions is how to deal with apartment blocks... I'd say this is related to many forms of address that are related to an entity that is not a street in addition to apartments, such as buildings in a business park, buildings in a campus etc. Typically being areas that can cover a reasonably large area...

I'd summarize the address possibilities as follows, please add if you've seen any more...

1. Buildings are against a road with each having their own building number related to the road, e.g. Appt 102, 49 Hill Street, Fake Town...
2. Buildings are against a road with each having their own building number related to the road, but, apartments/suites/etc reachable via specific entrances, e.g. Appt 102, Entrance 4, 49 Hill Street, Fake Town...
3. Buildings are part of a larger complex with buildings named or numbered relating to that complex with the complex potentially having a name and/or number relating to the street, e.g. Appt 102, Building 3, Homely Community, 49 Hill Street, Fake Town...
4. Buildings are part of a larger complex with buildings named or numbered relating to that complex, specific entrances existing that provide access to certain apartments and the complex itself having a name and/or number that relates to the street, e.g. Appt 102, Entrance 5, North Building, Homely Community, Fake Town or Appt 102, Entrance 5, North Building, Homely Community, 59 Hill Street, Fake Town.

I'm trying to work out how to deal with the latter of those where a complex/community may have 1 or more named or numbered, possibly gated/guarded entrances, the community will likely be an entire block, the community will have a name and it may have a housenumber for the entire community, buildings are named or numbered and have 1 or more entrances providing access to the apartments within.

The use of addr:street unfortunately only applies to streets, otherwise it could have been used to link the building numbers to the complex then the complex overall node could have gained the street number and addr:street to show which street the housenumber relates to... dkt 10:02, 9 December 2008 (UTC)

If we added addr:aptnumber=*, addr:aptname=*, addr:aptblocknumber=*, addr:aptblockname=*, would that solve the problem for blocks of flats/apartment blocks? They're not traditional houses, that's for certain. --achadwick 21:33, 7 March 2009 (UTC)

--achadwick 21:33, 7 March 2009 (UTC)

Proposal: Making the link of housenames to streets more robust (by User:SlowRider)

The following proposal tries to incorporate Relations/Proposed/Collected Ways to get an unambiguous and reliable relation between housenames and the street they belong to. All segments of a street are first put into a street relation. The relation is given the name of the street. Then the housename nodes are added to the very same relation as role=addr:houselink.

This makes the address relations much more robust, but puts some extra work on the shoulders of the mappers:

  
<node id='1'  lat='48.99772077613563' lon='8.390096880695504' />
<node id='2'  lat='48.996870577321786' lon='8.388697443728406' />
<node id='3'  lat='48.99797799901517' lon='8.390466092937745' />
<node id='4'  lat='48.99767157650778' lon='8.390030650427239' />
<node id='5'  lat='48.997682328174704' lon='8.389127510405448' />

<way id='10'>
  <tag k='highway' v='footway' />
  <nd ref='1' />
  <nd ref='2' />
</way>
<way id='11'>
  <tag k='highway' v='residential' />
  <nd ref='2' />
  <nd ref='3' />
</way>
<way id='12'>
  <tag k='highway' v='residential' />
  <tag k='bridge' v='yes' />
  <nd ref='3' />
  <nd ref='4' />
</way>
<way id='13'>
  <tag k='highway' v='tertiary' />
  <nd ref='4' />
  <nd ref='5' />
</way>

<node id='6' lat='48.99758693554065' lon='8.390053067282306'>
  <tag k='addr:housenumber' v='1' />
</node>
<node id='7' lat='48.997905619553315' lon='8.39046152143938'>
  <tag k='addr:housenumber' v='2' />
</node>
<node id='8' lat='48.99761386658398' lon='8.38915312158458'>
  <tag k='addr:housenumber' v='3' />
</node>
<node id='9' lat='48.996866530131754' lon='8.388753644441946'>
  <tag k='addr:housenumber' v='4' />
</node>

<relation id='13'>
  <tag k='type' v='street' />
  <tag k='name' v='Foostreet' />
  <member type='way' ref='10' role='member' />
  <member type='way' ref='11' role='member' />
  <member type='way' ref='12' role='member' />
  <member type='way' ref='13' role='member' />
  <member type='node' ref='6' role='addr:houselink' />
  <member type='node' ref='7' role='addr:houselink' />
  <member type='node' ref='8' role='addr:houselink' />
  <member type='node' ref='9' role='addr:houselink' />
</relation>

Could you develop how it's more robust than the current relation model? Also, what's the benefit, from your point of view, of repeating the street's name in the relation (I hate cloning info BTW, see #Redundant_tagging_a_problem above).

It Looks to me like the suggestion isn't that the street's name is repeated, but, that it only exists in the relation. dkt 19:23, 10 December 2008 (UTC)

Also... It's more robust in that the housenumber nodes are linked to the generic street relation achieving a single relation for one street rather than multiple relations for numbering and naming or the alternative without relations, addr:street... dkt 19:28, 10 December 2008 (UTC)

Isn't that very similar to Proposed features/House numbers/Karlsruhe Schema#Case: Relations (easy for computers, difficult for humans)? type=street is better than type=associatedStreet but role=street is better than role=member and role=house is better than role=addr:houselink --Phobie 22:31, 10 December 2008 (UTC)

That's what I thought too. I think the working model is robust enough. I fear User:SlowRider thinks there must be a single relation for every house or something... —Preceding unsigned comment added by Pov (talk • contribs) 00:39, 11 December 2008

It is very similiar. But the point is that one relation would be easier (and thus more widely used) than at least 2 relations (one 'accociatedStreet' and one 'street'). Since both relations try to do something similiar (define what street objects belong to), it is reasonable to use one relation for both. Put all street parts into one relation as well as all housenumbers, instead of all street parts in one relation and the housenumbers in at least one other relation. I guess the role-values can still be discussed on. I would prefer 'house' over 'addr:houselink', since it sounds more generic. The street parts might not even need a role, since they make up the 'street' (ways in a route don't have a role either, do they?). You already know that they are a 'member' of the relation and that they are part of the 'street', so at least those two roles would be kind of redundant. But I guess that's not the most important issue. :) --Driver2 15:12, 11 December 2008 (UTC)

First, sorry for forgetting to sign my previous comment.

The more I think about it, the more I think you're right: Relation type=street is enough compared to associatedStreet. But I think that not adding roles for street segments is dangerous. First because it will create problems with interpolation-ways if one forgets to add a role and because it kinda contradicts the logic of determining members by their role. If we think that because the way is tagged accordingly is enough to determine it actually is a way, then, why bother with a role for other members? They're nodes with a addr:housenumber key or ways with an addr:interpolation key. Isn't that enough? For the sake of consistency we should either role everything or nothing, but not part of it.

Pov 16:59, 11 December 2008 (UTC)

I didn't say we determine the role by the fact that it's a way. I meant it is determined by the fact that it is absent. "No role" = "Default member", in this case a member of "type=street", so it's part of a street. But anyway, I have no objections to adding a role.

I would propose: type=street for the relation, role=house for a house-node/area or interpolation line, role=street for the parts of the street (ways).

--Driver2 16:54, 12 December 2008 (UTC)

I was about to blindly agree with all of that but then I remembered to do a search and found that there's already a Relation:street that exists. Should we merge or should we either keep the existing associatedStreet name or move to a more logical type=addr:link ? Pov 17:47, 12 December 2008 (UTC)

Of course it already exists. That's exactly what is being proposed here: Use the street-Relation for housenumbers too, instead of having two types of relations (street and accociatedStreet) for a very similiar task. The page you mentioned is linked in the very first post of this subsection. --Driver2 18:45, 12 December 2008 (UTC)

In a perfect world a rule for the street-segments would not be needed, but in reality we will see houses and interpolation-ways without a rule set. If all members needs to have a rule set it is easier to find errors! --Phobie 05:21, 13 December 2008 (UTC)

way ids instead of addr:street

Wouldn't it be more consistent (against typing errors, for further use of OSM data and not to redundantly add the addr:street tag again and again) to add a way id to a house. Simply:

<node ...>
<tag k="way_id" v="84573485">
...
</node>

Editors could support this and automatically add the way_id, when the user sets a street name. I am planning to write an algorithm which tries to get the way id for every POI. We HAVE the ways in OSM, why don't use their ids to connect the houses with the ways? --MapDeliverer 16:35, 29. December 2008 (UTC)

Your idea is already implemented! Add the node/way to a relation and only tag the relation. --Phobie 16:15, 29 December 2008 (UTC)

addr:interpolation=alphabetic

"alphabetic" doesn't seem to render the line between the addresses at its ends, a test is here.

Also it isn't very clear from the description "7a - 7f will be: 7a, 7b , 7c, 7d, 7e" what the last housenumber should be. If the street has houses from 8a up to 8c, what addr:housenumber= values would the end nodes have? I suppose "8a" and "8c", but the page suggests "8d" (what comes after "z" then?). Balrog 14:01, 5 January 2009 (UTC)

Giving hints about the road-access

The proposal how to map hints about the road-access is incomprehensible:

<relation id="??">
  <tag k="type" v="roadAccess" />
  <member type="way" ref="11" role="accessto" />
  <member type="node" ref="11" role="accessvia" />
  <!-- (optionally multiple <member type="node" ref="11" role="accessvia" />
        for multiple access-locations to the adressed place e.g. for
        convention-centers) -->
  <member type="way" ref="???" role="accessfrom" />
</relation>

• Where I can put the address node (or addr:housenumber and addr:street)? This information is necessary.

• I do not know which way is intended to have the role "accessto".

• I do not know which way is intended to have the role "accressfrom".

For me the following scheme seems more logical:

<relation id="??">
  <tag k="type" v="roadAccess" />
  <member type="node" ref="??" role="accessto" />
  <member type="node" ref="??" role="accessvia" />
  <!-- (optionally multiple <member type="node" ref="??" role="accessvia" />
        for multiple access-locations to the adressed place e.g. for
        convention-centers) -->
</relation>

--Hatzfeld 22:50, 17 January 2009 (CET)

I agree. The example needs to explain these 3 points. --MarcusWolschon 06:41, 19 January 2009 (UTC)

I think it would be better to implement the ideas of Proposal: Making the link of housenames to streets more robust and the talkpage of Relation:street:

Example:

<relation id='13'>
  <tag k='type' v='street' />
  <tag k='name' v='Foostreet' />
  <member type='way' ref='10' role='member' />
  <member type='node' ref='678' role='associated' />
  <member type='node' ref='888' role='accessible' />
</relation>

<relation id='14'>
  <tag k='type' v='street' />
  <tag k='name' v='Barstreet' />
  <member type='way' ref='11' role='member' />
  <member type='node' ref='888' role='associated' />
</relation>

• 10 is part of the street Foostreet
• 678 is a house on Foostreet
• 888 is a house accessible from Foostreet while it is part of Barstreet

--Phobie 09:50, 29 January 2009 (UTC)

I like this, however sometimes it might be needed to only associate a part of a road as access to a house. If a street goes around the house, you never know which part of the street allows access. Or would you neglect that? --Driver2 17:13, 31 January 2009 (UTC)

That's the beauty of using relations: they apply to ways (unlike vague tags like addr:street which aply to all ways having the same name), split the U shaped way in two, only use the part that makes sense in the relation. Pov 17:36, 31 January 2009 (UTC)

The street relation is thought to combine all ways belonging to the a street. Including only a part of the street in the relation doesn't make sense. However with the associatedStreet relation, this would be possible, but my question was directed at the street-relation. --Driver2 17:57, 31 January 2009 (UTC)

But the accesssvia way isn't supposed to be part of the main way, no ? So we can add only the relevant segments of the access way to the relation while keeping all the segments of the main way in the relation. Pov 20:29, 31 January 2009 (UTC)

'accessible' is meant to be a rough hint for navigation. If you want to be exact draw a access-service-road or invent a "access-from-street-node" house node tag. --Phobie 12:47, 21 February 2009 (UTC)

Addresses format (as used in other datasets) in British Isles

It would be good to see full addresses be added to tags on addresses nodes / buildings (and other addressable objects) in UK with elements relating to BS7666 standard, although in this format they may not make up a quite so readable postal style address.

http://www.govtalk.gov.uk/gdsc/html/frames/BS7666Address.htm

In that way OSM could in future inferface with datasets that held address element in BS7666 format. or even become if not linked to a free version to rival the National Land and Property Gazetteer.

http://www.nlpg.org.uk

To work out well it would be good if the tools used to edit OSM parse/validate the address tags to BS7666 format. Pulling some fields such as locality and administrative area from wider polygons is something to be consider but this may cause more problems than worth.

More on format of NLPG: http://www.idea.gov.uk/idk/aio/6055969

I think worth looking at specs of these other address sets, I realise we have to be carefull to avoid any contamination, as like with mapping data it would have to be made clear that details entered into OSM tag would have to be from direct local knowledge, public domain or suitably licensed sources. The only data that could be directly used coming from the NLPG itself is the Unique Property Reference Number (UPRN). Hopefully in time these will become more widely know and used. At moment it is only if particular professions that it is used outside local government. http://www.searchflow.co.uk

There is also Unique Street Reference Number (USRN) which is being by all that dig in the road, which could be added as tag to OSM streets, where know, e.g. from roadworks notices. Note there are significant differences with addresses in format of the Royal Mail's Postcode Address File (PAF) ftp://ftp.royalmail.com/Downloads/public/cmwalk/doc/active/doc21800003/PAF_Digest_Dec_03.pdf which is widely used including as basis for Addresses Layer 2 (which also contains Address in BS7666 format) from Ordnance Survey.

http://www.ordnancesurvey.co.uk/addresslayer2/

One difference for addresses the numbers with suffixes eg 1A or in ranges 1-3 are treated like building names in PAF but as numbers in BS7666 Format.

Discussion of OS AL2 vs NLPG http://www.agi.org.uk/POOLED/ARTICLES/BF_NEWSART/VIEW.ASP?Q=BF_NEWSART_217205

Ordnance Survey response: http://www.agi.org.uk/POOLED/ARTICLES/BF_NEWSART/VIEW.ASP?Q=BF_NEWSART_229130

For a list of 'post towns' see: http://www.abcounties.co.uk/bpa/bpasection3.htm It seems Association of British Counties would wish to encourage a tag/field of traditional county as distinct from administrative area.

And when it comes to international address standard then trying to relate fields of various systems that have grown up in each postal system presents all sort of challenges. See: http://www.isotc211.org/Address/Copenhagen_Address_Workshop/index.htm http://www.isotc211.org/Address/Copenhagen_Address_Workshop/papers/CoetzeeEtAl_TowardsAnInternationalAddressStandard_GSDI-10_2008.pdf http://www.isotc211.org/Address/Copenhagen_Address_Workshop/papers/Coetzee_AddressDataExchangeInSouthAfrica_ISOWorkshop_May2008.pdf

Bunny 1 Feb 2009

Well, you are free to define a tag for this to be used in the UK, start using it and then document it in the wiki. As for international addresses; Yes they can be difficult but for a map of the world we cannot have 100+ address-tags-semantics and the current one works most of the time. As for editor-support... everyone is screaming for editor-support of his/her idea. Write a patch/plugin for at least JOSM and Potlatch and submit it. That's the way to go here. We are short on software-developers all over the place and they are not sitting around waiting for new ideas what to do with all that free time of theirs. --MarcusWolschon 07:41, 2 February 2009 (UTC)

Giving hints about the road-access - why not use the highway tag for this?

IMO the access of a house is simply a footway or sometimes a service road. IMO its strange to use relations for this purpose. A special highway type (e.g. highway=access_footway) might be more suitable.

Advantages:

• Its easier for a mapper to draw ways than to create relations.
• Non-linear ways can be added (useful for non-convex houses).
• A renderer can draw the ways that access the houses if he wants to.
• Some mappers are already using highway=footway for this purpose now. This has the drawback that these way can not be omitted from rendering.

--Grungelborz 11:41, 1 March 2009 (UTC)

That is actually an interesting idea. --MarcusWolschon 12:02, 1 March 2009 (UTC)

I agree, interesting idea. I'd combine this with mapping entrances to buildings. In situations where buildings are directly adjacent to, for example, a pedestrian area, you'd probably not draw some footway, but only add an entrance node into the building polygon. In other cases, entrance + access footway leading to it seems to be the most natural solution. --Tordanik 13:56, 1 March 2009 (UTC)

Sounds good to me, at least for places where individual houses are mapped. For a walkway to the house, I might suggest highway=footway, access=private. Renderers probably shouldn't render such a combination prominently anyway. If anything, a thin/faint dashed line. For a driveway to a garage/carport, there already seems to be highway=service, service=driveway. I'd think that last one should probably imply access=private. I can see this happening in rural parts of the US, where many houses are set back a half mile or more from the road. Vid the Kid 15:43, 22 April 2009 (UTC)

House-Numbers supported in Traveling Salesman

Great news: I was able to add support for searching house-numbers (nodes, house-polygons and numerical interpolation) to the Traveling Salesman -navigator.

Now I expect you to add more of the missing house-numbers to the map so people can actually route house to house. ;)

• forum-post announcing the feature
• Test address-search in Traveling Salesman via Webstart (dont forget to import a map first)

If you find anything wrong, you can open a browser-windows for a bug-report simply via help->file bug report . --MarcusWolschon 18:36, 14 March 2009 (UTC)

Case: Selecting the street the series of house-numbers belongs to

Proposed features/House numbers/Karlsruhe Schema#Case: Selecting the street the series of house-numbers belongs to

I find it odd that the code there puts the <tag k="addr:street" v="AStreet" /> one one of the nodes, and not on the way with <tag k="addr:interpolation" v="even" />. Seems to me, it makes a lot more sense to associate the entire way with the street, not just one of its nodes. After all, in the relation version, it's the way that's in the relation, not one of its nodes. Did someone just typo the code? Does anyone even care about the non-relation version? (Having a relation or two for every street seems like overkill to me. Potlatch doesn't make it easy to work with relations in an area where there are already several relations, and I've heard some complaints about making a lot of relations in JOSM, too. I guess eventually relations will be everywhere, but the editors will have to be able to manipulate them in a more streamlined manner.) Vid the Kid 15:20, 22 April 2009 (UTC)

Yes, looked like a typo. I changed the text. IMHO one type=street relation for every street and its related objects is a good thing. In JOSM there is no problem with using many relations and Potlach should not be used for any complex thing. --Phobie 23:01, 23 July 2009 (UTC)

Hamlets/Localities without street names

In rural areas in Germany, residential streets in a hamlets or even smaller living places often don’t have a name. Instead, houses are numbered through the whole village. I know of other regions in other countries where this is the usual way of numbering houses. Using this proposal, I would have to name all the residential streets like the village (because that’s the “street” part of the addresses there) and add them all to the associatedStreet relation. As the streets aren’t named, this tagging would be “wrong”. Thus I am missing a way of adding a place=* node to an associatedStreet relation in this proposal, may it have the role “street” as well or something different. --Candid Dauth 17:23, 17 May 2009 (UTC)

Another example is the Highlands of Scotland, where most crofting townships have numbered houses in villages, without named streets.--tms13 16:41, 22 June 2009 (UTC)

Actually you would just use no street-name at all (the nearest street=way with "highway"-tag is used and in rural areas there are not many streets) or an associatedStreet-relation (does not need a street-name). So...is there a problem? --MarcusWolschon 10:13, 23 June 2009 (UTC)

Loads of numbers in a small area

Sometimes, there are loads of numbers in a very small area. In this example, the apartments in a two story house are individually numbered from 22 to 56 (I have used the interpolation tag, but typed it wrong, it's in the process of rerendering). It is impossible to tag every number individually if you don't want the map to be extremely clobbered with numbers, and apartments on top of each other can't possibly be shown correctly. Also, it would require going up to every entrance and check the number, and that's just a little too creepy to me... This is where interpolation has to be used, and I know what's written on the page is an utopia, but it's really impossible to accomplish even if you would want to. /Grillo 21:22, 19 May 2009 (UTC)

Well, then I can only suggest to use interpolation or to propose a better schema or an extension to the current schema for discussion. --MarcusWolschon 05:55, 20 May 2009 (UTC)

Node with house number in the way

Why not simply include the house number in the way itself, that way routing algorithms could figure out the number more easily ? Refer to http://www.openstreetmap.org/?lat=-23.544124&lon=-46.561296&zoom=18&layers=B000FTF Diogownunes 21:55, 24 July 2009 (UTC)

Which side of the road are they? How far from the road? What about different numbers on opposite sides of the road at (otherwise) exactly the same place? Alv 22:08, 24 July 2009 (UTC)

Good points, I don't really care which side of the road they are - as long as you can actually get routed close enough to the number you want - I see that in most cases, the house or building or entrance is very close to the street. Leaving the house numbers on the side of the road makes for beautiful maps and all, but would be next to impossible to implement in routing software in an easy way.--Diogownunes 02:06, 22 August 2009 (UTC)

Makes little sense. The point of house-numbers is to be routed to the point where the house is. If I can only be routed to the street (that may span a dozen kilometers) I would not need house-numbers in the first place. Of cause you are not forbidden to make the way itself an interpolation-way for very trivial cases or of you have no more details e.g. in an import. --MarcusWolschon 06:51, 27 July 2009 (UTC)

Not what I meant at all. You would have the house numbers every so often, so that routing software could "suggest" a location close enough to where you're trying to get to. Check the link to see how the map is rendered.--Diogownunes 02:06, 22 August 2009 (UTC)

I Actually sees Diogo's point of view. I have used routing software that grouped addresses in bunches of, lets say 25 numbers, giving you sections of the road where you are close to the house, but not necessarily infront of it. This will give the same accuracy as addr:interpolation, and works perfectly fine if the numbers are parallel (i.e. 110 is between 105 and 115), but this would not work very well if the numbering is offset between left and right hand sides of the road. It is not necessary to put in every single house when numbering (though I have almost done that as most houses I have marked have unique names), setting an address node at the side of the rode and connect them with addr:interpolate is a very good way of simplifying the tagging. Of corse if an import have no information if the numbers are left or right, than this is a temporarily solution, but the area should than be resurveyed to locate the numbers left/right at an oppertunity (maybe an idea for Walking Maps Paper mapping party?) --Skippern 03:40, 22 August 2009 (UTC)

Additional address tags needed

There is a need to extend the (standardized) list of address tags. Some countries use county/district in addition to (or instead of) national subdivision (state/province). Also often street names are unique on suburb/city-district level, and address should contain both city name and suburb name.

This idea is well supported by other standards for address elements:

• RFC 4119 defines elements a1 (state/region/province/prefecture), a2 (county/parish/gun/district), a3 (city/township/shi), a4 (city division/borough/city district/ward/chou), a5 (neighborhood/block), a6 (street); RFC 5139 extends RFC 4119 scheme by adding new thoroughfare elements
• OASIS xAL (Extensible Address Language) uses these: Country, AdministrativeArea, SubAdministrativeArea, Locality, DependentLocality, Thoroughfare, DependentThoroughfare
• UPU (Universal Postal Union) standard S42 (developed together with CEN) uses these: country, region, proximate town, town, district, thoroughfare, secondary thoroughfare.

I suggest extending the list of address elements here on global basis rather than developing local conventions for each country in order to facilitate unified mapping and allow various software to understand various address components. --Yuri Nazarov 09:31, 26 August 2009 (UTC)

Also see: Proposed_features/House_numbers/Karlsruhe_Schema/Additional_tags. --Driver2 12:44, 15 December 2009 (UTC)

Why is there addr:housename when name is perfectly fine?

Why do we have addr:housename=* when name=* would be perfectly fine for this? --seav 06:01, 29 August 2009 (UTC)

Because in some countries housename is part of the address. --Skippern 18:55, 10 September 2009 (UTC)

And does that imply that because there's no "addr:" prefix then name=* can't become part of the address data? Is there an example where addr:housename=* and name=* have different values? --seav 13:17, 13 September 2009 (UTC)

It theory there can be a lot of examples of that, for example a named house, lets call it "House" can have a restaurant in it, called "Eat Out". In Brazil almost all apartment buildings, and commercial buildings have given names, and in many areas hold space for shops, restaurants, and much more on street level. This can as well be common in every country with named buildings. --Skippern 14:32, 13 September 2009 (UTC)

But I'll argue that its wrong to tag the whole building with name=Eat Out (which gives addr:housename=House) because the whole building is not the restaurant. My preferred way for that is to add an amenity=restaurant node inside the building way. This indicates that there is a restaurant inside the building even if the restaurant is the only public amenity inside the building. --seav 05:32, 14 September 2009 (UTC)

Recent edits to the page

The recent edits are an excellent example why proposals shouldn't be modified after they have been "approved" (in this case: stabilized). To sum up the events

• originally, the example for interpolation ways did not suggest to add addr:street to the interpolation way
• Gernot then added that tag to the example, hidden within a massive amount of edits
• one month later, people on the mailing list were pushing addr:street on addr:interpolation ways rather than house number nodes/areas, refering to the "original proposal"
• some people (I was among them) checked the history and noticed Gernot's modification to the example
• Joto then modified addr:street tags in the examples, which removed the addr:street from the addr:interpolation way, but also modified other examples; the edit was announced on the ML, but had no edit comment
• MarcusWolschon reverted Joto's edit, without an edit comment and without any discussion.

I suggest to revert the proposal page to this version, which was when the status was set to "approved". I'm aware that editing had been going on before that point, but massive modifications started only after that version. If you prefer to add street names to interpolation ways or whatever, please create another proposal or change current documentation after appropriate discussion. In my opinion, this is the only way to keep things transparent - directly editing pages like this just causes chaos. --Tordanik 13:45, 10 September 2009 (UTC)

I asked Joto about it on his talk-page but got no answer yet. Btw, what mailing-list are you talking about? We have dozens of them. --MarcusWolschon 08:03, 11 September 2009 (UTC)

talk, specifically this message and its replies. --Tordanik 16:58, 11 September 2009 (UTC)

The "addr:street" tag on the interpolation way was certainly not something envisaged by the Karlsruhe Schema team when we invented the whole thing. It does not make sense to me, and I have again removed it from the examples. I have indeed received complaints from people why the OSM inspector does not recognize that tag, and have heard from people who had actually tagged lots of addresses according to the original Karlsruhe Schema and then were told to move the address onto the interpolation ways because "it is on the Wiki". We want interpolation ways as a temporary construct to make mappers' lives easier, but once all houses are mapped individually, we want them to go away, and tagging vital information onto the ways does not make sense. OSM is a free and open project and anyone can tag what they want but if someone wants to invent their own address tagging schema then please make your own Wiki page for it and choose a different name. --Frederik Ramm 20:20, 13 September 2009 (UTC)

Indeed it makes sense to do it this way. But please next time have some kind of note on the talk-page or at least a more meaningful comment when changing pages describing established semantics. I'll use the talk-page next time instead of a message to the editor even if that means that he/she does not get the message. --MarcusWolschon 07:44, 14 September 2009 (UTC)

member roles of relation roadAccess

To be compatible with Relation:restriction we should change the member roles of the relation roadAccess.

• accessvia -> via
• accessto -> to
• accessfrom -> from

--Vsandre 18:05, 25 September 2009 (UTC)

One question: Why do we need to be compatible with a relation that will never be used in conjunction with this one as it does the complete opposite? --MarcusWolschon 06:03, 26 September 2009 (UTC)

Because a OSM-user will not learn a role name for each relation if the meaning is the same. At the moment (OSMdoc 2009-08-12) it stands 10978 to 33 for the restriction relation.--Vsandre 09:00, 26 September 2009 (UTC)

Good point. Do you want to formulate and announce a proposal? --MarcusWolschon 07:14, 27 September 2009 (UTC)

Do we need a 'real' proposal? Because it is not wide spreaded at the moment, I will only announce it at the mailing lists.--Vsandre 08:29, 27 September 2009 (UTC)

Yes we need one because several tools would need to be reprogrammed to userstand both your proposed and the current format. Including JOSM and at least 2 navigation-programs. --MarcusWolschon 10:53, 28 September 2009 (UTC)

Skipping house numbers in a way

In my city it is the rule more often than the exception to number houses skipping one, or possibly two numbers in the sequence, so that the even side of the street is numbered xx00, xx04, xx08, etc. and the odd side numbered xx01, xx05, xx09, etc. I see no way, under the current scheme to tag this situation other than as individual nodes. Sorry, way too much work. Therefore, I would like to propose the addition of an additional key addr:skip=*, or addr:interpolation:skip=* to define how many numbers should be skipped in the even, odd, or all sequence. I initially thought to use the tag increment, instead of skip, but that was too ambiguous. If you increment the even side by 4, do you increment to 00, 04, 08, ... or 00, 08, 12, .... The former is more intuitive, but it is also prone to strange errors. For example, what happens if the even side increment is 3? This would be interpreted as 00, 03, 06, 09 ..., not all even. Thus "skip" appears to be less error prone. Comments? --Turbodog 06:04, 7 October 2009 (UTC)

Very strange city. In how many other places does this happen? How big is "in my city"? --MarcusWolschon 08:10, 7 October 2009 (UTC)

"My city" is Fort Worth, Texas. The pop. is getting close to a million now. It happens in most suburbs of the city. --Turbodog 14:52, 7 October 2009 (UTC)

This usually happens when the housenumbers were given to the land when there were small houses planned, and now the houses built are bigger and each takes several pieces of land (and thus several housenumbers). It is pretty seldom that this is done in a so regular manner that you can tell a skip step. I recommend to use nodes, just like here: [7]

--Lulu-Ann 10:01, 7 October 2009 (UTC)

In the suburbs, i.e., out of the dense downtown area, this is the rule rather than an exception, even though the houses are new. I think the city must have established something like a 40 foot +/- interval for house numbers, and the developers use more like 60-90 foot lot width (newer homes have narrower lots). But, that's just a guess. Using nodes will probably more than triple the effort (six nodes vs a way) in most neighborhoods. I'll code a couple of blocks, and leave a link. I started to add some house numbers in my local neighborhood. I gave it up when I ran into the problem, and decided to post here before going further. I'll have to take another look at your link, Lulu-Ann, but when I took a quick look I saw a lot of ways. All of those ways would have to be broken down into nodes in my area. Surely Fort Worth isn't the only city with this problem. I'll have to check with friends and relatives in other Texas city suburbs. --Turbodog 15:02, 7 October 2009 (UTC)

Well, that wasn't TOO painful. I've mapped housenumbers to one street using Potlatch, to demonstrate the problem. See [8]. The north side of the street is mapped properly, using the current rules. The south side is mapped using my proposed rules. Of course, currently, a renderer would map twice as many addresses as are actually present on the south side of the street, since it would ignore the "addr:interpolation:skip=1" attribute.

It took eight entries vs. 21. There are 300 houses that this impacts in this one small neighborhood, and thousands of houses throughout the city that are similarly numbered. The difference in labor to number them using current limitations is very significant, actually to the point of not really being feasible. (I went back and deleted a bunch of stuff in and after the immediate previous post, because I was able to put the demonstration up faster than I thought.) --Turbodog 20:57, 7 October 2009 (UTC)

Just wanted to chime in on this subject and affirm that the skipping phenomenon Turbodog mentions is not at all uncommon in the U.S. In my city (Chicago) house numbers are assigned based on the street grid and have nothing at all to do with the presence or absence of any actual buildings. One block will typically span 100 numbers, whether there's 100 buildings, one, or none. I haven't done any serious address tagging yet, but if I did I would want a scheme which allowed me to say, for example, "The numbers on this side of the block are even, beginning with 1200 on the east and ending with 1298 on the west." Or maybe even create an interpolation way that spans many blocks, with a node wherever it intersects with a street that identifies the number of the street. Something like that would allow reasonably-accurate address information--it would get you to the right area of the block, at least--to be added very quickly. --BBMiller 16:32, 15 July 2011 (BST)

associatedStreet relation: several postcodes

What to do with a street with changing postcodes ? - need a child-relation associatedStreetPart ! --Skyper 12:30, 5 November 2009 (UTC)

Do you have different postcodes on both sides of the same way or can you simply split the way? --MarcusWolschon 13:46, 16 November 2009 (UTC)

Isn't the postcode set by the boundaries of the village? So an associatedStreet realtion should say nothing about the postcode. If you can split a way on a boundary, I would do it. Certainly if the numbers restart.--Sanderd17 22:15, 2 December 2010 (UTC)

No, the postcode is NOT set by the boundaries of the village. This is a global project. Skyscrapers sometimes have more than one postcode... --Lulu-Ann 10:11, 6 December 2010 (UTC)

Errors in examples on feature page?

It appears to me that (as of my signature date) the examples for relations are incorrect:

The example under "Associating a building polygon with a street" is identical to "Associating a node with a street" without the node definition.

The example for associating a series of housenumbers is actually the example for associating a building polygon with a street, and there is no example for associating a series of housenumbers with a street. -- --turbodog 16:25, 14 November 2009 (UTC)

Adress for buildings that are relations

Today I stepped over a building where I wanted to add name and adress that was a relation (i.e. an outter way and several inner ways). Should the adress be put on the outter way or the relation? According to the current documentation, addr-tags can only apply to points and ways. But probably the relation would be the more consistent way. Sample Building: http://www.openstreetmap.org/?lat=52.451942&lon=13.288967&zoom=18&layers=B000FTF --Hanno 17:56, 30 November 2009 (UTC)

number *or* name?

The page says addr:housenumber or addr:housename. But it's okay for houses to have both, right? This is fairly common. Ojw 17:08, 21 March 2010 (UTC)

p.s. housename doesn't seem to be rendering on mapnik. I only managed it by giving a name= tag to the building, which doesn't work if semidetached houses have a name each.

Yes, you can have both at the same time if the house does have a name. --MarcusWolschon 06:46, 22 March 2010 (UTC)

... and, imo, if the name is part of the address. If you would only put the housenumber, not the name, on a letter, then name=* is more appropriate. --Tordanik 11:12, 22 March 2010 (UTC)

I support Tordanik's view. Some buildings have names, and those would be best tagged with name=*. Only those places requiring 'names' for addressing letters/parcels would have addr:housename=* Many older homes in Australia have names, they are not used as part of the address. Warin61 (talk) 06:09, 18 March 2020 (UTC)

An experience

I've done some experiments with Karlsruhe schema and want to share them, to get comments.

One is to create an associatedStreet relation which covers several highways (they have the same name, but different oneway values) and thus have two street members: http://www.openstreetmap.org/browse/relation/1189514

The second one is to include addr:interpolation ways as house members of the relation (same relation).

The third one is to attach a multipolygon relation for a very wide pedestrian highway as the street member: http://www.openstreetmap.org/browse/relation/1189209

Please comment

Relation hierarchies (relations within relations) are hard to visualize, hard to edit and should therefore be avoided. Even plain associated street relations make editing harder for beginners with no real benefit. --Tordanik 16:21, 27 September 2010 (BST)

Housenumber at house door

It is also possible to map the side of the main entrance by using a extra node for the house number of the building. Ah, you don't understand what I mean? Example: [9] -- Derstefan 18:00, 9 April 2011 (BST)

That's generally used as the solution for mapping a building that has entrances with different house numbers. It's also possible to use that mapping style when there is only one house number for the entire building, but I don't really like it in that case, as it would leads to duplication if there are multiple entrances or POIs that would each need a copy of the address tags. By the way: Regardless of whether it carries address tags, an entrance should always be tagged as building=entrance. --Tordanik 18:14, 9 April 2011 (BST)

associatedStreet

streets can be split up in many ways. it's not clear what parts of a street i have to add to the relation. all ways of the street or only the one way that is the closest? --Flaimo 12:22, 25 April 2011 (BST)

I've wondered about this one myself. The proposal says one way per relation, and JOSM gives an error if there's more than one way with the street role. I think Relations/Proposed/Street is meant to replace the associatedStreet relation, which will support multiple street segments and associating other objects than just houses. -- Joshdoe 14:21, 25 April 2011 (BST)

Archiving of this page

Hello, as documentation should not life on the proposed features subpages I propose to move the content of this page to respective key or tag pages. See http://wiki.openstreetmap.org/wiki/Relation:associatedStreet as an example. Any objections? --Andi 00:55, 9 March 2013 (UTC)

I found another solution: I moved the page in the general namespace with the name Karlsruhe Schema and archived this proposal page. --Andi 18:02, 6 November 2013 (UTC)

conact:housenumber / Bremen Schema / extended Karlsruhe Schema

I recently started to discuss to introduce the tagging-scheme contact:housenumber as the extended Karlsruhe Schema. The Discussion is here Talk:Addresses#conact:housenumber_.2F_Bremen_Schema_.2F_extended_Karlsruhe_Schema. --Cracklinrain (talk) 00:48, 20 June 2013 (UTC)

Move to Karlsruhe Schema

What is the idea behind the move to a separate page, Karlsruhe Schema? There is already current documentation outside this proposal, e.g. at Key:addr, and this proposal is therefore no longer entirely current. If anything, its visibility should be reduced, not promoted with a regular page that makes it look like the current state of the art? --Tordanik 08:31, 7 November 2013 (UTC)

I agree and suggest to move it back to avoid broken links. --rayquaza (talk) 23:36, 2 January 2014 (UTC)

Can you show me where there are broken links? There should be links or redirects everywhere. --Andi 15:19, 5 February 2014 (UTC)

To the Idea of the move: Proposals are in my point no for documentation and shouldn't be translated. I thought we discussed this issue somewhere but couldn't find this discussion anymore. Basically there should be created a new english page about house numbers (not addresses). When this page is stable, the translations can be created on base of this new house number page. --Andi 15:19, 5 February 2014 (UTC)

Delete proposal

This page should be deleted, as a preparation to undo the move of its contents to Karlsruhe Schema. --Tordanik 21:16, 24 June 2014 (UTC)

I oppose deletion. Archiving should be sufficient. -- malenki 19:20, 25 June 2014 (UTC)

That's what I want to do. When you look at this page's history, you can see that this is not actually an archived version of the original, despite the template suggesting otherwise. I want to bring back the original with the full history to this page title (where it had been for years, including during the vote), and then archive it. But I can only do that if the fake archive page that currently occupies this page title is deleted. --Tordanik 20:47, 25 June 2014 (UTC)

Shouldn't this be moved to Approved features then? --Skippern (talk) 21:55, 25 June 2014 (UTC)

Approved features is now only a category, so there would be no change in the page title (unlike what was still commonplace a few years ago). But the restored page will of course be inserted into that category, I'm going to follow the guidelines for that. --Tordanik 08:27, 26 June 2014 (UTC)

In this case I agree with the deletion. --Jgpacker (talk) 11:18, 31 October 2014 (UTC)

I also agree. But be careful not to delete the talk page. --rayquaza (talk) 08:38, 1 November 2014 (UTC)

Thank you. As the author of this page has also agreed (privately), I'll proceed with the delete request. --Tordanik 12:03, 1 November 2014 (UTC)