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] crossing=uncontrolled#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 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] node/8897151054
[2] 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 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?

Hi, I’m not very familiar with the distinction, so apologies if I’ve made a mistake. I added node/8262966505 based on https://saesdp.sccgov.org/sdpdocs/4215410-SocialDistancingProtocolForm.pdf , which is part of a dataset we were importing at the time. The name is “Milpitas Musallah”, so I was under the impression that place_of_worship=musalla would be appropriate. There are also a few mosques in the area, which the local Islamic communities seem to distinguish from the musallas. I hope this helps!

Fantastic detail here! By the way, I think this is all one building structurally, so it would be more correct to remove the building tag from each of these areas and surround them all with a single building area that connects to all the same nodes along the outer walls. Unfortunately, this will cause the inner walls to go missing from the default Standard layer, but then you can add more details for indoor renderers like indoor= and OpenLevelUp – particularly handy for both Jungle Jim’s locations.

https://community.openstreetmap.org/t/verifying-the-southern-leg-of-the-cincinnati-subway/115820

changeset/153710886 cleans up one of the bridges a bit more, but it’s quite a tangled mess overall.

No worries, it’s totally understandable. Thanks again for your help in this area!

Hi, thanks for helping to keep this part of the map up to date. Please note that the name=* key (Name field) on a highway=motorway_junction node (Motorway Junction / Exit) is only for when the exit has a special name distinct from the off-ramp’s destinations. This is typical on some toll roads on the East Coast but doesn’t happen at all in California as far as I know. I’ve removed these names in changeset/153269802.

Instead, routers and navigation applications use the destination=* (Destination) and destination:ref=* (Destination Road Numbers) tags on the ramp itself. You’ll notice that these tags don’t appear on the Standard map layer. This is by design, to avoid crowding out other labels and icons. However, other map styles may choose to show them at high zoom levels.

Most of the exit ramps in this area already had destination tags, but some were outdated. I fixed a bunch of exit ramp destinations based on your edits, but there are probably more needing review. Also, most of the entrance ramps are missing destination tags. Adding them would improve turn-by-turn navigation instructions.

Let me know if you have any questions about these tagging conventions.

Hi, the highway=motorway_junction tag is only for the beginning of an exit ramp (off-ramp) or a lane split (fork in the road) on a freeway, not for the end of an entrance ramp (on-ramp). I’ve removed these tags in changeset/153269802.