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!

Nice work! Around here in San Diego, we could use this data to discuss with our land managers the suitability of the utility roads they have designated for recreation. Grades >25% are not fun!

Haha! Yeah, I spent a lot of time figuring out where to find the files for BLM roads (i.e. “Ground Transportation Linear Features”) and then once you have that all the other pieces are right there.

The key is this page: https://www.blm.gov/services/geospatial/GISData And specifically this link on that page: https://gbp-blm-egis.hub.arcgis.com/

Importing the OHV areas for California was easy enough that I went ahead and downloaded the OHV Shape files for Arizona, Utah, Colorado, and Oregon. I’ll probably get to them before I finish with the GTLF data for California because conflating and aligning backcountry roads is a lot of work.

I skipped Alaska, though. BLM has a special relationship with Alaska and there’s a lot of unique data up there.

BLM data is generally not well represented in OSM, so there’s a lot of productive work that can be done easily. If you’re interested, pick a data set and start bringing it in to OSM!

Yeah, after attempting to use NHD for several waterways, I came to the conclusion that it’s almost always easier to draw the ways by hand.

That said, the NHD Flowline data is useful as a reference if you need to confirm the extent of a smaller, unnamed waterway. And in forested areas where the aerial imagery isn’t useful, it may be a good source of data about waterways.

The other NHD data files can also be useful for reference.

The Waterbody data can be helpful where it’s difficult to distinguish between open water and wetland using aerial imagery.

The Point data can help locate springs, which are often not directly visible in aerial imagery.

And the Line data can help determine the location and extent of dams and other features.

But in every case you want to use the NHD data cautiously and attempt to confirm and correct it using other sources.

Thanks @Skunkman56! I did see that work on feedback from PublicDomainOSM to US govt. agencies was underway. I’d really like to see that happen, especially with BLM routes where the data quality is not that good. If there’s an opportunity to try out working with feedback to BLM, USFS, or USGS, I’d be up for that.

I’ve been working on BLM routes in Imperial County, CA. There are official, numbered BLM routes that traverse desert dune areas where the sand frequently shifts.

The actual tracks on the ground follow the general direction within a few hundred yards, but vary significantly depending on where the dunes can be crossed.

I could clearly tag these ways with trail_visibility=horrible. But are there other tags that would be appropriate given how navigation on the ground varies?