Nice catch!

Howdy! I reviewed your changes here. Thanks - your addition looks great! The attraction tag you added is a fine fit for this. Based on my research of this poi, I think tourism=artwork is slightly more descriptive. I changed it to that. However, if you disagree, I'd love to hear your opinion. Also, if you have local knowledge about this feature that is really valuable and we should try and capture that!

Let me know if you have any questions about this or mapping in general. Thanks again for your contribution, and welcome to OpenStreetMap!

I came through here the other day, and saw that there are no physical barriers separating most of the turn lanes in this area. Specifically I'm referring to things like this: osm.org/way/1317734950

But, I could still be wrong. Ezra, are you sure there's a physical barrier separating the turn lanes specifically on and off of 1100 South?

Regarding Organic Maps' options for street name, that app is likely searching nearby roads for available names, but only parsing name=, which is indeed just 200 East. It should be checking for name:full or name:prefix when matching addresses. Here's a link to the page that describes the way addresses are laid out in Cache Valley and much of Utah: osm.wiki/Utah/Naming_Conventions

Sorry I never got back to you on this. Originally, you changed addr:street from "South 200 East" to "200 East". Typically when rendering an address, OSM data consumers will do addr:housenumber + addr:street. Since housenumber is (correctly) 15, it makes sense to have the full street name, including "south" prefix, so that it's rendered as "15 South 200 East" instead of "15 200 East". Hope that makes sense! And sorry for the delay.

Hi, did you see my comment on your other changeset? osm.org/changeset/158468386

Hi, and welcome to OpenStreetMap! Thanks for your contributions!

One more note, just to clarify, it's absolutely fine (and necessary) to have overlapping areas. In fact, this is great because you can pick a spot and have a hierarchy of areas that encompass it, eg landuse area, city area, county, state, country, etc. All overlapping.

All that being said, nice job on getting the hang of multipolygon creation! :)

Hello again! Looking at this changeset, you created a multipolygon for the Wellsville mountain range and added the forest areas as "inner" members. While this is valid as far as relation semantics, it doesn't make sense since the mountain range feature encloses (and includes) the forests. It's not like when you enter the forest area you leave the mountain range, right? Hope that makes sense. Multipolygons with "inner" areas are to be used for things like a parking lot that wraps around a building, where when you enter the building you also leave the parking lot.

Fortunately iD makes it really easy to create them. Here's how:
- Draw the OUTER area and tag it appropriately. In this case, leisure=park.
- Using the "line" or "area" tool, draw an INNER area. Or, select another existing feature inside the one you just drew.
- Select the outer and inner features, and press C. This will create a multipolygon automatically.
- Just to double check, you should now have a relation with both features as members. One with the inner role, and one with the outer role.
Let me know if you have any questions.

Hi Ezra. Thanks for your contributions so far! One suggestion I have is that you look into multipolygon relations. I saw that you added some features that are best represented as areas with voids within them, and you used a workaround with the little sliver crack on one side. Here's more information on multipolygons: osm.wiki/Relation:multipolygon

Hi, and thanks for your contributions here and throughout Utah! One suggestion/request I have for you is that camp pitch numbers (and most numbered things) should be ref= instead of name=. More info: osm.wiki/Tag:tourism%3Dcamp_pitch

Just to be clear, I don't think features should be blindly added, either - whether that's by copying USGS topo map or strava or whatever. I get the sense that some of these were added like that. However, in my opinion, if there's a visible trail that can be walked, it does indeed belong in OSM.

Hi, and thanks for your contributions! In this case, were you able to verify that the trails you deleted really don't exist? What's your source for the deletions? Just because something isn't maintained or sanctioned doesn't mean it is non-existent. By leaving real features in OSM and tagging them appropriately (such as informal=yes or access=no) we can also prevent later unaware contributors from re-adding them anew (often with just highway=path...)

Hi, thanks for your contributions! Is Guinavah-Malibu campground re-opened?

Oh, I see. Thanks for your response! I'm really glad to hear that you're using multiple sources and not blindly going off land ownership boundaries. (IMO using just the boundaries is OK as long as we're certain they correlate 1:1 with access in a given area.) Thanks for your contributions!! Like I said, I think access data is extremely valuable for a lot of different applications!

Perhaps I've asked this before, so I apologize if that's the case.
Is your source for these access restrictions inference based on land ownership boundaries? I appreciate you working on this since I think road access data is really valuable for routing and the road network, arguably OSM's core feature. This is a double-edged sword, too, since incorrectly tagged access can have a huge negative effect on routing usefulness. This is something that has impacted me directly as a data consumer in the past.
Anyway, I just want to be sure we aren't incorrectly assuming access. Let me know what you think. And thanks for your contributions!!! :)

We'd better hope the river never forks a third time or we'll have "South Divide North Branch South Fork Ogden River"!

Thanks for catching that!