Thanks for this. I’m 30% of the way through curating this revised data set. I dropped anything that wasn’t a natural=peak as well as anything that didn’t have USGS Topo available (the further out Aleutians and one of the offshore islands). That left a bit over 1300 to deal with. I’d give this data set a B+. Good but not great, and still a fair number of errors. I agree that it isn’t fit for bulk import this without curation.
Yeah, I’m aware that there would be errors without manual review of every single node. But since I’m not going through all the nodes, the question for me is whether it’s better to have the data (with some errors) in OSM, or not.
If you found any problems that are not simply matters of adjusting the location of a node, I’d like to know about them so that I can follow up with GNIS.
There were a handful of nodes that needed conflating with existing ones, there were a few that were North/South peak combinations where there was a node for each in the pair and one for the combination, and there were a couple that were missed in the initial sanity pass. That sort of thing. If the position is close enough I kept going, but if it was markedly off, I moved it. I’m trying to go fast so it doesn’t take forever but is reasonably human curated for mountains in the middle of nowhere.
1 Like
I would definitely be interested in missed conflation nodes. That generally doesn’t happen unless the existing node is missing a lot of information or has information that differs significantly from what’s in GNIS. But those are cases I would want to use to look more closely at the conflation code.
When I’m done, you’ll see the conflated ones in the file because they’ll have an OSM ID.
1 Like
I think what you are seeing is an artifact from the surf, note in the screenshot below (3DEP contours overlaid on Bing aerial imagery) that the contours stop well south of the location where Sugar Hill is depicted. Some of the white in the imagery is clouds, but other areas are surf.
For example, just ran into this:
Doe Mountain and Anvil Mountain, from left to right. This is the sort of thing I’ve been just dropping off the data set.
Here’s the output of my reviews. It includes some conflations from existing source and drops a bunch of features as described above.
I’ve also set gnis:reviewed=yes
With the 3DEP Contours turned on, they look like they could be “hills.” Anvil Mountain, the taller of the two, has an elevation of 125 feet according to 3DEP.
Thanks @ZeLonewolf, much improved. I am noticing a few remaining issues, e.g.:
125 meters from location indicated by 3DEP contours
gnis:feature_id=1407692
name=Mount Owen
50 meters from location indicated by 3DEP contours (original location from GNIS was better):
gnis:feature_id=2057025
name=Mount Jimmy Doolittle
50 meters from location indicated by 3DEP contours (original location from GNIS was better):
gnis:feature_id=1406901
name=Needle Mountain
78 meters from location indicated by 3DEP contours (original location from GNIS was better):
gnis:feature_id=1421218
name=Cordova Peak
60 metes from location indicated by 3DEP contours, and in Canada:
gnis:feature_id=1399384
name=Mount Pullen
- What will we consider to be “truth.” I suggest the 3DEP contours
- For two dimensional data you have to use something like Circular error probable - Wikipedia
For spatial data a CE90 distance is typically specified, e.g. CE90 15 meters. - What should be our criteria for passing? Note that the National Map Accuracy Standard for a 1:24K map is CE90 12.2 meters[0]. I suggest double that.
- How did you come up with a sample size of 25? Is that large enough to give us a statistically significant result?
- What should be the criterial for non spatial errors, e.g. features misclassified.
I think we need to put the discussion about “accuracy” in perspective. The guidance on the wiki is that the reasonable level of accuracy depends on the existing data and that adding coarse data in areas where there is no data is an improvement. For many of the peaks in the data set, the nearest OSM feature of any type is miles away. In that context, being off by even a hundred meters is not a big deal.
3 Likes
Thanks for going through all this! I’m taking a closer look at the results.
One thing I noticed is that aligning to USGS Topo is not always the right choice. The alignment of USGS Topo tiles varies - sometimes it’s good and sometimes it’s not. Also, the USGS control benchmarks are not always placed at the exact summit of a feature. Often, where a feature has two high points separated by a saddle, subsequent data will identify that the one without the benchmark actually has higher elevation. And many USGS benchmarks are for horizontal position with elevation as a secondary attribute. That is, the elevation data may be good, but the location of the benchmark will not have been determined by the high point of the feature.
Using 3DEP to check the placement of summits works better. The 3DEP tiles generally have better alignment and sometimes have much more detail that USGS Topo. But even with 3DEP, there are cases where it is not certain that an alternate placement of a node would actually be better. In those cases, I defer to GNIS.
Just skimming through, I think there are a few nodes that you moved that I would have left in place for the reasons above.
Here are a couple of examples:
Purcell Mountain, where the original location (in grey) aligns well with 3DEP.
Mount Wright, where the vertical benchmark is not placed at the highest elevation. The original summit was inside a contour line indicating a higher elevation.
Camp Mountain, where the original placement aligns better with 3DEP than the new placement based on USGS Topo.
Agree, but sometimes it is difficult to tell from the 3DEP hillshade where the highest point is, so i have been usung the 3DEP countours.
I have found many cases where the original location was better than the revised location. In some cases both are less than acceptable imo.
Where are you getting the 3DEP contours? I must have missed that in JOSM.
I was thinking that a few were definitely better, a few were definitely worse, and many were a wash and possibly not worth the effort it took to move them.
The thing is, if @ZeLonewolf manually reviewed and edited all the nodes and decided to upload them, that would be manual editing and not an import and we wouldn’t have to discuss it.
Going through all 1700+ nodes was heroic, by the way. I appreciate that it must have been a huge effort!
Imagery - > Imagery Preferences - > WMS add button
Enter GetCapabilities URL=
https://elevation.nationalmap.gov/arcgis/services/3DEPElevation/ImageServer/WMSServer?request=GetCapabilities&service=WMS
Check “Store WMS endpoint only”
Check “Is Layer preperly georeferenced”
Enter name for this layer=“USGS 3DEP All” (or whatever you want)
Click “ok”
Click “ok” (again)
Above only has to be done once
During each session:
Imagery → USGS 3DEP All → 3DEPElevation: Contour 25
The contours are dynamic, the closer you zoom in, the more show.
Since you asked for any features that were misclassified,
gnis:feature_id=1405853
name=Maclaren Summit
This is really a mountain pass, ref:
The location of the feature is a little off. You will notice that OSM has “Maclaren Summit Trail”, and where that intersects Denali Highway is where I believe the feature should be located.
2 Likes
Thanks for the tile URL and the reference to Maclaren Summit! I’ll put that in my notes to talk to GNIS about.
Combining this with the 3DEP hillshades is excellent! Of course, they align perfectly. The hillshades have more detail, and the contours are easier to follow and occasionally more specific.
1 Like
Agreed. GNIS doesn’t provide a prominence attribute, but I assume there’s some way to compute it. I’ve been meaning to add it to a sledding hill so it doesn’t confuse users like some nearby waterfalls that measure only a few feet in height.