OpenStreetMap
Adding buildings with RapiD - what to do with existing address nodes?
Posted by mvexel on 11 August 2022 in English.I’m adding missing building with RapiD in Irvine, California:
As you can see, there’s existing nodes tagged with building=yes and address info, imported at some point from city data it looks like:
When I add a building with RapiD, it adds the following tags:
I’m inclined to do the following:
- copy the tags from the node
- paste them on the new building way
- delete the node
question: is this the preferred way to go about this?
By the way, lots of buildings to add in this area, please help!
There’s also a couple of new MapRoulette challenges that deal with buildings tagged as nodes. They’re pretty big!
happy mapping!
Discussion
Comment from Minh Nguyen on 11 August 2022 at 23:50
Cool challenge! In both iD and RapiD, you can select the building area and node and use the Combine operation. (In RapiD, you have to accept the candidate building area first.) As long as the area is being added in your current changeset, the node becomes the area’s northwesternmost vertex, but the tags get transferred from the node to the area. This preserves the node’s history while keeping you from having to manually transfer any tags.
If you ever need to transfer tags without combining features, there’s a button above the table of raw tags that switches to a key=value textbox, similar to the Level0 syntax. You can copy-paste tags freely between features using this syntax. Alternatively, you can use the Copy operation to duplicate the original feature, then Combine it with the target feature.
Comment from mvexel on 12 August 2022 at 01:58
I didn’t know about the combine operation! That is super handy! I had used the textbox trick before, and in fact that was how I was copying the tags over. I like the MapRoulette challenge also as a way to locate areas where RapiD has a lot of buildings that can still be added!
Comment from CjMalone on 12 August 2022 at 08:00
I had been combining the 2, so copy/paste the node tags onto the building way. (JOSM has “Merge address point”)
But now I’ve started leaving them separate, so in this case, deleting the
building=yesfrom the node.I do this for 2 reasons: * So future mappers can more easily add the address to the entrance node. (Or turn the address node into an entrance node by connecting it to the building and adding ‘entrance=home’) *
building=yesin OSM are often multiple building and/or have multiple addresses.I can see the second is not going to be an big issue in America with the sprawl. And the first is micro mapping that I don’t partake in. So no strong opinion from me.
Comment from tordans on 12 August 2022 at 09:22
My take: In general, I prefer separate (and single purpose) address nodes. They are more flexible. But for residential buildings, that flexibility is not needed so merging them with the area is IMO a good idea as well. It is a bit annoying when both mapping styles are used in one area though, so I like when mappers stick to one pattern in one area :).
Comment from OldManCelli on 12 August 2022 at 11:35
Glad you like the challenge! I’ve been using the “c”ombine option from RapiD to merge the address into the building, but I only do it if I see that other buildings in the area are mapped that way. Other wise when there are multiple addresses on a building or if it looks like it is not residential then I leave the address node and just remove the ‘building=‘ tag after making sure that the building I created has the same building tag as the address node. I have noticed some address nodes are tagged with ‘building=house’
Comment from mvexel on 12 August 2022 at 14:07
Now the comments here about leaving the node and way separate makes me wonder if the challenge would need to be revised / reconsidered? Does it need to be more specific in saying that you can also leave the address node but just remove the
buildingtag from the address node?Comment from n76 on 12 August 2022 at 15:12
I prefer to merge the point and the building as I think it more closely follows the philosophy of “one object in the world is mapped as one object in OSM”.
I was unaware of the “combine” operation in iD and RapiD. But the “update geometry” operation in JOSM will do it too. In the case of JOSM, it uses the existing node as one of the nodes in the new area way (moving the tags to the area) which has the effect of keeping the edit history for the node.
For what it is worth, many of the address points in south Orange County were from an import I attempted. Originally it was going to be both addresses and buildings but I felt the building geometries available were not accurate enough so I switched to just addresses. Getting addresses in would at least allow navigation apps to find the destination.
https://wiki.openstreetmap.org/wiki/Orange_County_Building_and_Address_Import
Comment from mvexel on 12 August 2022 at 15:37
n76 - nice to see these two data sources come together then! I am learning new things too here: I didn’t know about the update geometry operation. I usually do Cmd-c and then Cmd-Shift-v (probably Shift instead of Cmd on Win / Linux) to copy and paste tags onto a different geometry.
Comment from n76 on 12 August 2022 at 16:22
The JOSM update geometry can also be used to replace one polygon with another. For example, if a building outline exists but is so incorrect that tracing a whole new outline is faster and easier, then you can trace a new outline, select the old and the new outlines and “replace geometry” to transfer the tags and history to the new. I am not sure, but I think it reuses the polygon points too if possible.
Regarding building outlines in Orange County, there seems to be a slow but active effort by Facebook paid mappers to add buildings. They seem to have OSM IDs with “VLD” for the first few letters for example VLD032 has been adding buildings in Dana Point.
Comment from tordans on 28 August 2022 at 04:27
Sorry for the late reply…; I wanted to go into a bit more detail on my thinking / decision tree. I don’t see any disagreement in this thread. But maybe this summary is helpful for someone:
In general, having the address on the house is a great thing IMO (good to review, map, query, audit). However, that only works for rural areas (AKA not cities), and mostly for residential buildings (AKA “one family houses”, not shopping centers, commercial buildings,
apartments).Outside of those parameters, one building shape will very often have multiple addresses without a way to separate the building properly (AKA no on the ground truth, no areal image that would help). In those situation, having a floating address inside but “above” the building (nearby the entrance, if possible) is most convenient IMO. It gives the address good visibility (in Editor and Viewer) and makes it OKish easy to query for addresses “inside” buildings.
On that note: The way our editors and tools are build right now, I prefer having the address nearby but not “on” the entrance. I can see why people map it this way, but right now it hides this important data too much, IMO. And it does not have any relevant advantage (AKA routers will be able to route to the “nearest entrance” just fine with a floating address placed nearby).
Another rule I try to follow is, to keep the mapping patterns in one region the same. AKA in Berlin, where we have floating addresses, I would not start adding a few to the building shape even if it where possible.
You screenshot clearly shows the residential building-case IMO, so I personally would merge them with the same (if its not too much additional work).
Comment from Minh Nguyen on 28 August 2022 at 07:02
I think a more general way of putting it is that sometimes an address applies to the entire building (every room on every floor) or even the entire property encompassing the building.1 In this case, tagging the building itself with address tags explicitly tells other mappers that the building is complete in OSM and there are no more addresses to add. It also makes it easier for data consumers to determine the extent of an address (similar to how a boundary provides information that a lone place node does not).
The prevalence of this case depends on the local addressing practices. In parts of the U.S. that I’m familiar with, it’s quite common for a retail or commercial building in an urban or suburban area to have just one street address (often but not always with individually numbered units within). Some postal codes in New York City consist of just one tall building with one street address. On the other hand, if a single building occupies an entire city block, the whole building may have as many as four overlapping street addresses, one for each bounding street. The addresses may be used interchangeably, or each address may be for a specific purpose (e.g., mail versus wayfinding versus taxation).
One way to account for both of these cases while preserving the benefits above is to draw an address area coincident with the building. This already happens sometimes due to 3D and indoor mapping. However, some data consumers (such as openstreetmap-carto) are currently unable to handle address areas unless tagged with another primary feature tag. So tagging the building itself would be a more compatible approach.
Either an addressed building or a coincident area would make it easier for geocoders to associate entrances with an address for routing purposes. By comparison, if a geocoder encounters an address node floating within a building, it can’t be sure that all the building’s entrances can reach the unit with that address, versus another address that may or may not have been mapped yet.
Authorities in the U.S. typically assign an address to an area, such as a plot or building, but a delivery point can refer to the mailbox or entrance in particular. ↩
Comment from andygol on 8 September 2022 at 10:46
I prefer to use JOSM + builtins_tools for this type of work (merge address point with building outline)
Here is a video with an example - https://youtu.be/8QJNjmn3o7I?t=1313 (the video is in Ukrainian 🇺🇦, you can turn on subtitle translation)