I took a look at the issues you posted in the Overpass repo on Github. The incorrect messaging in shutdown.sh got a quick fix but that script is due for much more attention soon.

And I noted the issue you had with applying global diffs to the extract database. I think there’s a lock file issue lurking in there that needs more investigation. But that wouldn’t address the bigger issue of diffs needing to match the extract.

If you bump into any other configuration or operational issues, I’d be happy to help with those too!

Nice write-up! I haven’t tried to get Overpass working with smaller extracts, so it’s good to see how that worked out.

I have been actively working on the updated scripts in my fork on Github. At the moment, that means that fetch_osc.sh got the most attention. Other scripts will get more work soon, starting with apply_osc_to_db.sh.

If you happen to bump into any issues with the scripts, I’d love to hear about them!

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.