All of those ways were split apart because they're to be different relation members - each stop position in the transit center is the end of one route to downtown Detroit, and the start of that route from. The reason they're NOT different relation members yet is because me and @alisonc42 are busy with other things in life and haven't been able to map stops lately.

Oki. I've re-added it anyway because of DDOT 16 using it.

May I ask the point of marking the left-turn lanes as separated roads and breaking bus routes in the process?

Why add the turn restriction when the slip road that allows the turn it isn't mapped?

(Or was it mapped back then and somehow got deleted?)

The edit broke routes 495, 760, and 780. osm.org/way/40047194 was originally three separate ways; the north was part of only 780, the middle was part of 780, NB 495, and 760; the south was 780, SB 495, and 760.

The systems are long overdue for some updates anyway, so I'll be fixing it among other issues and general issues, but I'd like you to please be careful to make sure the ways you're merging are all consecutive parts of the same relation in the future.

(I'm also saying that to myself. I've made that mistake before.)

Just as a heads-up: Your change here broke the southbound 465, southbound 461, and northbound 430 - those routes use that left-turn lane from Big Beaver onto Lakeview. I'm going to fix it in my next changeset (I'll just split the Big Beaver way at the point it intersects the left-turn slip road), which is coming hopefully within the hour.

Fixed. Upon closer inspection, some were actually turning/passing lanes, so I simply removed the tag in those cases.

They're all `bus_bay`s. Will fix in a bit, but this won't be an instant edit. Thanks for pointing out the right tag.

Ok, I caused some major damage with this one because JOSM doesn't locally save uploads unless you manually ctrl-s, so everything from my *last* changeset got duplicated. I've attempted to fix that, but please let me know if I've missed anything or caused other damage with this changeset.

I'd like to issue a specific apology to StudentInGear, for messing up the changes made to Woodward at St Joseph Hospital in Pontiac.

Additionally, the tag "limited=yes" on some bus stops means it has the sign "LTD" on it, indicating that routes 445, 465, or 515 stop there.

I've gone ahead and reverted the changes you made to the ways 168147845 and 219470983 (comprising the service road for the Fairlane Town Center bus stop). The fact that only buses can legally access this path doesn't make it not a driveway.

As you haven't provided any evidence that this node doesn't exist, and there is evidence that this node DOES exist (see its tags, in particular https://www.pmel.noaa.gov/tao/drupal/pirata-display/0n0e.html which has data from 2019-02-08), I've gone ahead and reverted this changeset. If you have evidence it shouldn't exist, please link it as you delete the point, rather than just "knowing" that a weather buoy in the middle of the Atlantic Ocean doesn't exist.

I'm aware. I admitted that the extraneous tag (and other related tags) was the result of an oversight, explained why the tags were there in the first place, and already changed the tags in question (though I simply removed them in the case of multiple networks sharing a stop). Please call me out again if you see it again (which you may, even after this conversation), but please don't assume I don't already know this.

The reason I don't usually use the actual "network" tag is because I believe that information can be better inherited from the routes - especially in the case of stops that have multiple valid values (because multiple networks serve the stops). For example, if the stop is tagged "network=SMART/DDOT", then it won't be found if you search for exact values "SMART" or "DDOT", or if you search for "DDOT/SMART". But you can find it on SMART because it's a child of a *relation* that has "network=SMART", and you can find it on DDOT the same way.

It's a network tag. The same applies to "ddot=yes", "smart=yes", or "fast=yes".

When I'm mapping these stops, I'm doing so from a moving bus, so I have to make small tags like those so I can keep up as the bus passes more stops. I then usually forget to remove them.

I'm uploading another changeset to address these tags within Downtown.

Operators. I surveyed the stops from a moving bus, so I didn't have time to make detailed notes on the stops. This was the best way I had to tell apart DDOT, SMART, and SMART FAST stops. Still, rather inattentive of me to leave them on the stops in the upload - will fix in a moment.

Followers of my profile may notice that this changeset is offset from my others by about... 600 miles or so. I'll explain in a journal on my profile.

Thanks for the catch! To be honest, those keys should never have been on those nodes in the first place. I've taken the erroneous tags off the relation members in my newest changeset (#57090144).

In the future, I may re-tag `ddot:downtown`=`yes` on stops to which their "Inbound CBD" fifty-cent fare applies (or just put that in a note). But as of now, those tags hold no meaning and should not have been there.

- Added stop_position for all stops of 275
- Added stop_position and platform to routes
- Fix the southbound 275 routing at Cherry Hill: the buses are allowed to make a direct left and actually do so

Yeah, I've used that on various routes when it removes ambiguity from other routes of the same number that don't go the same way, for example 450 SB: Pontiac => State Fair vs 450 SB: Pontiac => State Fair via Royal Oak.

... Just looked in the wiki because I thought you were wrong here.

You were right. There is no `start` or `end` key.

While I question those tags' applicability to this route in particular (`from` and `to` are the same stop), I'm going to update the rest of them to use the proper tags.

... Crap, I put the wrong source tag on the changeset. It was supposed to say DigitalGlobe Standard Imagery.