Talk:Proposed features/House numbers/Karlsruhe Schema

From OpenStreetMap Wiki
Jump to: navigation, search


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)


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)


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 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 (talkcontribs) 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 Node 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 Nodes or Areas which are also tagged addr:housenumber=*. Currently only Way 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,9,11,13,15,16 Choose only odd numbers when enumerating ranges.


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 Node 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:3