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.

Reverted in changeset/174229200: short_name is for conventional abbreviations (e.g., AP abbreviations). USPS/GPO state codes go in ref.

Reverted in changeset/174229200: short_name is for conventional abbreviations (e.g., AP abbreviations). USPS/GPO state codes go in ref.

Thank you. There was some prior discussion about using NBI in [1], but it focused on weight restrictions rather than start dates. Perhaps you could help with the idea to map weight restrictions based on this dataset, since it seems to have stalled.

NBI could also be useful for improving road coverage in OpenHistoricalMap. OHM has mappers doing more bespoke research on road openings, but bridge-based inferences could complement that work very nicely. I proposed something similar to your process in the OHM forum. [2] Feel free to chime in based on your experience doing this in OSM. (You can log into OHM using your OSM account, then log into the forum using your OSM account.)

[1] https://community.openstreetmap.org/t/adding-bridge-information-in-kentucky-and-other-states/113229
[2] https://forum.openhistoricalmap.org/t/national-bridge-inventory/578

What were your sources for these dates?

¡Gracias! changeset/172690338