Support for multiline relations

[flha127]

Related threads #276 & #284

OHM currently only renders associatedStreet and multipolygon relations. It would be an improvement to have full support for multiline relations. To do this we could use a new "type=multiline" similar to "type=multipolygon". These objects unlike type=associatedStreet but like type=multipolygon are intended to be part of existing layers. A tram line type=multiline & railway=tram would join the transport_lines layer.

[1ec5]

FYI, type=multilinestring is much more common in OpenStreetMap.

[jeffreyameyer]

@danrademacher - any progress here?

[Rub21]

A tram line type=multiline & railway=tram would join the transport_lines layer.

For railway cases, it seems the tag is route=railway for relations: https://wiki.openstreetmap.org/wiki/Tag:route=railway. This tag joins all the pieces in one line, but it looks like we need to add the tag to each way piece as well. I am doing some tests to see if that can be done.

E.g https://www.openhistoricalmap.org/relation/2798877#map=9/-11.4639/-75.6862&layers=O&date=1949-07-07&daterange=1824-01-01,2024-12-31

[flha127]

Good morning, This type of relationship is not really useful as it duplicates the tags already present in the members, see for example this line, it already has the tag "name"="Alton District (T&E Line)" which we find in the relationship.

I agree with the proposal to use type=multilinestring and add a type=multipoints version to gradually remove the lines and points with attributes and replace them with type=multi... objects. This will result in a smaller database and makes it easier to check sources. I generally use a line tagged data_type=source with the quality and sources tags, then I have to copy and paste this line as many times as necessary to put the different attributes. With a type=multi object... we would only have this data_type=source line and as many relationships as necessary. And to check the sources, a simple search or query overpass works wonderfully see https://umap.openstreetmap.fr/fr/map/sources_963936#19/38.88948/-90.18436

[Rub21]

@flha127 , Good point,

According to OSM the definition 👇

Relation with type=multilinestring

A discontiguous series of unclosed ways that semantically represents a single physical object. https://wiki.openstreetmap.org/wiki/Relation:multilinestring

Relation with type=route

like multilinestring but contiguous, forming a route that can be followed from end to end, Used to describe routes of various kinds. https://wiki.openstreetmap.org/wiki/Relation:route

I am trying to understand which objects or relationships are going to be represented on which layers.

For example, for Caminos del Inca, all chunk members have been tagged, but there was no relationship for the route, so I created a relationship that would represent Caminos del Inca. I think the route can be added to the transport_lines layer. However, in this case, the feature will not contain any highway=* attribute, so maybe it needs another layer like transport_routes and the same for other relationships that are going to use type=multilinestring.

The Caminos del Inca could be tagged as type=multilinestring because it is a discontinuous series of ways, but it may still need to add route=road to recognize that is a route.

https://www.openhistoricalmap.org/relation/2798886

[flha127]

Hi, As for route= with a mode of transport (train, bus...) I am also in favor of putting them in a separate transport_routes layer.

As for route=road I would see a solution with two relationships :

1. the first one with highway=, type=multilinestring and no ref= tag which goes into transport_lines. https://www.openhistoricalmap.org/relation/2798912#map=10/-15.1517/-74.4763&layers=O&date=1924-03-20&daterange=1824-01-01,2024-12-31
2. the second with type=route and route=road which also goes into transport_lines. https://www.openhistoricalmap.org/relation/2798914

The second relation would be used to display what we usually display in OSM with the ref= tag, this would avoid having to duplicate the relations (or the lines currently) each time we change the route ref= tag.

The same thing could be done with railways with on one side a multilinestring object and on the other a type=route + route=railway object all going into transport_lines.

The same thing could be done with railways with on one side a multilinestring object and on the other a type=route + route=railway object all going into transport_lines. 1. https://www.openhistoricalmap.org/relation/2798921 https://www.openhistoricalmap.org/relation/2798922 2. https://www.openhistoricalmap.org/relation/2798920 https://www.openhistoricalmap.org/relation/2798919 https://www.openhistoricalmap.org/relation/2798918

[Rub21]

hi @flha127 , The relations as lines, cannot be added in the same transport_lineslayer due to conflicts with the existing ways, but we can create another layer called transport_lines_relations. Regarding the two cases, it seems we can standardize, so in that way.

Both relation cases, type=multilinestring and type=route, appear to be similar and can be included in the same layer. I agree with adding highway=* to type=multilinestring, and suggest it could also be added to type=route. I'm open to the possibility of including highway in both types. Regarding ref and name, if the route includes the ref tag in its attributes, it will be displayed in the vector tiles (Vtiles).

https://vtiles-staging.openhistoricalmap.org/#13.76/38.88522/-90.17039

https://vtiles-staging.openhistoricalmap.org/#7.88/-9.964/-76.758

@danrademacher @batpad, would you be comfortable naming the new layer transport_lines_relations, or do you have any other recommendations?

[flha127]

hi @flha127 , The relations as lines, cannot be added in the same transport_lineslayer due to conflicts with the existing ways, but we can create another layer called transport_lines_relations.

Hi, Multilinestring relationships are the multipolygons of ways.

Multipolygons are as multilinestrings physical objects however they do not have their own layer, they are included in the same layers as regular polygons, the risk of making two separate layers is that in the long term the creators of renderers forget the layers specific to the relationships and all these contents will be hidden. In doing so we also have to duplicate all the elements in JSON files to display the elements of both transport_lines and transport_lines_relations (JSON does not support two layer sources for an element) therefore having to modify all existing JSON files.

If there are overlapping relations and lines, JSON does not know how to display multiple overlapping labels so this does not pose a problem.

In any case, if we duplicate the elements of the JSON file with the two layer sources there will be in all cases duplicated tags, whether the elements are in a single layer or not.

(As of now, there are no multilinestring relationships, apart from 3 in eastern Europe, the test ones in Alton IL and the test ones in Peru)

As for route relationships which are not physical objects, they can remain in a separate layer, we can even group them with other relationships (bus, train, etc.) in a generic "routes" layer.

[flha127]

As for refs, if we maintain the use of the ref=* tag which would duplicate with the relationships type=route + route=road then we will also have to duplicate the elements of JSON files to display route refs :

• one for class=route + type=road and display name (or ref) ;
• the other for class=highway + type=primary/... and display ref. Personally I think it is better to encourage the abandonment of the ref tag and replace it with type=route+route=road relationships, it already does not make much sense on OSM where almots all roads and railways have these relationships .

I agree with adding highway=* to type=multilinestring, and suggest it could also be added to type=route.

I agree with you in order to correctly display the different types of routes (for example the color of the shield). But I think that we must limit ourselves to this in order to have two very distinct objects, the first for physical objects (streets, boulevards, avenues) and the second for routes.

[1ec5]

A forum thread would be a good place to resolve any lingering uncertainty or disagreement about which tags are appropriate for which situations. That said, I think can be certain that type=route (#440) is the more actionable tag to support at the moment, because it’s already used orders of magnitude more frequently and is well-supported by both iD and JOSM. Eventually, I would like for editors, renderers, geocoders, and routers to all support multilinestring in the same manner that they support multipolygon, but it’s going to be a lot of work. Even if we implement it in the tiler, no one will really use it until more software supports it. In the meantime, most of what multilinestring accomplishes can already be modeled as overlapping ways.

The Caminos del Inca could be tagged as type=multilinestring because it is a discontinuous series of ways, but it may still need to add route=road to recognize that is a route.

route=road is for a distinct designated on-road route, not for the physical road infrastructure, even if that infrastructure is routable. In my view, the Inca road relation is mistagged, because a route is more or less a linear feature, whereas that relation represents a whole network of roads. multilinestring would be more appropriate for this network.

As for route=road I would see a solution with two relationships :

This is effectively the combination of #440 plus what we already implemented in #94 for type=associatedStreet. There was apparently a misunderstanding about what associatedStreet is for. I think it’s unlikely that associatedStreet will ever take off in OHM, because it’s so widely disliked in OSM and would be even less compatible with our time-sensitive data model. We should remove that associatedStreet code. But what we implemented for associatedStreet is actually what people seem to want in a relation type for a physical street or road.

[flha127]

Hi @1ec5

In the meantime, most of what multilinestring accomplishes can already be modeled as overlapping ways.

Yes, it is currently the only way to do it, and for me who now has quite a bit of experience, it is mainly a source of headaches. I have this section of railway tracks in Belgium with three quality levels,

• the northern part quality=1 (green/brown) is average with a precision of +/- 5-10 m because I only have average sources here, a general staff map at 1:25000 and a track plan who tells me that this section is single track;
• the dark green part has a much better quality +/- 2-5 m because we have photos and videos;
• finally the last one in light green is a section still existing with a precision of less than 2 m (depending on the precision of the satellite imagery).

(step 1) We have data_type=source lines to have "functional" lines I must first copy these, delete the quality and source tags then combine the lines into a single one if possible, in this case we will always have 4 objects (1 north; 2 for the siding; 1 south).

(setp 2) 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). So I copied the lines obtained in step 1 6 times for this.

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.

Multilinestring relations approach: (step 1) no need. (step 2) I create my multilinestring relationships using my data_type=source lines (no overlapping lines).

Now let's say that I made a mistake in the date for the dismantling (...)

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

route=road is for a distinct designated on-road route, not for the physical road infrastructure, even if that infrastructure is routable. In my view, the Inca road relation is mistagged, because a route is more or less a linear feature, whereas that relation represents a whole network of roads. multilinestring would be more appropriate for this network.

I agree but it is a bias that we have with our current routes, the route included 3 route variations and is separate from the Inca road system. Here we can consider to be more precise to have 3 route relations Mollepata, Classic, and One Day instead of one.

[1ec5]

I agree that the multiple geometry approach is quite fussy for linear features with high connectivity, such as roads and railroad tracks. It’s a workaround. In the long-term, I think there will always be some need for overlapping ways, just as most mappers don’t use multipolygons for every situation where two areas touch, but it’ll be nice to have that tool wherever the complexity would be too great otherwise.

Regardless, multilinestrings are currently so experimental that I wouldn’t recommend converting existing roads and railways to multilinestrings, due to all the confusion that would result. Maybe for a more exotic feature type perhaps?

[Bauer33333]

Is it possible that this approach will have the same negative effects on routing as mentioned here? https://github.com/OpenHistoricalMap/issues/issues/94

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.

This sounds easier in ID. If there was a better time filter UI like an activateable timeslider to see only one point in time it could even be faster than figuring out and selecting the correct relation, but that is an other issue

[flha127]

Is it possible that this approach will have the same negative effects on routing as mentioned here? #94

When you talk about routing, are you talking about this? https://www.openstreetmap.org/directions

I have two assumptions:

• if I remember correctly OSM for routing looks if two lines have a point in common and if yes then it can do routing even though for example a line is not split at each intersection;
• in OHM when we export a multilinestring as with associatedStreets it does not export a single object but it takes each segment and pastes the attributes to it.

Routing is not possible because of these same overlapping lines that we are talking about unless we spend hours merging every overlapping nodes so every single line is connected... currently working with overlapping lines is difficult there we would move to a level that would discourage any contributor. And that raises a new problem, my railway line was dismantled by the Germans in 1916... so I have a level crossing with start_date=1891/end_date=1916 and another with start_date=1920/end_date=1950 but I can't make these two elements coexist if the overlapping points must be merged... unless you use a type=point or multipoint relationship, so in the end we still have to use a relationship.

Now this will seem very complicated but I assume that no contributor will be crazy enough to spend hours merging nodes so that all the lines are connected which is not possible anyway (previous point) .

We start by making a query with the mode of transport then the date range: From there, instead of checking if the two lines have a point in common we will check that the GPS coordinates of points match and therefore assume that the lines are connected. It would probably take a while to calculate but at least it would allow multilestrings to be used.

This sounds easier in ID. If there was a better time filter UI like an activateable timeslider to see only one point in time it could even be faster than figuring out and selecting the correct relation, but that is an other issue

Open iD, set filter, select the line select the line select the line select the line change the date ; select the line select the line select the line select the line change the date, done.

Open JOSM, select the relation change the date, select the relation change the date, done.

Don't get me wrong, I don't want to appear stubborn or want to impose my way of doing things, I myself was very skeptical about this idea back in 2021 when the issue was first raised in #276 and #284, this is simply my feedback from hours spent with overlapping lines. Now, it is no longer experimental and there are no challenges to face, associated_street which is a multilinestring under another name already works (even if very little used), this would be a huge step forward to have objects type=multilinestring with the exact same tags as their single-line counterparts to come in use the same way multipolygons work both to avoid increasing the weight of the database with overlapping lines, by facilitating the rereading of sources and above all to make the work of contributors simpler.

[flha127]

The relations as lines, cannot be added in the same transport_lineslayer due to conflicts with the existing ways, but we can create another layer called transport_lines_relations.

Hi @Rub21

I was looking at the config.toml file for associatedStreets and its "datasets" osm_relations, osm_relation_members (I don't know how they are called precisely).

For simple objects like lines, by integrating them into the datasets we change their tags to have a main type= tag like highway=primary which becomes class=highway+type=primary in transport_lines.

If we plan to create datasets dedicated to each type of relationship (route_relations+route_relations_members/transport_relations+transport_relations_members) will this pose a problem if we proceed in the same way? For the route_relations dataset: From the OHM relation type=route+route=road to the route_relations dataset as class=route+type=road. For the transport_line_relations dataset: From the OHM relation type=multilinestring+highway=primary to the transport_relations dataset as class=highway+type=primary. This is in order to have, as for simple objects, a class= and a type= tags.

Then we create providers.layers routes/transport_lines_relations from these datasets which export each member of the relation and paste the relation tags to it (in the same way as with associatedStreets). As this providers.layers is only made up of simple lines we can then, if we want, integrate them into existing layers via the maps.layers example [[maps.layers]] name = "transport_lines" provider_layer = "osm.transport_lines_relations"

What do you think ?

[jeffreyameyer]

What is the current recommended solution for mapping a line that might be referenced in a treaty? For example, how should the Greenville Treaty Line, be modeled/mapped? (Let's assume it's not just 1 or a few ways, but maybe 100) Seems like a route isn't correct, but a multilinestring would be cool. Not worried about rendering, but possibly returning in search results.

[jeffreyameyer]

@Rub21 - where are we on answering @flha127's questions above? It seems like there are possibly some answers in #717, but I'm not sure if @flha127 has caught that.

@1ec5 - any thoughts here? You suggested a forum post to clear this up a few posts back. Is that still valid? (seems that way to me)

@danrademacher - I feel like the basic question of multilinestring support has been answered in some ways for routes, as Ruben has pointed out above, is that correct? This thread is more about how to construct a vector layer for some specific (but not all) routing needs, if I'm reading it correctly & it seems like we have quite a few tickets tied up in this discussion, mostly focused on routes & route styling, but not all multilinestring objects are routes (per my prior note).

[1ec5]

What is the current recommended solution for mapping a line that might be referenced in a treaty? For example, how should the Greenville Treaty Line, be modeled/mapped? (Let's assume it's not just 1 or a few ways, but maybe 100) Seems like a route isn't correct, but a multilinestring would be cool. Not worried about rendering, but possibly returning in search results.

I think in an ideal world, this is what we would mean by “boundary” – a claim line modeled as something geometrically similar to a route – whereas what we actually call a boundary would be a territory bounded by multiple boundaries. But unfortunately that isn’t how these concepts have developed in OSM and OHM.

Instead, something like the Greenville Treaty Line, Mason–Dixon Line, or Line of Actual Control is modeled as a series of boundary ways with matching name and wikidata tags, similar to how we typically model roads. Geocoders are already in pretty good shape here: Nominatim is already capable of coalescing adjacent ways that represent the same road or boundary.

A multilinestring relation could group these boundary ways together, though I don’t know that this generic relation type is actually an improvement over a more semantically specific boundary relation that is left unclosed.