On Sun, Jun 14, 2020 at 4:21 PM Mateusz Konieczny via Tagging <[email protected]> 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 _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
