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'

osm.org/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

I guess the context for this change was https://wikis.world/@samwilson/111084626354658237, which incidentally sparked some discussion in OSMUS Slack: https://osmus.slack.com/archives/C2VJAJCS0/p1695020657752419 .

An individual street isn’t quite the same thing as a route (in the plain English sense of the word). But type=route isn’t just for routes: these days, it’s also used for a variety of routable features, including type=route route=railway for railways, which are analogous to these streets. route=railway causes endless confusion, but it’s very entrenched at this point. At least the previous tagging of type=route route=street kept renderers from getting confused and treating them as highway routes, which require route=road.

The current tagging is technically valid, since type=street also tries to represent the street geometry using the “street” role. This is similar to how type=waterway can include tangentially related members like side streams and springs, but the “main_stream” role is reserved for the main geometry.

That said, I’m not a fan of type=street as documented: it’s basically an attempt to reimplement a geocoder under the false assumption that the technology for data compression or spatial querying hasn’t been invented yet. Taken to its logical conclusion, literally every feature in Fremantle would be part of a street relation.

Another option would be type=multilinestring, which avoids overloading the term “route” while also avoiding the ill-conceived street relation proposal.

By the way, the community appreciates it when you provide a descriptive comment with each changeset, rather than repeating something generic each time: osm.wiki/Good_changeset_comments

This changeset was mentioned in https://community.openstreetmap.org/t/ky-i-69-purchase-parkway-issues/106196

Changeset 144063434 demotes Wolfe between Homestead and Stevens Creek back down to secondary.

I would keep South Tantau as tertiary, given its centerline stripe and right of way at most intersections. So far, I’m seeing tertiary take on a wider range of physical characteristics than before, just as secondary is taking on a wider range of characteristics as we demote primary roads down to secondary.

The main thing informing my idea of demoting Pruneridge west of Lawrence to tertiary was the Homestead–Lawrence–Pruneridge jog, but I don’t know if it’s as common as it used to be.

Changeset 144047223 restores the street lamp and separates the signs by layer.

The documentation for traffic_sign doesn’t really consider the possibility of keys besides traffic_sign on a traffic sign node. Mapping separate nodes isn’t uncommon, and it is common to separate them using different layers. I started a discussion at osm.wiki/Talk:Key:traffic_sign#Multiple_features_for_multiple_signs about acknowledging this approach.

The merged node is nonsensical. Since when does a street lamp have a frequency of 1670 kHz?

osm.org/changeset/144045989

Regarding the traffic signals: I’ve also been moving traffic signals to the stopline lately. This is a reversal from what I had previously done. Both styles are valid, and both come with tradeoffs for renderers and routers. But this area has so many unusual intersections where only the stopline style can accurately describe the traffic control on each inbound way, so I figured it’s better to be consistent.

One downside of the stopline style is that many intersections around here have staggered stop lines, so the highway=traffic_signals node is actually at an arbitrary location. I’ve been using road_marking=stop_line road_marking:stroke=solid ways to clarify that situation, at least to mappers; no software recognizes them yet.

North Tantau did become more important after Pruneridge got truncated to make room for Apple Park. However, I think it might still be affected by the reclassification efforts currently underway across the South Bay. So far, more roads have gotten demoted than promoted, especially in South San José.

As part of this effort, I’m considering demoting Wolfe to secondary, since the segment that’s currently primary isn’t one of the longer-distance arterials like Stevens Creek or El Camino. If that happens, I think it would be a little more reasonable to demote Vallco Parkway, North Tantau, and Pruneridge west of Lawrence to tertiary, though not a slam dunk. Regardless, I agree with keeping these three roads consistent with each other.

I can see how the dual carriageways around the traffic islands looked out of place, but they did adhere to a literal reading of osm.wiki/Dual_carriageway and what’s sometimes referred to as the “physical separation principle” – that some physical barrier is what determines whether a road is divided or not. We have no rule against someone now coming in and mapping the traffic island itself, in which case the road would conflict with it.

The five crosswalk segments you’re referring to are a very common mapping practice in U.S. cities these days. This detail is being used by some renderers that focus on street-level detail, and there’s even a tag for the portion within the traffic island, used over 20,000 times: osm.wiki/Tag:footway%3Dtraffic_island

There’s certainly no requirement for you to map in such great detail if you’re mapping a street for the first time, but someone went through the effort to add it and their approach isn’t any further outside the mainstream than yours.

What’s so bad about micromapping? Now the crossing is rather misleading: to a pedestrian, it’s as if there are random curbs in the middle of the road.

Hi, was the renaming of “Remington Pond” to “Pond Pond” intentional? It’s a rather amusing name. osm.org/way/48250550/history

Thank you for the quick response. Yes, I realize you were looking at the lane markings. I’m not sure if your team’s policy accounts for this, but a solid lane divider marking normally isn’t enough to justify drawing a separate link road that branches off; that’s what the turn:lanes and change:lanes tags are for.

Upon further inspection, the previous modeling wasn’t quite correct either, because the link way is only for the southbound left turn lane, not the northbound lanes or the motel’s service road. Your changeset did implement those restrictions by coincidence, so thank you for that. I’ve added a oneway tag and turn restriction to restore those restrictions.

Hi, this changeset is incorrect. There was already a link road, but you replaced it with one that incorrectly curves around as if there’s a physical separation between the left turn lane and the through lanes. The previous link road respected the turn lane tags that were present. I’m reverting this changeset to fix lane guidance in this area.

osm.org/changeset/143557291