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