According to Mountain Trails this Trail's official name is Tricky Pickle. Can you please provide evidence that is it named Bob's Bad Mountain Cut Trail. Thanks.

Ok, thanks!

I want to clarify that I wasn’t trying to change the boundaries of Ogden Valley. Honestly, those boundaries aren’t my focus, and I have no intention of messing them up—intentionally or otherwise. My main goal was simply to clean up the overlapping geometry in North Fork Park. Most of what I adjusted was ground cover that a previous user had added, and I was just trying to tidy it up to make the park’s boundaries stand out more clearly. While ground cover data is useful, it’s usually not the main reason people look at a map.
I admit I’m not fully following everything you mentioned about the Weber County GIS system, future modifications, or the process of publishing final changes. If I understand correctly, it sounds like a government agency will eventually update the Ogden Valley boundaries, which is great.
For my part, I don’t plan on changing those boundaries, but I also know that, given the open nature of OSM, things can change as others edit the map. That’s just part of how the platform works. I’m not trying to be difficult; I just genuinely don’t know how I can accommodate your concerns in this case. My intention was only to fix the park’s geometry, not alter the boundaries.
Let me know if there’s a specific way you’d like me to proceed, or if there’s anything I can do to help keep things running smoothly.

I’ll do my best to improve, and I appreciate the feedback. That said, I want to be honest—I'm unlikely to go into extensive detail moving forward. I know that might not be the ideal response, and I don't mean it to come off negatively.

The reason is based on a past experience where a well-intentioned, detailed description led to a serious misunderstanding with another user. Despite my efforts to clarify, things escalated, and it ended up causing ongoing issues outside of the platform. It wasn’t entirely their fault or mine, but I realized afterward that a simpler comment would’ve avoided the situation altogether.

Since then, I’ve adopted a more minimal approach to commenting—not out of disregard, but out of caution. I focus instead on making the highest quality edits I can. In my experience with OpenStreetMap, too much explanation sometimes opens the door to more miscommunication, not less.

That said, I do understand the value of comments for collaboration, and I’ll make an effort to be a bit more clear when it’s helpful. I’m always open to constructive dialogue and working with others, but I also want to avoid repeating a situation that was difficult and counterproductive.

Hi,

Thanks for reaching out—and I really do appreciate the time and thought you’ve put into mapping this area, especially having visited it in person and using satellite imagery to assess the vegetation. That kind of careful work is valuable and helps improve the quality of the map.

I wanted to explain more fully why I deleted the polygon and why I believe very large ground cover polygons can present challenges in OpenStreetMap, even when they aren’t extremely complex in terms of vertices or relationships.

There are a few reasons this approach can become problematic:

Editing Performance and Stability: When large polygons do have many relationships—whether now or in the future—they become harder for the editor to render and manage. I’ve run into slowdowns, errors, and rendering issues, especially when trying to work within large multipolygons that have lots of inner components.

Error Tracking: If there's an issue like an unclosed way or a small geometry error, it's much harder to find and fix in a large polygon with many relationships. The bigger and more complex the structure, the harder it is to debug.

Broad-Stroke Mapping: These large polygons tend to “paint with a broad brush.” Even if accurate in general, they often don’t reflect local variation and make it more difficult to add detailed features like parks, campgrounds, water bodies, or residential areas. These features can end up overlapping or needing to be added as inner polygons, which increases complexity.

Long-Term Maintenance: From experience—including work I did around Zion National Park—I've found that large polygons often need to be broken up as more detail gets added. I initially tried to keep large polygons in place, but the amount of relationships they accumulated made them hard to edit, prone to errors, and increasingly fragile over time.

Future Development: In this particular case, the area around St. George is going through ongoing and upcoming development. I expect more roads, buildings, parks, dams, and reservoirs to be mapped in the near future. Leaving a large polygon over the area makes detailed editing more difficult for those contributors.

Even though the polygon in question didn’t yet have inner relationships, I felt it was still contributing to the broader issue I’ve seen emerging in the region. I’ve noticed more large polygons like this popping up in the St. George area, and I believe addressing this pattern now will make it easier for contributors to add and maintain detail moving forward.

I’m absolutely not trying to dismiss your work—it’s clear you’ve put real effort into it. I just wanted to offer a full explanation of my thinking and experience with these kinds of issues. If you'd like, I’d be happy to collaborate on a revised approach to mapping ground cover in this area that balances broader context with local detail.

Thanks again, and I appreciate you taking the time to follow up.

Astotes, looks like you are a new mapper. Welcome to OSM. We hope you'll have much to contribute. I've seen a few of your edits already and you have made some good additions. This edit, however, introduced some significant errors with the relationships. I've fixed them, and some disconnected trails from another edit, but I did want to point that out so you can be aware of it as you continue to learn and map. There can be a steep learning curve to OSM, especially relationships. If you have questions I'm happy to share what knowledge I have. Happy mapping.

Hey, your call out is deserved. Just so you are aware I've been working on composing a thoughtful response to this mapper. Life has gotten in the way and I'm just behind on finishing it up. My intention is not to discourage new mappers. I'll get a response out as soon as I can. I wasn't even aware of the meetings untill about a week ago but I'd like to participate at some point.

I agree that it’s easier to make edits and changes when the geometry doesn’t overlap, and that’s probably why people often recombine the pistes when they see I’ve split them into separate ways. It’s likely a losing battle, but I think it’s worth trying to maintain the separation for all the reasons I mentioned earlier, as it helps with accuracy.

Ultimately, though, I’m not the final say, so you and others can make different choices. That said, I’ve made a lot of edits to the Nordic routes throughout the state, and since I know you do a lot of mapping, you’ll probably encounter other Nordic routes I’ve mapped. I wanted to communicate the logic behind these choices so you can decide whether to continue this approach or not, but at least you’ll understand the reasoning and intent behind it.

Your change wasn’t significant, so it’s entirely up to you whether to revert it or not. If not, I might revisit it at some point.

Hey, just a quick FYI. I'm aware that piste and highway features can share the same way, and they don’t necessarily need to be overlaid. In theory, the tags should be structured in a way that clearly distinguishes which tags belong to which feature when they share the same way. However, I've noticed that in practice, many systems don’t always interpret these distinctions correctly. For instance, even if the piste:name tag is present on a way, the name tag is often used in its place.

There are cases where the names of roads, trails, and pistes differ. When this happens and the name tag is applied to both, it can introduce small inaccuracies. I’ve found that if I separate the piste into its own track, I can use both the piste:name and the name tag to ensure that the name of the piste gets applied accurately by the system interpreting the tags.

To help prevent misinterpretation, I sometimes overlay a piste way on top of roads or trails to make the distinction as clear as possible. However, I’ve seen some cases where people will then re-combine the two ways back into one. While this isn’t technically incorrect as you've mentioned, it can lead to issues with how the tags are interpreted by systems that might struggle with these distinctions.

I understand that we're not supposed to map with a specific interpretation in mind, but my approach isn’t about shaping the map for any one system. Rather, it’s about mapping in a way that reduces the chance of any system misinterpreting the tags.

I just wanted to share the reasoning behind my decision to overlay the piste.

Thank you for reaching out, and apologies for the delayed response.

I completely agree on the importance of verification and careful tagging. I use multiple official public sources, such as the NFS, BLM, NPS, and local management, as well as global heatmaps, various imagery sources, and public GPX tracks. I rely on a combination of these sources rather than any one alone to ensure a comprehensive approach when updating trails.

We differ slightly on the idea that "if there's a visible trail, it belongs in OSM." Many visible trails are damaging shortcuts or closed paths, so I believe careful consideration is needed to promote sustainable trails. What we map in OSM often appears in services like AllTrails, and the public may use these trails regardless of their official status. Including informal or closed trails on the map can lead to resource damage, especially if they are unofficial or shortcut established routes. My goal is to make OSM useful while contributing to responsible trail stewardship.

In this changeset, I removed trails added by a mapper who has a tendency to include any path walked by humans. I've seen them re-map trails I've updated as closed or abandoned per local management guidelines. My intention isn’t to criticize, but to explain that they add many trails without fully considering the impact.

For trails like these, I generally use highway=abandoned and add a note to prevent reopening. I probably should have applied this more in this changeset. However, many trails—particularly on ridgelines—had no visible, walkable path according to multiple sources, so I chose to delete them instead of tagging them as abandoned or closed.

This reflects my process and methodology. I’d welcome your thoughts.

Also, thank you for all your hard work—I see the significant contributions you make throughout the state.

Yes, tourism=camp_site is very intentional since tourism=camp_pitch does not get rendered on the map by OSM, nor many other mapping systems. So if you want to show the sites/aka pitches on them map unfortunately to "correct" tag, tourism=camp_pitch, is not effective.

I apologize for the delay responding but I wanted to verify some info first. While some of the documentation about tourism-camp_site vs tourism=camp_pitch is not as clear as it could be, and thus leaves the interpretation somewhat ambiguous, I think technically you are correct.

Howerver, tourism=camp_pitch, while technically the appropriate tag, doesn't prove to be the most effective tag and here is why I say that:

--OSM doesn’t render tourism=camp_pitch when mapped as a stand-alone point
--OSM doesn’t render tourism=camp_pitch when mapped as an area
--OSM will flag tourism=camp_pitch with an error if it is not a stand-alone point (meaning it cannot be connected to the drive way of a camp site without throwing and error--and again OSM won't render it any way.
--Most 3rd-party systems don't render tourism=camp_pitch either

(I tested this but feel free to let me know if I made errors)

Ultimately a map should be useful. Showing the individual camp sites and site numbers within a campground is helpful. tourism=camp_pitch is supposed to be the appropriate tag for this; howerver it is tourism=camp_site and tourism=caravan_site that are proving to be more effective tags for campsite mapping.

Let me know your thoughts. Ultimately I don't know everything, but I've found this to be a more effective mapping strategy. But I'm happy to work together if a better solution exists.

*some mapping systems will not show a name for the piste unless it has a psite:name tag*

I've noticed that some mapping systems will not a name for the piste unless it has a piste:name tag, even if there is a name tag. So I've been adding the name and piste:name to pistes for good measure.

The official name is "Bell" Canyon. All the signs, city website documentation, etc. list it as "Bell" not "Bells"

Here is a link to a Google Street View of the "Bell" Canyon Preservation Trailhead Sign: https://www.google.com/maps/@40.5719508,-111.8000785,3a,15y,127.34h,83.97t/data=!3m6!1e1!3m4!1sb18hO2NC3BObnLZ0zsQ2dA!2e0!7i16384!8i8192?entry=ttu
---

Published using OSMCha: https://osmcha.org/changesets/136751827

It's alright. No apology needed. :)

I'm not exactly sure I understand your question. It seems you are referring to the way for "Upper Cottonwood Rim" trail that I marked as abandoned. If so, all the tags are still present from before, I just marked it as abandoned as the info I had at the time was that the "Lower Faulty" trail is a newer, more maintained trail, that is supposed to be a replacement; and the cottonwood trail is not really used anymore. If my information was wrong feel free to make the appropriate changes. If you're referring to something else please let me know. Hope that helps.

That tag was not something I added when I updated the alignment of the way/trail. I also didn't look at the old tags because I was just updating the alignment with newer imagery and heatmaps. According to historical change logs it appears that "time" tag was added over 10 years ago. My guess is that it was probably originally meant to be how long it took to hike this trail, but if that is the case it is an irrelevant timeframe in my opinion. eel free to make any necessary changes though.

I think in most cases the official naming is a good idea. With this trail, though, almost no one knows it as anything other than "Donut Falls Trail." this section from Cardiff Fork Road to the trail that is now called "Donut Falls Connector" is a recent addition and when this new alignment was built out a few years ago the only name associated with it was "Donut Falls Trail." In fact the signage says "Donut Falls"

When viewing other USGS sources the "Jordan Pines" is not in use and the old name for the "Donut Falls Connector" was just part of the "Donut Falls Trail" https://ngmdb.usgs.gov/topoview/viewer/#15/40.6447/-111.6579

Give the historical use of the name "Donut Falls Trail", the fact that signage either uses this name or is absent of the official "Jordan Pines" name, I think it would be confusing to the public to change the name of such a high-use trail to an unfamiliar name. This is why I switched it back.

For the record, though, I did not switch back other trails that you updated with official names...despite my favorite name, "Red, White, and Bluebird" being removed. I'll leave it to you to decide if that one should stay. lol :)

Just to be clear, I mean no offense. I'm happy to correct my mistake and work to prevent such mistakes in the future. Any insight you have into how to better identify sources that I should avoid I would appreciate. I thought I got this one correct but clearly I didn't so I would appreciate opening a dialog so I could learn from you. Thanks.