Proposed MapRoulette challenge: minor service roads along bus routes

A few days ago, I made a set of MapRoulette challenges to check and retag minor service roads along bus routes. Some questions were raised about the challenges, so I’ve paused them to gauge community sentiment around the changes.


A new OSM route relation editor, Relatify, was released earlier this month. While trying it out, I noticed that it wouldn’t allow me to add minor service roads (service=driveway, service=parking_aisle, etc.) to route=bus relations. I mentioned this to the developers of Relatify, at which time there were about 7,000 ways tagged as minor service roads along bus routes in the United States. @ToniE confirmed that PTNA, a quality analysis tool for public transit routes, behaves the same way.

The Relatify developers responded that most of these ways are likely tagging mistakes, and that for the small percentage that are correct, adding psv=yes|designated or bus=yes|designated will allow Relatify to recognize them. I inspected a small sample of the affected ways, and I agreed with this assessment. We figured that MapRoulette would be the best tool to fix this issue, as each affected way will need individual attention to determine whether it should change classification, or just have bus=* added. When I announced the creation of relevant MapRoulette challenges on the OSM-US Slack, the response was generally positive and prompted some mapping activity, but I may have jumped the gun on publishing them without enough community buy-in.

The MapRoulette challenges

The challenges cover the whole US, split up by state, with CA, IL and NY further split into sections to encourage mappers to contribute in their local area. They highlight ways on OSM tagged highway=service + service=…, missing bus=* and psv=*, that belong to at least one route=bus relation. The instructions are, verbatim:

For each service road segment:

  1. Check to make sure the underlying route=bus relations truly follow the path of the bus.
    • Mark the task as too hard if the relation is broken or incorrect. Write a comment describing the issue.
    • Or, fix it! Use JOSM to route the relation properly.
  2. Retag the service road segment.
    • Remove service=driveway, service=parking_aisle, etc. if this roadway is clearly more important than a driveway or a parking aisle, for example.
    • Or, add bus=yes if this roadway’s tagging really is correct. This helps OSM editors like Relatify and quality analysis tools like PTNA recognize it.

Are there any objections to this project? Should I publish the challenges once again? Let me know your thoughts.

1 Like

My gut reaction is that sometimes a bus route transits a parking aisle, usually because it’s driving through a parking lot to the front door of a shopping center. I don’t think it’s appropriate to selectively add bus=yes to that parking aisle simply because a bus route happens to run over it. I think it would be better for PTNA to change their quality assurance to not flag this as a problem.

That said, when I reviewed this challenge for my state, many of the cases were incorrectly tagged as service=parking_aisle, so there is value in a challenge for reviewing the list. The number of legitimate cases where a bus route transited over a legitimate service=parking_aisle was very small once I completed that review.


PTNA reports these issues as ‘notes’ not ‘errors’.
I think it is worth reporting that, because the vast majority of the cases are valid notes.
I considered them as being covered by “Not every roadway within a parking lot is a parking aisle. Examples are…

I agree with this assessment. service=parking_aisle is often overused by mappers unfamiliar with the term “parking aisle”, who assume it means any road associated with a parking lot. service=driveway is overused especially by mappers in some parts of the U.S., where that word means any service road without a more specific description. This causes problems for both renderers (which cannot reliably filter out parking aisles and driveways without fragmenting the road network) and routers (which cannot reliably avoid using parking aisles and driveways as cut-throughs).

Compounding the problem, English has no word for parking lot entrances and exits or for the main circulatory roads around and through a parking lot, other than these unwieldy circumlocutions or worse. This ontological gap has precluded new service=* values and presets that would help mappers classify service roads more accurately.

I appreciate that these notes raise awareness of the problem and make it easy to spot-check for places where the mistagging is prevalent. For that reason, I would support the proposed challenge, even if it results in some perfunctory usage of bus=yes. I also think we should be open, within reason, to accommodating the needs of specialized editors like Relatify, which enables mere mortals to map public transportation routes. The one or two JOSM power users who’ve been tending to bus routes across the country simply haven’t been able to keep up with all the “transit death spirals” playing out in each city.

That said, I think it would be worth investigating a more direct way to detect mistagging and other issues. For example, if a bus route enters a parking lot, loops around it, and leaves it without stopping anywhere, there may be a missing highway=bus_stop or public_transport=stop_position, regardless of road classification.

More broadly, OSM Inspector can detect routing islands, and Osmose can detect when road classifications change abruptly; could a validator rule detect when a service=parking_aisle or service=driveway is the main roadway connecting two non-service=* ways? Moreover, we can pretty much guarantee that a parking lot circulatory road passes directly in front of every Walmart, Meijer, or other big-box store in the country, even if no bus goes through there. If that road is tagged as a service=parking_aisle, it’s a good sign to check everything around it too.

In the meantime, here are some examples of the edits I’ve made in response to this challenge so far, and I’ve only picked off a few tasks in one small town:

All the roads leading to this Walmart had been tagged as service=parking_aisle, even roads outside of the parking lot proper.

This parking lot was missing a bus stop and bicycle parking. The bus stop is on a minor aisle that I did not reclassify, but I did add bus=yes. Note the sweeping curve at the south end of the aisle, clearly designed to accommodate buses.

This parking lot was also missing a bus stop, which the transit agency apparently plopped right over some parking spaces.

Not only did this parking lot lack a bus stop and bicycle parking, but the bus stop’s location on the west side of the service road also indicated that all three bus routes were looping around the parking lot in the wrong direction, clockwise instead of counterclockwise.


Are you talking about Tag:highway=busway - OpenStreetMap Wiki ?

highway=service is not defined on OSM tags for routing/Access restrictions - OpenStreetMap Wiki though for me it doesn’t makes any sense a bus is not allowed to drive on a highway=service by default.

Not sure, in US you have something like rest areas along the motorways. They are typical tagged as highway=service and are of course used by bus and hgv. So adding those access-Tags sounds not like a good idea.

So in summary: I think it’s reasonable to bring those cases up by a QA tool like PTNA, but it’s a a problem of the editor, not allowing to add routes on such ways.

That’s not the question here: we’re talking about sub-type: service=driveway, =parking_aisle, =alley, =emergency_access and =drive-through

Edit: fix typos

1 Like

Where do you see the difference? Are busses by default forbidden to ride on a parking_aisle, alley or on a driveway? Is a bus not allowed to use the drive_through? There might be other reasons a bus can’t use them (max_width, max_height, max_length). So, in my understanding bus=no it should not be the default value on such roads and therefore it should not be necessary to add a bus=yes.

The discussion is the other way round: if buses use a service road then that service road should not be tagged as parking_aisle, driveway, alley, emergency_access or drive-through.

I.e. the classification of a service road with service=* is too low, is not appropriate for that type of traffic (public transport).

I must admit and agree that tagging this with bus/psv=yes is a bit misleading as this is usually dedicated for “access restrictions”

1 Like

A bus can of course use a driveway to enter the depot, park on a parking, use the drive-through at McDonalds,… so a default bus=no is not proper, as there is no such rule existing.

I agree, it doesn’t make sense a pt-route is using such roads. But this has nothing to do with access-tags. That’s why I said previously, it makes sense to question such situations in a QA tool. But adding access tags just to please an editor is tagging for the editor.

Agreed! This topic is about highway=service in a PT route relation, so passengers are on board - and that makes the difference to me.

I would agree, that this is the situation in most cases. However handling the exceptions should not “misuse” access-tagging.

1 Like

I don’t really agree that bus=yes would be an abuse of access tagging. While a fixed-route bus is in service, it is required to follow the designated route. The bus is by definition allowed on each of the roadways along the route. In most of the parking lots that are the subject of this challenge, the transit agency is only permitted to enter the lot by written or verbal agreement with the owner (example). I wouldn’t be surprised if the negotiations even included some discussion of the specific route, because heavy vehicles such as buses can incur maintenance costs on the lot’s owner. I think bus=yes would be accurate, albeit pedantic, along these specific service roads.

When a bus is out of service, it may roam public city streets independently of any route, but not every roadway. It may park in a designated bus parking lot, such as the one pictured to the side in my earlier post, or in a designated layover space, but it probably would be prohibited from parking in any other parking lot. So there are related but distinct permissions/restrictions that I think would justify some amount of bus=* tagging on roadways, bus=* tagging on parking lots, and route=bus relations.

1 Like

From what I understand is, that the agreement is about operating a bus stop and not about whether a bus is allowed to use the parking.

If a bus (out of service, not a bus used for pt) is not allowed to enter the car park, I would assume there is a sign indicating this. How else the driver should know? If there is a sign, adding the matching access-tag is totally fine in accordance with the access. But adding a access-tag to please an editor isn’t.


To be a bit more general. The existence of a has no relation to access. A bicycle route can run on a section where cycling is forbidden, for example a highway=pedestrian. If there would be a similar editor for bicycle routes, it would be wrong to add a bicycle=yes, just to please that editor. Why it should be different for pt relations?

Sure, you can add capacity:bus=no in case there is no parking slot for busses.

If the bus operator isn’t allowed to enter the parking lot, they’ll know because the parking lot isn’t on the operator’s assigned bus route. Moreover, most of these parking lots are private property. When you’re on private property, you follow the owner’s rules. Drivers of buses, RVs, and other large vehicles are generally presumed to be unwelcome at a parking lot unless invited by the owner.

I don’t know what the norm is globally, but in the U.S., you’ll rarely find a sign anywhere that says “No Buses” even if buses are prohibited. The reason is that the local transportation department can be pretty sure that a bus operator on their payroll isn’t taking a bus on a joy ride. It would cost money to put up regulatory signs for that bizarre scenario. Maybe Los Angeles put some up while Speed was being filmed?

The closest real-world situation I’ve encountered is that San Francisco has installed signs and lane markings exempting “Muni & GGT” from the Do Not Enter restriction on the busway below. Based on a literal reading of this sign, only those two transit agencies’ buses may use the busway, but other agencies that serve the city may not.

In reality, the authorities weren’t concerned about SamTrans or AC Transit bus operators going rogue. Rather, they wanted to make sure that tour buses and tech company shuttle buses wouldn’t enter the busway unauthorized. So this sign actually translates to coach=no tourist_bus=no and whatever the tag would be for the Google/Apple/Meta shuttle buses.

I don’t see how this is relevant. Presumably you’re referring to a path where the cyclist must walk their bike? That does happen along bike routes, typically when a bike path crosses the road at an intersection. However, that would be tagged bicycle=dismount, which (one hopes) has no analogue in public transportation.

We can’t assume that a parking lot has a long marked parking space if and only if it allows long vehicles. For example, Walmart is famous for allowing trucks and RVs to park overnight at many of their parking lots, but they never mark spaces for oversize vehicles. Buses often lay over at the back of a parking lot, splayed out over multiple spaces.

To reiterate, I realize that bus=yes on some of these parking aisles would be pedantic and redundant, but it isn’t misleading. In some cases, as in the “Chestnut Fields” example I gave earlier, bus=yes is a practical tag for indicating that the parking aisle is designed to accommodate buses; alternatives like turning_radius=* are probably unusable anyways.

Immediately after writing this, I remembered such a situation down the street from me:


This will give rise to a future Maproulette challenge - as bus routes change, the relations are updated. The new challenge: “Remove bus=yes from service ways not on a PT route”

1 Like

Analogy comes if the PT editor would be used to create cycling routes and tells you to add bicycle=yes in order to create the route.

And that’s my point. The existence of an route doesn’t grant access to it.

Same like on the parking you mentioned. The owner allowed a specific bus company to run a bus stop. Not any bus seems to be allowed. Typical in such a case in osm we would not add such information, as like you said the one having the permission will know it. Tagging a bus=yes would mean any bus is allowed there. So also greyhound,…

That’s a fair point, although I wonder if this is a difference without a distinction, when technically, any parking aisle in a privately owned parking lot would be at most access=permissive.

There is established precedent for this key to communicate something that isn’t strictly a legal restriction based on vehicle classifications. A bus stopping location is always tagged public_transport=stop_position bus=yes. We normally rely on network to communicate the fact that it’s served by certain buses, the implication being that other buses normally may not serve the stop.

However, I concede that there are real-world edge cases. I’ve troll-tagged a Google Bus stop as highway=bus_stop bus=no shuttle_bus=yes right in front of the Googleplex. The local transit agency has built the rudiments of a busway, so far for the exclusive use of Apple company shuttles; it’s bus=no shuttle_bus=designated. This bus bay is for employee shuttle buses, including the NASA Shuttle. space_shuttle=designated? :star_struck:

NASA Shuttle, Shuttle Buses Only © 2018 lvl5, CC BY-SA 4.0

Isn’t this why every validator has an ignore button? MapRoulette has a Not an Issue button too.

This wouldn’t necessarily be a disaster, as long as there is a possibility of bicycle=dismount. Of the more than 26,000 centerline miles (43 000 km) in the U.S. Bicycle Route System, over 4,500 centerline miles (7 300 km) or 17% are tagged bicycle=yes or bicycle=designated. Most of this usage is because hike-bike trails are often tagged as either highway=cycleway foot=designated bicycle=designated or highway=path foot=yes bicycle=yes. But bicycle=* also occurs on on-road segments, where a car router could benefit from knowing that the driver needs to “Share the Road” with cyclists, even if it doesn’t consider bike routes per se.

It might be a solution to use something like bus:<network name>=yes to indicate the parking area (access=customers or access=permissive) can also be used by a bus of a certain bus operator. That would also do for your Googel, Apple and NASA bus :wink: