The group of railroad crossing challenges listed in the previous diary entries is now complete. Many people worked on these challenges to make this happen. The tasks seemed to get more difficult as the challenge neared completion, since each task would correct a single crossing at a time.

Many of the tasks involved original TIGER highway crossings with poor alignment. I also worked on geometric alignment of the crossing approach roads to match the aerial imagery. Although almost none of these would be cross-checked against GPS traces, Bing imagery is almost always a factor of 10 more precise than the worst of the TIGER data. The resulting edits may have an effect on “TIGER desert analysis” - the study of large untouched areas in the US. Those “TIGER deserts” still exist but would be smaller. My personal contributions heat map now mostly shows areas in the US where there were rail crossings that needed fixing:

I have fond memories /nightmares of a task landing in West Virginia or Kentucky, and realizing that the only way I could fix the crossing called out by the task would be to untangle the surrounding 30 miles of rail and roads.

The challenges took a total of 10 months to complete. I attempted to keep the quality of tasks relevant by re-running the analysis every week. Thus any fixes completed outside of MapRoulette or edits of surrounding crossings would automatically be marked complete in MapRoulette.

In the role of the “Monday Morning Quarterback”, (with perfect hindsight) there are things that ideally would be done differently or included in a more detailed task definition page:

• Separate tasks into additional challenges to reduce the time needed to analyze each one. For example, a ‘duplicate rail crossing nodes’ task would define a work flow even if there is already a visible ‘X’.
• Create a video tutorial for the most popular editors to show the workflow for all the common tasks and how to fix. Even having screen shots of how to identify most common US bridges and tunnel types would help.
• I was able to concentrate on tasks marked as Skipped or ‘Too hard’ by querying the API. If the crossing was completely invisible from aerial imagery or alternate aerial imagery such as being under a bridge that might be 3 layers, the final task completion was to remove the task and leave an OSM Fixme or OSM Note. It would be useful to add a preference for those task status types in MapRoulette.
• Define a helpful sequence of alternate imagery: latest TIGER, NCOneMap (for North Carolina off-leaf imagery), use of SRTM Elevation to detect the difference between a tunnel entrance VS barriers on a decommissioned highway crossing, USGS Large Scale Imagery / NAIP for latest imagery for road realignments.
• Define a sequence of analysis when encountering a crossing that looks correct: was it recently fixed by someone else, or is the problem difficult to see? (1. Try a node “J”oin in JOSM. 2. Check date of last Crossing node edit - mark as already fixed if corrected in the past week. 3. Check the last edit date of both the highway and railway - mark as already fixed if corrected in the past week. ) The trickiest of these was a bridge - road crossing where all edits were much older than the last OSM synchronization. The problem was a ‘duplicate bridge’, two 2-node ways where one ‘bridge’ had no layer or bridge tag.

As a side note about the internal detail of MapRoulette, it seemed as though the Postgres SQL RANDOM statement was not truly random - as though there was an internal optimization or spatial caching of a previous RANDOM statement. My only evidence of this was that when encountering a 2-track crossing on a task where both level crossing nodes were corrected for the first task, the second crossing task would appear after only a small number of other tasks.

Because OSM is constantly being edited, there are now new unmarked crossings identified. I have not extended the Rail Crossings challenge because many of them come from new construction where there is no imagery to determine whether the crossing should be a level crossing or bridge. I may add these if I can find a way to ensure that just the solvable crossings are identified.

The end result of these challenges is that the Rail-Road network intersections in the US are much more accurate. They could serve as a reference to routing apps that can generate an alert for level crossings. This application has one case that doesn’t fit easily in the OSM tagging convention: busy tram crossings in cities, where there may be many crossing alerts generated over a short distance. Although they are actual rail crossings that would result in serious damage in an accident, continuous alerts are a case of ‘crying wolf’. This was briefly discussed in railway=level_crossing with in-street trams? , but without any definite resolution. For now, the application developer also needs to examine the crossing rail type to screen out tram crossings - probably not an ideal solution.