I’ve chanced upon a “connector” imported from NHD, which is a hydrologic modelling feature defined as “a known, but nonspecific, connection between two nonadjacent network segments”. Specifically, way #58399226, which has a permanent_identifier=167307973 in this NHDFlowline layer). More connector information from the USGS here.
In other words, a connector is an invisible stream. Given it’s invisible (no obvious stream channel or other topographic signature, historic or otherwise), should they be in OSM?
One reason for deleting would be because OSM is currently displaying the connector as it does any other stream, which is incorrect. A reason for not deleting would be if people are using OSM for hydrologic analysis, but I don’t think this is likely because OSM would always be obsolete compared to the source data.
Other than this thread, I haven’t seen this come up before, so I’m wondering what people think before I start removing connectors.
Not at all, what you are doing is requiring anyone who wants to use OSM for hydrological modelling to jump through some really complex hoops in order to have an interconnected set of data. Effectively by removing them you are removing the possibility of doing it at all.
Somewhere on the talk-gb lists there’s a very good comment by @Andy_Allan about this sort of issue (IIRC in the context of maxspeed tags).
This article specifies that a connector is included when the following criteria are met:
When connector is part of a network that is represented as being connected.
When there is a gap with no collected network feature object between pieces of the network; for example, at a 2-dimensional (polygon) dam/weir that causes a gap between an upstream lake/pond and a downstream stream/river.
It gives an example of a connector going through a dam in order to connect the artificial path going through Lake Oroville with the Feather River downstream. Apparently we’ve done two better by mapping the tailrace tunnels, though the wiki recommends tagging such connections as waterway=pressurized to avoid counterintuitive rendering.
This looks like basically a big fixme=geometry: NHD knows the pond connects to Island Lake but doesn’t know the precise path by which the water flows. I wonder if natural subterranean rivers are modeled similarly – those definitely should be in the database.
This is like saying no one uses OSM for transportation analysis. Certainly there are more authoritative sources out there, but there are reasons for conducting more casual analyses too. For example, Waterway Map (discussion) segments OSM’s hydrologic features into color-coded watersheds for QA purposes, and River Runner depends on waterways to route a drop of water from any location to the ocean. It’s all for fun, but this is how OSM got its start as a major source for transportation data too.
This has resulted in people in OSM asking what you’re asking, “Should we map them like that”, so even within OSM, it’s unclear how to map them. Most people support mapping them, but not everyone.
Not with NHD it won’t. I think we learnt years ago that NHD is often wildly outdated. However, because it’s an official source I suspect there’s a tendency to not update it on OSM.
I did experiment some time ago with using OSM data for hydrological modelling, using a package called BASINS. From what I recall OSM data is a reasonable fit (although some landuse classes now used are a tad ambiguous) other than it needed a bathymetric profile for larger water bodies (something which didn’t worry me as I was concerned with excavated gravel pits where I could use an assumed profile).
I think it would make a good student assignment to actually investigate this area in depth. (What kind of OSM data can be used? How does it need to be transformed? What data is missing? How does actual tagging affect validity of outputs?)
I think it is pretty easy to surmize looking at the situation on the ground, or in imagery, that the water - at least under some circumstances - goes from the upstream to down stream side of a dam. We map culverts, but I doubt many of us has actually crawled through one in order to be certain that there is a connection, so it should be with these “connectors.”
A distinction should be drawn between mis-mapping (or mis-tagging) so a feature renders in an existing renderer, and mapping so that someone could create a render to show a piece of information. Mapping a connector is not being done to make a particular analysis tool work (that I am aware of), but so that in general network analysis will be possible and practical.
I think my real qualm with connectors are that renderers display waterway=connector the same as waterway=stream/river/etc.: linear bodies of water on Earth’s surface, which is not an accurate depiction of reality. Aside from deleting the connector, I don’t know of a good way to ensure OSM reflects reality.
Thanks everyone! I think I’ve decided to delete connectors because:
mapping them violates the “on the ground rule” (connectors have no surface expression and therefore aren’t observable), and
they’re the ultimate example of “mapping for the renderer” (they exist only so hydrologic modelling works in NHD)
I don’t know whether I’m going going to go on a campaign to delete connectors (read: I think artificial connectors are probably fine), but I will be deleting the example way used in my OP.