[Talk-us] NHD import: what data quality is acceptable?

Greg Troxel gdt at ir.bbn.com
Mon Jul 23 01:25:40 BST 2012

Kevin Kenny <kkenny2 at nycap.rr.com> writes:

> A few months ago, I tried to get started on trying to resume the NHD
> import in my area - and some of the places where I hike. I'm trying
> to check results with both P2 and JOSM, and tripping over a lot of
> things, which made me put the project back on hold for a while. (I
> had some other things to be about.)

Working on this in my area is on my Copious Spare Time list.

> (2) One historic complaint I've seen about the NHD import is that it
> clutters the map,

That seems like a bogus criticism; renderers can choose to render or

If the criticism is cluttering the database, that's a harder call, but
water features are broadly important and it seems unreasonable to
exclude them on clutter grounds.  Sooner or later we're going to need a
layer concept in editors and probably the API.

> and that the assignment of "river" and "stream" is
> difficult.  What I'd propose is to tag as "river" anything that has
> more than two nodes of its flowline as "Artificial Path", and "stream"
> anything that's smaller.  In my area (eastern New York), for instance,
> that would mark out the Schoharie Creek, the Mohawk, the Hudson, and
> the lower reaches of the Catskill, the Kaaterskill, the Esopus, and
> maybe a few others. Is this a reasonable approach?

It seems like following the NHD norms is sensible.  For those who didn't
go read the wiki
"Artificial Path" is a NHD codepoint for river flowlines when NHD has
riverbank data.

Are you just talking about someone not quite being sure in edge cases?
Or are people upset about river/stream seeming off in OSM because it is
off in NHD?  Or something else?

> (4) What about cadastral lines (administrative boundaries, and land
> use, leisure, etc.) that appear to follow flowlines? My inclination is
> not to touch these at all, even if the flowline is being refined.
> Oftentimes, when a stream changes course, the cadastre remains
> unchanged. Only the recorder's office in the jurisdiction in question
> would actually know the situation. I think I'd rather see slightly
> inconsistent boundaries than mess up something like that.

That sounds like a good plan to me.

> (5) In the area I have in mind, there are very few ways that actually
> would need to be conflated (a few major rivers). Is it likely to be
> called vandalism if I confine myself to copying the OSM-specific tags
> from the OSM ways onto the NHD ones? I trust a land survey rather
> more than I do someone tracing a shoreline from Bing imagery: in
> well-graded streams, the shorelines can be variable and ambiguous,
> and NHD has pretty sound information about high water marks.

In my view, if you are acting in good faith and believe the post-edit
map to be better than the pre-edit map, it is not even close to

Often what I do when I want to change something and am a bit unsure is
to see who last edited it and message them.   Usually I don't get an
answer, but sometimes I do and it's been overwhelmingly positive (as in
"sure, that sounds like progress").

So you could write to people that added the big rivers and ask about
their data and whether they think it is better/worse than NHD.

> (6) When I try a limited import, I get a lot of JOSM warnings about
> waterways crossing highways. Do people think that all of these have
> to be fixed before importing? In that case, I'll have to confine myself
> to the very small area that has highway-crossing-stream that I can
> visit myself (to try to settle what the boundaries of the bridge,
> dam or culvert are, and what type of waterwork it is). Is it considered
> acceptable simply to leave the crossings unmarked? (They still
> render correctly in Mapnik, for what it's worth.)

waterways crossing highways is how it is.  They shouldn't be connected,
because you can't navigate from one to the other.   Having the waterway
improves the map, and the fact that it doesn't have detail about bridges
or aqueducts etc. should not be a bar to the improvement.  No where
else in OSM do we require quality standards to be met - just that the
map after the edit is better.

> (7) In the event that I find a node tagged with something other than
> a waterway (or landuse=reservoir, man_made=dam, etc.) that collides
> with an NHD node, is the correct approach to conflate the nodes,
> introduce a duplicate, or offset the new node? Does this question
> even have a correct answer?

I would merge the nodes.

I think a key point is that if you are looking at an existing map
feature and at NHD data for a single actual thing, and you are thinking
about that case, and maybe looking at imagery and deciding what's the
best thing to do, that's 100% fine, and isn't really "importing" as it
is railed against.

If you were going to write a program to bring in large amounts of NHD
stuff that you didn't look at and have it find matching nodes and merge
them without human review, that would be something else.

> I'm trying seriously to "do no harm", and getting paralyzed by the
> fact that there seem to be no firm guidelines on what is acceptable.

I think it's "would most mappers, especilaly local mappers think that
your edits are an improvement", with a presumption that edits that you
don't actually review are really scary.

> I'm trying to start with areas where I have firm local knowledge,
> although clearly I cannot survey streams on private lands, so I
> have to depend on NHD there. But the result is not going to be of
> much use to me unless I can generalize what I learn to do better
> NHD imports in areas that I know less well.

I would say that if NHD says there is a stream, and there's no data
about hydrography in OSM near it, then the map is better off with the
NHD data.  My impression is that NHD data that I see on the map while
driving appears quite in sync with reality.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20120722/d3505c02/attachment.pgp>

More information about the Talk-us mailing list