I haven't heard back on this issue and am now reverting it. I am open to further discussion or communication.

osm.org/changeset/165610951

Thanks for the detailed and comprehensive reply. I would love to collaborate with you further about the groundcover approach here, I've seen your work in ZNP and appreciate it.

I do still think that deleting this feature is not the most effective course of action, and to explain that I'm going to try to address your points 1:1, and then present a thesis at the end.

Editing Performance and Stability: It definitely is more computationally intensive to deal with larger polygons and relations, however, in that OSM's ethos is to map what's there, I don't think this presents a reason not to use large polygons when the real world features they represent are, themselves, quite large and complex. This heath (sidebar: heath really isn't a great description for this groundcover, but it's the closest tag that presently exists. I enter information about vegetation and soil in the description in the hopes that one day we'll have better tags and that information will make the migration more seamless) is a pretty expansive feature, and it makes sense that a pretty large multipolygon would be required to represent one enivronment/habitat segment with one digital object.

Error Tracking: I haven't run into any issues with this, even at grand scale. iD's built-in tools do a pretty good job of leading you to issues, and where they fall short it's never taken me too much work to track down the remaining errors (I redid the topology on Lake Marion in SC a year or so ago, it was represented by something like 80 polygons with identical tags quilted together. I definitely encountered geometry issues in that process, but found the advancements for rendering and representation to be well worth the trouble).

Broad-Stroke Mapping: I absolutely agree with you that large groundcover polygons have a tendency to paint with broadstrokes, but I argue that broadstrokes are a vast improvement over a lack of strokes. I never intended for this feature to last forever, my hope was that it would undergo significant refinement and probably reduction over time to become more and more representative of what's there. I've had really good luck with that approach mapping in NC where a lot of large features like this already existed and I was able to refine them to get a higher level of detail over time. I found that workflow to be very efficient while also preserving feature history.

Future Development: as you said, this area is changing rapidly and there are going to be roads, parks, etc. being within this multipolygon over the next five years. My argument is that while reducing the size of this polygon to reflect that development is an extra step for other contributors, it isn't a challenging one, and is outweighed by the value of being able to see changes in vegetation over time on the map, through tools like openhistoricalmap. The data on OSM isn't anywhere near this point yet, but having an open data set that shows how development effects groundcover seems didactically invaluable to me.

This polygon actually did have two inner relationships, and probably needed two more. Which does support your point, but I still think is the most effective way of representing what's on the ground.

I am probably the source of a lot of the large polygons you've been noticing around st. george. A lot of them are just updating deprecated tags from existing natural=desert polygons making the polygons more visible. Some of them, however, particularly in Red Cliffs, are my own work exploring the region and representing it to the extent that I can. The borders are arbitrary because they represent the extent of the range I've assessed on foot, and many of them have numerous internal features because of the way the Navajo sandstone sporadically punches up through the eolian sand deposits that support most of the vegetation in that area. I find that kind of detail and continuity incredibly valuable when out in the field, knowing precisely where there's hard rock gives me tools for LNT when I have to get off trail, and knowing that I can expect the vegetation on either side of a knoll is a continuous habitat gives me ideas of what critters I might expect to find while I'm out. My intent is that future mappers be able to expand, refine, or reduce these features over time on the basis of their own ground-truthing.

I am curious to hear what design principles you followed in and around ZNP, and how you feel they would best be applied down here off the colorado plateau.

Thanks for your work in the region, and for taking the time to have this conversation, especially with such care and detail.

I look forward to hearing more from you, thanks for following up.

I disagree with deleting this feature. The boundary is a bit arbitrary, it's fair to say, but I had visited that area and assessed the vegetation, then used satellite imagery to mark boundaries. I can see you've marked some construction features on the east side, and I'm open to refining the geometry to reflect that development. As for being overly large, I'm not sure what issue you're running into, this isn't an exceptionally large feature, either by area or vertices, could you clarify? If I don't hear back from you I intend to revert this change.

All good, glad to have another mapper in the area. Feel free to message if you have any questions about finding documentation or anything else.

I haven't been on these roads, but I suspect from satellite imagery that they'd be most accurately marked as track/land-access road, documentation here: osm.wiki/Tag:highway%3Dtrack

These roads are not residential in nature. Adjusting tags to get a different appearance (or navigation characteristic) on a specific app or platform is considered bad practice (often called 'mapping for the renderer'). It is important that tags accurately reflect what exists on the ground, and it is the responsibility of the renderer or navigation tool to use that data effectively. Please see this documentation page for residential roads:
osm.wiki/Tag:highway%3Dresidential
---

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

Hey! I never saw these comments when they had been made (I'm still not super confident of how to get notified of them). I had changed the format to reflect what was commonly used by the people I was around while I lived in that area. In some places outside of Utah street signs with labeled prefixes are the norm, but I was only aware of two or three roads in Utah that were actually labeled with a prefix. I get what you mean about the format being up for debate. By on the ground principle my inclination would be to number houses with suffixes, ie 1683 east, because almost none of the road signs in Utah have prefixes, ie 400 west is a very common label for a road sign, but east 1000 west is an extremely rare one. It could be a source of confusion for someone looking for east 400 west rather than 400 west if they're from an area that doesn't have that labeling convention. That being said, this is all just my opinion on it, it looks like you have a lot of experience with this kind of thing (thank you for all the great contributions you've made); I respect the labeling decisions you've made and I think they are in line with the format guide you linked to.