Is it always safe to cut Ways when creating a multipolygon relation?

General talk
,
1

When creating a landuse=forest multipolygon where part of its edge is a barrier=fence, one would ideally cut out the forest-adjacent portion of the fence and make that a member of the forest relation.

But is this safe for all non-area Ways?

  • Would e.g. a junction=roundabout be ruined if cut into two Ways?
  • Would e.g. a type=restriction relation be broken if its from member got cut in two?

(I hear that it is poor style to use highways as the edges of areas, but those are the examples I could think of.)

The name key doesn’t disencourage splitting a highway or waterway, but are there any non-area ways, where it would be considered rude to split a non-area Way into two pieces with the same name? For a ridge, perhaps?

1 Like
2

I strongly disagree with this premise - rather, a new barrier=fence way should be added and the landuse=forest should remain an area (not a multipolygon) that simply shares nodes with the fence.

8 Likes
3

True, but you might get the same questions arise when adding a bus route, so it makes sense to ask.

4

Yes it is safe and allright to cut a way that’s a member of a relation, if there is a good reason. The editor will handle this by adapting the reation, but… (there is always a but…) the relation should be in the editor’s working space, otherwise the editor can’t handle it. The mapper has to make sure that it is.

As for the name: Cutting the way gives two sections with the same name. It’s up to the mapper to determine if the cut is worth it. I think it’s up to the data users to handle multiple sections with the same name as they see fit.

About turn restriction relations: in principle you need only one way as from member and one way as a to member. There’s no harm if this way is cut in two sections; but you might want to edit the extra section out, for neatness. I’m afraid I have not always done that when splitting roundabout ways (e.g. of two-ring and turbo roundabouts), to cater for busroutes and bicycle routes, which need different sections of the roundabout loops as members.

About routes: the editors should add the correct role in the relation to the new sections. AFAIK editors are handling this, if they have the relation in their downloaded working layer.

About mulipolygons using tagged ways as outer. This is valid for multipolygons, and it has been practiced extensively in the early days (so I’ve been told). The main problem is that highways have been used a lot for this, in mega monster tentacle MP’s, which is a major PITA even for reasonably experienced mappers who want to update the area.
In my opinion, it’s not a problem to use a section of fence as an outer for a wood area MP, provided that the fence is actually the outline of the wood area. In my experience, the fence seldom is; it’s usually placed within the wood, which warrants a separate way for the fence. But let’s say, school fenced school grounds or fenced playgrounds could be mapped as MP’s with the fence as an outer.

I have in fact done this with a few playgrounds surrounded partially by fence, partially by a hedge. And also, I have mapped roundabout centre islands outlined by an apron kerb, as MP’s tagged area:highway=centre_island, with the closed barrier=kerb way as the outer, and no inner. In fact, I have split a few of these closed-way outers, because there were sections without kerb, so I had to remove the tag barrier=kerb from these sections. No problem for the MP. JOSM handled it as it should.

5

I would argue that the the landuse=forest ends at the center of the outermost tree. Usually the fence it not going though the trees, so would have it’s own line, with some offset to the forest.

On other landuse the fence might share the nodes of the landuse. If there are no other reasons for a multipolygon, I would not create one for the fence. If a multipolygon is required anyway, I would split the ways.

1 Like
6

No this is not the case for multipolygons, it is one of nice things that you can edit a MP without having to have downloaded the whole thing. Even for route relations you only need the neighbouring members and that only so that you can maintain ordering (which is not required for MPs) and modern editors will ensure that that is the case.

7

A new fence should be added? So there should be two overlapping fences?

If the forest is small, then there is little reason to turn it into a multipolygon. I am not arguing for making multipolygons for its own sake.

But if the forest is large or complex, then defining parts of it using pre-existing elements is a help, and it also means not having to click on every single point that it shares with the fence.

8

Ah thanks, seems I missed a development. It also explains why I regularly find two adjacent members in a relation that seem to have switched places: a cut while the surrounding members were not available to the editor. I always wondered how that could happen.

9

Using a linear way as part of the area outline (if the way in reality outlines the feature) is in itself a reason to use an MP. That is just how MP’s are designed and defined.

I would advise against overusing this, e.g. the old practice to make adjacent landuses share lines by turning them both (or all) into MP’s is unhelpful IMO.

2 Likes
10

Relations are still awkward in OSM as each type is its own independent datatype that has to be implemented for each editor. I think OSM should make some official example code for each relation type, so each can be supported better.

Right, using pre-existing Ways as elements for multipolygons seems innocent enough. It is mostly highways that are unpopular for this role.

11

In general I would always avoid using clearly different object categories as elements in a MP.

For example one of the very annoying things is using parts of (administrative) boundaries in landuse, natural and similar objects. While I normally don’t support gluing, it is still an order of magnitude easier to deal with than any of that.

Just the day before yesterday I managed to empty lake Geneva (2nd time in two years) because historic boundary elements are shared with the lake MP (because the current admin boundary that I was working on is split to allow the historic boundary to continue to work without duplicating all the ways, naturally the issue is that we haven’t got rid of the historical boundary, but unluckily some people have emotional ties to it).

3 Likes
12

Anyways, I’ve noticed that unclosed Ways seem to have less of an “identity” than other objects:

  • A Node can’t be split.
  • A named, Way-based building should not be split in two buildings with the same name. That would be stupid and useless.
  • Most relation types can take many shapes, so there is rarely a reason to cut one apart.

But named, unclosed Ways - especially highways and waterways - get split all the time.
As I understand it, waterway-Ways are only named at all because some systems might not be able to read the name off of a waterway-Relation.
The name makes more sense on the Relation anyway. (A hundredth of the Nile is not “the Nile”; the whole Nile is “the Nile”.)

Splitting an aerialway=zip_line might imply that there is a terminal where the line was split, but apart from such examples, unclosed Ways seem to have much less sanctity than other OSM objects.

13

Oh, I agree that certain objects - like legally-defined boundaries - should not be used as the edge of landuse features and the like. I always hide boundaries whenever I edit anything near them.
But in those cases where a fence or the like have clearly been used to define the edge of a landuse feature, it makes more sense than not to use it as part of the edge.

By the way, what do you think about those cases where e.g. a forest and a farmland have been glued together, despite there being a wide belt of grassland between them?

14

IMHO completely OK if you see OSM modelling as a progression from the rough to the detailed.

PS: in the end for the example it depends on what “wide” is …

1 Like
15

This is slightly OT, but the difference is that MPs can be assembled regardless of the ordering in the relation, all editors that render MPs typically do that on the fly (obviously a broken MP is broken and a partially downloaded one will be rendered with whatever the editor dev considered a suitable amount of fix up).

Route relations however cannot in all cases be reassembled, aka sorted, correctly without relying on the existing order of the members. However if the previous or following members are available to the editor it is possible to insert the products of splitting a way in the correct order (see the long standing issue that iD had).

1 Like
16

Well, I think a wide belt deserves its own natural/landuse, where other mappers may think it’s just a wide edge line. The level of detail is increasing constantly, so old edge lines look like wide belts now.

Still, edges always require a choice: the perimeter of a wood is often a belt of grassland with trees on, or maybe trees with grass underneath. A cycleway through the wood usually has grass verges underneath the tree crowns: is that included in the way representing the cycleway, or is it just part of the wood, or maybe separate landuse/natural? The mapper decides. I tend to look at: what is the impression I get riding there, and what mapping best conveys that information. I confess to seasonal bias, but it seems to agree with later editors.

17

you don’t have to download all members, but you have to have the relation. If you only have some members you can easily break the thing.

18

the conclusion is to have relations for every road and waterway that consists of more than one way?

19

Sure but the only way you can get in that situation is deliberate and requires specific effort to shoot yourself in the foot.

20

It depends on what “name” means. If name on a highway is defined as “the name of the street” rather than “the name of this arbitrarily-split section of street”, then there is no problem.
Or perhaps using a Key different from “name” would be more technically correct.

Trying to create and maintain relations for highways would be hell, and also superfluous as address Nodes also contain similar data.

But making relations for all named waterways is not at all unrealistic. And it only takes adding a single culvert for one waterway-Way to become three, so I generally make relations for them before that happens, just to make sure.