The approach you take with addr:housenumber=* and addr:street=* is the one that I believe is correct. Certainly, it seems to be the one that the geocoders I know of will recognize.
Wouldn’t be too surprised if things like addr:street:prefix were either an import or from an early tagging scheme.
Deleting addr:street:prefix=West, addr:street:name=Main and addr:street:type=Street would be up to your judgement. But I’d be sure to have addr:street=“West Main Street” tagged or it won’t be recognized by any data consumer you care about.
I still feel too new to OSM to do large-scale “fixing” like this, though seeing the tag distribution (had never seen that tool, thank you!) sure makes a convincing case that it’s not right.
Perhaps an intermediate step would be to add tags so we have addr:street that represents the logical concatenation of the three-way tags, so the tools can see them properly but we don’t throw anything away, leaving that cleanup for another day.
Is this the kind of thing that a discussion, or at least a note, in the wiki (in addr:street) is appropriate for?
Yes, that is the course I’d follow: Add addr:street=* per the wiki but leave the undocumented addr:street:prefix, addr:street:name and addr:street:type alone. You won’t be removing any valuable information that way and you will be allowing more data users to understand what is there.
Ok, this is really helpful, but now I’m curious about automation; it seems to me that if there is a clear pattern of the data, it ought to be possible to build software that does systemwide validation.
Something like: for every node that has addr:street:name but not addr:street, construct addr:street from addr:street:prefix + addr:street:name + addr:street:type.
There seems to be a strong set of opinions about automatic or bot edits in the community. Mostly against the use as there were apparently some issues in the past where things did not go well. Not saying you shouldn’t do it, just saying you should probably get buy in by the appropriate OSM community members. Not sure exactly who they are but no doubt somebody on the tagging mail list would know.
Warning: I’ve never seen consensus achieved on any item in the tagging mail list, so it may be difficult and/or frustrating to go though all that.
Oh, I’m not doing anything without following the guidelines for mechanical edits, including a discussion, building the proper wiki page, getting buy-in, etc.
I don’t know nearly enough to just do it, but I can do some technical research on the backend to see what’s involved on the programming side, do some readonly testing, which would give me data to bring to the discussion.
Many of these old imports need review and clean up. Should be easy enough to do a bulk edit merging the various street portions together so it looks more in line with what we’d expect.
I have created this validator rule to stitch the keys together and run it over a section of the import. It does a good job and I will apply it more broadly next week. There’s a bit of fiddling to do when someone has added address data that conflicts but that should be a small handful of cases I can deal with.
I have seen prefix, name and suffix a set of roads from a city GIS department so I would guess that it isn’t documented because it’s from someone assuming external conventions apply when they don’t. A poorly implemented import as suggested by others on the thread would fit this quite well.
For items with “addr:street” I removed all of the parted out import tags ex: “addr:street:suffix”
For items without “addr:street” I merged the import tags into an “addr:street” tag and removed them
Removed addr:full when there was a addr:housenumber and addr:street
Expanded common street abbreviations in “addr:street” (avoiding common errors like expanding E Street)
Moved addr:housenumber:unit to addr:unit
misc small issues noticed by the JOSM validator
There’s still cleanup to do for cases that have addr:full but are missing either addr:housenumber or addr:street but at least that’s a standard-ish tag.
