Why does Nominatim derive an address from nearby ways for a building that already has explicit addr:* tags, and prefer a nearby highway=path over the street named in addr:street?
Searching osm.org for “6501 County Road 105, Lampasas, TX 76550” doesn’t return the building. Right-click > “Show address” at that spot gives “6501, Spicewood Canyon Trail, San Saba County, Texas, 76550, United States”.
The Nominatim details page shows address tags stored correctly, but the computed address has a nearby highway=path as the street, then San Saba County, Texas, 76550. Neither addr:street nor addr:city are taken into account in the computed address. The path replaces the street and the county replaces the city.
Two things that I noticed: The postal city (Lampasas) is in Lampasas County, while the building is in Burnet County (which is also different from the county in the incorrect computed address!). Additionally, this address is pretty far away from the actual road.
Is this a known quirk of Nominatim? My understanding is this completely breaks address search in many rural parts of the US. I’ve confirmed that the address is correct by cross-referencing with NAD.
That makes sense for the reverse geocoding (but in this case, it still fails, because it returns an administrative boundary that the requested object is not part of), but it is surprising to me that the normal geocoding request also doesn’t work.
Wonder if it’s because of the distance the building is from it’s road, with other things being much closer e.g. San Saba County is only 100m away, mid-river!
perhaps there should be a rule in nominatim to ignore everything else contrary to provided address fields in the tags.
A side note, a test area in nominatim would be helpful. I want to see how it gives address to a building block in a multi block housing project (among other things). Instead of opening n searching OSM, in a sandbox we draw simple polygons/landuse/house/road with necessary tags and stuff, then see what nominatim spits out.
if there is no issue for that at Issues · osm-search/Nominatim · GitHub it may make sense to report a bug, following instruction there (requires github account)
Is it correct that the address is Lampasas although its in Burnet County not in Lampasas County? Does the city of Lampasas span into Burnet County?
I think in most juristications a city only spans one parent admin boundary. So a city (Admin Level 8) is completely within a parent admin_level 6 and does not span multiple admin_level 6 or overlaps them.
Like in most other states, a Texas municipality is “in” a county but technically not a subdivision of it. Municipalities are orthogonal to counties, just another type of boundary along with school districts, water districts, and so on. A municipality may annex territory across a county line, because Texas hasn’t specifically banned the practice. (In states that have townships as actual county divisions, some townships may span county lines anyways, just to mess with mappers.)
By convention, maps depict municipalities as more local units than counties because they’re usually smaller in area, and their governments are subject to county governments for some purposes.
Lampasas doesn’t extend into Burnet County. However, this is only relevant to a description of the place, not an address. The county isn’t part of an address.
In a mailing address, what looks like a city is actually nothing more than the name of the post office that serves the delivery point (or a permitted alias). The USPS prefers to name a post office after the incorporated area it’s in, but a great number aren’t named after an administrative area of any sort. We put the name in addr:city=*regardless of its etymology, because that part of the address is called the “city name”.
Some localities have their own addressing systems for physical addresses that may not align with mailing addresses. Hypothetically, a Burnet County parcel database could assign the same parcel to something other than Lampasas as the city, such as “Unincorporated”. Whether this matters for addr:city=* would depend on whether the public uses the local addressing system for navigating or contacting in practice.
Nominatim’s QA tool flags this house as a “Suspicious addr:street tag” because County Road 105 is 3¼ miles away as the crow flies (5.3 km),[1] but Spicewood Canyon Trail is only 1½ miles away (2.4 km). As far as I can tell, Nominatim does consider highway=path when looking for nearby “streets”. I’ve run into a similar issue in the past when a school or shopping center gives their parking lot aisles vanity names.
Nominatim’s database structure models a rigid single spatial hierarchy of places that doesn’t work very well overall in the U.S., where multiple parallel systems and nonspatial systems are the norm. There’s an item on the roadmap for rearchitecting Nominatim to understand addresses as first-class entities with their own attributes. Hopefully this will include the ability to assign address components independently of spatial characteristics.
That’s the problem here, and the only problem. Nominatim has an optimisation that it reuses addresses from the street object for anything with addr:street, assuming that a street-level address refers to a street nearby, thus it’s address being good enough for the addresses along it. If the address is as far off as this example, Nominatim can’t make the connection because the search radius for the street is limited (and not worth extending for a corner case like this).
You might be better off using addr:place=County Road 105 in a case like this (basically indicating that the address is more or less free-standing and not really street-based).
Or just leave as is and ignore Nominatim’s quirks. Other geocoders will pick it up. Photon certainly will.
The other addr:* tags are taken into account for search in Nominatim, although they may not always be displayed. The location description trumps here. (There is an open ticket for that but it doesn’t look to be important enough that anybody every felt the need to pick it up.)
Not really. The US is as spatial as any other place on earth. It just has a tiny spelling problem but that’s unrelated to this issue.
Unfortunately, we don’t useaddr:place=* in the U.S., so its appearance on a far-flung feature would be quite surprising. “County Road 105” is a road name, and it properly belongs in the street portion of the address.
Not even close. We know of 2,677 longer driveways in the U.S., the longest being almost ten times as long. Most of them are in rural parts of Nebraska, Oklahoma, Virginia, and Texas, but there are even some in urban areas like Westchester County, New York. This doesn’t count interruptions from bridges/culverts/fords, the many driveways that we haven’t reclassified as highway=serviceservice=driveway, or the untold number of TIGER-imported driveways that we deleted back in the day, thinking we’d never need that kind of detail. So the distribution probably says more about where we’ve cleaned up TIGER deserts.
Naming the driveways after the street would likely cause routers to produce misleading guidance instructions. This driveway isn’t even at the end of the street, so a driver would get a misleading fork instruction.
In rural areas, setbacks and driveway lengths can be very arbitrary. If not for explicit address points or address attributes, a data consumer would need a routing graph to reliably associate addresses with roads via driveways, assuming a driveway even leads directly to the property. Long ago, I saw a project that generated a Voronoi graph of addr:street=* values to use in geocoding. It gave me hope that we could depend on the address tags without needing to expand a search radius by an unreasonable distance.
Along those lines, I wonder if, as another workaround, we could figure out the extent of the property this house sits on, then map it as a place=plot with an address on it. An entrance node could compensate for the plot having a less specific routable point than the house would. It’s just unclear to me whether the other fenced-in areas between the house and the county road are all part of the same parcel.
Unfortunately, I don’t think that’s a workable solution either. About a dozen different parcels can only be accessed from County Road 105 by going through 3975 CR 105. The property in question, 6501 CR 105, is the worst of them, accessible only through a series of six intermediate parcels, each one fenced off.
These situations are common all over, in both rural and urban settings. You’ve previously conceded that entrance=plot would require us to fabricate entrances where they don’t exist in reality. Too often it would mislead users on the ground who see only one entrance.
We’ve already mapped the address, on the house. The problem is just that its location surprises geocoders because of distance. If we really need to affirm that the addr:street=* is really what we say it is, we could tag the driveway with the associated street name, but we definitely shouldn’t put it in name=* like Apple Maps erroneously has it. street:name=* is already taken and I’m not sure we’d want to extend it for this purpose. After all, somewhere out there is a long driveway that has its own sidewalks. Copy addr:street=* onto the driveway? That would work here but not in analogous urban situations where a single street or driveway serves multiple addresses assigned to different streets.
Another thing we could map is the mailbox as a freestanding amenity=letter_box node. According to the USPS ZIP Code Lookup tool, this area gets mail delivery (which isn’t a given in rural areas), so each property will have a mailbox at the foot of the driveway along CR 105, with the number posted on it. The mailbox would be tagged post:housenumber=* and post:street=*. I can’t see the mailbox in aerial imagery, so we would have to guess its location. Maybe in such a rural setting, no one’s going to fret about whether we got it on the wrong side of the driveway or the wrong side of the street. (Mailboxes are often located opposite from the driveway.)
Some E911 datasets standardize on putting addresses at mailbox locations, so this is something that would be valid elsewhere. I’m just not sure if it would make things any easier for a geocoder. Could it detect that a post:housenumber=* along the street doesn’t correspond to an addr:housenumber=* nearby and expand the search radius, without having to do that always? Or maybe it would just give up and return the post:housenumber=* location as is, leaving it up to the user to find the other end of the driveway?
It may not be “right” but I have mapped similar situations with an address node where the driveway meets the street, the address on the house itself, & in some cases, with the street number also on the “driveway” (access track in this case!) as name e.g. 674 nowra road | OpenStreetMap & Way: 280 (531586474) | OpenStreetMap
Is it the proper & correct way of doing it? Possibly not, but I work on the concept that it will show where you have to turn off the road, which track to follow, & where the actual house is, which I think is the main thing!
This might have the effect of producing more explicit guidance instructions in routing, but a geocoder won’t interpret a roadway’s name=* as a house number. It still wouldn’t find 6501 CR 105 since addr:housenumber=105 occurs too far from name=County Road 105. An end user will get No Results, so any guidance instructions would be moot anyways.
On top of that, this shared driveway serves at least seven different properties. The parcel layer is inconclusive as to whether they all have different house numbers. Assuming they do, I don’t think tagging all of them on the driveway would make things much less confusing.
Anyways, a stranger wouldn’t be able to visit the house even with all the time in the world. There are multiple gates in the way. This is also a part of the country where one kind of expects a bevy of signs saying “Posted: No Trespassing (Violators Will Be Shot)”. So a amenity=letter_box node along the street would be more relevant than the house. Maybe Nominatim would be open to indexing those nodes (conflating some with addresses it can index already)?
The property in question seems to have a gate right next to the country road in question: Node: 12399047374 | OpenStreetMap This would probably a better place to repeat the address than on an address plot.
However, this all feels like tagging for the geocoder. The current tagging is 100% correct. It is just a quirk of Nominatim that it requires a street with the same name to exist close by. It could relax that requirement. It is already doing so for addr:place. I’ve just been reluctant to do the same for addr:street because 99% of the mismatches are indeed tagging errors.
There is another possible solution to this problem: associatedStreet relations. As much as they are a pain to process, this might be a situation where their existence and use is actually justified.
I don’t think the additional address point near the road is necessary. The driveway to use is unambigious from the map data. The router can solve the problem without further special tagging.
But if you like to mark the additional info, then ideally you give the node near the road additional tags to make clear it is not the main destination for the address. My suggestion would be to move the address point onto the drive way and then, add barrier=gate when applicable, or some variant of entrance=* (but not entrance=main, which I would reserve for the final destination on the house).
We know of 
