Hey Brian, I'm wondering about your rationale for deleting the relation here? Bays overlapping lakes are standard in OSM, at least now in 2026.

Thanks for your response. I fixed up the area in changeset/178361486.

Oh okay, thanks for the feedback. I reverted the tag removal and added a note.

Hi Adam! Naturally someone could paddle anywhere on the lake in good weather. Really this is less about strict modeling and more about creating a safe and intuitive paddle network for routing. For a large body of water it seems natural to me to follow the shoreline and only traverse open water where the distance is shortest. Though I'd fully expect an actual paddler to cut across wherever they felt safe doing so. Check out the rendering here: https://opentrailmap.us/#map=9.42/44.6824/-73.3895&mode=canoe

I would agree this could be further improved, e.g. by specifying why something is canoe=discouraged, or using canoe=yes but having enough other tagging for apps to draw their own conclusions.

Lake Champlain is a tricky scale because there are lots of islands and it's much smaller than the Great Lakes, where I think you'd definitely use canoe=discouraged for flowlines. But there's still a risk of capsizing in cold water miles from shore in high winds, and we don't want the map to entreat paddlers to make risky decisions.

Sorry, I should have included a link. In this changeset you added water areas like way/1458917115 and way/1458917107 which prevent the islands from showing. I'm wondering if this was intentional?

Hi, did you mean to add water areas over the boulder islands? It's not clear what's going on here.

Yeah I was sort of shocked at how few boundaries had population tags. I guess no one was really using these for labeling. I cleaned up most of them in North America but only where the boundary has a label node with the same name, which isn't true for a lot of townships and counties.

Hmm the docs must be out of date. There's nothing wrong with adding label nodes to type=multipolygon relations. Archipelagos need these since most apps force the label to be within the geometry of the feature but for these you'd typically you'd want the label outside.

Lol I meant Bermuda

Hi Udarian, thanks for the note. This is straight from the USGS dataset, which unfortunately isn't always as precise as we'd expect in OSM. Looks like this station has only been active since Nov 2024, so it might not appear in imagery yet. I added a fixme to resurvey when possible.

Hello again. I took the liberty of moving the main relation back to including all segments: relation/4485206

But I also left all the day trip segments and linked them to the guide webpages. The new super relation is here: relation/20015762

I don't think there should be any issue with the two methods living in parallel as long as the tagging is correct.

Hi, thanks for your reply, I see your reasoning now. Given that the trail sponsor's website has a detailed guide for each segment, I think these are okay to leave in OSM. I might add specific links to each segment like website=https://www.simblissity.net/get/guide-seg01.shtml

Thanks for condensing this!

Hi haprager, thanks for your work on this trail. I'm wondering what your rationale is for splitting it into so many subrelations? A large superrelation can be difficult to manage and 770 miles isn't all that long. The CDT for example is segmented by state at the moment.

Hello! Just noticed this changeset and am wondering if we can discuss further. I agree Long Island Sound is different than a bay like the Chesapeake Bay, but I wouldn't call it open ocean. I think the flowlines are useful here but maybe I'm missing something?

Hi silversurfer83, thanks for your review.

I see your point of view, but I'd note that the wiki isn't authoritative and that adding this type of clarity reduces the burden for apps to use OSM data.

This is because there is no native area type in OSM, so currently each app needs to maintain a list of what tags imply area geometry on closed ways. Ideally this could be done by looking only at top-level keys without caring about the values, but `aeroway` is different than keys like `highway` or `building` in that it's commonly used for both lines and areas, not merely one or the other. Adding `area=yes` to closed `aeroway` areas resolves this ambiguity without affecting existing apps whatsoever.

Hi Mateusz, I documented the meaning of this tag on the wiki page you linked, including what may be sold there. "Camp stores" are very common at North American campgrounds and don't fit well under other `shop` values.

Hi archiarch111, welcome to OSM. Seems like you were experimenting with mapping here, but accidentally removed some of the tagging information. I fixed the issue for you. I encourage you to read more about OSM before making more edits: https://learnosm.org/ Let me know if you have any questions!
-Q

Interesting. In the US we don't really have anything like European "node networks". And it's pretty common for named routes to be incomplete and therefore discontinuous. What is the issue you are trying to address here? The current mapping seems okay to me.

Okay, I'd say that `highest_point` is a little different than other "important features" because it's fundamental to the physical 3D shape of feature, bounding the feature by the z axis while the multipolygon ways bound it by the x and y axes.

But yeah, personally I think it's okay to use mapping patterns that are convenient but not strictly necessary (as long as they are accurate and useful). In this case I tried to lay out why it's indeed necessary to mark the highest point explicitly in order for an app to know this value. Wikidata is great but it's not a replacement for OSM.

I don't really see iD's relation handling to be an issue here since I haven't heard of any problems like this with `admin_centre`.

If you're a local mapper then by all means, feel free to remove the memberships if you want until this can have a broader discussion. But please retain the values in the US since the local community here doesn't seem to have an issue with the pattern.