Proposal:Public transport=demand transit

From OpenStreetMap Wiki
Jump to navigation Jump to search
public transport=demand transit
Proposal status: Draft (under way)
Proposed by: JPinAR
Tagging: public_transport=demand_transit
Statistics:

Draft started: 2022-10-22


Proposal

In US DOT has opened up a Demand Responsive Service option, see 49 CFR Sec 604.3(g), to public and non-profit bus/van/car like transit. This means the vehicle will have neither a fixed route or fixed schedule except, perhaps, on a temporary basis to satisfy a special need.

Any public passenger wishing to use the service generally will make a phone call or internet-based request to the transit operator who then dispatches a vehicle for pickup.

This model has many similarities to App based gig-based taxi services like Uber or Lyfy. However, these services are publicly funded and have more fixed operational areas that change infrequently and are easy to obtain through the public transit authority.

These were trialed but have seen wider adoption of late with both the pandemic and fuel price fluctuations and are seen as a way to both reduce gas costs while expanding service as passengers don't have to make their way to predetermined stops. These are also more common in mid-sized towns for which public transit is more volatile.

The public_transport=demand_transit tags will always be defined as areas (area=yes) that can either stand on it's own or be paired via relationship to station that can either serve serve as a transfer point between another demand-responsive transit (DRT) region, a fixed route, or both.

It is also possible that a demand responsive transit (DRT) region be one way with either a fixed origin or fixed destination. Examples include:

  • Many origins-One destination – for example a pre-arranged persons with disabilities or senior citizen which pick up people at their homes and take them to a shopping or recreation center
  • One origin-Many destinations – For example, a vehicle meets a commuter train, picks up the passengers and drives them to their homes.

This will always be an area and preferably be a child member of a relationship but may also function as a stand alone.

Rationale

The concept of Public Transit as something that functions strictly on fixed routes hasn't changed in decades but the gig-based taxi economy has challenged the preconceived notions of how public transit must operate in a way that actually makes public transit for smaller communities more tangible with smaller budgets. While I like many mappers would be resistant to allowing for app-based gig-based taxi services with constantly changing areas, hours, and pay structure I believe there is a place for this when restricted specifically to 'shared service public transit'.

The key was selected to match the existing public_transport key as there will fall under the umbrella and mindset of being inherently public transit. The key I selected was to align to the industry and US DOT adopted terminology as much as I could, that being 'Demand-Responsive Transit or Transportation' both using the abbreviation DRT. However, DRT is not immediately understood and demand_responsive_transit becomes a bit to long. I also intentionally avoided using bus/train/etc in the tags much like the rest of the now standard public transit v2 standard as something like a platform can be shared by a bus and train on either side. So tags like bus=yes or train=yes are required. (Most public transit can't leverage this because of how they are fixed by physical design.)

Tagging

The Demand-Responsive Transit (DRT) areas must be tagged as a area. DRT can be grouped with stations within their boundary by relation based on type for example type=route with route=bus.

Step 1: Create the Area The following additional attributes can be used:

Tag Usage Description
public_transport=demand_transit ! Required This tag was introduced in the Public Transport proposal.
website=* ‽ Important Where passengers can request ride.
phone=* ‽ Important Where to call to request ride.
name=* ‽ Important Name of the bus stop, if bus stop has it.
ref=* ‽ Important Reference of the bus stop, if bus stop has it - usually a series of letters and numbers used to find the stop on digitized systems.
opening_hours=* ‽ Important Especially if operations are not 24/7 then hours of operation highly relevant.
wheelchair=* ‽ Important See key for details but inclusion of tag is important for inclusion.
local_ref=* ? Optional Short reference of the bus stop - "A", "D1" for example
network=* ? Optional Name of the network if exists. The network (relevant e.g. for fares) is really dependent upon the bus company that is making a particular stop (i.e. see "network" on the route relation), so it may be better to omit this on the bus stop itself.
operator=* ? Optional Name of the operator if exists. Note that different parts may be owned by different operators; e.g. in Germany, it is not uncommon for the pavement to be installed by the city, the signpost by the network's NGO or one of the bus companies, and the shelter (if any) be managed by an advertising agency.
internet_access=* ? Optional Indicate if service internet access and if so what type.
bicycle_parking=* ? Optional Indicates a place to park or store bicycle either on a vehicle rack or within the vehicle. Suggested instead of bicycle=yes to avoid confusion with possible public bike transit areas, although unlikely and not suggested. As capacity=* will be presumed to indicate the capacity of the public transit itself, if bicycles can be carried as well then capacity:bicycle=* maybe used to indicate the number of bicycles that can be carried.

Many of these tags are comparable to a highway=bus_stop but only include the tags that describe the physical characteristics of the vehicle as there is no set location.

Step 2: Create a Route(s) Relationship

  • If a public_transport=demand_transit is a stand-alone and doesn't connect to any other DRT or fixed routes via a station then no relationship is required, otherwise, one or more route relationships should be created for each DRT-Station relationship
  • If a DRT is many origins-many destinations then the to=* and from=* tags should be left blank and a roundtrip=yes tag should be included
  • If a DRT is either one origin-many destinations or many origins-one destination then to=* and from=* tags must be included along with a oneway=yes

Step 3: (Rare-Conditional) Create a Route Master If a Public Transit has more than one route type, for instance, they switch between a fixed and demand-responsive transit route model then both should be associated via a Route Master. (For more on this see Buses#Step_3_-_Create_a_route_master_relation)

Examples

In Northwest Arkansas, we have Public Transit service through wikipedia=en:Ozark Regional Transit (ORT). For the cities of Bentonville and Rogers ORT provides On-Demand Transit via Phone or Apple/Google App. At old stops as well as common origin/destination locations signs have instructions and a QR code leading them to the mobile App for service, for those without the app service is via phone call.

I will be adding tags that show these for Bentonville and Rogers as Proof of Concept. Within NWA the Bentonville and Rogers Demand-Responsive Transit (DRT) regions overlap in two locations one at Northwest Arkansas Community college which is will be marked as a station despite it only appearing to serve as a stop on a route. However, this is the location where passengers can either swap between Bentonville/Rogers DRT regions or jump on the 490 Route which will take passengers along I-49 south to larger towns like Springdale and Fayetteville which have more traditional public transit via fixed routes. (Although Fayetteville has had one area of the town also as a functional DRT region as well.)

NW Arkansas use case:

The easiest way to display what this looks like is an Overpass Turbo Query of the Ozark Regional Transit (ORT) network this shows the intermixing of fixed and demand-responsive transit (DRT).

To get more into the details I'll point you to two nodes and their relationships the first is the NW Arkansas Community College 'Station' which connects:

The second is the Forum Business Complex 'Station' which connects:

Note: This station does not connect to any fixed bus lines and only serves as a switching-over point for those moving between the Bentonville & Rogers DRT areas.

Rendering

The rendering of this depends on the purpose of the render for most non-public transit-oriented renders this should be rendered more like a boundary=* with no inner fill/shading. However, for public transit-oriented renders, this should appear more like a solid boundary with a 10-20% opacity fill and be a background to fixed routes that should they overlap demand-responsive transit regions should appear on top.

Although query based this serves as an example what this might look like from a public transit map styled view Overpass Turbo Query of the Ozark Regional Transit (ORT) network.

Features/Pages affected

External discussions

Comments

Please comment on the discussion page.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Public_transport%3Ddemand_transit&oldid=2516782"