I want to open a discussion about a persistent data validation and semantic conflict in OpenStreetMap that affects millions of real-world addresses globally, particularly along highways.
The Problem
In many parts of the world, like Brazil, houses and businesses built along highways have official postal addresses determined directly by the highway’s route number (e.g., “Rodovia BR-101, Km 45” or “State Route 5, No. 120”).
When we map these, we run directly into a “catch-22” validation loop caused by two conflicting OSM standards:
The Address Rule:addr:street=* on a node/building is expected to match the name=* of a nearby highway=* line exactly so geocoders (like Nominatim) doesn’t flag a mismatch.
The Highway Name Rule: We are instructed not to put the classification/route number into the name=* tag if it already exists in the ref=* tag. Therefore, a highway with no proper name should only have ref=BR-101 and its name left blank.
The Conflict
If we keep the highway name blank and tag the house as addr:street=Rodovia BR-101, validators throw an “Address street name mismatch” error.
If we fill the highway name=Rodovia BR-101 to fix the address match, validators throw, and especially the community claims to be, a “Redundant ref in name” or “Description inside name” error.
This leaves mappers with a bad choice: maintain real-world address accuracy or format the highway geometry strictly to appease automated QA tools.
Questions:
Does your country face this same issue? How do your local communities handle addresses that rely entirely on a highway route number when the highway itself has no formal textual name?
Should we propose a new tag structure? Would a tag like addr:ref=* on the building (e.g., addr:ref=BR-101 paired with addr:milestone=45 or addr:housenumber=*) be a viable global solution?
Is this purely a tooling/data consumption limitation? Instead of changing tagging, should we update the global documentation and work with QA/Geocoding developers? For example, configuring Nominatim (and other tools) to automatically recognize that if addr:street contains the string of a nearby ref=* tag, it should be considered a valid match rather than an error?
I would like to hear your thoughts, regional experiences, and potential paths forward to solve this problem permanently.
Adding highway names to the alt_name tag (for example, alt_name=Rodovia BR-116) technically works, but it still triggers a validator warning because the main name=* tag is blank.
I think this specific scenario should be documented on the wiki. That way, mappers have clear guidance on how to handle it, and validator developers have an official reference to update their rules and prevent these false positives. Does a minor documentation update like this require a formal proposal and voting process?
Thanks for laying out this conflict so clearly. Yes, as noted in the GitHub discussion, we have a similar situation in the U.S. We actually don’t have a firm consensus on whether to repeat the route number in the roadway’s name=*. This debate has been going on for two decades and we seem no closer to resolving it.
We also deal with some complicating factors that may or may not exist in Brazil:
In many localities, the local addressing authority includes a cardinal direction in all street names. Streets named after routes are no exception. I think the community has been leaning towards naming the roadway in this case, to avoid dataloss, but there are some very committed holdouts. It doesn’t help that this approach results in inconsistencies between adjacent towns along the same route, as some localities use cardinal directions and others don’t.
Neither the way’s ref=* nor the route relation’s network=* specifies how to expand a route number like US:TX123 into a name as seen on street name signs or heard in conversation (“State Highway 123”). Each state and county has its own rules for how to expand a route number into a name. A single national route might have three different numeric names along its length. A geocoder or router needs to figure out how to do that translation by itself or consult Wikidata.
Even within a given jurisdiction, laypeople don’t necessarily use the official signposted name. “State Route 4” might be given as “Ohio 4”. The postal service accepts a variety of formats for the same route type. Users are accustomed to entering any of them and letting the computer correct it to the canonical format. Unfortunately, as it is, we don’t record the canonical format.
A given roadway may carry multiple concurrent routes but have a name based on only one of them. We don’t record which one.
Taking a step back, the reason we advise against tagging name=* is to avoid duplication. Redundancy creates opportunities for stale data, and it also causes unsophisticated data consumers to display or announce something more verbose than necessary, such as “BR-123 (BR-123)” or “State Highway 123 (TX 123)”. But maybe we could handle these complexities more robustly by tagging the name redundantly and expecting data consumers to deduplicate.