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 highway=path + 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 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 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 source:maxweight=US:R12-H17(-10%,Feb 1-May 15)

I added 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 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 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 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, 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 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.

access=delivery would be appropriate for gates that admit only delivery people. access=private;delivery and 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 access=private plus 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 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, 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 (place=neighbourhood or place=suburb), subdivisions (landuse=residential), apartment complexes (landuse=residential residential=apartments), or mobile home parks (landuse=residential 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.

Could you do a post talking through the process of locating other villages suitable for this treatment? I tried exploring the NARA archive but couldn’t make much headway.

The vast majority of NRHP properties are individual buildings, which are also worth mapping, but if you want a good concentration of buildings to map, look for entries with “historic district” in the name. Many, but not all, of these historic districts were long ago imported from GNIS as leisure=park points. (The Oldenburg Historic District is missing from GNIS, so it wasn’t imported.)

If you’re looking for a particular historic district but can’t find it in the NARA archives, these pages list some alternative places to look. (Some of the linked sites have temporarily gone down due to the federal government shutdown.)

Also, it would be great to hear more details about how to translate the written architecture descriptions into 3D building tags.

The descriptions aren’t standardized; they’ll vary from submission to submission based on the author. In the Oldenburg submission, many of the terms are also found in the simple 3D buildings specification or F4’s mapping guide, for example:

• “Gable roof” is roof:shape=gabled
• “Hipped roof” is roof:shape=hipped
• “Gambrel roof” is roof:shape=gambrel
• “Salt box roof” is roof:shape=saltbox

(One of the spires in Oldenburg is topped by a German-style onion dome, but F4 apparently doesn’t render roof:shape=onion.)

There are lots of details about dormers and gables. This helpful diagram appears in the specification:

Some other assorted notes:

• “Ranch style” implies a single-story house.
• A “lean-to” is a room-sized extension to the house, often a sunroom.
• “Frame” means wooden frame, but many of the buildings had brick nogging, which meant wall:material=wood;brick. I don’t think renderers support that value yet.
• I was unsure how to tag aluminum siding, which was common on “non-contributing intrusions” – more modern, historically insignificant buildings that happened to lie within the historic district. wall:material=metal would understandably lead renderers to pick a shiny material for the building’s faces, but aluminum siding is usually covered with matte paint.
• As far as I can tell, there aren’t established tags for windows (such as transoms), decorative elements on façades (such as lintels and cornices), or foundation materials. building:material can indicate interior structural materials, but then you have to make sure to tag wall:material and roof:material as well.

Hope this helps!

The wiki’s Ohio page suggests highway=trunk based on some physical characteristics, but I think it would be more convenient to say that each of Ohio’s trunks meets one of the following definitions:

1. Urban expressways built before construction began on the Interstate system and never upgraded to freeway standards (e.g., due to space and funding constraints). The quintessential example in Cincinnati is Columbia Parkway, a four-lane, undivided, 45-mph expressway.
2. Rural highways somewhere along the decades-long process of being brought up to freeway standards, starting with limited access along rural segments and freeway bypasses around major towns (which are tagged highway=motorway). Examples in Southern Ohio include US 23, US 35, and SR 32.

Unlike a lot of the trunk definitions I’ve seen so far, these definitions are intentionally flexible about grade separations, speed limits, lane counts, or length. Every urban expressway in #1 was built to a different set of (now obsolete) standards and every rural highway in #2 is in a different stage of development, yet all of them are essentially stand-ins for freeways.

Despite long stretches of simple two-lane roadway, the AA Highway in Kentucky satisfies #2; I think that would better meet the needs of map users in that rural area than any strict definition based on physical characteristics. This makes me think these definitions might be flexible enough for other parts of the country too. However, one challenge is that they require local knowledge – a bit of historical context beyond what you could necessarily glean just by driving down the road.

Just discovered the lanes:both_ways and turn:lanes:both_ways tags over the weekend – this is much better than cent{er,re}_turn_lane. 👍

The OSM mailing lists are notoriously hard to search.

It used to be a lot easier when Gmane’s Web interface was still around. If you use a newsreader like Thunderbird, you can subscribe to gmane.comp.gis.openstreetmap.region.us and search threads using the built-in search function.