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.

Hi SD Mapman, thanks for working on this route. Are these crossing routes signed on the ground? I'm not seeing them in the official data here: https://www.arcgis.com/home/item.html?id=56a1786b38354612b25a02774364b6f3

Oh interesting. I appreciate using parcel data for boundaries, but IIRC the rail trail ROW is owned by SEPTA but leased to the county and is fully operated as part of the park. Also the buildings at 40.098401/-75.073375 are integral to the park and not part of the railroad property (I lived in one of them for ~20 years)

Hi pkoby, I'm wondering why you replaced and moved lot of nodes along the Lorimer Park boundary. A lot of them seem misaligned, like the west boundary near the main parking lot on Moredon Road.

Hi, welcome to OSM. Just letting you know I had to revert this changeset since you turned the Dayton boundary into streams. I assume this was accidental. I recommend reading up more about OSM mapping before making more edits. Also, note that the warnings in the editor are just suggestions and it's not always correct to click one of the quick fix options. Let me know if you have any questions!

Hi ChristianahAde, thanks for trying to add the Saint Johns River. Unfortunately this feature was already mapped in OpenStreetMap, so I had to revert your edit. I'd recommend reading more about OSM data before trying another edit. Let me know if you have any questions.

*Remove boundary=national_park tag from members of protected areas

I would actually go the other way and say there should be 100+ ranks. A typical use case for this tag would be to show important features on maps at lower zoom levels than their tags would otherwise suggest. So if I'm looking at a general-purpose map of Chicago I would want every building and every sculpture labeled, but I would expect that the bean and the sears tower would be labeled. But when the labels collide I would expect the sears tower label to be prioritized because it is a more prominent landmark. And this has to scale to every zoom level. Having a wide range of ranks allows for more granularity. The exact differences don't have to be defined, just the relative importance between features.

Thanks for reaching out. This is a new tag I'm just experimenting with. I'm not satisfied with my initial round of `landmark` values (they're too low) but the idea is to have a way to convey notability for maps and search. Open to feedback!