OpenStreetMap
I just realized that I should mention here that I’ve been putting a good deal of effort (in fits and starts) into combining https://www.openstreetmap.org/relation/12907666 with adjacent wooded areas and converting it and the areas around it into multipolygon geometry. It’s a huge job and I only work on it every now and then, but I’m pretty pleased with it as an example of what well-designed geometry can be.
Discussion
Comment from SomeoneElse on 2 January 2023 at 03:03
Given that it doesn’t have a name, wouldn’t it make sense to split https://www.openstreetmap.org/relation/12907666 into much smaller wooded areas? That’s going to be a monster to edit!
Comment from mmd on 2 January 2023 at 09:27
There might be a geometry issue somewhere, as the relation doesn’t render on the standard map anymore. JOSM validator reports those sorts of issues.
Comment from SomeoneElse on 2 January 2023 at 10:22
(re mmd’s comment) JOSM’s validator notices that https://www.openstreetmap.org/way/1126399098 is an inner twice, but that is the least of anyone’s worries trying to edit this…
Comment from mmd on 2 January 2023 at 10:28
I think there are more issues, like a non-closed geometry up here: https://www.openstreetmap.org/relation/12907666#map=16/43.8049/-122.6301 … You need to re-run the validator, once you have fixed all reported issue, as new issues are likely to show up then.
Comment from yvecai on 2 January 2023 at 18:57
It’s definitely a good idea to split such polygons, but that’s a huge job in itself.
Comment from marnen on 2 January 2023 at 19:23
SomeoneElse: The fact that it doesn’t have a name or any other identifying info is why it makes sense to join the wooded areas IMHO. The arbitrary boundaries between identical areas are nonsensical and should be removed IMHO, which is what I’ve been doing.
Note that I’m not treating the adjacent managed forest areas this way; I’m leaving the borders intact in case they indicate different ownership or status that can be filled in later. But one natural wooded area, with no particular difference in status, should surely be one multipolygon.
mmd: I don’t think the relation currently has any closure issues, although I’ll look at the point you mentioned. There was an error that I fixed.
yvecai: There’s a reason this is a multipolygon, not a simple way. Each way in the boundary is in general fairly short so that editing doesn’t become problematic.
Comment from mmd on 2 January 2023 at 19:38
To be more specific, JOSM complains about way https://www.openstreetmap.org/way/1000494463, in particular the part of the way starting out southbound with node https://www.openstreetmap.org/node/9235211881 … once I remove that node, and everything further south of it, the closure issue is solved. Once option to achieve this is to split way 1000494463 at https://www.openstreetmap.org/node/9235211880
Comment from marnen on 2 January 2023 at 19:40
Thanks, I’ll check that. I’ve been very carefully checking for closure issues as I go, and using iD’s closure checker and sometimes other tools, so this is surprising.
Comment from mmd on 2 January 2023 at 19:49
By the way, after splitting way 1000494463, you should see one more member in https://www.openstreetmap.org/relation/15074887 … overall you shouldn’t have to delete any nodes or ways. Splitting up one way and making sure that the right segments are assigned to each of the two relations should do.
Comment from SomeoneElse on 2 January 2023 at 19:49
No - trust me - it really doesn’t. If you join everything up into one monster multipolygon it’ll get broken immediately and be a nightmare to fix, as you’ve found. You also may find it a challenge to use iD for this, since it tries to “hide” the geometry from you, which doesn’t always work when something is broken.
I find JOSM’s validator invaluable in such cases - you absolutely ought to be using that to check for problems as you go (even if you’re not using JOSM to edit).
Comment from mmd on 2 January 2023 at 19:57
Totally agree here. JOSM reported even some more issues: three relation members should have a member role “inner” instead of “outer”.
Comment from marnen on 2 January 2023 at 20:42
SomeoneElse: “Trust me” isn’t a good argument here. I work with multipolygons frequently and don’t break them; it’s not hard. Constructing the big multipolygon, as I’m currently doing, is a little harder, but that only has to happen once, and future edits shouldn’t be a problem.
I don’t like JOSM enough to use it as my primary editor, but its validators can be helpful; I will check their output here. I’ve been also using the osmsurround analyzer, which seems to be OK on this.
Thanks for the input. I think this is semantically the right thing to do, but I want to make sure I do it correctly. :)
Comment from marnen on 2 January 2023 at 21:06
All fixed now; thanks. I didn’t realize how much JOSM’s validator caught that other tools didn’t, so I’ll put up with JOSM’s ugly UI for this. :)
Comment from yvecai on 2 January 2023 at 21:44
Of course, a valid MP is a valid MP and if you feel comfortable with those, you’re not alone. However the argument against bigones I found sensible is to think of your fellow (future) mappers to can be put away by such a complicated task when it comes to update a simple forest.
Comment from marnen on 2 January 2023 at 22:01
Huh, I’d say the opposite. I’m much more put off by redundant simple polygons than I am by multipolygons. I find working with multipolygons much simpler and easier than the alternative.
Comment from Xvtn on 11 January 2023 at 00:35
Is the ultimate end goal here to have any continuously connected wooded area be a multipolygon? So most of the western US will be included if so? I agree that philosophically it makes sense that a “wooded area” have something describing/connecting the whole thing. I also agree that lines breaking up large polygons are arbitrary and don’t reflect anything physically on the ground.
However, in practice, I don’t see what it accomplishes. I agree with yvecai that it only creates headaches in the long run.
Comment from marnen on 11 January 2023 at 01:21
Yes, it seems semantically wrong to have semantically identical areas separate when there’s no actual boundary.
To me, the fake boundaries and their semantic wrongness create far more headaches than the alternative.