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.

Reverted in changeset/174663931

This changeset should be reverted. The U.S. community reached a consensus to deprecate subarea members of boundary relations:

https://community.openstreetmap.org/t/proposed-removal-of-subarea-members-from-us-boundary-relations/122865

Thank you for your quick response. changeset/174456278 changes the name=* tag back to the Hanafi Rohingya name, preserving the Burmese name in name:my=*.

If it turns out that the Burmese name is more appropriate for this village and the original edit was inaccurate, please feel free to change it back. Thank you for your help and understanding.

Hello, this changeset modified node/5095558947 to have a name=* tag matching name:my=* instead of name:rhg-Rohg=*. Meanwhile the linked Wikidata item still says the native name is in the Hanifi Rohingya script. Do you know if that’s inaccurate, or was the edit intended to be consistent with how other nearby places are tagged?

This came to my attention because I’ve been working on improving MapLibre’s support for Unicode text. Burmese script has been a priority, but I’ve also been using this Hanifi Rohingya name as a test case, so I was surprised to see it change suddenly. Thank you for any insights you can provide.