I am trying to add some roads in my town to OHM. Obviously I understand how to add the roads themselves, but I am unsure what is the best way to deal with their evolution. I am trying to represent the road numbers, which have changed several times. In addition, the classification of certain roads has also changed throughout, with the most recent being in 2007 with the opening of the town’s bypass. How should I represent these changes on the map?
Good question. This is a general issue with any secondary attribute of a feature, particularly noticeable to an experienced OSM mapper who would normally load up a feature with as many secondary attributes as possible. It’s an acute problem for roads, because the primary feature tag’s value is an importance-based classification that can change even if the road itself doesn’t physically change.
I don’t think we have a perfectly satisfactory answer yet, but here are two approaches that I’ve experimented with:
- Map each stage in the road’s evolution as a separate way (either overlapping or slightly offset). For example, this street overlaps with two other streets representing different time periods. iD’s validator will warn you if the streets overlap during the same time period.
- Map just one road geometry but add it to multiple route relations. For example, this highway is a member of four route relations, each representing one of the stages of the route’s evolution. In turn, the route relations are grouped in a chronology relation so it’s easier to keep track of them. This approach is more relevant for numbered highway routes than for ordinary city streets, though there’s been some work toward supporting a street relation type in the renderer.
Long ago, there was a proposal to introduce a “datespec” syntax as part of the key, so that you could reuse the same element even as individual attributes of the feature change at different times. Some mappers continue to use this syntax in OSM, especially for signposted former names of streets and buildings. However, it has no clear path to support in any software, because any kind of freeform syntax would greatly complicate a typical database schema. That isn’t a problem for OSM, where historical information about a feature is trivia, more or less, but it’s a bigger problem for OHM, which needs to visualize and analyze historical data.
Multilinestring relations have also been floated as a possible solution, similar to route relations but more general. But this is a geometry type, analogous to multipolygon relations, so it could be confusing if a roadway is part of multiple multilinestring relations and each one tracks only one attribute about the feature.
My opinion:
- Create the different
route=roadinstead of usingref=, which would simply be a mess when there are many concurrency, or they changed many times. You would need theroute=roadto obtain the whole thing easily, compared to parsing for theref=in a certain timeframe across a large area and long timespan (with many objects). - Ultimately, I recommend changing the feature to a single generic eg
highway=roadto solve this, avoid all the=*_linkalongside its limitations (crudely and arbitarily confined to the highest class, and missing=unclassified,=residential,=service), and be consistent with=pathandrailway=. In other countries, there is the worse yet more interesting topic of roads gaining or losing legal=motorwaystatus, that would necessitate even more redrawing if the situation isn’t improved. As for the attribute to be used to replace the classification, there appeared to be Key:class - OpenStreetMap Wiki in OSM that OHM can pick up. It can be stored in=multilinestringto start with.
route=road and type=street proper only solve ref= and name= respectively. They don’t deal with other attributes. A named “street” can change between different classifications, and even be a =path or =steps that vehicles can’t physically travel on in some sections.
In the few times I helped with the local OHM editing (busy enough with OSM), for the time being, I kept the highway= the same when the geometry doesn’t change. If it physically changes (widened, realigned, etc) together, then it is convenient to draw a new line as a different highway= classification.
I have been using the relation method to add road numbers. However, I do not know how I should handle realignments. Do I need to make a new relation every time a bend is straightened? This could get rather annoying and likely be less convenient than tagging each way with the ref.
I suppose that would be the most correct approach, but I’ve seen rail mappers often handle the same situation by including both alignments in the same route relation. Technically, this makes the route relation nonlinear – except that only one side of any fork would exist at a given time.
It’s not difficult by using JOSM’s “duplicate relation”. This is less worse than drawing a new line every time when only the ref= changes. You will end up with many overlapping segments. Then there are other attributes change eg name= commonly.
Don’t forget in theory, there will be other =route of =bus and =bicycle eventually. They have to be moved to the new highway= together.
Even it only changes only once, the section can be very long, when entire towns are bypassed or rerouted. Are you going to duplicate that too?
Yeah, I would always create a new relation for major realignments, town bypasses etc. It’s only minor realignments (straightening a bend etc.) that I’d consider including in the same relation as the original alignment.
@Minh_Nguyen, it appears our approaches to highway relations differ somewhat, and I’m wondering which is preferable. Highway 152 contains ways which belong to several relations, each with a different time span. But, I have been including only segments active only during each time span in the way’s parent route relation.
About a year ago, I mapped US-24 through eastern Colorado. For that route, each time-spanning relation contains only the ways active only during that time. All of these have been lumped together into a single chronology. Using your approach, I believe the two-lane stretch of US-24 between Calhan and Limon for example would belong to 13 different US-24 relations (plus one for the former designation, US-40S). Conceivably, some segments of some highways could belong to many more such relations. See Relation: US 24 (CO) (2738275) | OpenHistoricalMap
Should the entire highway as it was at that time be included in every relation? Or should only those segments active only during the relation’s time span be included? Or a hybrid approach, perhaps longer route relations, but limited to a county, state or major long-distance portion of the route?
The California State Route 152 relation was my experiment in modeling the route as pedantically as possible. But I recognize that it becomes utterly impractical for long-distance routes.
If you choose to segment the route relations by time period, then these relations should be joined together in a series of route superrelations that represent temporally consistent combinations of them, and those can be joined together by a chronology relation. Otherwise, I don’t think it would be possible to point to any element in the database as a representation of the entire route in a given time period.
Even in OSM, U.S. Route and Interstate route relations are segmented by state, because they’re technically collections of routes developed by the respective DOTs and coordinated by AASHTO. The per-state route relations are then bound into a route superrelation.
@Minh_Nguyen, Based on your comments and the California 152 example, it seems a chronology relation viewer should be able to select one entry and only one entry that corresponds to the desired time period, and that selection should provide a time-consistent depiction within the scope of the chronology (e.g. state, country…).
That being the case, revisions of the US-24 Colorado relations is now on my agenda. Then, perhaps experiment with extending to another state…
1 Like
I’ve updated Colorado US-24 relations and chronology based in part on this forum and on the CA-152 example. There is now a superroute for each time span and those are in a new chronology relation. Mapping is mostly complete from Kansas to Minturn (west of Vail). The area around historic Camp Hale needs some work and the segment from Minturn to Grand Junction is not yet in place.
Feel free to check it out.
1 Like
Oh, you’ve structured this more deeply than I would’ve anticipated. Do I understand correctly that each of these superroutes represents the entirety of US-24 during a given time period, while each of its member route relations represents a section of the route that shares the same history? What I normally do is skip the subrelations and flatten them all into a single level of route relations:
- US-24
chronologyrelation- US-24 from 1961 to 1969
routerelation- West Colorado Avenue
highwayway
- West Colorado Avenue
- US-24 from 1961 to 1969
That way, I can add an additional level for westbound versus eastbound, handy for the freeways that I more frequently map:
- US-24
chronologyrelation- US-24 from 1961 to 1969
routerelation- Westbound US-24 from 1961 to 1969
routerelation- West Colorado Avenue
highwayway
- West Colorado Avenue
- Eastbound US-24 from 1961 to 1969
routerelation- West Colorado Avenue
highwayway
- West Colorado Avenue
- Westbound US-24 from 1961 to 1969
- US-24 from 1961 to 1969
What you have is fine, since technically a route relation can be split up and nested an arbitrary number of times, but don’t feel obligated to do it every time you map a highway route. That must’ve been mind-bending!
I’ve been stacking segments on top of each other as dates change. For instance, I was just working on FM 145 near Farwell, Tx. Within each county going east, it started out as different roads (RM 699 in Parmer County, FM 1775 for half of Castro County, etc, etc, etc). At a specific date, TxDot changed all of it to one single road, which goes like 90 miles or something like that from it’s western terminus with US 84.
If you find this highway, you’ll see that I’ve just merely stacked the road segments on top of each other all the way up to its current configuration. I haven’t added road relations to any of the segments (one of my major weaknesses in OHM/OSM), but that’s what I’ve been doing.
How should we map partially-completed interstate highways? I’m now mapping I-70 across Colorado, 1961 to now, and wondering whether it’s best to map for historical routing or include only segments where construction has been completed in relations.
During its early history, the highway comprised a few short discontinuous segments connected by older highways. For each time period, I have been including the completed portions and the connecting roads in cross-state superroutes, and then stacking these into a chronology. That method will produce complete border-to-border routes for each time slice, but the superroutes will show more than just the segments that are complete and open.
Alternatively, If only the completed discrete highway segments were to be included at each time stage, they should be related somehow. But I would think a route relation should represent one continuous route from A to B. So might some other relation type would be appropriate? Just wondering if other mappers have some thoughts on this. Thanks!
These are great questions, and your I-70 relation looks good to me so far.
As I’ve been mapping various highways in the Cincinnati area, I’ve been trying to make these distinctions in the highway’s lifecycle:
- Under construction:
highway=construction - Complete but not yet open: still
highway=construction - Open but not yet designated as part of a route:
highway=motorwayname=*but not part of the route relation - Designated as part of a route:
highway=motorwayname=*(if still relevant) and part of the route relation
I started with a relatively easy case that doesn’t even need a chronology relation: I-275 in Ohio is one and the same with the Circle Freeway. As soon as another section of the highway opened, it was automatically part of the route. I’m not bothering to create a separate route for each time the route got extended, because there was never a portion of the Circle Freeway that wasn’t I-275. The route also has never been rerouted, apart from a temporary two-way pattern across a bridge span while the other span was being completed. As in OSM, the route superrelation contains several member route relations because, like most loop highways, it changes cardinal directions in several places.
By contrast, I-74 in Ohio needs a chronology relation because, even though today it’s coterminous with the Northwest Expressway, part of the freeway was excluded from the route for five years because it dead-ended at a local street that couldn’t handle interstate truck traffic. This might be easier to visualize, but I haven’t gotten around to mapping street relations yet. (OHM is using street relations for a different purpose than OSM, but we haven’t documented this discrepancy yet.)
1 Like
As @Minh_Nguyen has pointed out, great questions… I’m going to add this line of thinking to the project page, where, FYI!, I’ve also added you to the I-70 in CO row.
Yours to manage for status now, but it’s great to have more names up on the board!
@GeoDave5280 - this seems to me like the right answer and one that says we should not include undesignated segments like this in an I-70 route relation. Does that make sense to you?
That said, I’m in a bit of awe at the detail of the relations you’ve been working on - 100s of segments in each direction, superroutes, and then chronologies on top of that. Amazing.
I hadn’t seen a type=superroute relation before. Very cool.
type=superroute only exists for hysterical reasons:
I’ve been nesting type=route instead. The containing relation is thus a “route superrelation”, but not a “superroute relation”.
Ha! @GeoDave5280 - what say you? It does seem to me we can do everything we need with type=route - should we standardize on that or is type=superroute doing something special?
The only downside is that, due to an apparent miscommunication, JOSM has some special handling for sorting a superroute’s members, which probably won’t completely work for how any of us is modeling our route relations anyhow.