Should one member relations be converted to ways?

Help and support
1

I’ve been grinding out this maproulette challenge, and I’ve been noticing that some buildings not related to the challenge are just a single way but with its tags in a relation instead of the way. I’ve been removing the relation and putting its tags on the way. Is this the correct way of doing this?

Is there a valid reason people create one member relations? Should they be removed to make it simpler?

1 Like
2

For buildings? Probably not. Can you link to an example building? I’d be curious to know their origin.

There are other relation types (routes, boundaries) that I think ought to be relations regardless of member count, but multipolygons can be downgraded to ways if there’s just a single outer ring.

3 Likes
3

Hi, I think this is one of them.

4

I confirmed that this one has what I’m talking about.

5

In my experience this happens frequently in iD. For some reason the editor produces these relations fairly easy and I don’t see a need to keep them like this. I convert them, too.

6

Actually set up a custom search as Toolbar button in JOSM (type=multipolygon members:1) to seek them out at end of an edit session. Notably some have used 1 member MPs to be able to use the same outline for instance to tag a fence/wall/hedge. Careful with those. See multiple past discussions, one @FriendlyGhost expert in the field of pitfalls.

1 Like
7

Single landcover islets is a normal use case:

way:
  natural=coastline
  place=islet
  name=High rock
relation: (way as outer)
  natural=bare_rock
2 Likes
8

The complaint is about untagged member outlines. It has happened before. unwanted not necessary polygon->multipolygon transformation · Issue #5083 · openstreetmap/iD · GitHub
Furthermore in your case, while this is quite standard, mixing linear =coastline and area place= is still less-than-ideal. The =coastline doesn’t have a name= shared. So these technically need 1 more =multipolygon if we want to be clean with One Feature, One Object.

9

Oh, yuck. If you look at the history, there used to be inner ways.

The person mapped out the school grounds, but then punched out all the other features from the grounds as inner ways. That was undone in version 3, leaving the single outer.

So this particular instance would be a case of poor initial mapping, followed by an attempt at correcting the issue that didn’t quite go far enough.

1 Like
10

Yup, I’ve fixed a whole bunch of 1-member multipolygons and came across all sorts of corner cases. Here’s some of what I learned:

  • Leave small islets with coastlines alone unless you are very confident in what you’re doing.
  • Be careful with ways that have multiple (one-member) multipolygon relations on them (I figured this out the hard way).
  • Most 1-member multipolygons can safely be turned into closed ways, especially the buildings.
  • You can find and fix them easily with Overpass or with ctrl F in JOSM. Osmose is also really helpful.
  • In rare cases the multipolygons are part of something larger. This is usually an error, but do try to understand what previous mappers attempted to do so you can fix it without obscuring or deleting what they were trying to accomplish.
  • There are also multipolygons with multiple members but still no inners. Most of those can technically be converted to closed ways too, but by doing so you might step on the toes of mappers who actually prefer that way of mapping, as I found out the hard way.
  • 1-member multipolygons with the inner role on the way are usually missing their outer counterpart, so don’t delete these outright but look first if the outer still exists and re-add it if that’s applicable.

If you have more questions I can probably answer them.

P.s. there are also cases like a field or amenity mapped as multipolygon on top of a hedge/fence/wall way. You can make those into overlapping ways. The validators will moan about it, but there’s nothing technically wrong if you make this change. Just make sure to not merge the field/amenity and the barrier into a single way, because that violates the “One feature, one OSM element” principle.

11

Another thing to be careful about is the area-ness of objects. Multipolygons are implicitly areas, while closed ways are only sometimes areas, based their tagging. (The classic OSM example being hedges). Converting between the two may introduce ambiguity.

1 Like
12

In the linked issue, the multipolygon relation had two outer ways, apparently the result of splitting what had been a single area way. At some point, iD was fixed so that, if you select both of those outer ways and merge them, iD would automatically move the relation’s tags to the remaining outer way (turning it back into an area) and delete the relation.

So if you need it, one counterintuitive shortcut for simplifying a single-member multipolygon is to split the outer way and merge it back together. But rest assured that, even though you can simplify such multipolygons, they aren’t inherently invalid and they won’t break half-decent software.

4 Likes
13

Oh sorry, confused with another case. Still applies to untagged single ring in general, disregarding whether it has been split. That’s a stupid good trick though.

14

Check that the way is not used in other relations.

There are some cases where one closed way is used in several one-member relations.