Awesome! If you have any questions or just feel like geeking out over this stuff, some of us from the Cincinnati area hang out in OSMUS Slack’s #local-ohio channel, and some of us are also on the OSM World Discord server.

I added the chains on either end based on Bing Streetside imagery, which was taken during the day: the northern entrance was roped off, while the southern entrance was not (just the posts were visible). Only the northern one was tagged https://wiki.openstreetmap.org/wiki/Tag:access=private, preventing the parking lot from being used as a cut-through. This old imagery isn’t contradicted by newer aerial imagery. If I’m not mistaken, https://wiki.openstreetmap.org/wiki/Tag:barrier=chain is assumed to be passable unless otherwise specified (just like https://wiki.openstreetmap.org/wiki/Tag:barrier=gate). Some barrier values may have implied access restrictions, like block, but explicit access tags are a good idea to avoid surprises.

It looks like example 10 is intended to point out that the parking lot entrance should connect to Berryhill Street despite Berryhill approaching Derry Street at a sharp angle. It does require introducing a bit of a kink in Berryhill, which could cause an unsophisticated router to announce a standard right turn from Derry onto Berryhill rather than a sharp turn, based on a literal calculation of the turning angle. Fortunately, a half-decent router would classify the turn more holistically, by calculating the angle based on a point along Berryhill farther away from the intersection (great diagrams in that issue). So it would still be a sharp right turn. If it didn’t do that, the router would incorrectly classify all sorts of intersections in OSM, like this ostensible sharp right turn from Fox Street to Walnut Street.

Most of those segments not supposed to have U-turns, nor left across solid yellow.

Different local communities have very different, sometimes very strong preferences as to whether implicit U-turn restrictions should be mapped using relations. In this case in Ohio, you probably won’t get told off for adding them, but it’s also not a high priority because routers are very unlikely to suggest unlawfully pulling a Uey. (Also, most if not all OSM-based routers only suggest U-turns along divided roads, aka dual carriageways, because of uncertainty about OSM’s coverage of U-turn restrictions. Chicken, meet egg.)

Turning left at all these points is technically legal. Ohio’s relevant laws are lax compared to some other states like New York when it comes to double-yellow lines. But the gas station entrance is clearly shaped to discourage left turns, so a turn restriction there wouldn’t be unreasonable.

You “7 correct” is looks incorrect. Right turning turning slip lane starts way earlier.

Can’t tell if you’re being ironic, but just in case: that slip lane as mapped begins close to where the physical separation begins. The lane may begin way earlier, but that’s why these ways have turn:lanes:forward and change:lanes:forward tags. Otherwise, the whole intersection would be a mess of left-turning link roads.

a halfway competent router will collapse the turn instructions in this case.

Exactly, routers can collapse staggered intersections for the purpose of guidance instructions. The threshold for collapsing an intersection may not be perfect, but ideally it would depend on the mode of transportation, because a pedestrian and a motorist would naturally disagree about whether an intersection of a certain size is staggered or not.

Moreover, a router might need to give an affirmative “continue straight ahead” instruction, rather than staying silent as it would for a better aligned intersection. For example, the turn lane signs and road markings at this intersection point straight ahead, but if you’re behind the wheel with barely a line of sight to the other side and hear nothing from the application, you might wonder whether you’ve missed a turn or the application is buggy. This intersection even has a fanciful turn lane diagram to tell motorists to swerve right then left. (I’ve been collecting sign examples on the wiki.)

These nuances get lost if mappers go out of their way to contort roads to line up at these intersections. That said, it’s a matter of degree: at a small enough offset, staggering the intersection in the database would be pedantic even from a pedestrian’s point of view. I’ve searched traffic engineering papers for answers about where to draw the line, so to speak, but I haven’t found anything that conclusively addresses this question. Apparently 50 meters (164½ feet) is widely considered the minimum distance for two distinct T-intersections (China, UK), but there’s plenty of gray area within that distance.

The TIGER import gets an honorable mention here because it represented staggered intersections in the worst possible way: as a tiny, unnamed residential way connecting the two phases of the intersection, interrupting the continuous street. Many of these ways remain undertagged in OSM all these years later because they’re so hard to spot. Here’s a crude example Overpass query for this and similar issues across Indiana.

These paths should be removed from OSM. If remote mappers keep restoring them, it may be worthwhile to leave the line tagged with only a note.

This sounds like another potential use case for the not: lifecycle prefix. But a note is good too, because not everyone would know to look for not:highway in the way’s raw tags.

Tag as https://wiki.openstreetmap.org/wiki/Tag:highway=path + https://wiki.openstreetmap.org/wiki/Tag:access=nò + informal=yes where found, but ideally they should not have been added in the first place. There are arguments to be made for using a different tag than path`, but none exists as of yet. Deleting these from OSM is futile as locals or remote mappers will inevitably add them back.

There have been some experiments with explicitly tagging disputes, but they tend to be related to boundaries or names. A trail disputed to be in existence could be tagged https://wiki.openstreetmap.org/wiki/Tag:disputed=yes, but unlike with boundaries, data consumers probably aren’t expecting to add a special case for this tag on any arbitrary feature, so maybe a disputed: lifecycle prefix would be more appropriate.

It’s been wonderful to see Oxford shaping up over the past year, and now I know who to thank! Looking forward to your continued progress toward a complete map!

Very cool! To raise awareness about this resource and make it even easier to use, consider contributing it to the imagery indices that iD and JOSM use to display their lists of available imagery.

giving drivers more time to get in the right lane without breaking the law

I think you’re assuming that routers time announcements based on the location of the https://wiki.openstreetmap.org/wiki/Tag:highway=motorway_junction node, which is true of the current crop of routers. But that’s an argument for getting routers to account for the change (change:lanes) key when timing these announcements. As long as you place the junction node at the beginning of the lane change restriction, it isn’t possible to map change:lanes (or even turn:lanes) accurately, and it ends up being an exception to the physical separation rule.

That’s quite a difficult sign to understand. I wonder how many truck drivers can do the math while driving past that sign…

I guess the state expects truck drivers to know the current load as a percentage of the general legal load limit for their vehicle configuration. It’s a tall order for a router, though.

But I would propose to make a key source:maxweight in analogy to source:maxspeed. We use that source:maxspeed tag to encode which sign is used. So if legislation changes (and updates default rural or urban speeds), all roads with wrong maxspeeds can be found.

I.e. something like https://wiki.openstreetmap.org/wiki/Tag:source:maxweight=US:R12-H17(-10%,Feb 1-May 15)

I added https://wiki.openstreetmap.org/wiki/Tag:source:maxweight=sign, but I refrained from putting the extended traffic_sign syntax in the source:maxweight key, because tag values that require string processing are more difficult to consume or query for. Instead, I added https://wiki.openstreetmap.org/wiki/Tag:traffic_sign=US:OH:R12-H17 nodes and tagged them with start_date and maxweight:relative, which will make these cases much easier to find when the relevant law changes. (I prefixed the sign code with US:OH:, not just US:, because this sign is specific to Ohio’s statewide sign standard rather than the national standard.)

The percentage-based signs I’ve encountered so far are problematic because they’re obsolete signs that technically don’t correspond to any current standard code. However, I’m taking advantage of the fact that they’re very similar to R12-H17, except with a start date instead of a range of days out of the year.

The next time the law changes, we can use this Sophox query to find weight limits to update. (This query only considers year-round limits like the ones I encountered, but Sophox can parse more complex conditional restrictions, such as in the case of a seasonal R12-H17 sign.)

I also don’t agree with your point on documentation. This new feature is an alternative to Meetup. Meetup has about 140,000 organizers (over 25 million users). I doubt these people needed documentation. Ideally the feature is so easy it doesn’t need documentation.

Also, if you’re worried about commercial interests, then Microcosm should be a welcome alternative to Meetup, which charges organizers a monthly fee and has also begun charging many organizers per RSVP. I’m subscribed to one local OSM-themed Meetup that has been on the verge of disbanding for a couple years because of these fees.

Any of these choices make the non-English versions of the website fundamentally different to the English language. This would be a novelty on the website and as such a political statement.

Just to add one data point: as a translator in Vietnamese, a very different language, I’ve taken all three approaches you’ve mentioned at various times:

• “Node” is normally “nút”, but I translate it as “nốt” (as in music note) because “nút” also means “button”, which would be more likely to create ambiguity. I’ve replaced one metaphor for another.
• There is no good translation for “feature” or “element” that still sounds like it could refer to a part of the map, so I translate both as “đối tượng” (object).
• I leave “OpenStreetMap” alone instead of translating it to the unwieldy “BảnĐồĐườngSáMở”, even if the latter is more pronounceable. Even if I knew why “iD” is called that, I’m not sure I’d translate it either.

None of these choices is perfect, but translation is always a tradeoff among competing concerns, one of which is memorability. I don’t think it would be a huge barrier for users to discover what “Microcosm” means or how “Thế giới Vi mô” (micro-world) works in practice versus juggling a descriptive moniker like “Bộ quản lý Cộng đồng Địa phương” (local community manager) in prose and still having to figure out how it works in practice. Sometimes a term of art is the best solution to a feature that defies succinct explanation. That said, there’s always the possibility of distinguishing between a code name and a UI name. After all, the UI here labels a “Standard” style instead of “Mapnik” or “openstreetmap-carto”.

It looks like the project’s issue tracker is taking off. If you have naming ideas, perhaps they could be explored in more detail there.

Looking forward to your talk!

(I had no idea you could style a link like a button inside kramdown, neat!)

Unfortunately, as far as I’m aware, no OSM-based router is currently capable of “rewriting” intersecting barrier ways onto the node that joins the barrier way to the road way.

Amazon has been tagging access tags on road ways – even to the point of tagging every driveway as private. But tagging access restrictions on barrier nodes is useful. For one thing, it’s quite common in the U.S. for an impassable gate to separate two roads that otherwise are otherwise passable. Communities often install such gates as traffic calming measures.

I guess the question is whether delivery is mutually exclusive of the other access values. If we assume residents are authorized to use any https://wiki.openstreetmap.org/wiki/Tag:access=delivery entrance, then we’d need an additional tag to clarify delivery-only entrances that residents are not supposed to use. A resident won’t expect to be routed through it, because it won’t get unlocked for them.

By the way, delivery is also used in other situations besides gated residential complexes, and access is also used on https://wiki.openstreetmap.org/wiki/Tag:amenity=parking. For example, I’ve mapped plenty of light-industrial facilities with three entrances: a driveway leads to the loading dock has a “Deliveries Only” sign, an access road leading to a parking lot has an “Employees Only” sign, and another access road leads to a smaller parking lot has a “Visitors Only” sign.

For example, it may be possible for pedestrians to walk around a gate. Unless sidewalks have been mapped separately, it may be necessary to add foot=yes in that case.

In case we get the information on non-resident pedestrians to walk around, we can add “foot=yes”. @Minh Nguyen Please confirm if there are any challenges using this tag.

Yes, https://wiki.openstreetmap.org/wiki/Tag:foot=yes is appropriate if pedestrians can walk past the gate. If the general public is blocked from entering by foot or car, then the usual https://wiki.openstreetmap.org/wiki/Tag:access=private tag suffices.

Not in all scenarios. In certain cases we are coming across situations where only delivery agents were allowed to travel through. In such situations we can add “access=delivery; private”. Let me know if this is not possible.

https://wiki.openstreetmap.org/wiki/Tag:access=delivery would be appropriate for gates that admit only delivery people. https://wiki.openstreetmap.org/wiki/Tag:access=private;delivery and https://wiki.openstreetmap.org/wiki/Tag:access=delivery;private would imply the delivery+residents case I mentioned above. However, I’m unsure if the most popular OSRM-powered routers support multiple values in access. For example, it doesn’t look like OSRM recognizes semicolon-delimited values this way (#1571, #2643). In my opinion, it’s a sensible tagging scheme, but https://wiki.openstreetmap.org/wiki/Tag:access=private plus https://wiki.openstreetmap.org/wiki/Tag:access:delivery=designated may be safer. You might want to test out either approach first to see if it gives you the desired behavior.

Thank you for prioritizing gate access restrictions! This is an oft-overlooked detail (among mappers in general, not just your team). It matters a great deal for accurate routing, not only for to-the-door routing but also to avoid situations where a user winds up in the wrong neighborhood, with the right neighborhood taunting them through a locked gate. 😬

As you add these access restrictions, remember that the access tag can affect multiple modes of transportation, not just driving. For example, it may be possible for pedestrians to walk around a gate. Unless sidewalks have been mapped separately, it may be necessary to add https://wiki.openstreetmap.org/wiki/Tag:foot=yes in that case.

How do you plan to tag a gate at the front of a gated residential community (common in Florida) that allows both residents and delivery vehicles to enter but not the general public?

Doh! I knew I was going to copy-pasta something! Sorry, about that, now corrected.

The USGS just redesigned their website; unfortunately, it looks like the Geonames domestic names search engine is offline. Otherwise, you’d be able to search for individual features to get an idea for the kinds of sources used in Utah.

The GNIS search engine is back online. For example, https://wiki.openstreetmap.org/wiki/Tag:gnis:id=1449908 yields an entry from 1989 with this citation:

Real Estate Atlas of Salt Lake County, Utah. (See UT-T27)

Most of the rural places in your query come from USGS topo maps, though:

U.S. Geological Survey. Geographic Names Phase I data compilation (1976-1981). 31-Dec-1981. Primarily from U.S. Geological Survey 1:24,000-scale topographic maps (or 1:25K, Puerto Rico 1:20K) and from U.S. Board on Geographic Names files. In some instances, from 1:62,500 scale or 1:250,000 scale maps.

There’s some previous discussion in this diary entry from 2015.

In urban and suburban areas, these hamlets are more often then not neighborhoods (https://wiki.openstreetmap.org/wiki/Tag:place=neighbourhood or https://wiki.openstreetmap.org/wiki/Tag:place=suburb), subdivisions (https://wiki.openstreetmap.org/wiki/Tag:landuse=residential), apartment complexes (https://wiki.openstreetmap.org/wiki/Tag:landuse=residential https://wiki.openstreetmap.org/wiki/Tag:residential=apartments), or mobile home parks (https://wiki.openstreetmap.org/wiki/Tag:landuse=residential https://wiki.openstreetmap.org/wiki/Tag:residential=mobile).

The patterns do vary from state to state, because GNIS uses different sources in each state and for different kinds of POIs. Some of these sources are over a century old; others are quite recent. The USGS just redesigned their website; unfortunately, it looks like the Geonames domestic names search engine is offline. Otherwise, you’d be able to search for individual features to get an idea for the kinds of sources used in Utah.