Looks like a house at the end of that, the original tags seem to apply.
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/101492068

Additionally if the idea was to tag operator=*, then name and Midland Valley is also wrong. Not sure what, if any, that branch has, and the operator is definitely Tulsa Sapulpa Union Railroad

The railroad hasn't existed in a long time. There also is no passenger rail service there, which is what route=railway is for.

No problem. Sorry to suck you into this rabbit hole. I'm hoping things move in a more consistent direction in general vis-a-vis reserved lanes in general. I don't understand the resistance to this generally given that how Fairview got retagged including the bicycle lanes is consistent with other kinds of lane tagging, such as that for HOVs and buses, complete with access tags.

I do understand the need to understand the width, I just don't have a good method for measuring that given travel and "standing in traffic" implications. I would have added lanes:width=* if I knew the values, though they are at least wide enough to fit a car down as can be seen in the Bing imagery at various points.

In the case of shared lane, that's clearly visible where the lane line changes to a broken line. In California, this indicates that the lane is shared with other traffic for that length.

There's four lanes. The bicycle lane counts as a lane. The whole idea that a lane doesn't count just because of modal access is both preposterous and doesn't agree with other types of reserved lane tagging, does it? The wiki seems extremely wrong here. just logically working it out, especially a lane that even motorists are required to merge into in California in order to turn right.

I feel like a reclassification blanket up to primary for what is mostly a two lane state highway is a little ambitious. Typically that's done at a secondary level and more built up parts are classed higher.

The wiki is pretty unreliable anymore, a lot of wiki types like to be prescriptionist rather than descriptionist and that kind of pikes over everything.

I'm not going to go archive diving right now, I have work to do. You're welcome to do so. Or change the tag back. I'm honestly not that invested in this spur.

You might consider the usage tag instead of the service one mostly because that seems to be the direction things are going and validators are encouraging that, in order to leave service=* open for it's original highway=service usage.

Sure, usage=industrial works for me.

I believe this was discussed on the OSM tagging and the OpenRailwayMap mailing lists back in the late '10s.

service=spur has been deprecated in favor of usage=branch

Something about the fire hydrants having addr:full=* tags doesn't quite pass the smell test, especially since there's buildings that have the same address.

If the hydrant literally has its own address, then that's valid, but in my experience I've never seen any American city assign fire hydrants addresses.

This definitely is named. There's apparently a local rule that requires private roads to be named and the owner happened to give this a very hilarious name. I personally spotted this street on the ground.

This definitely is named. There's apparently a local rule that requires private roads to be named and the owner happened to give this a very hilarious name. I personally spotted this street on the ground.

Sure, on relation/6370352, it doesn't appear to be a specific trail but a whole collection of trails. I'm not sure this really works as a route.

Probably don't need the route relation for this based on what is in the relation. Route relations are for objects that make a linear route, not a collection of random objects, and need to be made once per route type, not multiple route values on the same route relation.

If you can describe more about what you're going for that might help me get an idea on which way to go with this.

I will defer to your superior knowledge of military history on this one, I've restored the original spelling.

Well, congratulations, you've managed to systematically ruin every public transport relation in Tulsa by blindly importing a completely inaccurate GTFS file.
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/94504007

Thank you for blindly changing the order and membership of this relation without having any on the ground knowledge. This totally didn't wreck hours of hard work and make the map worse at all.

Each route should be its own relation, not all routes in a single relation.

These problably should be lcn or some other network, not rcn. Relations are not collections, putting all the trails as a single relation also isn't appropriate.