@okiewxchaser - after recommending the National Transportation Atlas Database , I’ve realized that it’s a collection of databases. Which of these should we be using? (my guess is NHS, but I want to be sure):
meow!?
They all appear to be derived from the same dataset. A word of caution though, it appears they render a four lane divided highway with only a single line
1 Like
Thanks for getting this started! I moved the U.S.-specific parts of the page to OpenHistoricalMap/Projects/United States/Highways - OpenStreetMap Wiki so it’s less unwieldy. I’ll mention this table to the AARoads Wiki folks, since some of them have also been mapping Interstates around the country.
Should the table also list auxiliary highways, or would that be too much for now? I started by mapping I-275 in Ohio and I-280 in California, but I can shift my focus to the main Interstates for better connectivity.
There might need to be multiple columns related to status. I’ve been making sure to map a given stretch of highway’s entire history, but others may be focusing on present-day coverage as a first pass.
As of right now I want to keep the 2DIs as the primary goal (of course anyone is welcome to map the 3DIs along with their parent routes) and then later evaluate the remaining 3DIs as a second or third phase of the project
Let me think more about status. I somewhat like the idea of having it as a free text field for now as each project and mapper will be different
For those who may not know (I did not!), I believe “2DI” = 2-digit interstate, like I-95, I-80, I-5. “3DI” = 3-digit interstate, like I-280, I-395, I-485, etc.
I agree that having some degree of freedom per mapper is good and I also think have some low-bar of minimum consistency would be good. I think the main questions we need to be able to answer with status are: how should / could it be communicated that the primary mapper of an area is open to others joining in (e.g., mapping same highway in a different state) and what level of consistency we’re setting for the entire project.
Fair point on the status. I added two fields “Current Region” and “Current Time Period”. They should help block off what a mapper is currently working on while leaving the rest of the state and other time periods open to be mapped
Would make sense to import a group roads known to exist in the same slice of time. All the roads would have valid lifecycle date. Mappers could then update the Ihose dates to match the actual lifespan of a particular road segment. This would simplify imports without creating "false: roads.
Each Import could be anchored to major expansion points. Allowing individuals to handle the more complex and more often tricky job of stitching together roads segement that span multiple eras.
I think this is the problem - most data sources afaict are just for the present. I’d love it if we could import a dataset for roads known at a particular point in time.
Is that what you meant?
I’m not sure what you mean here - can you clarify?
I do think this will end up happening regardless of approach, and yes, the stitching together is a labor of love!
@okiewxchaser - as always, thanks for your guidance! Using what I could gather from this thread and the highways project page, I did a test run with I-95 in North Carolina.
Between the road geometries at the NC DOT GIS site and some great info at VA Highways: NCRoads.com Annex,
I was able to get something put together fairly quickly:
Then, I created a tagging section for the project page, using what I could see of yours and @Minh_Nguyen’s edits of ways and relations.
After my test run, I had plenty of n00b questions, which I’ve called out on the wiki:
But… inspired by what I see in Minh’s fine-grain edits, I’d like to get a little more precision into the life(birth?)cycle of I-95 than is offered by the NCRoads.com Annex.
Any advice / critiques / questions about this approach? (@Minh_Nguyen & others, please jump in, too!)
Is this “good enough” and should I move on to other NC highways or farther back in time, to identify roads prior to I-95? Or are we setting a higher / more precise standards bar for each phase of the lifecycle from here?
Again, this didn’t take all that long to create, so I’m looking for a balance of detail and quality to coverage & I’m hoping this discussion will be useful to other mappers who are thinking about joining in.
I think this is a great start! I personally don’t think we need more detail than this until after we have better coverage across the entire country
My personal next move would be mapping US Route 301 to compliment I-95, but I think there is value in moving to other NC interstates as well to create a cohesive network
1 Like
I put a note about this on the project page, but I thought I’d bring it up here, too:
how should we be tagging / linking to AARoads? It seems like this is the primary documentation / additional background / first referral we should be making for getting more information on highway history.
I’ve started with something like:
more_info:1=link to state-specific Interstate AARoads wiki page
more_info:2=link to Interstate-wide AARoads wiki page
but, I could also link to:
more_info:3=link to AARoads' Interstate-Guide page for an Interstate
I love linking to all kinds of sources, but I have to admit 3 separate links to these various AARoads sites might be overkill, especially if there were a page hosted by the state DOT or a separate state historical society page, etc.
Bottom line: I think we should link as tightly to AARoads as possible. The question is: how to do it well!
And… just in case you’ve ever wondered what a highway opening ceremony looks like in the South, here’s footage from a 1963-06-26 opening of a stretch of I-95 on the Virginia / North Carolina border.
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.
1 Like
That’s fair. The auxiliary routes would add quite a bit to the project’s scope at a time when we already have so much to do. Anyways, I-280 is a special case (one of a few in the San Francisco Bay Area) that isn’t really a child of any parent route in practice. At some point, we may want to create similar tables on local pages about individual states or cities to track the major highways there, including major state routes and auxiliary Interstates.
If you really want to micromap, you could tag the opening time of a given stretch of highway. I’ve found some sources that even indicate the times of the ribbon-cutting as opposed to when the roadway opens to traffic. I’ve been tagging the latter in start_date:edtf=*, as a bit of a conceit. Of course, this won’t make a huge difference until we add EDTF to the vector tiles.
I split out a separate “Interstate Highway System” page since the previous “United States highways” page was getting a bit lopsided.
1 Like
My takeaway: ref=* is optional and while users may elect to use this key, they should not have any expectations for any rendering or search result impacts based on this tag. Relations are the primary determinant of member road designation.
My takeaway: all interstates should be tagged with highway=motorway unless they are included on that list, in which case they should be tagged with highway=trunk and highway:source=https://en.wikipedia.org/wiki/List_of_gaps_in_Interstate_Highways#Freeway_gaps
My takeaway: expressway=yes is too mushy to worry about. 
It’s best left for more in-depth highway mappers to clean up later.
Good question… maybe we should either agree to a validation process from the get-go and use this tag, or agree that we’ll figure out any sort of validation after the fact and not use the tag, we’ll figure something out later.
I’d suggest that even if we haven’t done much validation in OHM so far, we haven’t really done a lot of things. We’re too young to draw and precedent from past activity, imo. Maybe we should start?
I think names like “Interstate 74 in Ohio”, “I70, Colorado”, and “I-95 in NC” are all friendlier names for relations that without the state-level information. Plus, this more closely matches the source and reference names (Wikidata, AARoads) as well as matching the process you outline of state-level management of the federal designations.
In cases where there are conventional names, couldn’t that be reflected with an alt_name tag?
Understood - Wikidata is a must-do. Per the above, we should link to state-level articles where available. I think the remaining question is we could/should also link to AARoads. Even if it’s optional, what would be the best way to do this?
Possibly. I’m hedging because that list definitely used to be longer and may have been significantly longer in the 1950s and 1960s.
It’s very mushy, but you’ll know when you need it. You probably won’t need it much if at all for Interstates.
If a route (as opposed to the roadway that carries it) has a conventional name, we should tag it in name=*, as that will more accurately reflect the contemporary reality. Not every state assigns conventional names to routes. If the conventional name was really obscure at the time, then yes, official_name=* or alt_name=* would be more appropriate.
Both Wikipedia and the AARoads Wiki have article naming conventions for consistency’s sake, but we shouldn’t overindex on those conventions on the route relations. After all, we’re tagging places in the Middle East with their names in the local languages, even extinct languages, not the names of their English Wikipedia articles. But the names of chronology relations can be a different story, because those relations are all about historytelling.
If you find constructed names like “Interstate 80 in Colorado” essential for discoverability, that’s a decent argument for putting those in alt_name=*. I think of alt_name=* as essentially a list of synonyms in a thesaurus or the keyword meta tag in HTML. Nominatim has no problem finding an alt_name=*, to the extent that it can handle a number in a name.
By the way, Nominatim is currently unable to find route relations by name. Its maintainer has stated a desire to support route relations but considers it to be infeasible given the constructed names on many of OSM’s route relations and, presumably, the date range suffixes in our route relations. If we can clean up our naming practices around route relations, there might be some hope yet.
1 Like