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.

Hi CrunchyBrunch, thanks for adding the cycleway tags to LaSalle Road. Just a note, when using cycleway:right/left tags, you shouldn't use the opposite_lane value. In this case with a lane on both sides you can just use the value "lane" for both tags. opposite_lane is really just for contraflow lanes, and only with the non-specific "cycleway" tag. See the Bicycle page on the OSM wiki. Thanks!

Hi, FYI for most of these building=house you could have used the more specific tag building=detached

Hi, thanks for adding Fifteenmile Stream. I noticed you added a number of culverts that are actually bridges. You can use the "USGS 3D Elevation Program" lidar imagery to tell the difference...culverts will usually appears as solid earth and bridges will usually have abutments visible

Hi, I noticed you changed the Flood Levee Trail to a cycleway, but the trail map online says it is "foot travel only", granted the map is from 2010. Has that changed? I was there yesterday but didn't see any signage.
https://portal.ct.gov/-/media/DEEP/stateparks/maps/mansfieldhollowpdf.pdf

Hi J_Hutch, there's no need to add access tags like access=yes, motor_vehicle=yes, bicycle=yes, etc to public highway=residential roads. They are already strongly implied, see: osm.wiki/OSM_tags_for_routing/Access_restrictions#United_States_of_America
Thanks