Add support for OccupancyStatus

[barbeau]

OccupancyStatus is now an "experimental/proposed" GTFS-realtime field, as discussed on the gtfs-realtime list.

I’ve managed to get OccupancyStatus (i.e., how “full” the vehicle is) added to the GTFS-rt spec (at least as an “experimental field”), and also added to the onebusaway-gtfs-realtime-api and onebusaway-gtfs-realtime-exporter projects (if you run “mvn install –U” on this project, you should be able to pull down the newest version of the libraries).

Here’s an explanation of the enumeration values: https://groups.google.com/forum/#!msg/gtfs-realtime/_HtNTGp5LxM/0mvvEW1WuMMJ

...and the same text inline, for convenience:

 enum OccupancyStatus {
    // The vehicle is considered empty by most measures, and has few or no
    // passengers onboard, but is still accepting passengers.
    EMPTY = 0;

    // The vehicle has a relatively large percentage of seats available.
    // What percentage of free seats out of the total seats available is to be
    // considered large enough to fall into this category is determined at the
    // discretion of the producer.
    MANY_SEATS_AVAILABLE = 1;

    // The vehicle has a relatively small percentage of seats available.
    // What percentage of free seats out of the total seats available is to be
    // considered small enough to fall into this category is determined at the
    // discretion of the feed producer.
    FEW_SEATS_AVAILABLE = 2;

    // The vehicle can currently accommodate only standing passengers.
    STANDING_ROOM_ONLY = 3;

    // The vehicle can currently accommodate only standing passengers
    // and has limited space for them.
    CRUSHED_STANDING_ROOM_ONLY = 4;

    // The vehicle is considered full by most measures, but may still be
    // allowing passengers to board.
    FULL = 5;

    // The vehicle is not accepting additional passengers.
    NOT_ACCEPTING_PASSENGERS = 6;
  }

@Mona77 Could you please add OccupancyStatus to the Bull Runner GTFS-rt TripUpdates and VehiclePositions feeds?

You’ll need to come up with a mapping from the % full values in the Syncromatics API to the above enumeration values. Note that we don't have enough info in the Syncromatics API for all of the above values - I think the only values we'll be able to support (based on a raw percentage we get from the Syncromatics API) are EMPTY, MANY_SEATS_AVAILABLE, FEW_SEATS_AVAILABLE, and FULL. Please be sure to document this in the comments in the code.

@jmfield2 @TNWolf After @Mona77 has added this, please add it to the MoBullity UI.

Thanks!

[Mona77]

I tried to add vehicle occupancy after I run "“mvn install –U”, but I can't access the setter of "occupancystatus". The only place that I have found this filed is: https://github.com/OneBusAway/onebusaway-gtfs-realtime-api/blob/master/src/main/resources/com/google/transit/realtime/gtfs-realtime.proto#L213

Do I need to add "gtfs-realtime.proto" package?

BTW I am using this package in my code: import com.google.transit.realtime.GtfsRealtime.VehicleDescriptor;

On Tue, Nov 18, 2014 at 7:12 AM, Sean Barbeau notifications@github.com wrote:

OccupancyStatus is now an "experimental/proposed" GTFS-realtime field, as discussed on the gtfs-realtime list https://groups.google.com/d/msg/gtfs-realtime/_HtNTGp5LxM/0mvvEW1WuMMJ.

I’ve managed to get OccupancyStatus (i.e., how “full” the vehicle is) added to the GTFS-rt spec (at least as an “experimental field”), and also added to the onebusaway-gtfs-realtime-api https://github.com/OneBusAway/onebusaway-gtfs-realtime-api/issues/4 and onebusaway-gtfs-realtime-exporter https://github.com/OneBusAway/onebusaway-gtfs-realtime-exporter/issues/5 projects (if you run “mvn install –U” on this project, you should be able to pull down the newest version of the libraries).

Here’s an explanation of the enumeration values:

https://groups.google.com/forum/#!msg/gtfs-realtime/_HtNTGp5LxM/0mvvEW1WuMMJ

...and the same text inline, for convenience:

enum OccupancyStatus { // The vehicle is considered empty by most measures, and has few or no // passengers onboard, but is still accepting passengers. EMPTY = 0;

// The vehicle has a relatively large percentage of seats available.
// What percentage of free seats out of the total seats available is to be
// considered large enough to fall into this category is determined at the
// discretion of the producer.
MANY_SEATS_AVAILABLE = 1;

// The vehicle has a relatively small percentage of seats available.
// What percentage of free seats out of the total seats available is to be
// considered small enough to fall into this category is determined at the
// discretion of the feed producer.
FEW_SEATS_AVAILABLE = 2;

// The vehicle can currently accommodate only standing passengers.
STANDING_ROOM_ONLY = 3;

// The vehicle can currently accommodate only standing passengers
// and has limited space for them.
CRUSHED_STANDING_ROOM_ONLY = 4;

// The vehicle is considered full by most measures, but may still be
// allowing passengers to board.
FULL = 5;

// The vehicle is not accepting additional passengers.
NOT_ACCEPTING_PASSENGERS = 6;

}

@Mona77 https://github.com/Mona77 Could you please add OccupancyStatus to the Bull Runner GTFS-rt TripUpdates and VehiclePositions feeds?

You’ll need to come up with a mapping from the % full in the Syncromatics API to the above enumeration values. Note that we don't have enough info in the Syncromatics API for all of the above values - I think the only values we'll be able to support (based on a raw percentage we get from the Syncromatics API) are EMPTY, MANY_SEATS_AVAILABLE, FEW_SEATS_AVAILABLE, and FULL. Please be sure to document this in the comments in the code.

@jmfield2 https://github.com/jmfield2 @TNWolf https://github.com/TNWolf After @Mona77 https://github.com/Mona77 has added this, please add it to the MoBullity UI.

Thanks!

— Reply to this email directly or view it on GitHub https://github.com/CUTR-at-USF/bullrunner-gtfs-realtime-generator/issues/4 .

Regards, Mona

[barbeau]

@Mona77 In the pom.xml for this project, please change the onebusaway-gtfs-realtime-exporter library version to 1.2.0-SNAPSHOT (line 33). Then do mvn clean install -U, and hopefully that should pull down the new onebusaway-gtfs-realtime-exporter JAR and make the method visible.

[Mona77]

@barbeau I modified the version but I got this error in my code: The import org.onebusway cannot be resolved

[barbeau]

Hmmm, ok, something must not be working right with the dependencies (not your fault, something wrong with OBA Maven repository).

Looks like you'll need to deploy the updated library manually. You can do this by cloning this project in a new directory: https://github.com/OneBusAway/onebusaway-gtfs-realtime-exporter

Then, at the command line of this project run mvn clean install.

This should install version 1.2.0-SNAPSHOT to your local Maven repository. After this, the "import x cannot be resolved" should disappear and you should be able to build the bullrunner project.

[Mona77]

@barbeau I figured out that the import error was because of spelling error. In the 1.1.0 version the name of the package is "org.onebusway", which has been changed to "org.onebusaway" in the new version.

But Still some classes(mutable and realtimeProvider) are missing in the new version and I got the following error: The import org.onebusaway.gtfs_realtime.exporter.GtfsRealtimeMutableProvider cannot be resolved Here are screenshot of the new and old version of onebusaway package:

1.2.0-sanpshot version

1.1.0 version:

[barbeau]

Hmmm, looks like the class structure changed a bit for 1.2. I don't know of the changed off the top of my head - you might want to see if you can find an updated example of using the exporter library and go from there. Or, look at the commit history for the exporter project and see where the code was moved to. On Jan 6, 2015 9:43 PM, "Mona Fathollahi" notifications@github.com wrote:

@barbeau https://github.com/barbeau I figured out that the import error was because of spelling error. In the 1.1.0 version the name of the package is "org.onebusway", which has been changed to "org.onebusaway" in the new version.

But Still some classes(mutable and realtimeProvider) are missing in the new version and I got the following error: The import org.onebusaway.gtfs_realtime.exporter.GtfsRealtimeMutableProvider cannot be resolved Here are screenshot of the new and old version of onebusaway package: [image: screen shot 2015-01-06 at 6 22 10 pm] https://cloud.githubusercontent.com/assets/5246494/5639864/75a19168-95d2-11e4-84ef-8093814117df.png [image: screen shot 2015-01-06 at 6 20 39 pm] https://cloud.githubusercontent.com/assets/5246494/5639867/7e3874ea-95d2-11e4-90be-c32a9aa551f7.png

— Reply to this email directly or view it on GitHub https://github.com/CUTR-at-USF/bullrunner-gtfs-realtime-generator/issues/4#issuecomment-68971533 .

[barbeau]

From @Mona77:

I have found the commit that causes these changes: https://github.com/OneBusAway/onebusaway-gtfs-realtime-exporter/commit/06912e161d982379f93dce2f7d6cfbe8227024cd

Some classes that are used in my project have been removed and some have changed

[barbeau]

cc @jmfield2

[barbeau]

@jmfield2 We'll want to hold off on implementing OccupancyStatus in the Bull Runner feed until we get further confirmation that the location of the field is correct. Right now it looks like it will be moving to VehiclePosition class - see https://github.com/OneBusAway/onebusaway-gtfs-realtime-api/issues/4#issuecomment-69971468 thread for details. When that issue is closed, then we should be ready to implement OccupancyStatus here.

[barbeau]

@jmfield2 Ok, we should now have a permanent home for OccupancyStatus, via the onebusaway-gtfs-realtime-api-1.2.0 library. Note that some of the packages for the classes may have changed, since there was some restructuring of the project to depend on the new official gtfs-realtime-bindings library. So, you could go ahead and update this project to the newest version of the library, and export the OccupancyStatus field, and consume/display this in the mobullity webapp.

[barbeau]

@jmfield2 Could you prioritize getting this field into the GTFS-rt feed? Thinking more about the arrival estimate error issue we've seen, it probably makes sense to do this update first, and then troubleshoot problems, because this update will include some fundamental changes to the code as a result of the new onebusaway-gtfs-realtime-api library version, from my understanding.

[jmfield2]

entity { id: "3" vehicle { trip { route_id: "E" } position { latitude: 28.057371 longitude: -82.41311 bearing: 0.0 } vehicle { id: "2142" } occupancy_status: CRUSHED_STANDING_ROOM_ONLY } }

Looks like I was able to get this working! I'll commit and test it on production tonight.

On Tue, Feb 24, 2015 at 12:48 PM, Sean Barbeau notifications@github.com wrote:

@jmfield2 https://github.com/jmfield2 Could you prioritize getting this field into the GTFS-rt feed? Thinking more about the arrival estimate error issue we've seen, it probably makes sense to do this update first, and then troubleshoot problems, because this update will include some fundamental changes to the code as a result of the new onebusaway-gtfs-realtime-api library version, from my understanding.

— Reply to this email directly or view it on GitHub https://github.com/CUTR-at-USF/bullrunner-gtfs-realtime-generator/issues/4#issuecomment-75807687 .

[barbeau]

@jmfield2 Awesome! :+1: Can you also share the cutoffs you're using to translate from APC percentage from Syncromatics to the enumerations in GTFS-rt spec?

[jmfield2]

I actually don't have the cutoffs yet - what I posted was more of a proof of concept. I'll work on those later or if you have suggestions for what those should be it might help.

[barbeau]

I don't have any in mind - except that we will only likely be able to use some of the enumerations, not all of them. For example, we don't actually know when the bus stops accepting riders, so we shouldn't use that enumeration.

[jmfield2]

Should be finished - see pull #7

I used the following cutoffs:

<= 0 EMPTY <= 50 MANY_SEATS more than 50 && < 95 FEW_SEATS more or = 95 FULL

[barbeau]

I just checked my notes, and apparently the USF Bull Runner defines capacity as "Sitting and standing room", with valid values 0-100 (see this Google doc). We should probably do some real-world checks to see how the seat count matches up to the reported numbers. I wouldn't want to say that 90% capacity is few seats if its actually more like CRUSHED_STANDING_ROOM_ONLY.

[barbeau]

And awesome that you got this working! :)

[barbeau]

Looks like this was fixed in 2ec95dbfeccb179758371fa6983dec66515d8676 and df3d3de06b70dcc01519901a94b4d9878dd823bf (https://github.com/CUTR-at-USF/bullrunner-gtfs-realtime-generator/pull/7), so I'm closing this ticket. @jmfield2 If I'm wrong, please re-open. And thanks for implementing this!