That site is very nice. I haven’t come across something similar for Ohio that seemed as reliable, so I fell back to diving through newspaper archives for opening ceremonies and the like. I’m also drawing from personal recollection of construction projects I’ve driven through or mapped and remapped in OSM over the years. But I think of this as just getting mapping out of the way that I would’ve done anyways; I don’t view this level of detail as a requirement for mapping highways in OHM.
With my highway mapping so far, I’ve been trying to distinguish between the physical infrastructure and the route designations as much as possible. Otherwise, if we conflate the two concepts, it becomes too tempting to conflate their dates too, which leads to anachronisms on the map. Quite a few of the existing roads and railroads in the Midwest have had this problem; I hope we can chip away at the problem over time.
While I have been tagging ref=* on ways, this is only a placeholder until I get around to creating the route relations. Otherwise, I’d have to create redundant, overlapping ways every time the ref=* changes, which would be a mess. I much prefer the mess of redundant, overlapping route relations separated by time. 
For example, this stretch of freeway carries westbound I-74, I-275, and U.S. 52 (not yet mapped). Westbound I-74 needs two different route relations to describe its evolution over time, independently of the completion dates of its physical roadways, so this particular way is a member of both westbound I-74 relations.
As I mentioned earlier, OSM’s U.S. community has struggled to shake off the legacy practice of way refs, because too many data consumers latched onto them as a shortcut early on. So far, OHM’s renderer doesn’t understand way refs, so we have an opportunity to avoid that sordid history.
tag notes example highway=trunkFEEDBACK NEEDED: when is this used on Interstates? Should we discourage this for less experienced roadmappers? See this part of I-35 expressway=yesFEEDBACK NEEDED: when is this used on Interstates? Should we discourage this for less experienced roadmappers? See this part of I-35
highway=trunk is appropriate for the roads that form the backbone of the state transportation network but aren’t built to the standard of a highway=motorway. One caveat is that what we might consider a substandard freeway today would’ve easily qualified as a state-of-the-art freeway at some point in the past, so I’ve been lenient about applying highway=motorway based on contemporary standards, only up to a point. I’m not going around tagging highway=motorway on just anything that the local press called a “superhighway” at the time.
Presently there are a handful of non-freeway segments within the Interstate network. I wonder if there were more significant ones in the past. expressway=yes is difficult to define, but you can think of it as an almost-freeway: generally but not necessarily limited access, generally but not necessarily divided, generally but not necessarily designed for high speed.
Confusingly for me, in the 1960s, these were officially known as modified expressways in the Cincinnati area, whereas expressways were what engineers would call freeways today. A couple of them continue to be officially named “… Modified Expressway”.
The established convention (from OSM) is that highway=motorway is assumed to be a one-way road unless otherwise specified, while highway=motorway_link/trunk/etc. are assumed to be two-way by default. If you’re mapping just a single way for a road that’s divided in reality, you’ll want to set oneway=no and probably fixme=*.
tag notes example validated=*FEEDBACK NEEDED: is this necessary & if so, is there a better key? ( validate?reviewed?) how do we ensure that all road segments are marked for review? should we add this to relations?
OSM’s TIGER import introduced a similar key, tiger:reviewed=*, but it didn’t really pan out. Everyone has a different idea of what it means to “review” something based on the aspects they care about most. Even the most diligent mapper may only review one end of a road but not the whole thing end-to-end. I guess it’s a question of how we want to track “validation” – something we barely do at all in OHM so far.
tag notes example wikidata=*use the data item Q-code
FEEDBACK NEEDED: in cases where there is a Wikidata item for the Interstate (e.g., I-40) and a Wikidata item for the Interstate in a state (e.g., I-40 in North Carolina), which Wikidata item should be used?Q94967
It depends on whether the relation represents the route just within a single state or the whole logical route across states. In the real world, a route such as I-80 or U.S. 50 is technically a collection of identically numbered routes developed by the respective DOTs and coordinated by AASHTO. With three-digit auxiliary Interstates, these numbers can repeat on completely unrelated routes. I’ve been focusing on creating relations for state-level routes, which would naturally link to the state-level Wikidata items.
tag notes example name=*FEEDBACK NEEDED: do we need these; are they optional where people would like to name them; this is different from named highways, but where should those be named? OSM sometimes uses description=* for this purpose (see: 2297413), but I (jeffmeyer) feel using name=* provides a better user experience in search results.
I-95 in NC
There are feelings about this in OSM. Recently, these systematic names were systematically moved from name=* to description=*:
I have been putting names like “Interstate 74 in Ohio” on chronology relations, because in general, the names of chronology relations are less about a contemporary name and more about what someone would call the history of something in, say, an encyclopedia article. However, I haven’t been copying these names onto route relations, because some routes have conventional names that may be important to distinguish from these systematic names. This will be even more apparent as we go back in time to when route numbering was less common.
Contrary to the post above, Nominatim isn’t very good at searching for anything by number and doesn’t index chronology relations, but perhaps a more generalized approach to search will eventually pick up where Nominatim leaves off.
tag notes example start_date=*FEEDBACK NEEDED: are these for the entire highway (e.g. all of I-95?) or just for the segment / state stretch (e.g. I-95 in NC?)
The start date of a route relation should match the start date of the first segment that opened, or the date when the route number was first assigned, whichever comes last. In other words, don’t include roadways under construction in the route relation, and don’t include a roadway in the route relation before the time when it was assigned. This will sometimes require creating redundant relations for different time periods, joined by a chronology relation.
tag notes example members FEEDBACK NEEDED: do these need to be continuous; sorted? roles? both directions in same relation or separated by direction? e.g. name=I-95 Northbound in NC? how do we feel about the roleforward?role={north, south, east, west}should be used only when those cardinal directions are used as part of an official designation, e.g. U.S. 301 North
This is a complex topic; I recommend reading “Route directions” on the wiki. In particular, I’ve been following the “One relation per direction per leg (per time period)” method, if only because I know it’ll be difficult for me to refactor the relations later on in iD. This approach doesn’t use roles at all, but it does require nesting relations pretty deeply. The other approaches are valid, with some downsides. If you use roles, then you forego some detail. For example, you can only have one role per member, but sometimes a route only goes backwards along a two-way street, to go northbound.
Cardinal directions are used on almost every route at the federal and state levels, and often at the local level too. There are some exceptions – even then, I think it’s fine to model the directions as separate relations and group them together in a route superrelation. However, if you don’t have the patience for distinguishing the cardinal directions, don’t worry about it just yet.
The OSM community feels very strongly about route member sorting. There isn’t a very strong technical justification for it, other than tidiness. It is important for disambiguating routes that backtrack or loop around, but these cases are exceptionally rare on highway routes. As an iD user, I just rely on iD to sort the members automatically. However, some of my route relations include ways representing the same road in different time periods. These non-coexisting members are a shortcut to avoid having to create lots of subtly varying route relations in a chronology. The downside is that they can’t really be sorted logically, but I’m choosing not to worry about that minor detail right now.
As an AARoads Wiki contributor, I’d prefer that we link to Wikidata, which can link to the AARoads Wiki in turn via the AARoads Wiki article ID (P12052) property. I’m working on systematically adding these links from Wikidata to the AARoads Wiki. This will avoid duplicating work, especially since the AARoads community is in the process of revising some article naming practices it inherited from the English Wikipedia. There’s already an extension to dynamically embed previews of Wikidata items on the website; we could integrate it into the website’s inspector code and trivially extend it to link to other sources, such as the AARoads Wiki.
If you use the AARoads Wiki as a source, you could use the normal source tags, but consider linking to a permalink or the upstream sources that the AARoads Wiki cites.