Roads – how to represent evolution?

Thanks for the promotion to the I-70 in CO project, Jeff (I think :slight_smile:)

When nesting route relations, using a “superroute” for higher-level relations prevents this warning:

There may be another resolution to that; still experimenting. Otherwise, I would be willing to standardize on “route” for route relations at various levels.

Also, excluding undesignated segments from route relations is fine with me. But that leaves non-contiguous route segments. Is it OK to group those into a single “route” for adding to a chronology, even if that route is fragmented?

1 Like

If I’m reading the code correctly, JOSM only issues this warning if at least one of the members of the parent relation has a nonempty role. If all the members have an empty role, then it shouldn’t even go anywhere near the code that issues this warning. The idea is to warn about a mix of mapping styles, such as someone inadvertently adding a way directly to a route superrelation.

Yes, in reality, the officially designated Interstate route may have a gap. There are some prominent examples of that even today. Often the state DOT will fill in the gap using a temporary state or U.S. route designation. On the other hand, it may be the case that the route temporarily followed some non-freeway segments – follow whatever your sources indicate.

1 Like

Dangit, did they reallly have to rename the whole highway for one day? That’s a lot more overlapping ways for me to map. :joy:

3 Likes

In all seriousness, it would be better treated as an event in the likes of festivals/expos and wars somehow, although temporary:*= isn’t needed in OHM. No one wants to do all the work to rename Bond Street Station to Bond St for 1 day, then change back.

This is my preferred method of mapping a street’s evolution, but the lack of a designated method does create some issues though.

A while ago, I mapped a bunch of streets in my area that went through several stages before the current one. Usually, the evolution is path/track with a name → became a proper street with a new name → sometimes another change or two (name changes, downgraded in importance over time, etc), so I could end up with two to four versions of the same street one on top of the other.

Unfortunately, a mapper had another way of mapping and recently transformed some of “my” streets to just a line with relations instead. Most of my work is still present in the relations’ tags, but of course don’t appear on the map since they’re just lines and not highway=* anymore.

Here’s an example : Way: 200681018 | OpenHistoricalMap

This is now a line with three of my old streets as relations, although not even as accurate as before since the third one timeline wise now randomly stops in 1970 because the mapper also added a whole lot of landuses based on a map that is actually set in the early-to-mid 1950’s in this area, and I’m pretty sure I mapped a forth version of the street (the current one) that reflected the downgrade in importance when the (not mapped) N90 slightly north became the main transit road in 1975.

So yeah, it kinda sucks that there isn’t a formal way of showing a street’s evolution over time yet.

1 Like

It looks like the streets were replaced with multilinestring relations, which are still pretty exotic. So far they aren’t supported by the vector tiles, or by the Nominatim geocoder or any editors, for that matter. Multilinestrings really should have better software support, but I’m not sure if they’re the best tool for modeling roads anyways.

Looking back at the previous discussions about multilinestring in OSM and OHM, I think there may have been multiple viewpoints about what this relation type should represent. Some have talked about multilinestrings as a wholesale replacement for tagging ways, while others have floated the idea of them as lightweight overlays representing only a single attribute that changes over time, such as a name or speed limit.

Back when I documented multilinestring on the wiki, I observed that OSM was mostly using this relation type for features that consist of multiple disjoint segments in reality, similar to multipolygons, but without any area. An example would be this colorfully worded geoglyph. However, a multilinestring is a basic geometry type in GIS, so the use cases can be fairly open-ended. These days, most occurrences are features that would normally be modeled as a single contiguous way, except that the way is long and complex enough to exceed the node limit, yet there’s a desire to maintain a single feature instead of a bunch of connected features. Examples include the Kazakhstan–Russia border, the Cascades mountain range, and this valley.

What all these features have in common is that the member ways have no tags. As with multipolygon and boundary relations, the idea is that the individual linear geometries forming the multilinestring are meaningless on their own. If any way has a tag, it represents a different feature that coincides with the multilinestring. (In other words, each of the ways of the geoglyph could be a man_made=letter_stroke or something silly like that. :upside_down_face:) Notably, none of these multilinestrings represent features that mainstream data consumers understand anyways. If someone were to replace a long street or railway in OSM with a multilinestring relation, it would get undone very quickly. We don’t have such strong backwards compatibility concerns in OHM, but we have far fewer developer resources to implement and maintain exotic solutions independently of OSM.

The idea of tracking a single attribute’s evolution over time is closer to the route relation type. A route relation only represents abstract information, complementing the physical infrastructure that’s still modeled as ways. Few data consumers understand route relations either, but this is seen as less of a problem because at least they understand the tagged ways. The OSM convention is to add railway=* ways to a route=railway relation, which only tracks non-physical attributes such as names and ownership. We already have many examples in OHM too. The closest analogy would be highway=* ways that are part of route=road relations, which are less common.

We’re pretty close to having route relation support in the renderer. Route relations are already exposed in the vector tiles, so it’s a matter of figuring out the best way to style them in the stylesheet:

Similarly, associatedStreet relations have long been exposed in the tiles but the stylesheet doesn’t use them. I think this was actually the result of a misunderstanding. associatedStreet relations are for geocoders, not renderers. The relation can contain a member with the street role, but that member still needs to have highway=* and name=* tags; the name=* on the relation is just to keep things organized in an editor. If we need something similar to route relations but “route” isn’t quite correct semantically, maybe we could repurpose this unused associatedStreet support for a new street or highway relation type.

Long story short, there are several possibilities, but none of them are quite as well-developed as multiple overlapping ways. If @flha127 would like to keep experimenting with multilinestrings with the understanding that they’ll be supported eventually, that would be fine, but maybe it’s best to avoid conducting this experiment on others’ contributions. There are still so many unmapped streets in the world, so a lot of room for experimenting without stepping on each others’ toes.

1 Like

I discussed this in the recent months when the abuse of route=road for collecting arbitrary roads by Wikimedia project users spread to my country in OSM, limited by Kartographer’s lack of progress to support more type= after years. Indeed semantically, I would highlight =associatedstreet was invented for addresses, not (only) the streets themselves. Some roads don’t carry addresses, and many don’t have names used for addressing.
For renderers, =associatedstreet has house addresses, which can include areas depending on the national convention, and perhaps addr:interpolation= lines. =street can have many more features, including linear barrier= and maybe even railway= =tram , =light_rail , etc, on street-running section. All these will complicate rendering. In other applications, if someone wants road data only, either of them won’t work.
As to how to cooperate in the meantime, there are methods of working together. I guess most users don’t bother to create overlapping lines yet, so I use route=road etc for attributes. I leave the highway= feature untouched to keep at least something gets rendered. I don’t bother with changing highway= classifications either.

2 Likes

For the Ferrer street you are talking about, the last road represented was a residential with an end_date in 1974, I corrected the residential to primary when switching it to multilinestring.

I also added source:geometry I forgot to add when I mapped it 1 or 2 years ago using the Walloon region imagery and I corrected the part between rue du Marais and rue de la Banque which used the current geometry offset from the previous situation due to the parking=side to the north.

We’ve discussed this on multiple occasions. The discussion was mainly about which tags to put in a multilinestring relationship and which ones to put in a route relationship.

I would add that the presence of a source for the geometry should be mandatory on the members composing it to allow potential reviewers to check the work of others.

I’m not sure because looking back at the old streets, I created Rue Ferrer as a highway=residential straight up (and forgot to remove the Rue Léopold tag in it :sweat_smile: ) and never put an end tag to it. I probably thought about having a version when it was the main transit road from 1909 to 1974 and the current version from 1975 onwards, but never did it. The closest things I mapped with an end date in 1974 are Rue du Many right west which did have a name change in late '74 to Rue de la Barrière, and a small chunk of that street a little bit later when the viaduct was built in 1975 and they removed the level crossing, making it the current dead end as a result.

Thanks for pointing this out. I’m also not a fan of the original type=street proposal, which basically duplicates associatedStreet, nor of the extended proposal that would add seemingly everything in a city to one or more street relations. If we were to adopt a street relation type, we’d probably need to “fork” it like we forked the start_date=* key to have different requirements than in OSM.

To me, route isn’t quite the right semantics, but at least we could clarify that it isn’t really a route, just a routable feature, using route=*.

It isn’t terribly uncommon to draw overlapping roads. As of today, 5,725 highway=* ways overlap with other highway=* ways from a different time period over a nonzero distance. I don’t know how many mappers are responsible for this practice, but it happens pretty much wherever there’s significant coverage of surface streets and attention paid to highway classifications.

Same, although it’s unfortunate, because accurate road classification makes the map more legible. Classification is probably the reason why some mappers have opted for a multilinestring relation containing bare ways. Whereas other linear features like railway=rail and man_made=pipeline mostly use secondary keys for classifications, highway=* indicates a classification that can easily change over time, and there are a lot of possible classifications, more than a renderer would ever need to use. It would be as if building:use=* didn’t exist, so you had to create a redundant building with a different building=* tag every time a different kind of occupant shows up.

Theoretically, we should move highway classification to a secondary key and use only, say, highway=motorway, highway=road, and highway=service. That would be unconscionable in OSM these days, but maybe we still have a small window of opportunity to do something like that in OHM if people feel strongly enough about minimizing overlapping geometries. Then the classifications could come from a route relation or somesuch.

Essentially, moving a feature’s primary tag to a relation will be relatively difficult for a renderer to implement, especially if it has to reason about two concurrent relations in the same time period that would result in a fundamentally different stylistic treatment. That’s my guess as to the lack of momentum on multilinestring.

On the other hand, I recognize that it can be challenging to navigate around overlapping ways in iD and especially JOSM. Better ergonomics would be quite feasible in Rapid, which renders its map canvas using a more powerful technology. For example, we could implement a special gesture to briefly tilt (pitch) the map, allowing the user to pick out a way from a stack of ways that are layered along the z axis according to start_date=*, layer=*, or some other key. It would be easier to rearchitect iD’s preset system to allow a multilinestring to represent any kind of feature, but multilinestrings would still be much harder to explain to inexperienced users than ways.

In OSM, I find =motorway to be worse when there’s a difference between the functional classification between junctions, and the legal definition in reality that can be located anywhere, necessitating the use of a counterintuitive-looking motorway=no . Then we have to arbitrary decide to use the higher class in =*_link , which is awkward when =motorway_link and other =*_link mixes. At the other end, there’s no =unclassified_link , =residential_link , and =service_link . So for both =motorway and =service , they can still mirror how railway= uses highspeed=yes / passenger=national , and service= , to be unified in a single highway= for two-tracked vehicles.
highway=road can be an acceptable solution at first. Shifting to a single highway= feature should also be about the ease and effort of editing. Users shouldn’t need to draw along the same road many times when there’s no positional change relatable.
Specifically for the highway= classification, using rel allows the whole continuous corridor of the same class to be presented together (depending on how they are organized), making the logic of classifying more self-explanatory. Each section can be interpreted more easily when viewing and editing the data.

There’s definitely something to be said for being able to conceptualize an entire road as a single unit from end to end. However, I still wonder if it would really be worth the trouble of departing from OSM so fundamentally. Half the time this question about roads comes up, it’s because of a name change rather than a change in classification. Most mappers aren’t ready to apply classifications very rigorously yet. Even moving only names to route relations would require a good deal of user education. As it is, it’s hard enough to explain the difference between a road name/number and a route name/number.

To move things forward, I think we’d need to get to the bottom of why overlapping ways is fussier than concurrent relations. Does it come down to certain editor workflows that work better or worse? I could easily imagine, for example, a shortcut in iD for duplicating the selected feature (which exists) but keeping it connected to the selected feature. Enhancing editors and validators is generally a lot more feasible than enhancing the entire rendering, geocoding, and (eventually) routing pipelines, as we’ve seen with the decades-long saga of route relation adoption.

Not only this, the problem is worse. When you create a new variant, you would need to create a new variant for all the route= it belongs to, because the member has changed. Even for route=road , doing this for every road renaming (and other attributes) on any significant signposted route would be a horrible mess. Not to mention =bus , =bicycle , =foot etc. That’s not scalable and manageable. The route= that the changed road carries hasn’t changed on its own, so data models that creates a new variant of referred objects should be avoided.
In effect, this basically calls for One Attribute One Object, to put in in extreme. OHM has to keep track of evolutions in many attributes. They should be separated, so that different changes aren’t mixed together conceptually, and not compounding the complexity data-wise. This could benefit viewing and applications as well.
Without any knowledge, I imagine a combination of an unclosed Shrinkwrap / attached “parallel” tool, and “select non-branching way sequence” may serve as a conforming workflow. Outside the topic here, the latter action is more universally needed in iD, so that you don’t have click everything you want to select.

1 Like

[quote="Minh_Nguyen]but multilinestrings would still be much harder to explain to inexperienced users than ways.
[/quote]

Why ?

Consider a multipolygon but with ways.

  1. draw a way for your feature ;
  2. add a source for the geometry ;
  3. create a multilinestring relation and add the tags as you would do with a regular way ;
  4. add the members.
    Et voilà.

I have this tram line in Belgium with three part each with different sources,

  • for the northern part#1, I only have average sources : a general staff map at 1:25000 and a track plan who tells me that this section is single track;
  • the siding#1 and the southern part#2 was mapped using photographs and videos ;
  • the small southmost#2 part is still there.

#1 private right of way ; #2 street running.

This gets me 4 lines with only source tags.

Now the headaches, the dates are fictitious to serve as an example:
(1)- put into service in 1890 with steam locomotives;
(2) - electrified on 1898-10-01 from the north to the siding and 1898-12-01 for the southern part;
(3) - dismantled by the Germans in 1917 (railway=abandoned);
(4) - rebuilt in 1920;
(5)- closure in 1950 (disused);
(6) - dismantled in 1952 (railway=abandoned).

24 lines.

Now let’s say that I made a mistake in the date for the dismantling, it was not 1917 but 1916… how can I correct that?

  • Load the data into JOSM;
  • Select the lines (2) with the tags start_date=1898-10-01 or 1898-12-01 and end_date=1916… each time it’s scroll_button check the 6 overlapping lines and select or each time you have to create a filter ;
  • Same step for lines (3) (1917 to 1916) ;
  • Hoping not to have forgotten any and here I wasted 5-8 minutes doing that.

You can also use a query or filter but it’s also time consuming.
railway=tram AND (start_date=1898-10-01 or start_date=1898-12-01) AND end_date=1917

railway=abandonned AND start_date=1917 AND end_date=1920

Multilinestring relations approach:
I have created multilinestring relationships using the 4 lines and I made the same mistake with the dismantling date.

  • Load the data into JOSM;
  • select a line / select the relationship modify the date done.
    30s.

There are quite a few discussions on the subject on Github maybe you should take a look.

Sure, you get it as a JOSM user and I get it as a former Potlatch user, but relations in general are a bit of a mystery to less experienced mappers. I know many who have dabbled in OSM for years but give up when they need to map a route relation to represent a numbered road route, which is nothing unusual.

Multipolygons have been more successful among less experienced users, because iD has a special shortcut for creating one: instead of having to fuss with the relation editor and roles, you can simply select multiple areas and merge them. Most people who create multipolygons don’t even know what they are. They just know they want to combine multiple areas or punch a hole in an area.

For sure, this kind of history can lead to a lot of geometry duplication, which is one reason why route relations keep coming up in these discussions. To me, the question is whether we need to go further and use multilinestring relations, which require the underlying way to have no tags and require data consumers to use the multilinestring relation for everything.

Some of OSM’s railway lifecycle tags might be a bit redundant considering our other ways to represent change over time. I know there’s a lot of debate in OSM about the exact meaning of railway=abandoned, but isn’t railway=disused equivalent to the absence of a route=train or route=railway relation traversing the way during that time period?

If we at least keep a primary tag like railway=rail on the way to record physical existence and rely on route relations for the rest, there would still be two overlapping ways (representing stages 1–3 and 4–6), but this also provides a natural answer for any discrepancies in geometry between the two incarnations of the railway. As long as a single route relation contains the totality of ways that physically existed at any time during the route’s existence, I think you could filter relevant ways pretty effectively without having to select each one individually from a stack.

Returning to the original topic, roads have tended to be mapped based on function rather than physical appearance, so old alignments have often been represented by nothing more than the absence of a roadway in a given time. It might make sense to record a lingering old alignment or ghost ramp using a lifecycle prefix or similar, but I’m not sure that multilinestring relations would really be more convenient than overlapping ways.

We already have lots of tooling that can handle overlapping ways, however inconvenient, but almost none that can handle concurrent relations. For example, iD can warn if two roadways/railways overlap spatially and temporally. (We need to introduce something like this to JOSM.) If we migrate the primary tags to multilinestring relations, we’d need something like JOSM’s validator rule that boundary member ways must always intersect, even when they have nothing to do with each other. Would mappers really appreciating having to create fake intersections all over the place?

We’re starting to make some progress in restoring the rendering of roadways and railways that have been converted to multilinestring relations. The relations are in the tiles, but some challenges remain in getting them into the stylesheet, especially if we intend to support route relations or street relations simultaneously.

While this is cause for optimism, I remain pessimistic about multilinestring relations for navigable features. Beyond rendering, we’d urgently need to extend all the editors to support multilinestring relations as a basic geometry type and somehow make Nominatim aware of these relations too. This is outside the area of expertise of just about everyone on the development team, so we’ll need the community to help bring in people who can contribute this functionality to our forks. Realistically, if we adopt this relation type, we won’t be able to introduce routing for the foreseeable future. I simply don’t think it’ll be feasible based on how the major routing engines are architected. But I’d be happy to be proven wrong.

There are some practical data modeling consequences too. It’s really nice to be able to represent a road as a single object, but multilinestring relations actually prevent us from doing so. After all, a road that has varying speed limits, lane counts, surfacing, etc. over its length will need a series of multilinestrings. This is the problem that route relations are supposed to solve, and route relations don’t come with many of the downsides I just mentioned.