Addresses with addr:street:name and addr:street:type ?

I’ve been encoding my addresses as:

addr:housenumber = 123
addr:street = West Main Street

but I’ve seen some areas (Paso Robles, California, for instance) encode them as:

addr:housenumber = 123
addr:street:prefix = West
addr:street:name = Main
addr:street:type = Street

I understand the approach here, but:

  1. I don’t see documentation of this in the wiki, or anywhere else. I’ve looked around quite a bit

  2. JOSM’s validator doesn’t seem to know about the second form - it objects to an address with a housenumber but not a street

Is there a best practice here? Why am I seeing this second form?


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.

I guess my questions is: are the multi-part addresses correct, are they deprecated and ought to be “fixed”, or something else?

Looking at the distribution map at to see where things are that are tagged with addr:street shows it is world wide.

Looking at the same map for addr:street:prefix show very limited geographic distribution.

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.

I have a bot to research :slight_smile:

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.

I would take this up with the US-community on the maling list if I were you

Thank you: I’ve joined the list, will watch for a while to pick up the vibe before getting too chatty.

shouldn’t this be documented in the Wiki?

There are ~ 600.000 objects with addr:street:name but nothing in wiki …

Some history digging might reveal why

It’s remnants of an old address import that hasn’t been cleaned up. Ex: Way: 167141937 | OpenStreetMap

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.

1 Like

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.

I have completed a bulk edit of this area:

  • 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.

1 Like