(A consensus one way or another, that is.)

That tagging style was also discussed elsewhere at the time, for instance on talk-us: https://lists.openstreetmap.org/pipermail/josm-dev/2013-November/006781.html .

I understand the downside you’re describing, but as it happens that page has been pretty influential, as seen in https://taginfo.openstreetmap.org/relations/route#roles . Though this tagging style isn’t universal among U.S. mappers, it’s clearly more widespread than an individual change by Kristen, so we should discuss it more widely as a community. Maybe we’ll finally come to a consensus about it.

Due to an edit conflict with changeset 69492678, this changeset broke the TAH 7 route relation in many places. Changeset 69497394 fixes the route relation.

Cardinal directions as relation roles are one widespread tagging practice in the U.S., as documented at osm.wiki/Highway_Directions_In_The_United_States . OSRM is one example of a routing engine that makes use of those roles in guidance instructions. That said, it can sometimes be problematic to use cardinal directions as roles on surface streets, which may not always be divided and may only travel in one direction along a two-way street. The alternative of relations and superrelations (with direction tags on the relations) addresses that ambiguity.

Paul, if you feel strongly that directions should not be used as relation roles, perhaps it’s worth starting a discussion on the talk-us and/or tagging mailing list about it, laying out the pros and cons of each approach.

In general, the AA Highway should be highway=trunk, considering its importance and partial access control.

Thanks for adding more detail about this church. After drawing the building, instead of choosing “Building” from the list of presets and naming it “Church”, search for the preset named “Church”. In this case, there was already an existing POI for the church, so you can merge the POI into the building by selecting both, right-clicking, and choosing Merge.

I noticed in the Bing Streetside imagery from 2012 and Mapillary imagery from last year that the signs say “San Jose Vietnamese Seventh-Day Adventist Church”, not “Greater Church of Jesus Christ”, so I changed the name in changeset 69138615. Is that correct, or do people still refer to it as “Greater Church of Jesus Christ”?

Deleted in changeset 68885799.

Hi, thanks for all your edits in the area lately! Regarding this particular change, OSM’s guidelines for classifying places is intended to apply evenly across jurisdictions, even internationally. So even though Belpre counts as a city according to Ohio law, it technically only qualifies as a place=village in OSM based on its population. A place=city would have to be the focal point of a metropolitan area, such as nearby Parkersburg. You can read more about the guidelines at osm.wiki/Ohio/Map_features#Places .

Despite the guidelines, I retagged Belpre as a place=town in changeset 68710661, because of its significance as a major river crossing. Meanwhile, the Belpre POI is a member of a Belpre boundary relation that is tagged border_type=city; that tag correctly indicates the place’s legal status.

Hi, thanks for your contributions in San José. Please use the “Golf Cartpath” preset instead of “Unclassified Road” to represent golf cart paths through a golf course. This distinction keeps routers and navigation applications from telling car drivers to drive along golf cart paths. Thank you!

After examining street-level imagery and researching further, I’ve determined that the name isn’t dependent on the side of the street after all. “Columbus-Cincinnati Road” (with the hyphen) is preferred by the Ohio Department of Transportation, which posts all the street name signs along this road. However, “Cincinnati Columbus Road” (without a hyphen) is preferred by the West Chester Township Road Division, which posts periodic address signs along the road.

Since both names are equally prevalent, I’ve included both in the name tag, using reg_name and loc_name to clarify the situation. I put “Cincinnati Columbus Road” first in the name tag because that’s the name that most businesses along the road use in their addresses. I also mapped traffic_sign=US:D=3 and advertising=sign nodes for all the signs I could find that name this street.

Awesome, I’m glad there are local eyes on this part of the map, especially given the online attention that https://onezero.medium.com/how-googles-bad-data-wiped-a-neighborhood-off-the-map-80c4c13f1c2b brought this neighborhood.

My edits were only ever intended to be a starting point for further refinement. If you can determine the neighborhood’s boundaries independently using local knowledge, there’s no need to cite city-data.com as a source. Aligning or joining to the streets that form the boundaries would be worthwhile, to avoid incorrect geocoding on the other side of the affected streets.

Even if Buffalo neighborhoods aren’t formal enough to have administrative boundaries, we could still add a non-administrative boundary relation. Do you agree with Wikipedia’s claim that the neighborhood is “centered on” the High/Jefferson intersection? If so, maybe we should put a place POI there and add it to the non-administrative boundary relation with the label role.

This changeset moved node 6338689283 from the corner of High and Jefferson to a location along the edge of the neighborhood as it replaced the node with a place=neighbourhood area. This change is problematic for two reasons: the geographic centroid of this area is not the commonly acknowledged center of the neighborhood (as stated by Wikipedia), and place areas per se aren’t rendered by most renderers. If we were to map the neighborhood as an area, we would need to map the boundary as a boundary=administrative admin_level=10 relation, with the place=neighbourhood node being a member of that relation with the label role.

Apart from that, city-data.com says the neighborhood boundary data is copyrighted by urbanmapping.com. So I don’t think we should rely on it as a source, unless you or someone else has secured permission from urbanmapping.com under terms compatible with the ODbL.

I would favor reverting this changeset, though I thank you for deleting the other POI someone later added in the middle of the fruit-themed streets – that seemed to be a misunderstanding too.

This changeset removed important turn lane information. The ramp should begin where the physical separation begins, not where the lane change restriction begins. Turn restrictions should be mapped as relations, not as incorrect geometry.

To the team at Amazon Logistics: if you see that a road has already been mapped with turn lanes, please refrain from editing it as part of turn restriction mapping. Thank you.

Hi, I undid part of this change in changeset 68122862. Changeset 53221067 was correct to move the Costco gas station canopy to the rear of the parking lot by the tire center. In the Bay Area, none of the available aerial imagery layers have been updated since late 2017, shortly before the gas station moved. If you need help determining whether something has changed on the ground in this area, I’d be happy to help; just let me know.

Hi, I undid this change in changeset 68086436. Please be careful about keeping bus routes intact and lane counts accurate when reconfiguring intersections.

In this case, I think making part of Vine two-way is preferable. Even if your router doesn’t understand maneuver relations like the ones you deleted, it’ll say “turn right, then turn left” to go straight through to E. Court St., which is still intuitive. And to turn left onto Vine, it’ll say “turn left”, instead of “make a sharp left”.

Changeset 68037062 replaces these nodes with barrier=block nodes. As far as I know, noexit=yes is only used by QA tools, not by routers.

Please do not replace circular roadways with highway=turning_loop nodes. highway=turning_loop is less detailed than the ways you deleted. Thank you for your attention.
---

Published using OSMCha: https://osmcha.mapbox.com/changesets/60154559

This school had been retagged as a park in changeset 51441572 – and renamed to include the word “park” – to disguise the fact that it was intended to optimize for Pokémon Go gameplay.

Thanks for these edits. Retagged Miro Towers as a construction site in changeset 67572097.

Hi, it looks like you’ve been very manually building up a contiguous U.S. boundary relation. You may find it more convenient to use the Ctrl+Shift+{ and Ctrl+Shift+} shortcuts in iD (⇧⌘{ and ⇧⌘} on a Mac), which jumps directly to the first or last node along a way. You can also use the list of members of the main U.S. boundary relation to jump to pieces of the border.

The contiguous U.S. is something people might want to search for, so you’re right to add it to the map. However, it isn’t an administrative boundary in the usual sense. It’s probably better to leave off the boundary=administrative tag and give the relation a place=* tag of some sort. Perhaps place=region? osm.wiki/Tag%3Aplace%3Dregion

Hope this helps!