Fixed in changeset/183226750.

Hi, it looks like this changeset split some ways that are part of route relations. When editing using JOSM, make sure to download a way’s parent relations before splitting the way. Otherwise, those route relations break silently, affecting the ability of renderers such as OsmAnd and OpenStreetMap Americana to display proper route markers along the route. Thanks for understanding!

Boundaries don’t have to be administrative in nature, but the more different they are from administrative boundaries, the harder it is to justify them in OSM, unless they’re verifiable on the ground of course.

From what I can tell, some states have tourism district boundaries that might qualify, because they aren’t just collections of counties and get prominent billing on maps and signs, but I suspect we wouldn’t be able to make a blanket rule about them.

As I see it, the issue with these ecoregions is that boundary=* is really for the kinds of boundaries that are explicitly defined as such (think legal boundary description texts), not for aggregates of measurements or classifications that can only exist as GIS layers. That said, these GIS features might be useful for piecing together a reasonable shape for a non-boundary that we don’t otherwise have a good shape for, such as a desert or forest.

changeset/182669505 changes the network=* of the Ohio River Scenic Byway in Ohio back to US:OSRB for consistency with the Indiana portion. As far as I know, there’s no Ohio’s Byway branding on this route, just the multistate branding, so there’s no need to give it a similar network=* value. Also, renderers like OpenStreetMap Americana already depend on the US:OSRB value, so this change had the effect of breaking shields that were working.

Yeah, it’s looking even less realistic these days. I think the main reason to keep it at this point – a weak reason – is just that someone might revivify it otherwise.

Cũng được gọi là Cáp Ve, nhất là ngoài VN. Nên có alt_name:vi=* để người ta có thể tìm kiếm đến.

Cám ơn, anh chỉ đặt dấu để thống nhất với tên vịnh México theo yêu cầu của cộng đồng thế giới. (Người Mỹ vẫn hay gọi là vịnh Mễ Tây Cơ, miễn là không đổi tên theo thời tiết chính trị.)

Ủa, sao lại bỏ tên Uy Kiên, hình như tên này vẫn được sử dụng một cách không chính thức. Ngoài VN Uy Kiên chắc được nhắc đến nhiều hơn Ukraina (nhưng ít hơn Ukraine). alt_name:vi=* có thể có hơn một giá trị được phân cách bằng dấu ;

Arab chắc là một thay đổi mới gần đây phải không? Có ai còn gọi là Ả Rập Xê Út không? Nếu có thì có thể đưa vào alt_name:vi=* luôn.

Chắc nên giữ Ai-len trong alt_name:vi=* vì đôi khi vẫn được sử dụng trên thực tế. Có cả Ái Nhĩ Lan trên một bản đồ số (Apple).

Thực sự mọi ngôn ngữ cũng hay viết tắt tên này. Sau thay đổi này, chỉ có tiếng Việt có thẻ name là tên viết tắt. OSM có quy định tránh chữ viết tắt trong name=*, chỉ đặt chữ viết tắt trong short_name=*. osm.wiki/Abbreviations Vậy có nên tuân theo quy định không, hoặc có cần một ngoại lệ vì không ai biết đến tên đầy đủ chính thức?

Các lối biên giới này có thẻ maritime=yes nhưng không phải là biên giới trên biển. Một số bản đồ OSM đang ẩn các biên giới tỉnh vì thẻ không chính xác này.

OK, looks like it should’ve been highway=proposed proposed=motorway. Someone in Slack did some sleuthing and determined that ground hasn’t broken on this bypass (and is unlikely to in the near future).

Hello, what was your source for changing these roadways from highway=proposed to highway=construction (contrary to your changeset comment)?

I only added node/11306007733 node/11306007734 node/11306007735 around the railroad crossing, though it looks like there are only “Stop Here On Red” signs and stop bars. I’d be OK with deleting them. Normally I only map highway=stop when there’s an actual stop sign at the crossing, as opposed to a yield sign or traffic light.

In changeset/143555657 I tried to handle the requirement to go through the toll booth. It was difficult to model, but I think I had it right at the time. If things have broken since, I’d appreciate your help debugging and fixing the issue. Thanks!

That hasn’t been the general practice for many years. Maybe it was an isolated case that we had overlooked?

I suggest replacing “Business” with either 💼 or 🕴️to adhere to OSM Carto’s mandatory limit while avoiding abbreviations. (A rebus isn’t an abbreviation.)

In seriousness, please direct anyone who expects an accurate road layer to a map that can render route shields: osm.wiki/United_States/Road_signs#Implementations

Is the reservation really known as “Iowa (KS-NE) Reservation”? Or is that just a Census Bureau invention to avoid confusion with the Iowa the state? changeset/181159559 replaces it with the common and official names from the tribe’s website.

Also, Báxoje comes from changeset/116831339, where NFZANMNIM conflated the reservation with the people. changeset/181160635 replaces it with something that appears in land acknowledgements that seems to resemble a trustworthy dictionary entry [1] (other than apparent grammatical inflection). I’m still not 100% sure this is correct, but it’s better than what was there before.

[1] https://iowayotoelang.nativeweb.org/pdf/r_engtobax_sep_09.pdf#page=3

Please consider copying from Wikidata labels instead of Wikipedia article titles. Wikipedia article titles often contain disambiguators that don’t belong in a map label. Many data consumers already know how to fall back to Wikidata’s more cleaned-up labels when OSM lacks a name tag, but this edit forces them to show the messier names that you copied from Wikipedia.

As discussed in: https://community.openstreetmap.org/t/migrating-proposed-routes-to-a-lifecycle-prefix/141573