On Tuesday, July 29, 2014 1:46:18 PM UTC-4, Sean Barbeau wrote:For example, Tiramisu Transit (http://www.tiramisutransit.com/) by Carnegie Mellon crowd-sources occupancy from riders using their mobile app (i.e., not from a traditional AVL/APC system). It looks like they present occupancy to users in the app as "Bus Load", with the values "Many Seats", "Few Seats", "No seats", and "Full". I don't think they are presenting this data via an API, though.Hi everyone, I'm one of the Tiramisu Transit people. Sean sent me an email asking for our rationale and approach for our fullness metric. A quick bit of history: originally, we used Empty, Seats Avail, No Seats, and Full. This seemed to be confusing for our users, especially for the bottom two levels, so we moved to the terms Sean mentions above. We're close to releasing a major refresh and will be shortening the above terms to: Many, Few, Stand, and Full. This will save screen real estate.Our system is crowdsourced and therefore relies on rider perception of vehicle fullness. We didn't want to ask people to count passengers, were concerned about offering too many levels due to rater repeatability (the odds two people would give the same rating for the same stimuli), and the actual functional impact of each rating level.The functional impact part is really important. What does "this bus is 75% full" really mean to a rider? This doesn't disambiguate whether you're going to get a seat - which is the key question for a rider. An APC or farebox can't really tell if a seat is filled by luggage, a backpack, or a slouched passenger. Therefore, I think the spec needs to have the option to document seat fullness as an alternate to raw APC/farebox fullness calculations. An ordinal scale like Nisar's or our approach is also nice since it supports crowdsourced data techniques which can't capture numerical or percentage fullness. As an aside, we've also heard from colleagues that APC counts can be very noisy and often contain erroneous values. Therefore, placing too much faith in the accuracy of their raw numerical values could also be problem and it might make sense to map their data to 4-6 levels in order to mask the noise.Another key motivator for us was the functional availability of wheelchair seating spots (our research sponsor is oriented on disability issues). In the US, a "Full" rating is pretty much the same as "no room for a wheelchair." We didn't want to explicitly ask about wheelchair room for several reasons:
1) Improper interpretation of wheelchair space. We all know a driver will tell people to move out of the wheelchair seats and make room, but many end users might just mark such spaces as full.2) Malicious mis-reporting that spaces are full. While unlikely, it is quite possible an end user might start to mark wheelchair spots as full as a method for discouraging wheelchair users from seeking out their bus (long boarding times).3) Serving riders who need seats due to their physical capability. Asking about fullness instead of wheelchair seats is more universal and covers a wider range of disabilities. This extends the value of the data to frail older adults, people with disabilities that impact balance, and those who tire easily.In reality, there is a good mapping of our labels to wheelchair spot availability is pretty good. This mapping breaks down when both wheelchair spots (common configuration in US) are consumed on a bus that isn’t full. The odds of this are pretty low and that would probably be during off-peak times.We've been deployed for a while and have thousands of contributed trips (over 145k). We're in discussions with the local transit agency to compare their APC and farebox counts to our fullness ratings. We're still early in this discussion and hope to comment publicly on it sometime over the next year.--To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/7ad94bf9-2eb7-48f1-8be6-eed3d2eda76d%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/a402c075-a4f6-4320-8212-9c3fb2dcf7ff%40googlegroups.com.
Eric,
Good idea, I’ve added how SIRI represents occupancy (ordinal - seatsAvailable, standingAvailable, full) as well as TCIP (numeric - passenger count [0-255]) to the spreadsheet of known real-world examples of real-time occupancy.
In the list of existing real-world examples I’ve found, 3 of the 4 are presenting occupancy to end-users as a percentage. From speaking to regular riders here at USF, they say percentage is useful (even without an indicator as to whether its SITTING only or SITTING_AND_STANDING), as they are able to generalize what this means based on past experience (e.g., they’ll take a different route, or may have to wait for the next vehicle). I agree that for new riders percentage likely isn’t as meaningful.
Beyond the contents of the Google Doc spreadsheet (and obviously more data there), what would you like to see in terms of what systems are able to produce and how it’s shown to users?
Sean
--
You received this message because you are subscribed to a topic in the Google Groups "GTFS-realtime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-realtime/_HtNTGp5LxM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CAFLeBcHUs5bKMCerKcCe2%2Bg1x%3D%3DT_qrDKeNDdS7mz5DLeXpf3g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/9fe10772-9ec1-428e-876f-a3a8a798e6c9%40googlegroups.com.
Eric,
If the easiest step forward is to simply start with the enumeration, that’s fine with me. I added a single comment to the Google Doc, if you have a chance to review.
If there are no objections to starting with the enumeration, what’s the next step?
We’d like to start include this data in our GTFS-rt feed.
Sean
From: gtfs-r...@googlegroups.com [mailto:gtfs-r...@googlegroups.com] On Behalf Of Filippos Karapetis
Sent: Wednesday, September 03, 2014 9:20 AM
To: gtfs-r...@googlegroups.com
Subject: Re: [GTFS-realtime] Proposal: Add vehicle occupancy to GTFS-realtime
This idea could be extended to include the seat type, together with its availability.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/2ADFB73EE93D4541A085363403E99C0B0C2103594D%40USFMAIL2.forest.usf.edu.
--
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/41c77573-6767-4228-ad3c-1c834b353fb2%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CAFLeBcEs%3DrniTtPyzqXzFk%3DQN1ReonLsHnheF6vQUKa0L1iwdw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CADHEGt_%3D45NPa23F0u-C0841%2Bnd0DdoLUjv7ZK4urcx5Pxri5w%40mail.gmail.com.
Chiara/Brian,
We’re actually in the process of adding this field downstream in our GTFS-rt feed, so it hasn’t been deployed in production yet. So, timing is still good for changes on our end, if we can reach a conclusion in the next week. We’d of course still need to change onebusaway-gtfs-realtime-api with any updates.
I don’t think I agree with this change, though.
1 - Is the mutability of VehicleDescriptor more of an implementation issue on Google’s end? I don’t see where the mutability of VehicleDescriptor or VehiclePosition is defined in the spec – or am I missing something? If it’s a matter of the VehicleDescriptor definition (“Identification information for the vehicle performing the trip”) it seems more logical to me to change the definition. Logically, IMHO occupancy fits better under VehicleDescriptor.
2 - More importantly, I believe we’d lose the ability to represent vehicle occupancy in GTFS-rt TripUpdate feeds if occupancy is moved to VehiclePosition, since VehiclePositions aren’t included in TripUpdate feeds, while VehicleDescriptors are.
Also, a semi-related observation – I just noticed that in the hierarchy of objects in the GTFS-rt Element Index at the top of the page, VehicleDescriptor is missing from the VehiclePosition node:
https://developers.google.com/transit/gtfs-realtime/reference
VehicleStopStatus and CongestionLevel objects are also missing as children of the same VehiclePosition node.
--
You received this message because you are subscribed to a topic in the Google Groups "GTFS-realtime" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/gtfs-realtime/_HtNTGp5LxM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/gtfs-realtime/CAG9YwWAo49JL6TpiqJ_HpZB2EFRxN55vyOw1B2C%2BdSDE39CBDA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/471FDBB8FE1A8D4C9991FF0A0BBD2CD00331ED%40USFDAG1A.forest.usf.edu.
It's not an implementation detail. I suggested the change because most of the properties of VehicleDescriptor (and similarly TripDescriptor) are things that don't change for the course of the vehicle journey. Where-as fields in the parent entity do. I think that seems like a good convention to keep when deciding whether to add things to the descriptors vs the parent entity.
As for wanting occupancy status in a TripUpdate, that's a fair point, but really, you can make that same argument for every field in VehiclePosition.
If you want to cross-reference the two, I think that's an argument for providing both vehicle positions and trip updates as feeds (perhaps in the same stream even).
--
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/f77fd492-4cd3-4c04-b4c5-bffb3b3c32c1%40googlegroups.com.
3) Encourage agencies to provide combined vehicle-position + trip-update feeds, and make explicit that VehicleDescriptor should match between the two.
--
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CALp-iYQ5ho8%2BzJCs725qJOv-_-qQDhhEiRd1Q2RNV7YvuneBvg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CAG9YwWBmpeDwwsfmLOD_9xn%2BdjvJ86h9vAakhQRe62_Pf-VgaA%40mail.gmail.com.
1) Just put OccupancyStatus as a field in TripUpdate.
2) Heck, make VehiclePosition a field of TripUpdate ;)
3) Encourage agencies to provide combined vehicle-position + trip-update feeds, and make explicit that VehicleDescriptor should match between the two
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtime+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/d42c99ff-7d36-451d-a2c4-40f33881a74c%40googlegroups.com.
In terms of legacy feeds, I think that no matter what we decide here, it makes sense to stress in the spec that if both vehicle positions and trip updates are provided, then providers are strongly encouraged to supply VehicleDescriptor or TripDescriptor values that match between the two feeds.
So to summarize, my preferences:1) Put OccupancyStatus in VehiclePosition.2) Add stronger language about id references between VehiclePosition and TripUpdate.3) Allow merged VehiclePosition + TripUpdate feeds if an agency desires.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/7334c23f-bc56-49f4-81e6-efc8f724cc86%40googlegroups.com.
Hi everyone –
I’m writing as someone who works in marketing and is not a computer programmer.
I would have to ask riders for their opinion on what they think of having this kind of information available. For sure, I know some people personally who would think this is extremely cool. There are riders who will want to have this information because, quite frankly, we have a lot of bus bunching along our lines (it happens when there is a lot of congestion) and it is useful to know if, say, the first bus in a bunch is full so that they can board the next one that will be arriving monentarily. That said, we don’t consider a bus as ‘crush load’ (aka full) until the passenger load is 130% of the bus’s seated capacity. I understand this might be an industry standard. I guess I’m trying to think through what value would be meaningful to people. You suggested that the valid value would be 0, 1, but I have the feeling that some riders would find it very useful to see that, say, there’s standing room but it’s not standing room—you cannot get on the bus and the bus driver will be skipping your stop consequently.
If this isn’t feasible from a programming standpoint, please disregard my suggestion!
Best regards,
Sirinya Matute
Santa Monica Big Blue Bus
--
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/48108ac1-676b-442d-a954-b758553b3d43%40googlegroups.com.
--
Mike/Sirinya,
Good point on exceeding 100% capacity. I guess it comes down to what our definition of occupancy is – a) the number of passengers that the vehicle is rated for, or b) the number of passengers that the vehicle can physically carry (sitting and standing room). And, how the data is actually represented by the APC system.
In our case, we’ve been told by the AVL vendor that occupancy_percentage value provided by the AVL system will never exceed 100%. Our transit operations people say that a driver should technically refuse any more passengers when this hits 100% (although, it sounds like reality might be a bit different).
If others represent this differently, sounds like our choices are:
1. Allow occupancy_percentage > 1
2. Require that producers normalize their data, so 100% occupancy is when they cut off picking up more passengers
#1 is definitely the simplest, although it places the burden on the rider to guess whether or not the vehicle is accepting more passengers. But, given that it sounds like there a different interpretations of “full” and the cutoff point may be more of a driver judgment call, it seems like it’s the best approach.
So, a new definition of occupancy_percentage:
Sean
--
You received this message because you are subscribed to a topic in the Google Groups "GTFS-realtime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-realtime/_HtNTGp5LxM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CA%2BvEGE0AQbLm26sJ-TJ9WyXAQxod-bV5djg%3DOZmAz5yKjphAzA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/2ADFB73EE93D4541A085363403E99C0B0148DE4A%40USFMAIL2.forest.usf.edu.
What is meant by “is”? ;)
The way I phrased it below was intended to capture the number of passengers at which no additional passengers would be allowed to board the vehicle. So, “true” capacity vs. “rated” capacity. True capacity should not exceed 100%, while rated capacity can. It sounds like our AVL vendor uses more of a true capacity measure, if occupancy_percentage never exceeds 100%, while others are using rated capacity.
Sean
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/4B6686D4-BA7F-4082-8E13-0FC9D11B54CE%40nyct.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/2ADFB73EE93D4541A085363403E99C0B0148DEB5%40USFMAIL2.forest.usf.edu.
You imply that through the example but it's not actually stated in your proposal. In practice, if this is expected to be broadly used, different places will end up using it differently and the interpretation of 'can' will be implementation-specific and a function of vendor system specs, operational procedure, local policy, etc. I recommend saying as much up front.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/A4AF3D91-89F3-41A2-AB12-227A004F124E%40nyct.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/2ADFB73EE93D4541A085363403E99C0B0148DE4A%40USFMAIL2.forest.usf.edu.
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/2ADFB73EE93D4541A085363403E99C0B015689AF%40USFMAIL2.forest.usf.edu.
For example, Tiramisu Transit (http://www.tiramisutransit.com/) by Carnegie Mellon crowd-sources occupancy from riders using their mobile app (i.e., not from a traditional AVL/APC system). It looks like they present occupancy to users in the app as "Bus Load", with the values "Many Seats", "Few Seats", "No seats", and "Full". I don't think they are presenting this data via an API, though.