The point you're missing is that I'm not the one suggesting a change here - you are.
The "standard" you're claiming exists really doesn't, it is nothing more than (your) personal preference. Some folks will agree with that preference, others won't.

There's entire road networks that are not mapped the way you're claiming is the norm.
The status quo is simply that there is no (community-approved) standard for whether to include the refs on the ways if they're already on the relation. If you want to change that, again, please follow the proposal process to establish a standard (be that to always include them, never include them, or something in between). Until then, mappers will do what makes the most sense to them. For me personally, that means not duplicating the refs and fake-tagging them as attributes of ways, when semantically, they're really attributes of the relation, just to satisfy a renderer.

TIGER or not was not the point - the point was that your "but there's a lot of examples on the map that support my preference, and that makes it the standard" argument is flawed.

The process you're describing (=filling in stuff based on history that may or may not have been right) and without verifying whether these segments are actually currently(!) part of that route, is precisely what I expected, and why I believe these are undiscussed mechanical edits. The part that is clearly missing is verification that each of the segments you tagged is indeed part of the route right now.

De facto doesn't make anything a standard, a proposal does.
De facto, millions of road segments have tiger tags from old imports. That doesn't make keeping them a standard in any fashion.
De facto, large areas of the US are missing building footprints. That doesn't make "no buildings" a standard.
De facto massive amounts of major roads have lane tags not matching the ground truth along the entirety of the segment, because someone looked at a subsection of that way at some point only when they tagged the entire segment. Again, that doesn't make having miles and miles of road tagged as two-lane the standard when in reality there's sections turn lanes along that segment.

If you want to enforce your preferred tagging style as the standard, there is a process for that - a proposal. Until then, please respect that your preferred style is not everybody else's preferred style.

Also, be careful with just blindly "inferring" that every way in a route relation should have the segments tagged and forcing these tags in without any further verification. This probably fits the definition of a mechanical edit (which I'm assuming was not discussed in the proper channels either?)

hold on for just one second though - would you mind sharing a link to the proposal that established the tagging style you seem to be preferring personally as "the standard"? All I'm seeing under that link looks like a random dude's opinion on a wiki page - that doesn't quite meet the bar for what I would consider standard. Especially, if the main argument there (and the one you chose to reference here) essentially boils down to "tag for the renderer" (when there is no ground truth for the tags on each of the way segments contributing to the relation).

because the ref sits on the relation (1656989)

are you sure about the name change on way/178411958? The park district lists this as Fox Hill Park on their website, and that's also consistent with what's visible on the sign in bing streetside imagery. Google Maps shows this location as Wheatlands park, but copying anything from gmaps is a copyright/license violation...

Hi there - thanks for catching this. I have a preset for blank addresses which makes address tagging from scratch somewhat more efficient for me, and must have used the wrong keyboard shortcut (bound to this preset) by mistake. There's nothing automated about it. This was meant to be tagged noexit=yes instead. Fixed in changeset/150106083.

Copying anything from google maps would appear to be a copyright violation ( see osm.wiki/Google ).
The Pace website could work - do you know if they have some sort of open data policy explicitly allowing their data to be used?

Hey there - fences can be difficult - the entrance/gate is often not easily identifiable, and depending on how the shadows fall on the aerial, it may not even be obvious whether there's fencing surrounding the entire(!) area at all. For these reasons I typically try to stay away from the fences. After all, I find the number, size and location of each of the courts to be more useful than the position of the fence (if any), though others may certainly chose to disagree.

With that being said though, if a fence was mapped to begin with (either on the way representing the giant tennis "court", or as a separate way sharing the same nodes), I do not typically remove it (as in "I add more detail where I can, but don't remove any existing detail").

Interesting; thanks for sharing. Looks like they forgot to update the list of posted stops then.

Where on the bing aerial did you see that the NB Main&NW Hwy stop is on the NE corner of the intersection? It's very clearly on the SE corner on bing streetside; which is consistent with what Pace publishes on their website in the list of posted stops locations.

Also, please refrain from using abbreviations in names. We've discussed this point before, but in case you forgot, please re-read the "Abbreviations" page on the wiki for further details and background [1]. Please respect the rules and guidelines of the community you've chosen to be a part of. Thanks!

[1] osm.wiki/Abbreviations

"Farther out zoom levels" - where exactly? On the slippy map on the openstreetmap.org website?
This is only one data consumer out of many; and any of them is free to abbreviate names so they look better visually. For a data consumer, it is relatively easy to abbreviate spelled out terms, whereas guessing the correct spelled out word from the abbreviation is quite error prone.

The one exception is abbreviations that are themselves idiosyncratic (think CTA, FBI, ...) - these are generally accepted.

If you insist on having the abbreviated version tagged also, I guess the official_name tag could be worth looking into. However, not sure if you're aware or not, but Pace in particular isn't entirely consistent with how they name their stops themselves (e.g. in some cases, the names on the time table don't match the names on the list of posted stops, or the name on the ventra app, for that matter).

In a way, abbreviating names so they display nicely on one particular map (e.g. the slippy map on osm.org) is a form of tagging for the renderer, which should generally be avoided - see here for more details: osm.wiki/Tagging_for_the_renderer

Here's some further info on names and abbreviations. Note that this isn't just talking about street names, but names in general.
osm.wiki/Abbreviations

osm.wiki/Names#Abbreviation_(don't_do_it)

A typical PTv2 route would consist of one route master relation, with the individual routes (e.g. an one for eastbound, one for westbound trips) as members (without a role).
If any of the trips took an alternative path, these would be added as separate routes within the same route master also.
In this particular case, we had one route master (relation/15594524) that contained another route master (relation/15594510), which then contained the routes. Hence, the "real" route master was "nested" within another (redundant) route master, which I removed.

Regarding the names, the PTv2 scheme does explicitly define how the name tag should be used. For bus route masters that is "Bus<ref>" and for bus routes it is "Bus <ref>: <from> => <to>". When multiple bus routes would end up getting the same name this way, "Bus <ref>: <from> => <via> => <to>" should be used.
The official_name tag is a good place for the descriptive name.

You can find more detail about the naming here: osm.wiki/Buses

The original proposal that PTv2 is based on is here (it defines the naming conventions in this exact way also): osm.wiki/w/index.php?oldid=625726

Hey there - What are these foot=no restrictions based on? Like are there actually signs stating that it is forbidden for pedestrians to use the roadway now? Last time I checked that wasn't the case, and per the IL rules of the road, it is legal for pedestrians to use the road in areas where sidewalks and shoulders don't exist (as is the case on this stretch of Ogden).

foot=no

Hey there - glad to see more routes getting converted to ptv2! Just one note - the order of the ways in the relation does matter - they should be in the order of travel. I notice you're using the iD editor; and if I remember it right from the few times I played with it, getting the relation's members in order isn't the easiest thing in iD (I use JOSM, which lets you spot gaps quite well). I've been cleaning up a lot of the unroutable mess that many public transit relations in the area are lately. If you want me to get the order fixed before working on the PTv2 conversion of a particular route, please reach out any time. Thanks!

Please do not replace spelled out names by abbreviations. Abbreviating something is easy for a data consumer to do; while correctly resolving abbreviations is not. These types of "fixes" are a step backwards.

Quoting directly from the wiki: "If the name can be spelled without an abbreviation, then don't abbreviate it. Computers can easily shorten words, but not the other way (St. could be Street or Saint)."

See here for more details:
osm.wiki/Names
osm.wiki/Abbreviations

Hi there - thanks for responding.
I believe the "one light only if it's just two roads crossing" approach is consensus anyway, it's specifically the ones on double carriageways that I'm concerned about.

As far as redundancy is concerned, I'd argue it's the other way around - moving the lights into the center of the intersection, with no restrictions as to what specifically each of them applies to actually _introduces_ redundancy, bc now you have multiple "fake" (not applicable) lights no matter what direction you're moving.
I understand the "I can't get it to work the other way" argument when mapping new/missing lights, I'd just ask to not move them if they're already mapped in the (more detailed) newer fashion. Does that sound acceptable?

If you care to find out how the approach arrows work, here's some details:
In the end, it's just another tag on the light itself: direction=forward (if the light applies to vehicles traveling in the same direction the way is drawn) or direction=backward (if the light applies to vehicles traveling the opposite direction).
If no direction tag is specified, the light applies to vehicles approaching from either direction.
However, if the light sits on a way that is tagged as oneway=yes (or oneway=1 I believe), you can omit the direction tags altogether (so on intersections where two dual carriageways cross, like IL59 / Royal Worlington Dr, you literally just place the light on the stop line on each of the incoming ways and that's it - no extra tags required).
The same approach works for stop signs too, by the way, not just lights.

Hi - please stop "fixing" names by abbreviating them.

Please refer to [1] and [2] for best practices on naming and why abbreviations are generally to be avoided. In short, any data consumer can easily abbreviate "Boulevard", "West", "Street" etc. itself, while automatically and reliably deriving the spelled out form from an abbreviation is often impossible because some abbreviations are ambiguous.
Thanks!

[1] osm.wiki/Names#Name_keys

[2] osm.wiki/Abbreviations

Also, would you please consider being a little more specific in your change set comments. "Fix Points" is super generic and as such, hardly indicative of what exactly it is you're doing. All that says is "I made some unspecified changes to some unspecified objects", which is hardly more meaningful than no comment at all. Thanks!

Hi - could you elaborate on how moving the traffic lights into the middle of the intersections is "fixing" them? This results in going through three individual lights when making a left turn at these intersections, which obviously isn't ground truth. Also, mapping the lights on the incoming ways is perfectly valid per the wiki. I'd argue that these "fixes" not only add no value, but actually disimprove the situation by replacing a more specific mapping scheme by something less accurate...

I'm tempted to revert these, but I'm curious to hear your thoughts first.

Thanks!

Hey there.

Just wanted to make you aware that amenity=school and building=school are not the same thing - the one is the site, the other is the school house. In 99% of the cases, the name goes on the amenity, not the building (that is, unless, for some reason, the building itself has a name of its own - but that is not common).

You can take a look at the wiki* for a detailed description of how schools should typically be mapped, including visualizations of which tag goes where.

The same is true for fire stations (amenity=fire_station is not the same as building=fire_station).

I cleaned up some of your school edits; and I'll try to take a look at the remaining ones in the next couple of days.

Thanks,

* amenity=school#How_to_map