In case there’s any misunderstanding, if a highway=* is known by multiple names, the common name usable for wayfinding should go in name=*. [1] I never said name=* has to be usable for in-car navigation specifically. I am sympathetic to the argument about searchability, hence my habitual use of official_name=*, but many mappers recognize that this is far from ideal. After all, federal law emphatically states that these names are *not* official.

changeset/180078301 records another memorial name designation in Miami, Avenue of the Americas. In one Mapillary frame, you can see how this city distinguishes between a memorial name designation and a generic alt_name=*, Biscayne Boulevard Way. [2] Granted, New York City doesn’t make the distinction so apparent. Different state, different standards. They figure everyone should know that streets in Lower Manhattan are denominated by ABCs and 123s. Prompted by your comment, changeset/180075547 scales Sesame Street back to just the block on which it’s signposted.

As far as the on-the-ground rule goes, Trump Boulevard is nothing more than a single double-sided sign posted at one end of the street, which I’ve taken the liberty of adding in changeset/180080039. It takes a certain amount of wishful thinking to extrapolate this into name=*, so I hope we can leave it here at alt_name=*. However, this will be a prime candidate for memorial_name=* once a proposal gets underway.

[1] name=*#Values
[2] https://www.mapillary.com/app/?pKey=329012028614409

The name got reported on because of its namesake, not because of “ground truth” as you put it. It’s functionally obscure because, by law, it can’t be posted anywhere you’d be able to navigate based on it. It’s trivia because memorial name designations are so exceedingly commonplace. That is not to say anyone would be against geocoders exposing this information, appropriately downweighted to reflect relatively minor functional utility. Do I understand that you would be fine with memorial_name=* if only it were better supported by Nominatim?

Please put your pitchfork away and assume good faith. changeset/180033385 was clearly about more than this one obscure street name that you care way too much about. Perhaps the changeset comment could’ve called out this particular retagging. I think we can give NE2 the benefit of the doubt that it was an oversight. If he had wanted to cover his tracks, he wouldn’t have commented on this changeset, alerting you to his edit.

NE2’s edit was clearly more correct than incorrect. Before you toss around accusations of “close to vandalism”, remember that your initial edit was based on a forward-looking article from a local TV station that someone overseas may not have the local context to interpret correctly. Anyone in the U.S. would by now be familiar with such reports of “renamings” that turn out to be memorial name designations. NE2 is asserting that this is a memorial name designation and I see no evidence to refute that. The law is very clear that a memorial name designation is not intended for wayfinding, so it isn’t a candidate for name=*. [1]

Over the years, memorial_name=* has come up often in OSMUS Slack because mappers believe official_name=* is putting too fine a point on it and alt_name=* doesn’t distinguish them as memorial name designations. These mappers are fine with it falling out of search results, because it amounts to trivia. Some mappers don’t even bother to tag any name and map the sign instead. I personally use official_name=* because I haven’t encountered enough instances of a feature having both an official name and a memorial name designation, but I guarantee you that if we take this conversation to the forum, memorial_name=* will proliferate as a result.

[1] https://mutcd.fhwa.dot.gov/pdfs/11th_Editionr1/mutcd11theditionr1hl.pdf#page=571

alt_name=* is also fine. The main thing is to keep Southern Boulevard as the name=*.

NE2 is right. The brown blade signs are merely memorial name designations. This is extremely common in cities across the U.S. When mappers bother to tag them at all, it usually goes in official_name=*, but some mappers prefer memorial_name=* instead.

Hi, names shouldn’t go on the ways that make up the boundary relation, unless there’s a special name for a particular part of the boundary. The name of the city is already on the boundary relation; that should be enough for a renderer to label the edges of the boundary if it makes sense to.

Reverted but we can discuss this on the forum or Slack if you feel the national guidelines need to be revised from a minimum of 2 miles upward to 6 miles.

Reverted, but

changeset/179886419

Regional importance is the primary criteria for highway=trunk, not necessarily highway=motorway when it comes to an isolated stretch like this. The Wilmington Bypass meets all the criteria for the exception for “motorway islands” under these guidelines. It came up many times in the discussions that led to these guidelines, with the overall consensus that this was a borderline case that could be kept as a motorway.

osm.wiki/United_States/2021_Highway_Classification_Guidance#Exceptions_and_Borderline_Cases

The neighborhood predates the historic district designation (and the name Asia on Argyle), and a historic district is not really a neighborhood per se. I split https://www.wikidata.org/wiki/Q138509081 from https://www.wikidata.org/wiki/Q2564147 so that we can model the two areas independently. I’d suggest making the place node represent the neighborhood. A historic district doesn’t really need a place node, even if that’s how it got imported from GNIS originally.

Agreed, crossing:signals=* is about whether a pedestrian should wait for a signal of any kind before crossing, just as highway=traffic_signals represents the location where a road user should wait for a signal. If there is only a common vehicular traffic signal head, the pedestrian is controlled by it and this should be reflected in crossing tagging. This is consistent with the law and it’s what routers expect.

I hope Facebook hasn’t been going around flipping these crossing:signals=* values systematically. I kindly ask the team to review your recent edits and correct any tags that arose out of this misunderstanding. If you disagree, please start a discussion on the OSM forum so we can explore a way forward. Thank you for your understanding.

Thank you so much for making this change! I had been meaning to clear out the old numbers but it fell off my radar. [1] Aside from the countywide plan, the City of San José does have a system of three-letter codes that appear prominently on trail markers. [2] We should probably map them as ref=* along with the colors as colour=* and the icons as symbol=* – please feel free to take that on if you have the time. Thanks again!

[1] https://community.openstreetmap.org/t/vestigial-pacific-coast-bicycle-route/114350/23
[2] https://www.sanjoseca.gov/home/showpublisheddocument/9855/636656974736870000#page=80

changeset/177587497 undoes most of this changeset. This stretch of highway hasn’t been SR 123 since 1999. Also, we should be using turn:lanes=* and change:lanes=* to represent lane change restrictions, not parallel link ways.

https://warrenco.maps.arcgis.com/apps/Shortlist/index.html?appid=088a131de1854b698f58840d9dffcc41 says they’re only adding some lanes and putting in a center turn lane, no median.

changeset/176794379

Ah, there goes my favorite test case for advanced Unicode support. 😛

Hi, someone flagged this changeset in OSMUS Slack because it looks like the launchers you’ve mapped no longer have any trace on the ground in the present day. Unfortunately, that would make them pretty clear candidates for deletion from OSM.

Are you aware of OpenHistoricalMap? If you map these features there instead, you’d be able to turn the time slider back to May 1971 and see them on the map. OHM is still pretty much blank in the Pittsburgh area, but this would be an interesting starting point. Let me know if you have any questions about how to contribute to OHM.

https://www.openhistoricalmap.org/#map=16/40.59662/-79.82263&layers=O&date=1971-12-31&daterange=-1775-12-31,2025-12-31

Since it seems there’s still a disagreement, let’s continue the discussion on the forum where others can weigh in:

https://community.openstreetmap.org/t/future-interstate-designation-along-california-state-route-99/139900

Please delete the relations and revert the ref=* tags. This does not even qualify for fut_ref=* because no Future Interstate corridor signs have gone up.

If you need to make a map of where the routes would go, you can do that in an Overpass query that lists the way IDs and upload the result to Wikimedia Commons as a GeoJSON file. See the tutorial at https://wiki.aaroads.com/wiki/AARoads:Maps/Tutorial

An Interstate 7 or 9 would require legislative action to renumber an existing state route. California does not use the same legislative number for a state route as an unrelated Interstate, and the legislative route numbers are aligned with sign numbers. You must already know this, since you’ve been citing that section of the Streets and Highways Code as justification in some of your other changesets.

Yeah, I agree that it’s a weird misnomer in this context. Basically all we need is a top-level feature tag to apply to whatever area we tag as access=private. Modeling it as a nature preserve inside a nature preserve seems counterintuitive. That happens to converge with the rationale for mapping actual forest compartments, but I think we’d all be open to a more fitting tag as long as we can drum up enough support for it among data consumers.

Hi Doug, there’s some discussion in changeset/171036308 as well as a bunch of scattered threads in OSMUS Slack. [1] A bunch of preserves in the area had been split up into “open” and “closed” boundaries, but the global community has been calling this into question because in reality it’s just one preserve.

The favored approach these days is to map distinct boundary=forest_compartment ways or relations inside the original boundary. As a starting point, we have “closed area” compartments such as way/298116730 , since we haven’t mapped any individual parcels. Others have been mapping the compartments; I’ve only been tidying them up to share the same nodes.

boundary=forest_compartment is a relatively new tag. Unfortunately, the Standard layer doesn’t render it at all. The Tracestrack Topo layer does outline them but doesn’t label them as far as I can tell. Only OsmAnd labels them.

[1] https://osmus.slack.com/archives/CCJ2P6KCH/p1746564953498049