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