Adding bridge information in Kentucky and other states

I am documenting these as I find them…

37.7400127, -87.9226047 (import location)
37.743053, -87.922775 (NBI location)
Structure Number: 113B00002N
image

In this case the import preparation process moved the bridge location by 338 meters!

This is the NBI location (circled in green) on top of the USGS topo:


One can see the bridge carries KY-130 and intersects Lost Creek, both of which are consistent with the data in the NBI and the import file.

This is the NBI location (circled in green) overlaid on top of Bing aerial imagery. There is clearly a bridge and waterway here:

This is the location (circled in green) from the proposed import. Although it is on KY-130, it doesn’t appear to intersect any waterway.

This is the location from the proposed import laid over Bing aerial imagery. There is no evidence of either a bridge or a waterway here:

3 Likes

37.816387, -87.55972 (NBI location)
37.8174368, -87.5595576 (import location)
Structure number: 051C00087N

image

In this case the import process moved an NBI bridge point 117 meters from a location where there is clearly a bridge to one where there clearly isn’t.

This screenshot shows the NBI location (green circle) and the import location (red circle) on top of Bing aerial imagery:

=====================

37.803055, -87.69361 (NBI location)
37.8036203, -87.6937248 (import location)
Structure number: 051C00068N
image

This is another case where the import preparation process moved an NBI bridge from a location where imagery shows a bridge, to a location where imagery shows no bridge. The bridge was moved 63 meters.

This screenshot shows the NBI location (green circle) and the import location (red circle) on top of Esri World Imagery (Clarity) Beta imagery.

The USGS topo shows that the NBI location (green circle) is near Pond Creek, which the NBI says the bridge intersects.

==========================

36.63361, -85.8125 (NBI location)
36.6338458, -85.8117819 (import location)
Structure number: 086C00011N

This screenshot shows the NBI bridge (circled in green) and the location of the proposed import (circled in red) overlaid on Bing aerial imagery. The import preparation process has moved the bridge 63 meters from a location where there is a bridge, to one where there isn’t.

1 Like

Hi @tekim ,

My name is Nitin, and I’m a member of the team working on this project alongside @Maneesh-Mahlawat . Although this is my first time posting, I’ve been closely following the message thread here and appreciate all the insights shared by the community.

Thank you for your valuable feedback regarding the discrepancies in bridge locations within the import data. We’ve carefully reviewed the issues you highlighted and have successfully corrected all the cases in the latest output: merged-approaches-association-output.csv

Let’s look at the issues raised for the mentioned bridges.

As seen in the image below, the bridge location for structure number 049C00158N from import data (green) is now placed near the NBI bridge location (orange).

Similarly, structure number 113B00002N, which was previously placed 338 meters away from the actual bridge location, has now been correctly positioned at the accurate location.

Hi @nitin-khandagale That is a good start, but please understand that my review of the proposed import was not exhaustive, it was only a sampling. You should do more than just correct the specific issues I found (there are many more that I didn’t have time to investigate, plus likely more that I didn’t find as I only looked at a few cases). You should review and revamp your process so that errors such as these do not happen.

Hey @tekim,

Thank you for your feedback. I want to clarify that our team’s corrections were not solely focused on the specific cases identified. We conducted a comprehensive distance-based analysis to ensure the accuracy of our import data.

In this analysis, we compared the distances between the NBI points and our imported data points and identified around 50 bridges with significant discrepancies. As a result of this analysis, we noticed that the cases you raised were among those that showed notable differences. Upon further examination, we found that in some instances, the NBI location was more accurate, while in others, the location derived from milepoint information proved to be more precise.

Based on this analysis, we believe that solely relying on NBI locations might not be sufficient. Incorporating milepoint and hydrography information alongside NBI data has proven to provide a more accurate result. To address these discrepancies, we have implemented an additional layer of checks based on distance thresholds and corrected the cases where necessary.

We believe this approach enhances the overall accuracy of the data and ensures that such errors are minimized moving forward.

We’ve noticed that in some cases, the NBI location does not match the exact bridge location. In these instances, using milepoint information from state road and bridge data has helped us place the bridge more accurately.

Let’s take a look at an example where the import data location is accurate, but the NBI location is not. As shown in the image below, the bridge location from NBI for structure number 078B00085N, (marked in orange) is significantly distant from the actual bridge site, which is quite unusual, while the import data shows the bridge point (green) at the correct location.

Looking closely at the import location, we can see that the bridge there is 40 feet long, which matches the bridge length provided by NBI.

Glad to see others are working on this!

Although my interest primarily lies in mapping by-hand, rather than automated imports (for all the reasons given above and then some), I have thought quite a lot about bridges and how they can work in OSM, and limitations of current approaches.

One idea I had which I’m about to begin implementing is new ref:US:NBI:* tags which can be used to uniquely identify and source data for a given bridge from the NBI database. I would be interested in receiving additional feedback.

I agree. Although the review process can be quite tedious:

  1. distinguishing a culvert from a bridge - I use the CULVERT_CONDITION field as a guide if I have nothing better
  2. aerial imagery is poor quality (Bing)
  3. aerial imagery shows a different structure than recorded in NBI, e.g. a rebuilt or washed out bridge, or active construction site
  4. NBI bridge coordinates may be very inaccurate e.g. downtown Lanesville, IN
  5. relevant highway(s)/waterway(s) don’t yet exist in OSM or are (un/mis)named

In most cases, there is no problem - the most common issue is inaccurate coordinates - but there are a lot of special edge cases where one needs to have all these things in mind and be an experienced mapper. Sometimes that means digging deeper into source data, comparing imagery, even making no change until better data or ground survey is possible.

I should add that another benefit of manual review is that frequently one can find non-NBI bridges in the vicinity, and have the opportunity to map them as well.

My review process has morphed into something like this. I use an NBI layer (like this), find the best aerial imagery available with compatible license (e.g. IndianaMap, KyFromAbove) and if necessary more recent imagery, use an NDH overlay because waterways are often unnamed or missing from OSM. Before uploading, I take care of the intersecting ways which is where I find my bridges.

It likely goes without saying, but as we talk about bridges and culverts, please don’t forget to use the proper layer=* tag and value: often or usually layer=1 (or a higher positive value if other structures / layers / levels exist, though be careful with distinctions between layer and level denotations, especially in underground train stations) for a bridge and often or usually layer=-1 (or a higher negative value if other structures / layers / levels exist, ditto) for a culvert.

Thank you @rhythmicbalancer @stevea for sharing your detailed review process, and I completely understand the concerns you raised. We acknowledge that distinguishing certain structures, like culverts from bridges, and handling inaccurate data, especially with aerial imagery or NBI coordinates, can be challenging.

In our approach, we’ve been distinguishing culverts and bridges using both NBI and OSM data. We’ve also incorporated NHD (National Hydrography Dataset) data into our process to improve accuracy. While both the NBI data and our milepoint method might have individual inaccuracies, combining these datasets helps mitigate many of the challenges. Additionally, we’ve implemented a manual review process specifically for cases where discrepancies still exist. This allows us to catch and resolve issues, including inaccuracies in coordinates or mismatches with on-the-ground structures.

One thing we haven’t incorporated yet is aerial imagery, which you mentioned. I’d love to understand more about your process here—does the use of aerial imagery require manual review in each case, or is there a way to automate it for certain scenarios? Any insights on how this might be integrated in an automated manner would be incredibly helpful.