Changeset 70665554 had eviscerated this relation by mistake, leaving just one of the members in tact. I’ve reverted that changeset and this one in changeset 111940282 to restore the full 3D building.

Hi, what you deleted were actually the details that allow some maps to show the St. Peter in Chains building in 3D. The editor you were using didn’t recognize 3D building parts at the time, so I’m sure it looked like a mess, but it’s better now. I’ve undone your changes in changeset 111940282. In a short while, you’ll be able to see what it looks like in F4Map for example:

https://demo.f4map.com/#lat=39.1035912&lon=-84.5191434&zoom=19

Some of these may be good candidates for tagging as Driveway (service=driveway) or Alley (service=alley), though a plain Service Road (highway=service) would be appropriate for shared driveways, at least until a more specific tag for them arises.

The access=* key is intended for a legal access restriction, such as one that would be established by posting a No Trespassing sign. The shared driveways aren’t public roads in the sense that they aren’t publicly owned, but if for example a delivery vehicle can go there, then it isn’t really the same as having a No Trespassing sign.

The Mapbox Streets source assigns its “street_limited” class to roads with access=private among other things. But it also has a “service” class, corresponding to the highway=service tag, that’s intended for public and private driveways in general: https://docs.mapbox.com/vector-tiles/reference/mapbox-streets-v8/#--road---class-text If the particular map you’re using makes the “service” class look too much like a through street, that could be a bug on the application’s part rather than a data issue.

In any case, kudos for the attention you’re paying to the quality of the road network as you work towards your goal. In case you’re interested, the local volunteer mapping community meets online every other week to chat and learn about OSM: https://www.meetup.com/Code-for-San-Jose/ You can also connect with other mappers who run all the streets on OSMUS Slack: https://slack.openstreetmap.us/

You’re absolutely correct in using access=private on driveways that have gates or no trespassing signs. I was just unsure about your intent because some of the driveways didn’t appear to have gates mapped; I didn’t know if you had intended to tag all driveways as access=private on the basis of their ownership.

Routers already more or less assume access=destination on driveways by default, by penalizing them heavily and not allowing them to be used as cut-throughs, so it’s OK to leave the access key blank in cases where there’s nothing explicitly preventing access.

Hi, thanks for taking the time to detail these driveways and shared driveways, especially those gates. In case you aren’t aware, the access=private tag is specifically about restrictions on who may enter or pass through a property. There’s a different tag, ownership=private, for indicating that a property is privately owned: osm.wiki/Key:ownership . There isn’t a built-in field for ownership=private, but you can add it in the Tags section.

Hi, I changed this stretch of the 101 back to a motorway because signs at the Monterey St. on-ramp say “Freeway Entrance”.

Bicycles are sometimes allowed on Interstates in California. (Notably, a large stretch of I-280 in San Mateo Co. allows bicycles.) The roadways in question already have bicycle=yes tags to indicate that bicycles are allowed. If you’re seeing different behavior from a routing engine, it may be due to a bug in that routing engine.

Hi, you spotted a very outdated line on the wiki that was added back in 2009, before the U.S. community had really coalesced around any best practices for road classification. I think it just got overlooked in the years since. I’m sorry it wound up causing confusion.

In general, a state DOT’s functional classification system can be a useful starting point for road classification in OSM. However, it needs to be taken with a grain of salt, in part because the internationally developed highway=* key has values that don’t align with HFCS.

The longstanding U.S. standard for OSM road classification isn’t strictly tied to any DOT classifications: osm.wiki/United_States/Road_classification . (You may be interested in a recent proposal to refresh the standard: osm.wiki/United_States/Highway_classification .) There’s also a separate key, osm.wiki/Key:HFCS , that allows you to indicate the functional classification regardless of any other considerations.

Thanks for these updates! By the way, it isn’t quite up-to-date enough to show the new elementary school coming in, but the KyFromAbove 2020 imagery is now available in the sidebar and is a little bit newer than the Bing imagery you were looking at. It might be handy for other updates you make in the area.

These destinations are inaccurate. Not every green sign should be recorded in the destination key; some of them should’ve been tagged as destination:symbol=train_station.

Destinations on freeways in most of San José have already been reviewed many times for accuracy. Minor mistakes or outdated information is always possible, but before making drastic changes, consider reaching out to the local community to double-check anything that looks amiss, in case there’s any context that isn’t apparent from the imagery you’re working with. Thank you.

I belatedly realized the flagpole in Washington is on private property. osm.org/changeset/109721756 adds the flagpole in front of the embassy (still presumably flying the U.S.-recognized flag, designed in 2013).

Please follow the links to https://www.wikidata.org/wiki/Q108111555 and https://www.wikidata.org/wiki/Q30747910 . This change merely clarifies that, whatever happened in Afghanistan today, the flags in Washington and New York represent the internationally recognized government.

FYI, this changeset somehow removed much of the U.S. 278 route relation, and changeset 63079505 subsequently created a redundant relation for U.S. 278 that also had large gaps. I think I fixed the issue in changesets 109072963, 109075864, and 109077198, but if you had intended to make any changes to this route relation in this changeset, I may’ve inadvertently blown them away.

FYI, this changeset somehow created a redundant relation for U.S. 278 that had large gaps, possibly based on a relation that was broken in changeset 62564979. I think I fixed the issue in changesets 109072963, 109075864, and 109077198, but if you had intended to make any changes to this route relation in this changeset, I may’ve inadvertently blown them away.

Changeset 109071854 restores the full U.S. 31 relation.

(Embarrassingly, I miscounted the number of boundaries above, but you get the idea.)

Take a look at the syntax that the Overpass turbo query wizard generates for the “in” operator <osm.wiki/Overpass_turbo/Wizard#Location_Filters> or, more directly for JOSM, the area filter in the raw query language <osm.wiki/Overpass_API/Overpass_QL#By_area_.28area.29>.

The contiguous U.S. has 51 state-level administrative boundaries to query within. If you prefer, you could batch up a few of the more compact states. This is quite a reasonable alternative to either extreme of a single changeset or thousands of them.

If the ramps are to remain highway=motorway_link, then that classification shouldn’t arbitrarily end at the foot of the flyover bridges. If the railroad weren’t there to require a bridge in the eastbound direction, I’m guessing you wouldn’t’ve ended the ramp at exactly that spot.

In lieu of a better answer, changeset 108716632 moves the start of both ramps to where the 0 mile marker for SR-201 is visible going in the westbound direction, opposite to the crash barrier in the median. There isn’t a corresponding mile marker in the eastbound direction, just a reassurance marker a little further to the east, but I’m assuming UDOT would consider the main road to start at around the same spot going in either direction.

Some state DOTs publish straight-line diagrams that take the guesswork out of this exercise, but at least we’re lucky to have street-level imagery here.

Hi, is the temporary turn restriction still in effect, or can osm.org/relation/10279464 be deleted now?

Hi Yulia, no worries, I recognize that it’s a confusing situation for mappers. This particular situation was harmless, but I wanted to make sure your team was aware of the distinction in case there are situations where similar arrows elsewhere would produce misleading guidance for users.

Hi, these are wrong-way arrows, not straight turn lane indications. See osm.wiki/Key:turn#Identifying_a_turn_indication . The example on the page shows a different style of arrow, but Caltrans sometimes uses this style of arrow for wrong-way arrows too.