Hi! I’m not very involved with OSM discussion in general, so apologies if this has already been discussed somewhere.
I primarily edit in the Los Angeles area, most recently casually chipping away at the many locations where houses are being replaced by apartments and townhouses. While observing the tagging of the imported buildings, I’ve noticed that the detached carports commonly found alongside mid-century apartment buildings have been imported as apartment buildings themselves. Interestingly, they have a building:units=* tag with the same value as the apartment building they belong to. They do, however, usually have their own (plausible) values for height=*,
I initially assumed this situation would eventually get sorted out with AI assistance, but today it occurred to me that a pretty good heuristic would be to find “apartment buildings” with building:units=* tags and having a height=* value less that four. Indeed, a quick random sampling of the results from this query found no false positives. Adding a check for an adjacent building with a matching building:units=* value and substantially greater height would probably give very reliable results.
I’m not prepared to make a semi-automated project of this myself, but I figured I would bring it up here for discussion, in case anyone else finds it an interesting itch to scratch. Cheers!
EDIT: After sifting through the query results some more, and finding a few cases of low height values on what appear to be residential buildings tagged as apartments, I changed the query to only match building:units=* values greater than four, which thinned things out a little, and seems like a reasonable threshold for an apartment having these types of carports. It still catches some odd cases like this one, though.
Nice to see another SoCal mapper on here, and thanks for bringing this up! I have also noticed inaccurate building tags on detached garages, both next to single-family houses and apartment buildings, originating from the LA buildings import, so I agree that this sort of cleanup is a good idea.
I think the issue you’ve noticed is a symptom of the broader issue that the import appears to have tagged building=* and building:units=* identically on every building on a parcel, even if the parcel contains multiple buildings. It’s sort of described in this issue on the import’s github, though it’s been left unresolved for many years.
Your heuristic is implicitly assuming that any real apartment building will be more than one story (i.e., height > 4), which I can believe is pretty good but not perfect. This might be a nice use case for MapRoulette, though I don’t personally know much about the details of how to set such a thing up.
PS I’ve noticed a few other issues with the import, although most of them amount to varying degrees of minor annoyance at worst. For posterity’s sake/to get it off my chest, I’ll list them here:
The import added office=yes to various buildings used for commercial purposes, which is already covered by building=retail/commercial. I’ve seen many on purely retail buildings. Exactly when was documented in the import, but I think it was a mistake, as this tag on a building without a business POI doesn’t add any further information IMO. It has the unfortunate side effect of rendering mysterious blue dots on random buildings in Carto.
The import added a couple of shop and other “POI” tags to imported buildings, like shop=department_store, but they added it identically to every building on the parcel, including tiny little side buildings like here: Way: 441468772 | OpenStreetMap
This isn’t documented, but I think they also tagged amenity=grave_yard on buildings occupied by mortuaries, like this one I recently fixed: Way: 440188656 | OpenStreetMap
The import used building:units=* instead of the more accepted synonym building:flats=*, making up 99% of the usage of this key.
Condominiums, which are essentially apartments where each unit is privately owned, were mistakenly imported as building=house + building:units=1, instead of building=apartments like they should’ve been. This was apparently a known issue during the import, but was never fixed.
If anyone has bright ideas on how to address these/wants to take on fixing any of them I would be very supportive! I haven’t found the bandwidth to address any of them systematically myself.
Thanks for the github link, I didn’t think to look around there… I probably should, to get a better sense of context for some of the import quirks.
It was more that I was explicitly assuming that even single-story apartments would have a value of at least four meters, but it looks like that was optimistic. I also found several carports with values greater than four (and a few lower than three) while doing more auditing of the results today, so… I guess height isn’t as strong of a discriminator as I initially thought. Given that, I’ve taken the approach of raising the units threshold to 10 (updated query link), which helps, but at the cost of missing some outliers. It’s probably a better starting point for any kind of organized editing, though.
My reason for posting about this particular import issue was that I found it to be both widespread and consistent enough to possibly be worth applying a semi-automated approach to. That may be true of others too, but this is the one that kept showing up on my radar. I don’t think I’ve encountered any buildings tagged as graveyards (yet), I’ll have to go look for some now.
Have you consistently found that to be the case with apartments tagged as houses? I do see those sometimes, but didn’t make the connection with condominiums.
Another area where things can kind of messy is with some newer styles of smaller townhouse structures replacing single homes (or being added as ADUs) in many places. I generally use the building=terrace tag for these.
I don’t think I’ve encountered any buildings tagged as graveyards (yet), I’ll have to go look for some now.
Here’s an overpass query for amenity=grave_yard + any building value: overpass turbo. I don’t think that tagging combination is valid in almost any circumstance, so these are almost certainly all errors. I think some should be mortuaries, while the ones actually inside cemeteries are a bit more complicated, depending on their exact purpose (it seems like tomb-tagging might be controversial! Who knew).
Have you consistently found that to be the case with apartments tagged as houses? I do see those sometimes, but didn’t make the connection with condominiums.
I don’t know whether it’s always the case, but I’ve definitely seen it often enough to notice. Like I said, the importers apparently noticed it too, and considered a solution involving finding when parcels overlapped in their source data, but they never followed through: A solution script to mistagged condos · Issue #97 · osmlab/labuildings · GitHub.
For a low accuracy filter, here’s an overpass query that looks for building=house + height values > 20 m: overpass turbo. Certainly that wouldn’t catch all of the mistagged condo buildings, but it picks up some that are clearly in that category, like Way: The Grand Condominiums (386446689) | OpenStreetMap. Amusingly, this query also appears to reveal a separate issue regarding unrealistically large height values for houses in very hilly areas.
Yep, I did the scan for building-graveyards right after my last post, and there really are quite a few. I saw a few in places I’m familiar with, fixing the rest will be an interesting ongoing side-project when I get sick of looking at carports. AFAICT from the wiki, there’s very little around here suited to the graveyard (as opposed to cemetery) tag, which makes its use seem even more odd.
I’ve wondered about the accuracy, and about the methods used to obtain the original data in general. I’m constantly amazed at how many tiny shed-sized “buildings” the county had a record of.
Just wanted to pop in and say thanks for taking a look through things like this. There’s a lot of work “finishing” old imports and I appreciate any one digging in to one.