I've also been following this thread without commenting in hopes of California mappers working things out among themselves. Since that clearly isn't happening I guess I'll pile on. I support a connected trunk network and I haven't found Adamant1's arguments for why a trunk route should stop at the edge of town convincing at all.

Don't worry @G1asshouse, everyone on Slack agrees with you that this should get reverted. It's been submitted to the DWG.

Thank you, OneC. Your efforts are much appreciated!

Thank you for reviewing. Please note that on its own, a sign reading simply "private" or "PVT" does not indicate access=private, only ownership=private. A more strongly worded sign such as "keep out", "no trespassing", or a physical gate indicates access=private. It's important to not overuse access=private because it is a very strong restriction and routing engines will completely avoid all roads marked as such. If you must apply an access value to road signed as "private" or "PVT", access=destination or access=delivery may be appropriate.

access=private
access=*#List_of_possible_values

Hi, OneC. It appears you are adding access=private to a lot of driveways and privately maintained roads. This is not correct unless these driveways all have "no trespassing", "keep out", or similar signs posted. To specify that a road or driveway is privately owned and maintained, the proper tag is ownership=private.

Thanks for contributing to OSM in VT, and please join the OSM US Slack where we have a #local-vermont channel.
https://slack.openstreetmap.us/
---

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

Thanks for updating the map here. I feel like there must be a good story behind this "sad experience". What happened!?

Hi, thank you for the detailed work on the Burlington Country Club. However, in this changeset you deleted a number of things without replacement. I see that you've since replaced some of the deleted buildings, but without the address information that previously existed. Looks like a forest area has also not been replaced. As this is a collaborative project, it is important to improve upon the work of others rather than deleting and replacing.
osm.wiki/Keep_the_history
---

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

https://osmus.slack.com/archives/C3LJ03BCY/p1638162053104400?thread_ts=1637039485.038000&cid=C3LJ03BCY

Hi, kevinchen1. Thanks for your edits here. However, highway=track is not the appropriate classification for this road. From the VTrans Roads dataset I can see that it is a class 3 town highway and from aerial imagery I residences and other buildings along the road. highway=track is for minor land access roads that aren't used for access to homes or other buildings. I've changed this back to highway=unclassified.

highway=track
https://geodata.vermont.gov/datasets/1dee5cb935894f9abe1b8e7ccec1253e
---

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

Apologies! Didn't mean to re-explain something you already know about. I primarily use JOSM and the orthogonalize (square/Q) function works nicely for a group of connected objects like this when you select them all together. I just tested in iD and it seems to not work so well unfortunately (I had assumed they worked the same). Seems like the iD function only operates on one object at a time so as you square one object it takes then next connected one out of square 🤷‍♂️. JOSM does have a number of efficiency boosting plugins for this kind of thing. This one might be helpful for example: osm.wiki/JOSM/Plugins/Terracer

Hey, Hugh. From the comment I'm guessing you're trying to make these parking spaces as close to rectangular as possible. I case you aren't aware there is a Square function in the iD right-click menu that will make all the corners square for you. You can also just press Q for a keyboard shortcut that does the same thing.
https://learnosm.org/en/hot-tips/tracing-rectangular-buildings/

Why restore this? Seems like a historical artifact that would be more appropriate for https://openhistoricalmap.org

Hi Necessarycoot72, it looks to me like you've re-aligned a number of buildings in this changeset by lining the polygons up with the roof outlines on aerial imagery. This results in building footprints that are often significantly out of alignment unless the imagery was captured at exactly a 90 degree angle above the building. In downtown Burlington this is almost never the case. If you want to re-position buildings, please line them up with their ground position, not the tilted position that the roof shows up at. LiDAR from VCGI is another great resource for building positioning and does not suffer from this problem.
osm.wiki/Vermont#Resources

thank you for restoring my work 🙂

Hi webfil,
This changeset left a gap in the Lake Champlain multipolygon, breaking rendering. Please be careful!
relation/132216
https://ibb.co/xst6k8w

I fixed it in this changeset: changeset/112811246

It looks like a remnant of the administrative boundary you deleted still exists. I wasn't sure if I should clean it up or not.
relation/12631636

Love it! One of these that anyone can buy?
https://order.spaghettimonster.org/Ordination/

I think it's less about a credential and more about what does this building appear to be and are there actual religious services conduced there. If I walk by it would I see a sign making it clear that it is a Church of the FSM? Would it look like a public building where people gather to worship? Or does it just look like the same normal house visible here:
https://goo.gl/maps/nVaptzgaqijBaGMe7

While I'm certainly love to drive by this building and see that it is an actual Church of the Flying Spaghetti Monster, I'm having a hard time believing it 😄. Do you have any photos or other evidence that Pastafarians regularly gather to worship his Noodliness here?

I've opened and iD issue for this false positive: https://github.com/openstreetmap/iD/issues/8724

Also, a warning in iD is not "breaking things". QA tools like this often have false positives that can just be ignored. If there is some data consumer out there that this is actually causing a problem for, that is a different story.

I see what you mean, although flagging this as a warning appears to be a bug in the iD editor. The "Broadway" way isn't even tagged oneway=yes, just piste:type=downhill. The JOSM validator doesn't flag this an an issue. Nothing wrong with separate ways I guess, but it seems fairly redundant.