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

There’s a marking at the beginning of way/1454396610 that says “TUGS ONLY”. I believe it refers to the kind of vehicle that pulls an airplane around, also known as a pushback tractor. [1] This is in contrast to the surrounding ways, which allow other tractors and ground support equipment.

[1] https://en.wikipedia.org/wiki/Pushback_(aviation)

Also fixed some gaps in boundary relations along the river.

way/444208347 is a segment of a river, not a flowline that only exists for theoretical purposes in OSM. For example, Mobridge is on Lake Oahe but it’s also on the Missouri River.

Every language has its longstanding conventions. Vietnam and Korea have a shared linguistic heritage as part of the Sinosphere. Transcriptions between the CJKV orthographies are normal, expected, and standardized – not an ad hoc guess by someone sitting in an armchair halfway around the world. I have no idea what the usual practice is among Persian speakers, but Korean is totally irrelevant, and by bringing it up you’re casting doubt on whether you know what you’re doing.

Hi, the page you’re citing is outdated and historical, as seen at the top of the page. See osm.wiki/United_States_roads_tagging/Routes#California for current tagging guidelines applicable to California. If you think we should adopt the “CR” prefix, there should be some discussion in either https://community.openstreetmap.org/c/communities/us/78 or https://slack.openstreetmap.us/ .

Also, the format of ref=* on a route relation such as relation/74885 should never include the alphabetic prefix, unless that prefix is presented as an integral part of the route number on signage. I undid this part of the changeset in changeset/175010519 .

Hi, it looks like this changeset removed indigenous names from the main name=* tag of each of these boundary relations and place points. (The indigenous names were already in the corresponding name:*=* tags.) I realize this changeset was a while ago, but do you recall if it was spurred by something in particular, and if there was a particular reason for editing these features but not other tribal reservation boundaries and places that also have indigenous names in name=*?

Theo các thẻ trong bộ thay đổi, bạn đã tra cứu lớp Esri để thực hiện các thay đổi này. Tuy nhiên, trong lớp Esri, các mương này vẫn còn tồn tại. Tại sao bạn xóa chúng? Nếu có vấn đề nào đó thì nên khắc phục vấn đề, chứ không xóa hẳn đối tượng.

Các thay đổi này cũng không có liên quan đến đường sá gì cả. Bạn nên cung cấp lời tóm lược sửa đổi chính xác, nếu không thì người khác có thể nghi ngờ các thay đổi này là phá hoại.

Chào bạn, bộ thay đổi này xóa nhiều tòa nhà và đối tượng khác: https://osmcha.org/changesets/174322251 Bạn có nhớ tại sao cân phải xóa các đối tượng này không? Hình như các tòa nhà vẫn còn xuất hiện trong lớp Esri mà bạn đã sử dụng. Xin lưu ý rằng các lời cảnh báo hay lỗi trong trình vẽ không nhất thiết có nghĩa là cần xóa đâu, chỉ có nghĩa là cần sửa đổi một số điểm nét nhỏ, thí dụ một phần trùng với tòa nhà khác hay góc không vuông.

Ngoài ra, khuyên bạn nhập một lời tóm tắt sửa đổi rõ ràng hơn khi lưu các thay đổi. Câu “Fix roads” không cho biết làm sao các đường sá bị hỏng trước đây và cũng không giải thích các thay đổi khác như xóa tòa nhà.

name:pronunciation=* should normally be in IPA. I added a name:hur-fonipa=* tag in changeset/174671583 based on the English Wikipedia article. In any case, an explicitly tagged pronunciation should be unnecessary for Halkomelem. It would be more appropriate for the official name, which embeds the Halkomelem name inside an English name.