Hi, it looks like you undid all the changes in osm.org/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.

Do these really have to be “superroutes”, or can they just be routes within routes, as documented at osm.wiki/Route_directions and originally at osm.wiki/Superrelation ?

The status quo with crossing=* is objectively the consequence of multiple errors over the years. [1][2] A fair number of mappers are OK with the status quo, but they don’t quite agree among themselves about what that is. Fortunately, OSM’s tagging standards do evolve over time. crossing:markings=* and crossing:signals=* are an attempt to break out of this stalemate. Additional expressiveness can compensate for any additional verbosity.

It looks like you use iD. That editor’s maintainer has also expressed interest in adopting crossing:signals=* [3], and there are multiple pending pull requests that would do so.

Although crossing:signals=* is a de facto key, there is a draft proposal to extend it with more specific values, in the same way that crossing:markings=* provides more detail than crossing=* was previously able to. [4] You’re welcome to leave some feedback on the talk page.

[1] osm.wiki/Crossings#Street_crossings
[2] osm.wiki/Tag:crossing%3Duncontrolled#Terminology
[3] https://github.com/openstreetmap/id-tagging-schema/pull/590#issuecomment-1308665554
[4] osm.wiki/Proposal:Crossing_signalization

Another mapper on OSMUS Slack suggested telecom=carrier_hotel as well, so I added it in changeset 159018292 and will retag a couple other carrier hotels that I see elsewhere in the country.

See osm.org/changeset/135363897 for more discussion.

This building has always housed a variety of data centers, some of them more well-known than others. But to passersby, it isn’t a data center at all; it’s an office tower full of lawyers and accountants and the IRS.

We’ve already mapped several data centers and exchanges within the building [1][2], so a data center inside a data center seems kind of weird. There’s a documented building=data_center tag for buildings built as data centers, but since this building was originally built as an office building, changeset 158989447 replaces telecom=data_center with building:use=data_center. telecom=carrier_hotel or telecom=colocation_centre would be reasonable too.

[1] osm.org/node/8897151054
[2] osm.org/node/8897129886

This updates the boundary to reflect the land swap effective October 30. [1]

I took the coordinates specified in the unsigned draft compact [2], which match the signed and executed compact [3]. This work is in the public domain as an edict of government. [4] Since the coordinates are given in NAD27, I used NCAT [5] to convert them to NAD83(2011) and QGIS to convert them to WGS84 [6].

[1] https://www.texastribune.org/2024/11/07/texas-oklahoma-border-change-lake-texoma/
[2] https://www.ntmwd.com/DocumentCenter/View/2797/Amended-and-Restated-Texoma-Area-Boundary-Agreement-Proposed
[3] https://static.texastribune.org/media/files/b983c74d2b8a295a5f85ddbdf7dccb57/2024%20Texoma%20Area%20Boundary%20Agreement.pdf
[4] https://copyright.gov/comp3/chap300/ch300-copyrightable-authorship.pdf#page=37
[5] https://geodesy.noaa.gov/NCAT/
[6] osm.wiki/How_to_transform_data_from_NAD83_to_WGS84

Hehe :-)

(Typo: I meant “transcriptions”, not “translations”. I didn’t rely on Google Translate to do any actual translation.)

Glad to help. I’m kicking myself for not taking more photos while I was there.

I don’t read Chinese myself, beyond a handful of characters. Fortunately, the Google Translate application’s Google Lens feature does a somewhat decent job of OCR’ing CJK text out of photos if you set the source and destination to the same language. I double-checked these translations by looking up each character or couplet in the English Wiktionary.

Interestingly, the Chinese names aren’t word-for-word equivalent to the English ones. For example, 中一西街 means “first street west”, not “first street southwest”.

Ah, this one gave me a headache a long time ago. Unbelievably, the city’s official name is actually “The City of The Village of Indian Hill”. I think official_name would be the most appropriate key to put that in. If we make “Indian Hill” the primary name, then “The Village of Indian Hill” should be in alt_name, since it’s also pretty common in formal contexts.

Should we also change osm.org/node/153998156? If anything, the node representing the populated place should conform to the common name even more than the administrative boundary.

(I meant “state historic landmark”, not “static historic landmark”.)

An amenity=university area represents a single university campus. The area in question is Main Campus.

If we combine Main Campus and South Campus into a single geometry, we lose the ability to indicate that they have different addresses and different Wikidata IDs, or that Main Campus is a static historic landmark while South Campus is not. [1]

SJSU considers Hammer Theatre, the International House, the Child Development Center, the Mineta Transportation, and the hangar at Reid–Hillview to all be off-campus facilities. [2] However, their map of off-campus facilities does depict the North Parking Garage as part of Main Campus.

[1] https://ohp.parks.ca.gov/ListedResources/Detail/417
[2] https://www.sjsu.edu/map/off-campus.php

Should the inner sidewalk looping around Roosevelt/Alvarado/Cimarron have access=no?