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?

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: footway=traffic_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. 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.

changeset/143557291

That’s a bug in Wikimedia’s geoline service. [1] As a workaround, you can still query for one of these relations, convert it to GeoJSON, and upload it to Commons. The AARoads Wiki (a fork of Wikipedia) has a decent tutorial for creating these maps [2], although Wikimedia’s Kartographer extension is a bit pickier when it comes to bounding boxes:

[1] https://phabricator.wikimedia.org/T156433
[2] https://wiki.aaroads.com/wiki/AARoads:Maps/Creating_a_GeoJSON_file_from_OpenStreetMap

Subarea relation members aren’t really a good idea overall; this is what spatial queries are for…

Fixed in changeset/143076741.

I used the iD preset for rolled curbs. The bug in OSRM is being tracked in https://github.com/Project-OSRM/osrm-backend/issues/6582 .

Also, the AARoads Wiki maintains a variation of this style that makes certain routes easier to follow at a glance; it makes use of the same standard tagging:

https://aaroads-wiki.github.io/openstreetmap-americana/

Hi, please see this guide for the standard tags for each route network:

osm.wiki/United_States_roads_tagging/Routes

In this case, future I-27 would be tagged network=US:I:Future and ref=27, not network=US:I and ref=I-27 (which would imply a present-day Interstate I-27).

If you haven’t seen it yet, I highly recommend checking out OSM Americana, an alternative map style that correctly renders route shields based on route relations:

https://zelonewolf.github.io/openstreetmap-americana/

Annnd… article: https://en.wikipedia.org/wiki/Heinlenville