<div dir="ltr">
  
    
  
  <div bgcolor="#FFFFFF">
    <div class="gmail-m_-1556212839839875535moz-cite-prefix">On 10/13/2017 02:06 AM, Frederik Ramm
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>Hi,

   there's a LOT of NHD:* (and nhd:*) tags on OSM objects, see

<a class="gmail-m_-1556212839839875535moz-txt-link-freetext" href="https://taginfo.openstreetmap.org/search?q=NHD%3A" target="_blank">https://taginfo.openstreetmap.<wbr>org/search?q=NHD%3A</a>

- 1.9 million NHD:FCode, but also 188k "NHD:Permanent_" (note the
underscore), 10k "NHD:WBAreaComI", or 1.5m "NHD:Resolution" just to grab
a few.

I haven't researched who added them and when, but they would certainly
not clear the quality standards we have for imports today. Most of this
information can be properly modelled in usual OSM tags, and where it
cannot, it probably shouldn't be in OSM in the first place.

Is there any systematic (or even sporadic) effort of cleaning up these
old imports? Is there reason to believe that the neglect extends to more
than just the tags - do geometry and topology usually work well on
these, or are the funny tags a huge "this whole area hasn't had any love
in a long time" sign?</pre>
    </blockquote><div bgcolor="#FFFFFF">ON IRRELEVANT TAGGING:</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">I, at least, ordinarily do not make a specific effort to ferret out</div><div bgcolor="#FFFFFF">irrelevant tags. For the most part, they're harmless to me. If some</div><div bgcolor="#FFFFFF">random object on the map haapens to have 'zqx3:identifier=2718281828'</div><div bgcolor="#FFFFFF">among its tags, the only real damage is the diffuse cost of shipping</div><div bgcolor="#FFFFFF">the data around.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">That said, you're quite right that such tags might indeed be a symptom</div><div bgcolor="#FFFFFF">of a neglected import, or one that was originally done with processes</div><div bgcolor="#FFFFFF">that wouldn't clear today's bar. Even that has only some bearing on</div><div bgcolor="#FFFFFF">the data that are meaningful.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">ON IMPORTING NHD:</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">In the specific case of NHD, data quality varies by region. As Dave</div><div bgcolor="#FFFFFF">correctly notes, Alaska is uniformly atrocious. (There really are no</div><div bgcolor="#FFFFFF">good mapping data for Alaska. The technical challenge of acquiring</div><div bgcolor="#FFFFFF">high-quality data for much of the state simply is greater than the</div><div bgcolor="#FFFFFF">perceived value of the data.)</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">Where I am, on the other had, NHD is actually quite good - in the</div><div bgcolor="#FFFFFF">maps that I render, which are almost all in rural areas, I use it.</div><div bgcolor="#FFFFFF">I most often use it in combination with OSM and with other data</div><div bgcolor="#FFFFFF">sources (USFWS national wetland inventory, Adirondack Park Authority</div><div bgcolor="#FFFFFF">wetland inventory, NYSDOT, ...) which give the rendered maps a</div><div bgcolor="#FFFFFF">somewhat 'cubist' appearance, but I find that appearance helpful -</div><div bgcolor="#FFFFFF">it's an indication of data variability, and gives me an idea how much</div><div bgcolor="#FFFFFF">uncertainty to expect in the field.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">The fact that NHD is often quite 'stale' does not bother me at all</div><div bgcolor="#FFFFFF">locally. I live in a heavily glaciated area, and the cities have been</div><div bgcolor="#FFFFFF">settled for quite a long time by US standards. Out in the countryside,</div><div bgcolor="#FFFFFF">the streams run typically in deep ravines, disproportionate to the</div><div bgcolor="#FFFFFF">size of the streams. They aren't moving anywhere. They most likely</div><div bgcolor="#FFFFFF">haven't moved significantly since the Wisconsinan glaciation, 14000</div><div bgcolor="#FFFFFF">years ago.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">In the valleys, the detailed course of the streams does shift a bit,</div><div bgcolor="#FFFFFF">but in the cities and towns, the streams are engineered, and</div><div bgcolor="#FFFFFF">elsewhere, the terrain tends to be beaver swamp, and the streams shift</div><div bgcolor="#FFFFFF">with every move of the rodents or every major storm. I never expect</div><div bgcolor="#FFFFFF">the track of a watercourse within a wetland to be accurate, on any</div><div bgcolor="#FFFFFF">map, ever.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">NHD's topology is audited before it is released, so it's at least</div><div bgcolor="#FFFFFF">consistent (and likely correct).</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">It's certainly hypothetically possible to map the streams using</div><div bgcolor="#FFFFFF">'hand-crafted' methods - and I have done so for a few, when I've</div><div bgcolor="#FFFFFF">happened to follow them in wilderness travel. (I occasionally go</div><div bgcolor="#FFFFFF">hiking off-trail.) But the OSM community is never going to be able to</div><div bgcolor="#FFFFFF">do that for the great many watercourses that flow over my extremely</div><div bgcolor="#FFFFFF">well-watered area. There simply is too much land inhabited by too few</div><div bgcolor="#FFFFFF">people, most of whom are not well enough connected nor technologically</div><div bgcolor="#FFFFFF">literate enough to become OSM mappers. (Seriously, in some of these</div><div bgcolor="#FFFFFF">communities, there is no cell service and only a quarter of the houses</div><div bgcolor="#FFFFFF">have any sort of network connectivity. It's effectively working with</div><div bgcolor="#FFFFFF">Third World infrastructure.)</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">It's virtually impossible to map most of these watercourses as an</div><div bgcolor="#FFFFFF">'armchair mapper.' Our 'old second growth' timber gives rise to</div><div bgcolor="#FFFFFF">extraordinarily dense tree cover - denser than true 'old growth'</div><div bgcolor="#FFFFFF">forest. Even some fairly major watercourses - major enough that I</div><div bgcolor="#FFFFFF">wouldn't attempt to ford in springtime - are difficult or impossible</div><div bgcolor="#FFFFFF">to see in aerials.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">There has been an OSM project to map lakes and ponds in New York</div><div bgcolor="#FFFFFF">State, starting from point features giving their names. I've preserved</div><div bgcolor="#FFFFFF">these tracings in OSM, because I don't replace mappers' work with</div><div bgcolor="#FFFFFF">imports, ever. Nevertheless, I find them to be uniformly worse than</div><div bgcolor="#FFFFFF">NHD. They're usually quite rough, and in a great many of them, the</div><div bgcolor="#FFFFFF">mappers treated mats of floating or emergent vegetation as the</div><div bgcolor="#FFFFFF">shoreline, making shallow ponds much smaller than they are.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">For all these reasons, NHD is what I have in my area. I've never done</div><div bgcolor="#FFFFFF">a large-scale NHD import, and nobody else has done one around me.  If</div><div bgcolor="#FFFFFF">I need a stream for a rendered map, and don't want the 'cubist' data,</div><div bgcolor="#FFFFFF">I sometimes import it as a single object from NHD. Where else will I</div><div bgcolor="#FFFFFF">get it?</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">(That's pretty much my guideline on when importing is likely to add</div><div bgcolor="#FFFFFF">value: I as a data consumer have an identified use for most or all of</div><div bgcolor="#FFFFFF">what I'm bringing in, I have no ready way to acquire the information</div><div bgcolor="#FFFFFF">by mapping on the ground, and the external data set appears to be of</div><div bgcolor="#FFFFFF">good enough quality in the places that I have boots-on-the-ground</div><div bgcolor="#FFFFFF">mapping, and clean enough topology, that I can import without too much</div><div bgcolor="#FFFFFF">trouble. Nobody's reverted yet.)</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">ON TAG RETENTION:</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">When I import, I retain tags that are likely to be useful. Synthetic</div><div bgcolor="#FFFFFF">tags like 'area' I remove. I do occasionally retain tags that have the</div><div bgcolor="#FFFFFF">appearance of 'foreign keys' - but they are quite specific and I do</div><div bgcolor="#FFFFFF">ask mappers please to leave them alone.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">As an example, with the public land polygons that I've imported,</div><div bgcolor="#FFFFFF">I retain single unique ID's. I do repeat imports of those data sets,</div><div bgcolor="#FFFFFF">and I use the ID's in a semiautomated process for reconflation. (The</div><div bgcolor="#FFFFFF">reimported data are all checked manually, and I respect the work of</div><div bgcolor="#FFFFFF">mappers who've modified the import. The ID merely gives the script a</div><div bgcolor="#FFFFFF">starting point.)</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">When importing single objects from NHD, I remove most of the rubbish</div><div bgcolor="#FFFFFF">but I do keep 'permanent_identifier'. (The 'PERMANENT_' tag is an</div><div bgcolor="#FFFFFF">artifact, coming from the fact that some intermediate database</div><div bgcolor="#FFFFFF">somewhere in the pipeline is limited to ten-character column names.)</div><div bgcolor="#FFFFFF">I also retain 'reachcode'. That string of digits is, according to</div><div bgcolor="#FFFFFF">USGS, guaranteed to be stable - they don't reuse them - and encodes</div><div bgcolor="#FFFFFF">information about the topology of a stream. I know some of the local</div><div bgcolor="#FFFFFF">codes quite well - I recognize at a glance that codes beginning</div><div bgcolor="#FFFFFF">with 02020005 refer to waterways that drain to the Atlantic by way</div><div bgcolor="#FFFFFF">of Schoharie Creek (a locally significant river despite the name,</div><div bgcolor="#FFFFFF">with dams, reservoirs, power stations), the Mohawk River, and</div><div bgcolor="#FFFFFF">the Hudson River. It's effectively a machine-readable 'second name'</div><div bgcolor="#FFFFFF">for the object. The other stuff, that doesn't map to OSM tagging,</div><div bgcolor="#FFFFFF">I discard.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">CONCLUSION</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">Should irrelevant tagging on NHD objects be stripped? Maybe, although</div><div bgcolor="#FFFFFF">the diffuse cost of the database space and network bandwidth to retain</div><div bgcolor="#FFFFFF">and exchange it doesn't keep me awake at night. Please keep</div><div bgcolor="#FFFFFF">'reachcode', though, I use that one!</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">Should the presence of the irrelevant tagging cause the underlying</div><div bgcolor="#FFFFFF">objects to be removed? Please don't. The data aren't perfect, but we</div><div bgcolor="#FFFFFF">don't live in an ideal world. NHD's data quality is variable, but</div><div bgcolor="#FFFFFF">where it's good, it's very good, and even where it's bad, it's often</div><div bgcolor="#FFFFFF">better than anything else we're ever going to get our hands on.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">Are the data obsolete? Sure - but obsolete data about stable features</div><div bgcolor="#FFFFFF">are almost as good as up-to-date data about the same stable features.</div><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">Would I import them wholesale today? Surely not. That's primarily</div><div bgcolor="#FFFFFF">because of the controversy that would ensue. I'm no stranger to</div><div bgcolor="#FFFFFF">controversy, but I respect the community consensus that large-scale</div><div bgcolor="#FFFFFF">imports are a matter of last resort, and forgo them where there are</div><div bgcolor="#FFFFFF">significanat technical counterarguments. (I ignore the arguments that</div><div bgcolor="#FFFFFF">are based solely on contentions that "imports are always bad for the</div><div bgcolor="#FFFFFF">community," or else I'd never import anything.)</div><div><br></div>
  </div>

</div>