Help me understand why my changeset broke this park

I pushed this changeset, and it ended up breaking the park so that it no longer showed on the map. I couldn’t figure out what I did wrong, so I had to revert it, as I couldn’t fix it.

All I did was remove the old ways making up the park boundary, create the replacements, then I added them to the park boundary relation. I didn’t add or change any tags.

For reference, here is a visualization of the changes.

1 Like

Separately from what might have happened here, but which map did it no longer show on? The “OSM Carto” layer at osm.org has a fair amount of server-side caching, so whether or not it shows might not be related to your most recent changes.

Did you click the “validate” button in JOSM for the relation after the 161483317 changes? There are a few new relation members in that changeset; I can’t obviously spot a geometry issue in there but there might be something.

Edit: I tried running the validator at the post-161483317 state (using the revert plugin in JOSM but not uploading anything) and I think that Way History: 1352286496 | OpenStreetMap was self-intersecting after 161483317 - that might have been an issue.

1 Like

I only checked Carto.

Yeah, I’m aware of that and the refreshing that has to be done for changes to show. That isn’t the issue here: I wasn’t waiting for something to show, — the park gradually disappeared as the map rendered the changes.

Yeah. Both manually before upload, and JOSM also automatically validates before an upload completes.

Yeah. That was pretty much the entire change. I deleted the old members, and replaced them with updated ones. The park is a boundary relation containing individual chunks of ways that describe its segments. The existing ones were out of date (inaccurate) so I deleted them and replaced them with up-to-date ones from open data. In JOSM, I literally just deleted the old members, then added the ways from the new dataset to the relation. I didn’t even add or modify any tags. I just removed the automatic ones from the dataset.

Hm, maybe. I would be surprised if that’s the case though. The intersection is just a single shared node in one of the members. I can try to upload the other segments of the data that don’t have that intersection and see if it works. I think I remember reading that if there’s an intersection like that it can be fixed with a multipolygon, so if this is the issue, I’ll prob try that to see if it fixes it.

1 Like

Okay so I did a test of just uploading a smaller chunk (not including the one with the self-intersecting way), and it uploaded and rendered fine. So, yeah It must just not like the way with the self-intersection.

Alright so it looks like the issue is fixed! It turns out it was an 8 Area Error. So I split the way at the intersection point, and specified the inner bit as an inner of the boundary relation, and the outer bit as the outer of the relation. Works fine with the intersection point. The tagging for that way was put on the outer one.

2 Likes

This case of intersecting areas in a single node is only an “informal” warning in JOSM. You need to enable “informal” warnings manually in the preferences but be warned that these warnings might contain lots of false positives.

Mmh, by rule an intersection in a single node is valid for multipolygons and especially boundaries. That is the reason why it is only an “informal” warning in JOSM. There are plenty of real world cases, so a renderer should coup with that.

The wiki is about buildings. where it makes sense to split it into two parts. Your approach with the “inner” and the “outer” part is correct but I do not see much difference between version 21 and 28 except that all member ways where replaced by new ones. I looks to me that we are looping and that it might rather be a problem of the renderer (and the tagging of boundary plus leisure on one object). What are you trying to solve?

If you can point to one in UK or Ireland I can tell you whether a few popular ones do :slight_smile: