<div class="gmail_quote">On Thu, Aug 5, 2010 at 4:43 PM, Alan Mintz <span dir="ltr"><<a href="mailto:Alan_Mintz%2BOSM@earthlink.net">Alan_Mintz+OSM@earthlink.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
At 2010-08-05 11:52, Ian Dees wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br>
It isn't any different. I had made the (bad) decision at the time to import over any existing data because in the several hundred places I spot-checked, NHD was vastly superior in resolution (and probably quality).<br>

</blockquote>
<br>
By "import over", do you mean to add duplicates, replace the existing features, or merge the info from the two manually?<br></blockquote><div><br></div><div>Add duplicates.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As I manually survey various features (POIs, some hydro, etc.), I usually try to merge in the data from existing imports so as to maintain the link (e.g. gnis:feature_id) back to the original database, in case we want to exchange updates with them again.<br>

<br>
One thing that occurs to me that may be a problem is that I occasionally have to delete a feature that is no longer present (e.g. <a href="http://www.openstreetmap.org/browse/node/358808220" target="_blank">http://www.openstreetmap.org/browse/node/358808220</a>). If we were to feed an update back to GNIS or get one from them, this situation would have to be taken into account.<br>
<br></blockquote><div><br></div><div>When I made the original GNIS import I saved the resulting XML and IDs (which would have allowed us to detect deletions) but promptly lost it in a hard drive crash.</div></div><br>