Hello everyone,

I am getting into OSM mapping and have a question to the community concerning addresses. I know there is no standard for address mapping and several ways to do it (buildings, POIs or relations). I would like to have your take on my question:

I am currently mapping in the US, where many buildings already have addresses (partly from publicly available GIS data sets). This means that the building is a way mapped as building=yes and with various tags such as addr:street = F Street Northwest addr:housenumber = 2519 ...

Now if I add a POI to this building, for example a shop on the ground floor. Would you recommend adding the addr: information (that is already contained in the building information) to the shop's POI? Yes or no? Yes would mean that the shop's POI information is as complete as possible, but that the address information is contained in the map twice: once in the building, once in the POI. No* would mean that the shop's POI is in some regards incomplete, but it somehow seems cleaner to have no information repetition.

Cheers and Thanks

asked 18 Mar '16, 14:31

rabon's gravatar image

rabon
1914512
accept rate: 0%


We are dealing with a geographical database under the covers and all the data consumers should easily determine that a point (POI) within a polygon (building) shares the address of the polygon. So it is not necessary and many consider it potentially harmful as if something changes it is one more thing that needs to be maintained. The general philosophy is to enter something only once. And there are some QA tools that will definitely flag that as an error to be corrected, so don't be surprised if some remote mapper fixes that for you.

Another situation that comes up is a place with multiple buildings all sharing the same address. You can deal with that by drawing another polygon around the buildings and putting the address on that. No need for a relation here either, all the routing and mapping software deduce the buildings all have the address of the surrounding polygon.

permanent link

answered 18 Mar '16, 23:31

stf's gravatar image

stf
7.6k963120
accept rate: 19%

I agree with that as well as well as with the opposing point raised above by SK53 about ease-of-readibility. I realize that e.g. Osmose flags multiple addresses as erroneous entries. In the US, one building often hosts several addresses, which are then shown as their own nodes. That opens a third option, namely adding another node (a shop, for example) close to the address node, or adding the shop tags to the existing address node. I guess, for a good data reader this should make no difference, and I realize that there is no coherent practice for how to do this in OSM.

(29 Mar '16, 16:43) rabon
3

@rabon: One building often with several addresses can be elegantly tagged by tagging the entrances, as usually each entrance is assigned one address. If not, you can tag a range (addr:housenumber=33-37). Some mappers also create separate address nodes, but I would not consider that a good idea. Address information should be attached to some object that "has" that address (be it an area, a building, or an entrance).

(01 Apr '16, 10:57) sleske

@sleske: I think this is a great point. I am currently surveying and mapping in the Washington, DC, area. Most buildings, streets and addresses here come from public GIS data sets. Many of these tag the addresses in a single node on the building (which often comprises several addresses). I realy like the sound of your solution, and will consider it for future mapping. For now, the quasi-standard seems to be individual address nodes on buildings. Which, I agree with you, is not optimal.

(04 Apr '16, 04:13) rabon

I see no problem with adding the address information to the POI as well.

The very nature of tags in OSM mean that we do duplicate information all over the place so trying to avoid it for notions of a clean dataset is probably self defeating. People who do want this type of clean dataset already have to implement suitable data cleansing processes on OSM data; and this should be good practise for any one using OSM as a source.

Furthermore a clean implementation of addresses would treat them as first class objects and not as attributes, so any OSM approach to addresses will never satisfy the requirements of a truly elegant approach (here just one example of a different issue, multiple buildings all having the same address). However, rest assured we are not alone, almost every customer system in the world treats addresses as attributes.

Having to query buildings or parcels for associated address information does impose more complications for people consuming the information. So the duplication of data may assist people not interested in using the building data.

permanent link

answered 18 Mar '16, 15:19

SK53's gravatar image

SK53 ♦
22.4k46229350
accept rate: 20%

Thanks for your complete answer. I agree with you, it seems to make more sense to add as much information as possible rather than creating a beautiful dataset which then might fail if not read correctly. What is your take on using relations for this issue? Some (10% on average I have read in the osm wiki (?)) buildings use relations to connect information shared by POIs and the building or even several buildings such as the house number or the street. I presume adding a relation as a third way of storing address information (additionally to storing it in the POI and the building) is a possibility. But it also seems to be not too popular, partly because of relation's more complex nature compared to POI/building mapping. Would you agree? Cheers

(18 Mar '16, 16:02) rabon
4

I also see no problem in adding address information twice, just the contrary. But I would rather refrain from using relations. My main reason for both is that we heavily rely on random users contributing to OSM. For those it should be made as easy as possible to add or correct information. While there are enough "specialists" out there heavily getting every detail into the complex railway and public transport relations it's those simple elements as shops and amenities that are still far from completely mapped and where we need the not so data-objects-savvy users for.

(18 Mar '16, 16:23) TZorn
1

@TZorn yes, very good point which I should have made.

(18 Mar '16, 19:25) SK53 ♦
3

While I agree with the "keep it simple" approach, there is a problem with redundant address tagging: It becomes harder to tell wether an address really exists multiple times, or is only stored redundantly. E.g., if I search for "33, Xstreet", which is a building containing multiple shops, I should only get one hit. However, if there really are two buildings with this address, I want two hits. This can be solved with filtering, but it's tricky.

(01 Apr '16, 09:26) sleske
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×159
×158
×56
×55

question asked: 18 Mar '16, 14:31

question was seen: 4,382 times

last updated: 04 Apr '16, 04:13

powered by OSQA