Thanks for writing up these comments on features that don’t have precise boundaries!

I think about this as well in the context of natural=desert, which has unfortunately been conflated with natural=sand. It’s true that there are some sandy deserts, but most of the world’s deserts are rocky rather than sandy. And even deserts have scrub. Sadly, the wiki entry for natural=desert isn’t helping this.

Deserts are important places and have rough boundaries defined by cultural, biological, and geological distinctions. And like oceans or many other large natural features, these boundaries are indistinct and subject to different interpretations.

In spite of the fact that the wiki says natural=desert applies only to areas, there are more deserts mapped as nodes than as areas. And I imagine that many of those areas are either conflated with natural=sand or have issues with the verifiability of the borders.

It would be nice to be able to map deserts as nodes with some indication of the size of the area. The sqkm tag is a possibility, but I see the issues with it as well. Just as it’s hard to get consensus on the boundaries of features like this, it is hard to get consensus on the precise area as well. Does it matter if the Mojave Desert is 65,000 or 130,000 sq km? Maybe that doesn’t make too much difference to a renderer, but it could lead to endless “corrections” to the tag.

It seems like mapping large, poorly defined areas is an old problem in OSM. If we do find a solution, it would improve mapping for many different types of features.

I’m not sure what you’re asking @lindsaywoods219. The idea of using a small, inexpensive computer to run Overpass is to have something convenient for local usage and not to burden the larger public Overpass servers with lots of speculative queries.

In general, this is not a solution for a large scale or high-reliability Overpass system. Query response times are OK for small volumes but a small system like this does not handle large volumes of queries well. And there are still some reliability issues. For example, a power outage or other unplanned shutdown can still result in corrupted data that needs to be manually repaired. Often, that means starting from scratch with a fresh database copy.

If anyone is curious about the withdrawn and historical GNIS records that are currently mapped in OSM, I have Overpass queries that will find them.

Withdrawn GNIS records in OSM - Overpass Query

Historical GNIS records in OSM - Overpass Query

Any attempt to correct these features should be done with care and should take several things into consideration.

• Many GNIS records have been withdrawn because they were duplicates of other records. Additional research is necessary to identify and apply the correct GNIS Feature ID.
• Withdrawn and historical features may exist in some form that can still be mapped in OSM (e.g., as abandoned: or historical=yes). Additional research is necessary to confirm the current state of the feature.
• Where withdrawn or historical features still exist in some form, they may have been altered or repurposed in a way that the former GNIS data no longer applies. Additional research is necessary to confirm the current attributes of the features.
• There are some false positives where GNIS withdrew records for airports that still exist and may still be in use. (GNIS no longer maintains records for airports.)
• Some features were marked as historical before GNIS archived several feature classes in 2021. These features will appear to have been withdrawn from the current GNIS data set (but have been identified as “historical” in the query above). Any review of features in the archived classes must use the archived GNIS data set.

That’s pretty cool! Thanks for doing the analysis!

Given the scale of the data, the overlap between categories at one standard deviation is remarkably small.

This would be a good topic to post on the OpenStreetMap Community Forum to see if we can get some consensus on how to map mountains whose names differ from the names of their summits.

Those are some interesting thoughts on mountains whose summits are named differently from the mountain itself.

I think of all the things you mentioned, using natural=mountain as a single node to label the mountain is the most practical. This is a natural feature that has a presumably verifiable name, so it can be mapped. However, as the area of the mountain is likely indistinct and not verifiable (except in unusual circumstances), it doesn’t make sense to map it as an area using a closed way.

I understand the desire to use a relation to group related features, but this is something that OSM struggles with right now. Consider Relation: Great Lakes (1124369) which has had a history of being tagged in different ways, or the challenge of structuring a Tag:place=archipelago relation.

You could make a relation with natural=mountain and the peaks as members, but I think that would be somewhat experimental until OSM figures out how to map groups of things effectively.

Thanks for writing this up! All the old landuse=quarry nodes definitely need to be cleaned up.

One tip is to look at the USGS Topo map for the area. If there’s an adit or shaft at the location (identified by specific USGS symbols), then it’s definitely a mine and not a quarry. Where the adits and shafts are still present, they can be mapped with man_made=adit or man_made=mineshaft.

If you’re feeling adventurous, you can even try to look up the mining records from the Mineral Resources Data System. Some of these records have historic information about the mine like the types of minerals that were being mined, which can go in the resource=* tag. And the Deposit ID can go in ref:US:MRDS=* to link back to the MRDS record. MRDS records are often transcribed from old handwritten documents and much of the data is missing or of poor quality. But if you dig deep enough, you may find some gems!

Thanks for the kind words, stevea!

I don’t think I would want to make an ominbus proposal of everything in the glossary at once, but many of the undocumented tags could be ready for individual proposals to document existing usage, and there are several open proposals that I think deserve support:

• Proposal:Atoll
• Proposal:Dry lake
• Proposal:Volcanic features
• Proposal:Tag:natural=butte
• Proposal:Tag:natural=mesa
• Proposal:Tag:natural=plateau
• Proposal:Natural=cave
• Proposal:Whitewater
• Tag:waterway=stream_end

I hope that mappers will support these proposals by commenting on them either in support of the proposals or to suggest improvements. And I hope that mappers will find these tags to be appropriate and useful when they’re mapping.

@rtnf, we’re in uncharted territory since none of the tags for alluvial fans are in use yet.

My general inclination is to tag the basic form of the feature using natural=* and use geological=* to be more specific. So I might keep natural=sediment and add geological=alluvial_fan.

One thing about using the natural=* tag is that it might bump into other things that could be tagged at the location, e.g. natural=wood. That’s a little less likely with the geological=* tag.

All of this is definitely open for discussion and I would encourage some experimentation. Let’s try some things to figure out what works best and what the community likes best!

Thanks! Yes, I was hoping to make this a general wiki page after the initial work was done and when there is some consensus that the information is reasonably useful.

Nice work! I don’t see much of this spam where I’m mapping, but I’ll keep an eye out for it!

Very nicely done! I love the cost analysis!

Thanks for the comments @mmd! I’ve added a script to safely shutdown Overpass, including using --terminate to stop the dispatchers instead of killing the processes.

That’s the general idea, although some service roads can be used for through traffic (e.g. alleys). And, of course, there are plenty of tracks that go somewhere and stop.

Different regions have different conventions, so you want to consider what’s right for the local area. As Msiipola and VileGecko mentioned above, the considerations for track versus service are different in Sweden and Ukraine than what I would use for the US.

I take that back. After looking more closely, there’s a track that continues around the gated property. It’s not immediately visible in aerial imagery, but it is mapped.

That’s why this way is part of the route relations. In which case, track may in fact be more appropriate.

Yes, service. It’s hard to see why it would be any different from the two-node way at the end near the gate. Or, except for the access restriction, why it would be any different from the way on the other side of the gate.

But take a close look at that way’s membership in route relations. That seems a little odd.

I like to consider the classification of roads in the context of their relative importance in the overall road network. An unclassified road provides more connections and carries more traffic than a track.

For me, in the context of US highway tagging, service roads are a lower classification than either unclassified or track. As the Wiki says, service roads provide access to or within a well defined area like an industrial park or campground. So, driveways or alleys would be service roads.

But of course you want to make your tagging consistent with local usage. That means looking at what other mappers have done in the area and considering the accepted local tagging schemes for highways.

I haven’t done much mapping in Austria, but based on the context, it looks like the current tagging is good.

Here’s an example of a road that has been classified as service but that I would consider a track. Looking back at the history, you can see that different mappers have different ideas of how this road should be classified. That’s why I figured I would write this up.

I think there’s a lot to be said for cleaning up tags from old imports. That might be the first way this project could contribute something to the map.

Since there were only a few examples globally, I went ahead and manually fixed all the malformed gnis:feature_id tags, which were generally all duplicates of existing data (mostly duplicates of name). Turns out, many of those features actually had real GNIS IDs that I could fill in.

And there was one exception where a mapper in Germany put some apparently useful data in that field. I didn’t know what to do with it, so I just left a comment on the changeset.

I was just going to say the same thing! I do have a particular perspective from the US and I don’t know how far that carries into other countries.

The comment from @VileGecko is a different (and valid!) perspective. It’s interesting to see how the nature of the highway infrastructure itself is different from one country to another. And of course that leads to differences in tagging conventions.

There’s no reason that roads in Ukraine should fit neatly into a classification that works for the US. And many of the roads I’m working with don’t fit neatly into @VileGecko’s scheme.

Take this road for example. This road is 6.5 miles long and connects to other roads in the area so it can be used for through travel. It is reasonably well maintained in comparison to other roads in the area (probably by the utility company) and the location is relatively fixed by that maintenance. It’s comfortably wide enough for heavy utility vehicles, but just a single lane. The road is on land managed by the US Bureau of Land Management but they have not published a name or reference for the road. I haven’t been there in person and there is no street-level imagery for the area but I would be surprised if there was any signage.

So, that’s not a perfect fit for either my scheme or @VileGecko’s scheme.

I’ve mapped this road as highway=track. If I were to map the small stubs going out to the individual pylons, I would tag them as highway=service. I think that makes sense in the context of other roads in the area. But if this was another country with different conventions for tagging roads, I would follow those other conventions.

@Msiipola there are certainly cases where the good judgement of the mapper is the best guide. Thanks for the comment!