MassGIS is helpful, but for local road naming the City of Cambridge GIS takes precedence. Since it shows a different name, removing or changing the name should be discussed first.

I’m not saying it’s a motorway. My comment is solely about the road name — the name appears on the city’s official map, which is why I raised the concern about removing it without discussion.

Removing this name without discussion isn’t productive. The road name is present on the city’s official map, and any change should be coordinated with supporting sources.

Thanks for following up and for sharing the survey date and locations — that’s helpful. During my on-the-ground survey, I did not observe signage prohibiting pedestrian access in the portions of the area marked as Pendergast Avenue, and both parking and pedestrian use were clearly occurring at that time. I also recently reviewed available street-level imagery and did not see pedestrian-restriction signage present in those areas. That said, since your survey was conducted more recently than mine, I’m comfortable leaving it tagged as foot=no if you feel that is the most appropriate representation of current conditions.

This is an active railyard, but there are no posted signs prohibiting pedestrian access. Tagging this as foot=no is therefore not accurate. The area is routinely used by pedestrians accessing adjacent parking, which I have personally confirmed through an on-the-ground survey.

I classified those as tracks based on my on-the-ground survey of Salem Common. From what I recall, they’re noticeably wider, which made highway=track the most appropriate classification.

This was incorrect. The road does exist and is listed in the town’s official GIS street map. Its presence was also confirmed through an on-the-ground physical survey. The Lyft-owned aerial imagery appears to be outdated or incomplete in this area.

Thanks for the link — that’s helpful. Given that Ericson Place doesn’t appear on the official Providence street maps, and there were no signs present, I agree the name likely isn’t officially recognized. That said, I’ve removed the name until there’s clear municipal evidence or on-the-ground signage to support it.

I only extended the name to the rest of the road because the portion already named in OSM didn’t cover the full road. Since the name Ericson Place was already present in OSM and also appeared in ARCGIS, it seemed reasonable to extend the existing named road rather than treat it as a separate, unnamed feature.

Fennessey Court doesn’t exist at this location.

Map reference: https://www.chr-apartments.com/sites/default/files/2021-03/Interim_maps_7-Approved3-9-21.pdf

Coolman Commons Condominiums is not the name of a road in Boston. Please avoid adding invented street names unless they’re supported by signage or official sources. For clarity, the buildings in that complex are numbered 239, 241, 245, and 251, which aligns with the existing numbering on Norfolk Street.

Thanks for the follow-up. To answer your question about my objection: my point is simply that the Wiki’s current guidance treats two different posted names as separate directional names, not as “multiple values of name.=*” The name:left / name:right tags exist specifically to avoid merging distinct names into one field.

The semicolon or slash patterns are older approaches, and the modern examples leave name=* empty in this situation.

So to stay consistent with that, I removed the combined name=* and kept the directional names.

Appreciate the discussion!

Thanks for the explanation. Based on the OSM Wiki, name:left and name:right are the correct tags when a road genuinely has different names on each side. In those cases, the name tag should not contain multiple values or use “;”.

The Wiki example you referenced (Cincinnati) actually shows that when a road has different names on each side, the proper tagging is:
• name:left=*
• name:right=*
• and the name tag is omitted, not a semicolon list.

The semicolon format is for multiple values of the same key, not for representing two distinct official names. So once name:left and name:right are added, the name tag should be removed rather than combining them with “;”.

Please update the tagging to follow that structure.

According to the OSM Wiki (“Names” tagging guidelines), the name tag must contain one single name and must not use separators like “;”. If multiple names exist, they should be handled with appropriate tags (e.g., alt_name, loc_name). Please correct the name value accordingly.

Hi! Thanks for contributing. This update isn’t correct. OSM road types follow functional classification, not navigation data. The previous classifications were accurate and shouldn’t be changed for routing.

I believe you may have inadvertently messed up a border here.

Thanks for the clarification. Just to be clear, when I said “treated as a public street,” I wasn’t referring to ownership — only that it’s listed in the city’s GIS as a named street and used for addresses. I understand your interpretation and appreciate the thoughtful discussion.

I think one key piece was missed in your reply. The wiki itself says:

“The scope of this tag may overlap with highway=footway, which is generally used for narrower, often unnamed, pedestrian pathways and sidewalks. The distinction between the two may be region-specific.”

That line explicitly allows for regional/contextual flexibility. In this case the city’s GIS treats the way as a street and properties use it as an address, so it behaves like a named public street rather than an unnamed path.

I understand your point about the wiki guidance and the word “generally.” I read that as allowing some flexibility for cases like this — where it’s not wide enough for vehicles but is still treated by the city as a public street. I leaned toward pedestrian since it’s mapped and addressed like a public street, which aligns with how pedestrian streets are typically designated in the city and fits local mapping practice.

Soden Place should be listed as a pedestrian street — it’s shown in the city’s GIS map and has properties that use that address.