You’re right, I must’ve duplicated that one, forgot it, and duplicated it again as a starting point for the next medallion. Thanks for your vigilance. Fixed in changeset/146532532.

Thanks, that’s definitely an improvement. I retagged the POI in changeset/146205486.

Since the linked proposal mentioned hotels, I wonder if I should also use it for a dormitory lounge like node/8562709678 . I’ve previously used amenity=clubhouse, but that tag got co-opted by a more literal meaning of “club house” that got rejected. It seems closer to a layperson’s definition of a “lounge” than a “clubhouse” anyhow.

Looks like the individual ways got added to the I-11 superrelation instead of the northbound and southbound route relations. They need to be moved to these relations:

relation/14104671
relation/14104672

Other than highway=motorway, the highway=* key does indicate a functional classification of sorts, just not necessarily the classifications that Caltrans has determined using the FHWA’s framework. There are various reasons for this, including different incentives like funding levels.

There is a separate HFCS=* key for indicating the official FHWA/Caltrans functional classification of a given road. Mainstream renderers and routers don’t use it yet, but that’s because the mappers who added most of this data are no longer active within the project. You could help to revive this form of mapping, at least here in California, where we can copy from DOT maps without infringing on copyright.

The choice to depart from FHWA/Caltrans functional classification is not mine or willkmis’s, but rather that of the project as a whole. If you disagree, you need to take this up with the wider community on the forum: https://community.openstreetmap.org/c/communities/us/78 . Otherwise, your work is inevitably going to get undone by passers-by in a matter of weeks, but much more haphazardly than the systematic tagging that willkmis did.

The Trunk Road preset’s lack of a bike lane field is a simply an oversight. Please report issues like this in https://github.com/openstreetmap/id-tagging-schema/issues . Thanks!

Thanks for looking into amenity=lounge. I agree we need a tag for lounges – not just for airport lounges, but also for less exclusive lounges, like at train stations. That said, judging from http://morganhillbowl.com/strixe.html , I think this one might be better described as a sports bar.

There was never a solid consensus about consistently using highway=trunk to denote an expressway. In 2022, the project decided that expressway=yes is the tag for an expressway, not highway=trunk, at least in the U.S.

Thanks!

https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508

Looks like the GitHub authentication option was removed in https://github.com/OpenHistoricalMap/issues/issues/389 because it wasn’t set up correctly and no one had been asking for it.

I’d keep “JT Express” in old_name and any other defunct attributes you think are still relevant in disused:*=* tags.

I think it should be feasible for OHM to support more login providers besides OpenID. Feel free to file a request at https://github.com/OpenHistoricalMap/issues/issues .

JT Express used to have “Jimbo’s and Tengu Sushi” in their logo, in small type. Come to think of it, that would make it more of a strapline=*, since probably no one referred to it by that name. I’ve also added name:etymology=* per your suggestion.

There aren’t any hard-and-fast rules about how to name a chronology relation – it’s basically whatever you’d call the historical account if you were to write an article about it. So sometimes I go with the most recent name; other times the name by which it was best known.

Mergers and splits can get tricky. Since the JT Express relation also serves as a chronology for the pre-merger Jimbo’s, I’ve added that as an alt_name. In general, though, I’ve used a POI’s membership in two different chronology relations to indicate a merger.

There could be a chronology relation to track the occupants of a storefront over time. I haven’t gotten around to making them for most of the shops I’ve mapped, but I had a bit of fun with this one: https://www.openhistoricalmap.org/relation/2749168

https://www.openhistoricalmap.org/changeset/103779 maps the history of this space, including Jimbo’s and Tengu Sushi that merged into JT Express and the upcoming Spread. I think we can safely remove the data about JT Express from OSM now; nothing actually supports the date suffix tags, despite what some wiki pages recommend.

Moved to OpenHistoricalMap in https://www.openhistoricalmap.org/changeset/103581

Someone should probably start a forum discussion eventually about whether flag:type is even necessary on features that already have flag:wikidata, since Wikidata’s flag items convey these distinctions a lot better. It’s not as though a national flag is automatically larger or less worn out than a regional one.

iD is just listing the most common values of flag:type from taginfo. The typical tagging for U.S. state flags is flag:type=regional, not state. flag:type=state is mostly used for the other kind of state flag, as in the flag of a government, as opposed to a civil flag. We don’t generally make that distinction in the U.S.

https://nsi.guide/index.html?t=flags&k=man_made&v=flagpole&tt=california#california-85bb3f

Thanks for going through and resolving these discrepancies!

'Hi, thanks for taking a look at this part of the map! In the past, we’ve gone back and forth about whether South Campus should be conjoined to the main campus somehow, but the general sentiment is that it should remain as a separate map feature. Both South Campus and the International House are still identifiable as part of SJSU based on the operator tag but aren’t really a single “site” per se. It would be more accurate to describe South Campus as a university campus than as a generic area.

I’ve undone these changes to the site relation, but please don’t let that stop you from looking around and making any improvements you see fit. We can even create a second site relation for the entrances to South Campus. 🙂 Also, SJSU is looking rather bare on OpenHistoricalMap – we could use some help remapping the buildings with start dates there. https://www.openhistoricalmap.org/relation/2705125'

changeset/144850429

Honestly I was confused about that too until the other Americans hit me with a cluebat in the thread linked above. 😅 I was aware of railway routes also being an oddball, but I thought that was type=railway, not type=route route=railway.

I posted to the Oceania forum to give local mappers an opportunity to chime in:

https://community.openstreetmap.org/t/streets-as-street-relations/106436

The OSRM code I linked to is a test case proving the existence of behavior that is uniform globally. The code that implements it lives elsewhere.

The Australia tagging guidelines don’t discourage using route=road for ordinary streets because of common sense. Again, the use of “route” for non-routes is a slight perversion of the language, even if it’s one that we live with for historical reasons. The tagging guidelines were overhauled just a few months ago after extensive discussions. If there was any thought to modeling streets as highway routes, one would think the Jacaranda Street example would look a little different.

I should clarify that this distinction between routes and the roads that carry them is not specific to the U.S. (Even in the U.S., some states make a clear distinction while others do not.)

Anyways, I’m not opposed to retagging as route=street if you feel strongly about doing that yourself. But so far I haven’t heard a particularly compelling reason as to why route=road needs to be used here when there are more accurate alternatives.

Tagging for highway routes in Australia is documented at [1]. That section doesn’t discuss route names specifically, but those numbered routes very frequently come with signposted names that are distinct from the names of the streets that carry the route. This is similar to the distinction between roads/streets and routes in many U.S. states.

I mentioned route=street because this changeset had replaced many occurrences of type=route route=street with type=street. As far as I can tell, route=street wasn’t causing any problems, but using route=road for this purpose would dilute an important tag for renderers and routers.

Some renderers such as OsmAnd and OSM Americana display shields based on route=road relations or render certain networks at lower zoom levels. Routers such as OSRM and Valhalla modify guidance instructions when they encounter route=road relations. [2]

This discussion is getting rather unwieldy for a narrow comment box. Perhaps we can take this to the forum if you’re interested in discussing further?

[1] osm.wiki/Australian_Tagging_Guidelines/Roads#Routes
[2] https://github.com/Project-OSRM/osrm-backend/blob/31e31a63d062fb804f5f4695ed3036ca7a269ead/features/car/route_relations.feature#L238-L248