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.

@dmjab13 You're probably right.

@ZLima12 I see your point, but as someone who's worked a lot with OSM data, I do feel strongly that we should try to minimize inconsistencies. More than 99% of all ways tagged `highway` are roads and paths, and we should be able to make basic assumptions about them without knowing the exact values. `highway=rest_area` and `highway=services` are notable exceptions, and require every single data consumer to write special code to properly account for them. This increases the burden for apps using OSM. Adding `area=yes` to all exceptions like these reduces the burden without affecting other applications. It's easy enough to ignore the tag.

Hi pyrog, thanks for reaching out. For the water trail discontinuities, did you mean the segments weren't ordered properly? Thanks for fixing that. For the Golden Spike Trail Network, this isn't really a route so I changed the relation to be type=network. I think it's fine to retain relations for stuff like this as long as they're tagged correctly and don't mess up other tools. I also advocate for using a descriptive value for the `network=` tag to group together related walking and cycling routes rather than using generalized blunt values like `network=lcn`, but that requires a larger discussion.

Hi there, thanks for reaching out. This is a somewhat experimental role that I've been using in the US for awhile now. Happy to revert if the local community doesn't want this data.

The highest point of a feature is of interest to certain data consumers that may want to, say, label a peak at lower zoom levels even if it's not particularly tall. Adding nodes as relation members won't mess up other use cases since most data consumers ignore node members. This pattern is similar to the admin_centre role of admin boundaries and carries similar importance. The highest point cannot reliably be found through queries since sometime: 1. The point may lay exactly on the edge of the feature (such as Mt. Everest on the Nepal/China border) and may fail point-in-polygon tests (due to precision errors). 2. The highest point of a feature has not yet been mapped (common with smaller or flatter islands and boundaries). 3. Points with unexpected `ele` values may appear in the data at any time (perhaps due to typos or bad imports).

Thanks for the heads up, I've resolved the issue. I think it just needed a leisure=nature_reserve tag.

Oh and it would be fine to add the namespace to the other tags as well if we could be sure they referred to the razed feature and not a potential current feature tagged on the same entity. Namespacing `information` is safe since it's supposed to be a direct subtype.

`information` is treated as a top-level tag by some apps like Nominatim and as a subtype tag by many others. Adding the namespace creates additional safety to prevent more apps from treating these as active data. See another example: https://taginfo.openstreetmap.org/keys/disused%3Aparking

Hi there. This is a pretty routine type of edit and was not discussed. I'm happy to revert if it messed up any data.

I think your argument has been that `information`=* can be used without `tourism=information` to indicate that something provides information without being a tourist feature? This is essentially treating `information` as a top-level tag on par with `tourism`, instead of as a dependent tag. If you agree with this pattern then I'd hope you'd support my tagging proposal. But either way, it doesn't make sense that the tourist component of a feature could be destroyed while the information part remains.

Hey there! I'm pretty sure all these `unclassified` streets in Ithaca should be `residential` based on OSM standards. What was your thinking here?

Oh neat, thanks for confirming. You might add `source` and/or `note` tags so these don't get deleted.