I'm very much a proponent of richer data. That said, it's a pretty broad understanding that bike access is implicit across the US. Not to say that these tags are wrong, more to say that they are unnecessary. Is there a particular data consumer you've found to get this wrong a lot?

These shouldn't need bicycle=yes? MA law is that bikes have a right to all streets other than expressways/limited access roads where explicitly disallowed, so the bicycle=yes is implicit

please note that access denotes legal access, not safe or preferable routes. Road classification can be used to help with that

I agree that this is something the state would generally mark as no access by bikes horses and peds, but in this particular case, I'm not sure if there's the exact signage that is required (state law allows bikes on all public ways except limited access/express state highways with signage specifically prohibiting bikes). I'm not going to argue with the way you've tagged this, just noting the oddity

would you tag the location of the gate as well?

Also: the scheme for access is heirarchical, so if you set `access:private`, it's presumed to be access private for all modes, and you don't need to tag other modes specifically

yeah, this looks good, I think it's actually a fence, but it's movable fence so I don't have any complaint with the current tagging. Had just wanted to comment to clarify, and to validate that yes this is blocked

This may have been disconnected because of the fence, this "park" hasn't been accessible for years I don't believe

I also don't have a lot of strong distinction between them. I've seen a lot of places where both are tagged with most of the data, this populates data for the way, and so could be represented in the pedestrian network, as well as for the node, which can be represented in the auto network, which is why I suspect both get populated so much. The tags there's more consideration around are kerb and tactile paving tags, which can be ambigurous (e.g. barrier=kerb on a way would indicate there is a kerb along that whole way) crossing=*#Accessibility

Oh, more than "crossing:markings=yes", I would mark these and the ways as "crossing:markings=zebra" to indicate the logitudinal bars

I don't believe `crossing:signals` is a standard yet, I'd keep `crossing=traffic_signals` as well. I generally aim to do that along with `crossing:markings` to be explicit about whether and how it's marked

Did you also update the tags on the crossing ways? I know the construction here is more recent than the imagery, is the markings here accurate or would you happen to know them?
---

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

I think it's necessary for things like Quincy Street with the contraflow lanes, but not on streets where the bike lane goes the same direction as the car lane

Can you help me understand your use of the oneway tags here? My assumption for the on street bike lanes is that `cycleway:oneway` would only be necessary if there's a specific restriction that applies to the bike lane, but by default the bike lane would be assumed to share direction with the side of the street it's on. Is the explicit tagging of cycleway:right:oneway and cycleway:left:oneway to align with some way data consumers interpret this?

Why did you use a cycleway oneway tag on western Washington St and a few other places?

Also: The Somerville Ave cycletrack is complete from Mansfield to Union Sq

It looks like you marked parking:no on Otis St?
---

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

A lot of these don't appear to be in relations, and the one that I found, relation/11580889 does not include the bikeway, the pavement on the other side, or a name

There is substantial benefit to tagging name on separately mapped cycleways or including them in named relations. As more and more bike lanes in the area have been mapped as separate cycleways, tools for routing have increasingly been unable to provide the name of the street, which has been degrading the utility of the map

Thanks for restoring it! I fixed it in changeset/156841177

For the future, when you're using the iD editor and have a node with tags that you want to separate from a way, there's an action "Extract" in the right click menu that you can use to pull out the node without disconnecting any of the ways, and then you can just drag the intersection point back to where it's supposed to be

It looks like this had been an accidental drag, thank you for fixing it. Did you intend to also delete the bench on Lovejoy Wharf? It also looks like you didn't restore the connections between the driveway and the parking aisles
---

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

Per imagery and https://www.nae.usace.army.mil/Missions/Civil-Works/Flood-Risk-Management/Massachusetts/Charles-River-Dam/, I think that northmost waterway is a fish ladder? Or, within osm terms, a fish pass

It also looks like you marked the large lock as boat:no? Is there a current closure of that lock to traffic?

Is it possible to tag this as a buffered lane? "highway=cycleway" gives the impression that this is an off street cycleway, which makes the map less useful for bicycle routing
---

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

Those signs are particularly ambiguous. In keeping with the height limits, they're primarily targeted at trucks. I don't believe those would be understood to prohibit motorcycles, for example. Those signs also aren't in keeping with how the commonwealth prohibits bikes, horses, and pedestrians in other cases, like at entrances to I-93.

I think this is something Mass DoT aught to clarify. Note another example, where Mem Drive passes under Mass Ave: there are the same Cars Only signs, but there is no bike, ped, or horse specific signs, only a sign indicated no trucks. I would not be suprised if the "Cars Only" were not there as a legal restriction, but to remind the uhauls about storrowing

I do not know of any signage prohibiting bikes here
---

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