@tekim Thank you for pointing this out. We are thinking of not using “Approach 2” since we are not very confident of keeping “relation” accurate using code. We got a similar feedback from others. We will use “Approach 1” since this does not delete anything
1 Like
I’d suggest that you skip all roads that are tagged with tiger:reviewed=no because there’s a good chance that these roads are not in the right place.
Having dealt with the consequences of zealous mappers putting ford=yes on every intersection of a TIGER road and an NHD waterway, I can attest that the original alignment in the source data sets was often poor. And this resulted in a lot of misplaced or imaginary fords.
There’s no sense in putting in a bridge in the wrong place because undoing that gets more complicated.
Also, the Bridge and Truck Restrictions Import page does not link to any actual processed data. I see the link to the Github source, but it would be good to see some sample results so that it’s clear that the processing actually works as expected.
1 Like
I’m familiar with this problem, having fixed many roads that still ran along former river crossings but in reality got bypassed many years ago, including in Kentucky. Unfortunately, tiger:reviewed=no is not a reliable indicator of whether or not a TIGER-imported road has been reviewed. All it means is that it was originally imported from TIGER. In some cases, mappers have updated this tag as they clean up the data, but there’s no meaning to this tag that generalizes to a whole state, let alone a whole country. I routinely encounter roads without tiger:reviewed=* or even with tiger:reviewed=yes that are in worse shape than those with tiger:reviewed=no.
I don’t think this proposed import is comparable to the phenomenon you’re describing. There’s little question that a bridge exists along the road near a given point. Is the concern that NBI or the state DOT has a reasonably accurate location for the bridge, but that we’re tossing it away by snapping to the TIGER-imported road? If so, would establishing a maximum snapping distance alleviate this concern?
1 Like
True. You know how bad TIGER roads can be.
I don’t know if NBI or the state DOT coordinates are reasonably accurate. I guess that’s a hypothesis that the proposed import still needs to test. But we do know that there are a lot of TIGER roads that aren’t in the right place.
Establishing a maximum snapping distance between the bridge coordinates and the road in OSM could be a good check.
I guess the import also needs to consider some edge cases:
- Roads that have intersections within the apparent span of the bridge
- Roads that are split into separate ways within the apparent span of the bridge
- Multiple roads that are adjacent to the apparent span of the bridge and where the placement of the bridge might be ambiguous.
It also wasn’t clear to me from looking at the JOSM scripts whether the processing would be able to make its changes without breaking any parent relations.
2 Likes
@Kai_Johnson @Minh_Nguyen We have been busy integrating, testing, and making sense of the data. Now we are at a stage where we know most of the missing bridges in certain areas 
First of all let me address some of your earlier comments:
I’d suggest that you skip all roads that are tagged with tiger:reviewed=no because there’s a good chance that these roads are not in the right place.
Having dealt with the consequences of zealous mappers putting ford=yes on every intersection of a TIGER road and an NHD waterway, I can attest that the original alignment in the source data sets was often poor. And this resulted in a lot of misplaced or imaginary fords.
There’s no sense in putting in a bridge in the wrong place because undoing that gets more complicated.
It is like this: the basis of the bridge is NBI data. We are not automatically adding bridges assuming there should be a bridge over the water body. We are also getting bridge span width.
Also, let me address your other concerns:
Accuracy of NBI and State DOT Coordinates:
We see that the coordinates from NBI and state DOT are not the most accurate. However, we have implemented an additional method where we calculate bridge points using a formula that converts coordinates from a specific fixed-point format into decimal degrees. To know more, please scroll to the DATA LINEAGE SUMMARY section to see the formula that yields more accurate geo coordinates. This method has yielded more accurate bridge locations and effectively eliminated duplicate bridge points.
Establishing a Maximum Snapping Distance:
Yes, we agree that establishing a maximum snapping distance is crucial. We are using a 30-meter buffer along the water bodies data from National (NHD) to ensure that the bridges are accurately placed in their actual locations.
As we dived deeper into finding a correspondence between the missing bridge locations in OSM and bridges in NBI databases, we saw several edge cases. Here is how we are addressing those edge cases.
Addressing Edge Cases:
- Intersections within the bridge span: This issue typically occurs at freeway interchanges. Most of these locations already have bridges marked in OSM. For any unmarked locations, we use the layer tag in OSM to identify and manually handle these bridges.
- Roads split into separate ways within the span of the bridge: We are aware of this situation and are currently working on a solution. We will provide an update once we have a finalized approach.
- Multiple adjacent roads near the bridge: We have encountered this issue as well. To address it, we use the intersection between water bodies and OSM ways, along with the distance between the given NBI bridge point and the nearest way, to determine the correct bridge location on the appropriate OSM way.
Regarding the concern about the JOSM scripts and parent relations, we are ensuring that the processing does not disrupt any existing parent relations. Our team is testing edge cases to maintain the integrity of the data.
I think one of the challenges I see here is that you need to trust my statements. That doesn’t have to be the case. We are currently working on making whole of the data, all intermediate data files, and final data available for anyone to test, reproduce the steps, and comment. We should have that available in a few days and at that time you can test the data and make a better judgement.
Hmm. The current NHD data sets are great if you want to analyze the connectedness of various water features. They’re not so great if you want to know exactly where the waterways are. I’m sure I’ve seen cases where the NHD flowlines are off by tens of meters.
Comparing TIGER roads to NHD waterways is sort of the worst case of imprecise data being compared to imprecise data.
1 Like
@Kai_Johnson Maybe you are right. We will make the data available to you before uploading and point to us a location (where there are issues with TIGER roads and NHD waterways) where you see any issues. Or point to us some areas in Kentucky and we can make those available to you right away.
@Kai_Johnson Here are the steps to reproduce our method. You can see input data here. You can see all the output files here. If you are only interested in the final files, you can see final associations among NBI bridges and OSM ways here. Looking forward to your feedback
Hello @Maneesh-Mahlawat
Over the last day I have been taking a look at 01-Kentucky-OSM-Bridge-Association-Final.csv So far I have the following comments.
Some of the “bridges” in this file are actually culverts, e.g.:
Some others are “box culverts” 0. Note the vegetation between the edge of the pavement and the lip of the culvert.
There are bridges in the dataset that have the same, or nearly the same, coordinates as other bridges in the dataset:
In some cases the bridge already exists:
(The algorithm may have gotten confused because the bridge crosses water and a road)
In some cases the bridge point is quite far away from the actual bridge. In the example below, the bridge point is about 66 meters from the actual place where the road crosses the waterway. Also, this crossing has already been mapped correctly as a culvert as shown in the second screenshot.
Here is another case where the waterway-road crossing has already been mapped as a culvert:
Another example of the crossing having already been mapped as a culvert:
Another example already mapped as a culvert:
2 Likes
@tekim This is super helpful. We will look at these right away and see what we need to do here. Also, by definition, we don’t need to add any bridges less than 20 feet in span since they are culverts. Is that what you mean by pointing out culverts? What if those are covered in NBI database?
I am glad we are able to share all this before making any change to OSM. We will make the algorithm work before making any changes to OSM
@Maneesh-Mahlawat thanks for your quick reply.
I don’t think you can use Bridge_Length to definitively say whether something is a culvert or a bridge.
This is an example where Bridge_Length > 20 feet (6.4 meters ~= 21 feet), yet it is clearly a culvert based on available imagery.
This is another example where Bridge_Length > 20 feet, yet the satellite imagery suggests it is a culvert.
I mean that these are things that, based on the satellite imagery, are clearly culverts, yet they have been included in the file 01-Kentucky-OSM-Bridge-Association-Final.csv. If you add a bridge to OSM at the location indicated it will be incorrect. If a culvert doesn’t already exist in the OSM data at the location, it could be added.
You will have to find some way of filtering them out. NBI seems to include culverts as well as bridges.
2 Likes
As I’ve been remapping bridges as areas around me, I’ve noticed that Caltrans similarly tends to make little distinction between bridges and culverts in its bridge dataset. Fortunately, if memory serves, it is possible to filter out culverts from that dataset by looking for a vertical clearance of 0 feet or something like that. They also prefer to represent a state-maintained underpass instead of the bridge that goes over it, which means I need to pay closer attention to what I tag the name on. This exercise has somewhat broadened my conception of what counts as a bridge. I now end up remapping very narrow bridges at what I once thought were culverts.
2 Likes
I have worked on a bridge import before. I work for a state DOT in the GIS office and I’m quite familiar with NBI and all the intricacies of bridge GIS.
One particular thing regarding a bridge vs a culvert is that there is no formal delineation between the two in OSM. In Maryland, any culvert with a diameter greater than 48” is inventoried and inspected as a bridge.
From a practical purpose, where I draw the line is if there is a weight restriction on the roadway, I’d draw that as a bridge no matter how small it is. Because you can’t add a maxweight to a culvert.
2 Likes
Whether or not this matches the OSM concept of a “culvert,” NBI has its own definition:
Culvert. A structure designed hydraulically to take advantage of
submergence to increase hydraulic capacity. Culverts, as
distinguished from bridges, are usually covered with embankment and
are composed of structural material around the entire perimeter,
although some are supported on spread footings with the streambed
serving as the bottom of the culvert. Culverts may qualify to be
considered “bridge” length.
The reference to “bridge” length is that NBI considers a “bridge” to have a span of more than 20 feet (or 6.1 meters). And indeed, there don’t seem to be any records in NBI that have a Structure Length of less than 6.1 meters.
NBI’s “culverts” are identified with a Structure Type of 19. But this doesn’t necessarily align with tunnel=culvert in OSM.
I like @ElliottPlack’s distinction that culverts have no weight restriction. But it looks like even long bridges might not be posted with weight restrictions if the bridge’s operating rating is greater than the state’s legal load limit (which, for comparison, is 36.3 metric tons in California).
1 Like
I generally agree with this definition, although I am not sure what they mean by ‘may qualify to be considered “bridge” length’ - does that mean that large culverts are bridges in the eyes of the NBI?
Not withstanding the length part, the examples I have found are definitely culverts by the above definition. For example, you can tell from the imagery that they are “covered with embankment.”
Be that as it may, many of these “culverts” in the proposed imports have already been mapped as culverts in OSM. I don’t think we want a particular waterway-road crossing to be mapped as both a bridge and a culvert, and I don’t think an import should second guess what has been mapped by hand by a local mapper.
There is also the issue where the proposed import has multiple bridges in the same location, or within a meter or two of each other.
I don’t see why one could not have a maxweight=* tag on a section of road without bridge=yes. I have seen roads in reality that are signed as to maximum allowed weight (usually thinly paved residential streets).
3 Likes
In principle, I’d agree, but I’m finding that so many bridges are incorrectly mapped as culverts and vice versa. Some of that is because of mappers carelessly silencing validator warnings, but I think a lot of it is because mappers have made the same assumptions I used to make: that a bridge is guaranteed to be longer than it is wide, or paved from side to side, or that it must involve a change in pavement quality. I can find many counterexamples for all three assumptions.
On the other hand, Caltrans considers the Pacheco Pass Highway to cross O’Connell’s Spring on a concrete arch bridge with a deck 0 meters wide, but in reality it’s one of a series of massive fills across gorges. The creeks have been channeled through what NHD classifies as pipelines.
I don’t know if my examples are representative of the proposed import at all, but at this point I’m willing to approach this problem with more flexibility than in the past. At least if a culvert has been mapped but the dataset clearly disagrees, we could kick it over to MapRoulette or similar for manual review. It may need fixing up in other ways besides.
2 Likes
I think what NBI is saying is that “bridges” are at least 6.1 m in length and a culvert that with a span of at least 6.1 m is a “bridge.”
Compare the NBI definition of “culvert” to their definition of “bridge”:
Bridge. The National Bridge Inspection Standards published in the
Code of Federal Regulations (23 CFR 650.3) give the following
definition:A structure including supports erected over a depression or an
obstruction, such as water, highway, or railway, and having a track
or passageway for carrying traffic or other moving loads, and
having an opening measured along the center of the roadway of more
than 20 feet* between undercopings of abutments or spring lines of
arches, or extreme ends of openings for multiple boxes; it may also
include multiple pipes, where the clear distance between openings
is less than half of the smaller contiguous opening.
* (6.1 meters)
If you put that in context of the NBI data set, all the “bridges” and “culverts” they collect data on have a span of at least 6.1 meters. Apparently, if bridge or culvert has a shorter span, it’s not a “bridge” as NBI defines it and it doesn’t make it into the data set. But culverts can be big enough to be “bridges.” That’s what “Culverts may qualify to be considered ‘bridge’ length” means.
Not that these definitions necessarily apply to OSM, but it’s useful to consider them if we’re looking at the NBI data set.
Conversely, the NBI data set implies that many bridges do not have a signed maxweight because they can carry at least as much load as the rest of the road.
1 Like
I also would not be opposed to this practice… however, careless mappers are keen to merge/split/combine sections of similarly tagged roadway without regard for the detailed tags. Certain rideshare, navigation, and delivery companies are constantly chopping up roads for mapping lane changes and such. ID doesn’t do much to notify the user that extending a restrictive segment may cause unintended consequences. The bridge tag however does provide a strong visual cue that is easy for anyone to see in any editor. It takes a special kind of disregard for others’ work to merge a bridge into the surrounding roadway.
If these issues could be avoided, then I also think we could tag the NBI bridge_refs on the section of roadway above the culvert.
1 Like
I was considering the distinction of bridges and culverts due to encountering a culvert mapped as a bridge recently. I updated the OSM Wiki page on culverts with the following (the length element being struck by subsequent editor):
Bridges will have deep foundation,
typically will span more than 30 meters, and have a distinguishable superstructure (deck, girders) and substructure (abutments, pier, pile cap). Conversely culverts are buried structures and rely on the combination of internal capacity and the surrounding soil to carry vertical load.
Some further research seems to suggest that the distinction between a large culvert and a bridge becomes technical and that not all definitions are the same - for example, there is overlap but not complete agreement on the definitions in the context of highways vs. railways. Things get more grey when you compare a concrete slab bridge and a box culvert.
I did find this image from NYSDOT interesting to help draw distinction:
1 Like
This is a helpful diagram. At least it narrows the gray area a bit, for those of us lucky enough to have access to oblique imagery, street-level imagery, or a field survey for a given spot. If we do choose to tag a culvert at a spot where NBI or some other source might consider there to be a bridge, we could at least tag the roadway with something like overpass=yes. That tag hasn’t ever been used before, but some mappers already tag underpass=yes on roadway undercrossings, for example because the underpass has a name and number but the bridge does not.
1 Like