Reverted in changeset/163109297.

Reverted in changeset/163109177.

Please remember to square the corners of buildings that you draw by hand. You can press the Q key to square corners quickly.

Sorry, I didn’t realize I was getting in the middle of things. Another mapper reached out to me and asked me to take care of Vietnamese.

> Is Vịnh Mexico more common than Vịnh México?

It’s complicated. Vietnamese spelling of foreign place names is notoriously unstandardized, mostly a matter of personal preference. This goes for both the country and the gulf. In Vietnam, Mê-hi-cô is probably the most common “formal” name, being preferred by the government and in educational materials. However, in the U.S., the preferred formal name is Mễ Tây Cơ or Mễ. At this point, neither country understands the other country’s name at all. In both countries, Mexico is very common informally because it’s mutually intelligible and easier to type. Wikipedia’s approach is to use the Spanish name verbatim, which feels more learned: México.

Any of these names could reasonably be the name:vi=* on Mexico, but it’s currently México, so I guess the gulf could also use this spelling.

Fixed the Vietnamese name in changeset/161870600

Thanks for fixing it! By the way, Caltrans apparently hasn’t updated a different sign further up that refers to the road by the old name. (That sign is also unusual for the dyadic fraction. Hadn’t seen that before.)

[1] https://www.mapillary.com/app/?pKey=932214371489044

Yeah, sounds like they would’ve removed it anyways. I don’t think Caltrans tracks turnout names as anything particularly formal, other than in project specifications, so we can just remove the name if there’s no sign.

It came from a sign a quarter mile north that appeared in Mapillary [1] and KartaView [2] as late as 2019. Mapillary also has imagery from two years ago, but I can’t tell if the sign was removed or buried under the snow.

[1] https://www.mapillary.com/app/?pKey=489650309015635
[2] https://kartaview.org/details/2057238/9024
[3] https://www.mapillary.com/app/?pKey=199678662548755

changeset/160372474 moves this information back to the original Marion County relation; see https://community.openstreetmap.org/t/incorrect-indianapolis-city-limits/122928

Undone in changeset/160372474 ; see https://community.openstreetmap.org/t/incorrect-indianapolis-city-limits/122928

The source was https://web.archive.org/web/20241117171033/https://www.caltrain.com/location/stanford-stadium as well as https://www.caltrain.com/news/caltrain-will-provide-big-game-service-cal-vs-stanford-saturday for the fact that northbound trains stop at the southbound platform.

Fixed in changeset/160045907

Thanks for your response. I agree that conflating so many real-world features into one node makes it difficult to choose a single Wikidata tag, GNIS feature ID, or FCC ID to put on the node. In my opinion, that’s a sign that collapsing everything down to a node wasn’t a good idea.

I started a discussion on the forum so we can get more feedback on my short-lived experiment:

https://community.openstreetmap.org/t/colocated-broadcast-antenna-structures-nodes-inside-an-area/122626

In retrospect, I think there should’ve been some attempt to engage on a solution before deliberately deleting what clearly had more attention lavished on it than the average GNIS-imported mast. The wiki is not gospel; we can get the community to accept an updated approach, but examples of that approach are necessary for the sake of discussion.

I appreciate that you’ve been quite active in cleaning up our coverage of broadcast infrastructure, but if you happen to run across any other examples of this micromapping, would you mind preserving it until we come to a consensus on how to move forward? Thank you for understanding.

Hi, it looks like you undid all the changes in changeset/106515773 to represent the tower as a tower with multiple antennas on it. Applying man_made=mast to an area technically contradicts the current documentation, but I’ve proposed to relax that restriction, ironically citing these very towers as examples of why it’s necessary to map them as areas:

osm.wiki/Talk:Tag:man_made%3Dmast#Areas

Apart from the validator error you saw, do you have a particular reason to simplify them down to areas with the details about each antenna all mixed together? You’ve also eliminated any trace of the tower’s well-known name, Wikidata item, etc., which seems counterproductive.

Also removed bike paths in Augusta and Waterville from USBR 1 superrelation.

Looks like we have inconsistent documentation. Again, the longstanding *superrelation* documentation never required a special superroute type; this is a misreading that has taken on a life of its own.

Steve recently acknowledged your edits on the USBRS page [1], but it’s inconsistent with how other U.S. route networks are tagged, for example U.S. Routes [2] and the route directions page I linked earlier. As it is, the relations you’ve touched are the outlier. This may complicate efforts by data consumers or queries to make use of the superrelations.

We need to have a discussion somewhere the rest of the community can see it. If you aren’t on OSMUS Slack, perhaps we can discuss it on the forum?

[1] osm.wiki/Special:Diff/2760065
[2] osm.wiki/United_States_Numbered_Highway_System

As I understand it, “superroute” was originally the result of a miscommunication in the JOSM issue tracker. The superrelation documentation actually has always recommended nesting a route relation inside a route relation, but this is no longer clear because of the “superroute” page. Even so, that page also alludes to the fact that “superroute” relations are unsuitable for networks such as the USBRS, which is not structured like EuroVelo in the real world. (A USBR is still a USBR within each state.)

A route relation such as 8852715 ideally needs to contain one relation per state, which in turn contains one relation per signposted direction. This would be consistent with the standard for Interstate and U.S. Routes, which are also designated by AASHTO in the same manner. The claimed benefits of “superroute” relations would require the topmost relation to be something else like type=superduperroute…

Thanks, if this was in response to changesets like 72411037, that user went on a retagging spree several years ago ostensibly to connect county seats, but it turns out they were secretly trying to promote historic farm-to-market and intercounty highways to be identifiable on a zoomed-out map. They now contribute to OpenHistoricalMap instead, where that information belongs, so if you see any other oddly prominent township and county highways, that’s probably what’s going on.

I agree that we should be consistent at least within the country rather than doing it piecemeal.

With the hierarchical network=* format as used on road routes, the hierarchical level is more or less the number of colons in the value, though less complicated countries would probably prefer the other format (e.g., fr:national). But this differs from the three-letter acronyms, which ostensibly indicate a zoom level range rather than any hierarchy per se.

For what it’s worth, this changeset moved the three-letter acronym to network:type=*, which is one of the ideas for preserving the ability of less sophisticated renderers to infer a reasonable zoom level.

Waymarked Trails does support the three-letter acronyms, but the developer isn’t a big fan of them: https://community.openstreetmap.org/t/bike-route-networks-classification-icn-ncn-rcn-and-lcn/121700/36

There’s longstanding desire for reforming recreational network tagging in the U.S. I’m a bit amused that it started with this trail of all things. The forum thread above is going around in circles, but one takeaway is that the hikers aren’t happy that cyclists coined cycle_network=* and left behind the hikers a second time.