Residential roads like Orchard Lane should be tagged highway=residential (as it was before), not highway=track. If it's unpaved then use the appropriate surface tag. See: highway=track#How_to_decide

There should definitely be more page on the wiki on this. But on the Key:access page, it says under List of possible values for access=no: "No access for the general public. Consider using additional access (like foot=yes or bicycle=permissive, etc.) to indicate who can use the element."
And under Transport mode restrictions it gives the example of access=no + bus=yes, among others.
Also from the dedicated access=no page: "access=no, as any other access=* value may be overridden by more specific access tags. See access=* to see in detail how access restrictions are defined. E.g. a road tagged access=no and psv=yes generally withdraws any legal right of way but permits public service vehicles."
access=no
Probably don't have to revert the whole changeset, can just find the specific cases with overpass...I can do that if you want

There were valid cases where bicycle=yes was being used to override access=no/private/etc, for example way/765837446. Technically it could also override vehicle=* but I didn't find any cases. access=*#Land-based_transportation

Why add bicycle=yes to highway=residential? As per wiki it's already implied.
bicycle=yes
and
osm.wiki/OSM_tags_for_routing/Access_restrictions#United_States_of_America

Hi, welcome to OSM. A couple of issues here. It seems you've mixed up cycleway:left and cycleway:right, for example on Asylum Ave, like way/613147760, it should be cycleway:left=lane and cycleway:right=no. Also, you've added cycleway=lane to a few ways that already have cycleway:both. Last, it seems on way/17189426 you added cycleway=lane but there are some sections (like south of Saint James Street) without a bike lane, only with sharrows, so you can split that and add cycleway=shared_lane. Thanks

Hi, a couple of notes:
- this section of the "cycle track" along the divided part of Edgewood Ave really just a lane according to osm definitions since there isn't any physical separation, hence why I had tagged it as a cycleway:left=lane previously, not a separate highway=cycleway.
- you accidentally connected a node to the road under the bridge
- the bridge section should be connected to the man_made=bridge outline
- the thing where you're adding access=no and whitelisting specific types of transport is unconventional/wrong. Particularly I noticed on way/39414553 that you added access=no and motor_vehicle=yes but this doesn't include other types of transport that can legally use it. For example, bicycles (bicycles aren't legally required to use the lane/track). Just follow the example of other roads and omit access tags unless they are different from the default access restrictions. I noticed you did the same on MLK as well.

Hi, I saw you added separate highway=cycleway ways along 25A but it's really reserved for cycle tracks (rather than bike lanes), and with physical separation from the roadway. See the wiki pages "Bicycle" and "highway=cycleway". I'd suggest it returns to the previous tagging with cycleway=lane or cycleway:right=lane on the road

Thanks -- yes. To answer the question you asked on the other changeset for the boundaries, I used another resource from CT ECO, which is pretty much a compilation of each individual town's GIS data: https://cteco.uconn.edu/data/parcels/index.htm
So I just imported the parcels directly from what the town supplied.
I wonder how the sources compare -- for example with the data I imported it was previously super accurate in at least one area: the boundary of Bluff Head with Great Hill Rd. It had tons of nodes and closely followed the edge of the asphalt surprisingly accurately within ~1-3ft. But I notice that it's now kinda crossing the road a bit and doesn't appear as accurate.
On the other hand, the data from Guilford didn't match up with the town lines near the Durham-Guilford-North Branford corner particularly well, which is why I didn't join Northwoods / James Valley directly to the town line there. So I'm not sure if Guilford's data is off or the OSM town line is off.

Hi again! I'd suggest checking out the layer "CT ECO Shaded Relief" in the iD Editor you're using. It's an extremely detailed elevation map of the state of Connecticut created using LiDAR. It's so detailed that you can usually clearly see the ~1ft deep depressions of hiking trails in the earth, so it's extremely useful for aligning trails. Generally this technique produces much better results than only GPS field recordings -- you can see it's about 20-30ft off in some places. Not a big deal of course but still a good resource

Careful with using the layer tag to resolve errors. Often it's a symptom of a bigger problem...adding layer=-1 or whatever to it will only make it harder to spot those bigger problems. For example adding layer=-1 to way/217341971 when that doesn't actually represent how it is in real life in relation to the building it was overlapping (plus, it isn't underground).
layer=*#Guidelines
Thanks

Hi, sorry for the late response!
- On "Inc", you're right, it looks like there was a mix before. The properties in North Guilford seem to have it without the "Inc" at least, as well as Eastwoods. There's no OSM standard for this, I'll leave it to you.
- On UConn MAGIC imports (usually natural=wood), yes there a lot of issues there. The accuracy can be very bad. But the main issue is that while they initially represented nature reserves and open spaces, they were imported in ~2009 with only natural=wood, which by itself only says "this is a wooded area" rather than “this is a protected wooded area”, or “this is a property line”, or anything about access. So somewhat understandably, other mappers over the last decade have sometimes modified these to match the woods better, meaning they no longer represent the property lines as they were originally intended (not that they did that very well either).
The ideal way to map things is to have completely separate elements: one just for the boundary (leisure=nature_reserve), and others for the physical land cover (wood/meadow/water/beach/etc). You can see an example of what I've done over at Lake Saltonstall in Branford. The boundary is self-explanatory, but the land cover often creeps past the boundary into private land, because that's just how it is on the ground. I don’t think access should be assumed either way for physical land cover like meadows/woods unless it has a name or other tags.
For the MAGIC imports, feel free to remove them if they’re too far gone, i.e. not representing either the property or the physical land cover particularly well.
By the way, as a proof of concept, a few days ago I redrew all of the Northwoods boundaries (from a better source than uconn magic!) and did some work on the relations. I hadn’t previously mapped anything like this where there’s a named protected area (e.g. Bluff Head) within a larger named area (Northwoods), and I wasn’t completely sure it would work nicely, but it did. I also wasn’t sure which parcels are part of Bluff Head vs. just part of the larger Northwoods, so perhaps you could let me know or fix it yourself. I assume every parcel north of Quonnipaug is considered part of Northwoods? Anyway, you can perhaps use this as a template for other properties that have named subset of a larger named set of properties.
One more thing. Ultimately the vast majority of end users interacting with OpenStreetMap data for hiking and biking will be doing so through AllTrails and Strava. Unfortunately, I don’t think either of these apps display any information in tags aside from the name.

Hi, welcome to OSM. Thanks for fixing the typo in the website. Any reason you removed soul_food from the cuisine tag though?

Hi, welcome to OSM. I think these might be better tagged with highway=service, as they are service roads to buildings. If they're unpaved you can add surface=unpaved.
highway=service

I'll have to check out the new trails here soon! If you haven't already, I'd recommend checking out the new "CT ECO Shaded Relief" imagery that Mashin set up. It think it's available in iD. Probably not that useful for the new trails, but the resolution is so good that you can clearly see many older trails carved out into the earth. It should be more accurate than a single gpx recording, in the woods at least.

- The way you're currently using 'note' seems like it's aimed towards the end user, but the tag is actually only displayed to other mappers. You might put that info in the 'description' tag instead.
- 'notes' isn't really a standard tag (even among mappers) and it won't be shown to any end user either. It's completely fine to add multiple notes to the standard 'note' tag instead.
- 'start_date' must not contain English like "Property acquisition dates". It should be a single machine-readable ISO8601-formatted date, such as "1991-07-27" start_date=*
I'd use the earliest date.
- Similarly, 'ref' shouldn't be plain English. I'd recommend removing the ref tag / assessor numbers altogether. Anyone interested in that can probably go to Guilford GIS or the town assessor instead.
- The child ways shouldn't have the tags that are already on the parent relation. You can remove 'leisure=nature_reserve', 'natural=wood', 'operator', 'opening_hours', and the address tags from the child ways.
- And small note, we had previously been using the operator "Guilford Land Conservation Trust" without the trailing ", Inc.". I'd be happy to switch to it with, but it would be good to switch over the other properties for consistency at some point (no rush).

The norm is to just rely on the one relation and omit the smaller details of the constituent parcels, but at the same time, more information isn't necessarily a bad thing.
I would suggest having individual polygons at least for the parcels with actual names, i.e. "___ Open Space".
Then for the parcels where only the prior owner is known, you can certainly leave them as a conglomeration if it's easier, but move the names to some other tag. I would use the "note" tag, and use a plain english sentence like "Parcels donated by _, _, and_".
note=*
If there was a case I didn't cover let me know, or you can also just default to removing the names from the polygons and moving them to the note tag. I just confirmed this with Mashin as well.
Thanks,
Andrew

I just caught myself doing it twice again...I upgraded JOSM yesterday and I think some key or mouse binding must've changed, but I'm not sure what it is!

Thanks!

Good to see GLCT on OSM! Would it be possible to split way/1126744314 into multiple ways with their own names? It's a little cluttered with the comma-separated list of names. And there's a similar situation over at Westwoods. Thanks.

Are ways 701004264 and 93968317 (Norwich Avenue) really cycleway:both=lane? On Bing they look like standard shoulders to me, not bike lanes.