Ah, OK, to indicate that snowmobiles are allowed, expand the Tags section at the bottom of the sidebar and set “snowmobile” to “yes”. Here’s some documentation about the snowmobile key: osm.wiki/Key:snowmobile . It doesn’t have a dedicated row in the part of the sidebar that you used because it’s a little rarer worldwide.

Here’s some documentation on mapping townships in Ohio: osm.wiki/Ohio/Boundaries/Townships

Hi, it looks like you’ve been setting “Motor Vehicles” to “designated” on footpaths and bridle trails. This would mean that the trails are mainly intended for cars and other motorized vehicles. It actually causes some routing engines to route people over these trails in some cases:

osm.org/directions?engine=fossgis_osrm_car&route=41.3400%2C-80.7788%3B41.3510%2C-80.7675#map=15/41.3452/-80.7743

Did you mean to set it to “no” instead?

Thanks for the details, I stand corrected. This is very recent construction. Lately I’ve been feeling confident about the Bing Streetside imagery in the area, which is current to last year, but this construction is even too new for that. Among the publicly available layers, some road construction is apparent in Esri, but I didn’t realize that led to a road diet.

I realize you’re normally unable to share the proprietary imagery as you’ve done here (thanks!). But perhaps when you’re making a change that’s very new and only available in this proprietary imagery, you could note its age in the changeset comment. This would give another mapper like me a heads-up that you know more than I do. :-)

I restored your suggested tags in changeset 127316900. Thank you for patiently explaining the situation to me!

By the way, I’ve also introduced lane connectivity relations to this intersection, since some lanes before the intersection lead to two lanes after the intersection. This isn’t always required, but as you’re updating lane counts, if you see any lane connectivity relations, it would be great if you could keep them up-to-date also. osm.wiki/Relation:connectivity

Hi, this changeset and others such as 119657559 introduced errors rather than fixing them. Vine St. has two more lanes than you may have recognized in street-level imagery – these can be parking lanes during some times of the day, but these are the exception rather than the rule. Also, the intersection of 5th and Vine has two more lanes, as shown by overhead signs and pavement markings. Finally, these changesets connected the roadway to bridges and tunnels, creating impossible routes. These issues have been fixed in changeset 127223264.

Several downtown Cincinnati intersections, including 5th and Vine, are staggered and therefore have unusual turn lane arrows. There isn’t an established tag for these arrows, so slight_right is the most compatible option at the moment: osm.wiki/Talk:Key:turn#Unusual_arrows

The intersection is correct now, but I’d welcome advice on how to keep it from generating a false positive in validation tools such as the one you’re using.

Also updated the address in osm.org/changeset/126968013

Most of the overconflation affected Confederate flags, which, well, are problematic for other reasons anyways. But node 4718501937 is an example of a historical flag of the United Kingdom and Ireland – same flag, different country represented. I’m not sure if it’s worth creating a separate entry; maybe the validator should be more lenient about subject differing, or NSI should omit subject altogether.

FYI, some of the flags had the correct flag:wikidata but a less specific flag:name. (I avoided creating separate NSI entries for them at the time, because I didn’t want these historical flags to be overrepresented in a still small part of the index.)

How would you distinguish between an undivided intersection that allows U-turns and one on the same undivided street that prohibits U-turns? Sure, most routers wouldn’t suggest making a U-turn here anyways, but most likely the authorities posted the sign here because a parent would otherwise be tempted to pull a Uey to drop their kid off at the school.

If you think non-universal legal restrictions should be disregarded except by mapping an ignorable sign node, then under what criteria would a turn restriction ever be mapped? If it’s based on the “flow of traffic” irrespective of a regulatory sign that’s enforceable, one wonders how turn restrictions could ever be verifiable.

If I understand correctly, these are essentially divisions of a single government agency (CAL FIRE). It’s much more common to indicate this kind of detail in operator tags of relevant features. For example, each CAL FIRE station within the CZU unit would be tagged:

operator=CAL FIRE San Mateo–Santa Cruz Unit
operator:wikidata=Q99306333

It’s possible that some CAL FIRE stations don’t even have any indication on them that they’re operated by CAL FIRE yet, so this would be a clear improvement.

The operator:wikidata tag would allow someone to easily query for all the stations operated by the unit without worrying about exactly how the name is spelled. Wikidata items have only been created for a few of the units so far, but more can be created using https://www.wikidata.org/wiki/Q99306333 as a model.

I meant to say: name:was is for the name in the Washo language; use old_name for the former name

access=private private=employees is a more accurate way to express the restriction than access=no, which means that no one (other than perhaps emergency personnel) can access the facility. If a routing engine is sending users onto the tarmac, the routing engine should be given a more specific waypoint than the middle of the airfield, such as a terminal or terminal door.

Morgan Hill boundary restored in changeset 125384083.

Huh, I must’ve misclicked or something. Fixed in changeset 125208043.

You can either tag it as highway=proposed proposed=cycleway (only works for highway=*) or with a lifecycle prefix like proposed:highway=cycleway (works for any kind of feature).

Note that proposed features don’t necessarily render in mainstream map styles, mainly because these tags have historically been misused to map very aspirational or nebulous proposals. But that shouldn’t necessarily stopping you from mapping a concrete proposal that has a good chance of becoming reality.

Hi, OpenStreetMap isn’t generally the place to record historic details that are no longer present in some manner. As you’ve noted, these houses are now private property (and one of them apparently takes pains to inform visitors of that). It would be inappropriate to draw attention to these houses as if they’re tourist attractions, let alone tag them as neighborhood boundaries as you’ve done. See osm.wiki/Limitations_on_mapping_private_information for some things to keep in mind as you map private residences.

The Steve Jobs Garage is unquestionably a notable place, but it’s better to stick to the facts: changeset 125002456 downgrades the plot to just a plot and instead tags the garage itself as being listed on the Los Altos historic register. To avoid calling undue attention to the property, I’ve added more details to their neighbors along the street, and I encourage you to add similar detail.

If you’d like to record historical information that’s no longer present on the ground, please consider contributing to OpenHistoricalMap: https://www.openhistoricalmap.org/ It’s just getting off the ground, but there’s a lot of opportunity to geek out about the history of the software industry there.

Hi, access=permit is for situations where the general public is allowed but needs to stop at an office to purchase a pass, typically at a state or national park. When you see a sign that says “Authorized Vehicles Only”, that usually means access=no emergency=designated. This looks like it would be an emergency crossover for police vehicles.

This is an amazing level of detail; thanks for taking the time to catalog all these species and tree numbers. The name tag is intended for the actual name of an individual tree, typically for a famous tree or one that’s dedicated in someone’s memory (which you’re more than welcome to indicate). For these other details, please use the ref and species keys.

For example, osm.org/node/8947755108 would be retagged as:

natural=tree
leaf_type=broadleaved
ref=325
species=Ulmus parvifolia
species:wikidata=Q1074099

If you don’t know the scientific name or Wikidata ID of a species, you can stick the common name in species:en and someone can come along and refine it later.

If a tree has been removed, as in osm.org/node/8943112399 , please refrain from mapping it in OSM, or at least tag it as removed:natural=tree instead of natural=tree, because data consumers won’t be able to understand the “removed” you put in the name.

Better yet, consider helping out with https://www.openhistoricalmap.org/ where historical details are more than welcome. (It’s just getting started, but there’s no harm in adding in some trees as a starting point.)

Hi, these are actually geoglyphs that appear to be advertising a nearby POI. See the discussion in changeset 123447364.

I used the CD:NGI imagery layer, which is the “best” layer for this region. It was taken in 2012, but it’s the only available imagery taken off-season, when these markings would be visible instead of crops.

For now, I reverted this deletion in changeset 124707407, but if you have reason to believe that the markings have been removed since 2012 or know of a better way to tag them, please feel free to fix it again.

For future reference, here’s a recap of all the relations that I’ve fixed that were incompletely reverted by this changeset:

U.S. 2 in changeset 124171132
U.S. 6 in changeset 124155648
U.S. 9 in changeset 124171210
U.S. 10 in changeset 124177930
U.S. 25 in changeset 124176718
U.S. 29 in changeset 124176907
U.S. 33 in changeset 124178051
U.S. 34 in changeset 124178186
U.S. 35 in changeset 124172891
U.S. 41 in changeset 124171800
U.S. 44 in changeset 124157306
U.S. 45 in changeset 124170474
U.S. 52 in changeset 124155180
U.S. 56 in changeset 124179111
U.S. 59 in changeset 124171561
U.S. 60 in changeset 124178687
U.S. 61 in changeset 124157802
U.S. 62 in changeset 124158939

Changeset 104513531 incorrectly conflated U.S. 13 Bus. with U.S. 13. The latter was restored in changeset 124180464.

Changesets 104473758 through 104586385 removed some ways from route relations entirely instead of pushing them down to subrelations. I’ve attempted to add as many as I could find to the subrelations, but some gaps may remain.

Much less importantly, this changeset sorted each superrelation’s members by name or relation ID, whereas it had previously been common to arrange them geographically. I’ve restored the geographical sorting for consistency with other route networks.

Finally, this changeset replaced type=route with type=superroute. In the course of reverting the major issues above, this tag has been changed back to type=route. type=superroute has its adherents, but it generally isn’t used in the U.S., since the distinction makes little sense when the combination of multi-state routes with two or more signposted directions can result in multi-level relation structures. (If anything, the topmost relation is the route per se; everything below it is mere route segments.)

I think this should more or less take care of everything that was broken in changesets 104473758 through 104846286, so you won’t keep getting messages about it from me. :-)

If you need help with anything else relation-wise, please let me know or swing by OSMUS Slack (slack.openstreetmap.us) to chat with the community about it.