[Tagging] nhd tags - documentation page review

Kevin Kenny kevin.b.kenny at gmail.com
Mon Jun 15 01:25:20 UTC 2020

On Sun, Jun 14, 2020 at 4:21 PM Mateusz Konieczny via Tagging
<tagging at openstreetmap.org> wrote:
> I created
> https://wiki.openstreetmap.org/wiki/Key:nhd:fcode
> https://wiki.openstreetmap.org/wiki/Key:nhd:ftype
> https://wiki.openstreetmap.org/wiki/Key:nhd:reach_code
> https://wiki.openstreetmap.org/wiki/Key:nhd:com_id
> about tags added in imports.

I agree with you  about fcode and ftype. My only caveat is that I'd
have to find my old notes; I seem to recall a couple of cases where
there were distinct fcode/ftype for some water feature or other, that
OSM tagging failed to distinguish. (The solution to that is to extend
the tagging and *make* these keys superfluous!)

Reach_code is useful.  It is a _stable_ identifier - the schema
specifies that reach code will not ordinarily change (unlike many
numeric primary keys in databases!). It not only identifies a
particular waterway, but also gives its primary drainage path; the
reachcode of a third-order stream will have that of the second-order
stream as a prefix, and the reachcode of the second-order stream will
be that of the first-order river.

(There are exceptions where, owing to the fixed length of the fields,
an enormous river needs to be divided into two or more parts, but the
principle is there, at least.)

Com_id is somewhat peculiar and I've hardly seen it as a foreign key
in databases other than NHD. I don't much care about it.

So, of the four, reach_code is the only one that I'll raise a stink
about. With that said, extraneous data in OSM are Mostly Harmless.
Deleting unneccessary (as opposed to incorrect) data is never
something that I'd demand.  (It would be good to request that any
further import from NHD - which would have to be done with careful
conflation - refrain from including the FCode and FType.)

73 de ke9tv/2, Kevin

More information about the Tagging mailing list