Missouri River Boundary

Issue: Missouri River Boundary Anomaly

I recently did a custom tile for a good chunk of the Central, Midwest and the Great Lakes region of the United States. I’m planning a trip soon, and I’m going to be visiting a number of areas, including South Dakota (this is as far west as I selected.)

Roughly speaking, the tiles cover Missouri (my home state), part of Nebraska, South and North Dakota, Wisconsin, Minnesota, Michigan and the entire Great Lakes, Illinois, Indiana, Ohio, and Arkansas (the southernmost part of the entirety of the tiles.)

This is my problem: Near the center of Missouri, near the town of Jefferson City (ironically, my city of residence,) I found, to my chagrin, that a good chunk of the Missouri River is a solid blue. I found this anomaly on my Garmin Dakota 20 GPS.

Please note the upper (northern) boundary line of what shows as “Missouri River.” A pop-up appears when hovering the cursor over an open, blank area of the blue area, when doing so in Base Camp. I took the following two screen shots of the Base Camp interface to illustrate the anomaly:



Again, Upon finding this issue on the Dakota 20 GPS, I opened Base Camp, selected my OSM World Routable map product, and found the same map anomaly. The bottom (southern line) of the Missouri River is correct. However, the northern part seems to have been turned into what appears to look like a widening-out of the river, as though on a flood plain.

The northern-most line runs (starting from the upper left of the anomaly, near the town of Lupus, Missouri) from east to west for about 14 miles. (14.4 miles using Base Camp Measuring Tool.) From there, the upper-boundary-line goes in an East-By-Southeast direction for a fairly long stint–about 76 miles (76.3 as measured using Tool,) then goes south about 3 miles (3.3 as Measured using tool) south, back to the Missouri River.

I can tell you that this is not the normal course of the Missouri River.

Now, the flood plain does go a bit northeast of Jefferson City, Missouri, and flooded extensively in a well-remembered flood of 1993. Still, this is not the case today, as a town to the immediate east of Jefferson City–Holt’s Summit, MO, across the Missouri River via the US-54 bridge–is quite high in elevation, and the Missouri River would have to reach a flood stage of Biblical proportions to have represented on the map the northern water boundary lines as indicated.

As I was typing this, I redid the map regions and downloaded a new installer file. I installed the new one, and the anomaly still appears in Base Camp. I’m going to download the gmapsupp zip file, transfer it directly to my gps, and see if the anomaly is visible on my Dakota 20. If it is, I would say that the map build process is messing up some hydrography data with some type of other boundary line, or the tile-merge is doing something weird.

Well, that’s it. I appreciate your hard work on these maps, and am enjoying using them. If you need any assistance with the tracking down of the problem on my end, please let me know what I can do and I would be glad to oblige.

Leaving you with my,
Warmest Regards,

Stephen A. Brown
Jefferson City, Missouri

UPDATE: I would concentrate on the following tiles:

US - St. Louis
US - Columbia
US - Jefferson City

I just downloaded the above three tiles, and installed them. Base Camp shows the same anomaly, so the current tiles are the probable culprit. Please check these to see what may be causing this issue with the MO River.

Again, I remain available to test anything if you have a need.


(Note: The use of the word “tiles” is used here to reference the selectable boundary areas only on the web site’s home page, and do not necessarily reflect any .img ‘tile’ itself.)

I ran into this with a local river also. I’m pretty sure it’s related to the guideline that ‘waterway=riverbank’ boundaries must represent a closed polygon.


To fix this locally, I went along the riverbank, creating closed loop polygons that touched each other to create a normal looking river.

Thanks for the reply, MikeN. I’m fairly new to GIS stuff in general, although I understand the general gist to what you’re referring.

I would like to contribute to this project, but I need a bit more education before I start trying to tweak things I don’t fully comprehend. I have JOSM, and have just loaded one or two of those…what are they termed? Nodes?..into it, just to see what’s happening on the surface.

I didn’t commit any changes, of course. What I need is a good tutorial on what I’m trying to correct. Since this error affects my area directly–there are a lot of forest areas that really don’t need to be ‘under water,’ as it were ;->, and I’d like to contribute the solution. I don’t know how, just yet, and would like to learn a bit about it so I understand fully what to do.

That way, I not only correct the problem, but I also learn about the OSM GIS more, so I can contribute more corrections, as needed. I sincerely want to participate in this in an active manner.

Any assistance in this matter would be greatly appreciated.

Thanks in advance,

MikeN: I’ve been looking around using Potlatch 2, as well as the link you provided.

As suggested, I’m looking for instances of a non-closed polygon; which would be evident by…what? Unclosed ways? There is a tag that caught my attention: natural=water, which is evidently used for lakes. I wonder if that tag was accidentally affixed to that portion of the river.

Anyway, as of 10:23pm Central Daylight Time, I’m still looking.

Will continue to update as I find out stuff.


I see that the Missouri River has already been placed into a multipolygon relation, 1756890 ( http://www.openstreetmap.org/browse/relation/1756890 ). One problem is that if there is a break somewhere along the hundreds of miles of riverbank, the relation will ‘leak’. This is hard to track down with current tools. JOSM indicate breaks in the relation with some graphical symbols. But the relation analyzer might be easiest to start with: http://ra.osmsurround.org/analyzeRelation?relationId=1756890 . Note that breaks and discontinuities are not necessarily errors because the relation contains islands.

Another problem is that because the relation covers hundreds of miles, the Garmin renderer might not be able to load enough of the data to see that there is no leak.

A solution is to create ‘cuts’ so that a waterway=riverbank represents a local polygon which is easy to verify. This is illustrated here: http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank , in the diagram under ‘islands’, ways #1 and #3. In theory, the cuts should not be necessary if all ways in the relation are correct, but there may be tool limitations.

Creating ‘cuts’ in JOSM is no simple task when also learning JOSM, but I could create a series of images that outline the steps to be taken. It would take several days however - let me know if that would also help.

Hi MikeN,

Thanks for the help. If you have the time, I’d thoroughly enjoy looking over any images that you’d like to create for me to look at.

Take your time, of course, as there’s no hurry. I placed some similar queries into a couple of other forums, as well as the OSM Q&A. Everyone has been most helpful, and a couple of people have supposedly corrected some of the issues.

I was also informed that the garmin.openstreetmap.nl database has not be updated in a while, so the changes in OSM may not yet be reflected in what I download. So at least I have that information now.

Relative to learning JOSM, please create those images if you feel up to it. Anything to help me learn is greatly appreciated! :slight_smile:

Warm Regards,
Stephen Brown/Firefishe