Comments (18)
Yup, there is! Nice! Thanks @ibi-group-team for making those proposals move forward and for drafting the proposals!
from transit.
@LeoFrachet Just as a side note, we've implemented this change into our Mecatran Urbiplan-alerts product, so all the feeds we produce with it will contain this field (well, as soon as this new release will be in production).
from transit.
I see the advantages of having a severity enum. I don't think the enum values should have a quantitative aspect as in the DELAYS_OF_UP_TO_TEN_MINUTES
and LEVEL_1_SEVERITY
examples. Severity levels would then be indicated by somewhat arbitrary individual words, so we'd need a table of exactly what the levels implied, e.g. a CRITICAL
alert should be distributed to all users by all means available and affects the whole transit network.
It does seem to me though that this is aiming to control the presentation layer. It might be better to include more enum-encoded factual information about the nature of the alert to enable consumers to decide who should see the alert and through what channels. The description says consumers making these choices on the fly will introduce latency and inconsistency. I would expect the added latency to be extremely small, so small as to be negligible, and arguably variation in how and when alerts are displayed is a desirable characteristic - this variety of approaches is one reason to supply open data to many different consumers instead of a single centralized trip planning system.
from transit.
We use a scale of 0-10 (as an integer). While we do have internal guidelines for what the values "mean" in terms of length of delays, that's subject to change and we have changed it in the past. And it's more of an ordering tool for alerts which aren't delays and don't have an obvious time associated with them. The system which sends alert notifications breaks the severity into 5 buckets (high, extreme, severe, moderate, minor) and uses that to decide which alerts to send to subscribers.
I don't think it's great idea to have the enumeration be time-specific, as it's not clear what that means for for non-delay alerts. I'm also not a fan of OTHER_SEVERITY
: how would we expect a client using this data to order that relative to the other severity levels?
from transit.
In my experience severity level is currently inferred by Effect. I think further clarifying severity and coming to an agreement on producer and consumer behavior related to that would be useful, but it's not clear to me the exact use case this proposal is trying to solve.
For example, if it's just ordering the alerts, then a simple integer value is probably the best solution. If it's distribution method, then an enum specifying the distribution method is probably the best solution. In it's current form it seems like this is too vague to effectively solve any of the use cases that it could potentially address.
Could we narrow down to a specific use case that this is currently being implemented for, and general agreed-upon behavior for producers and consumers for that case?
Also, “DELAYS_OF_UP_TO_TEN_MINUTES”, “DELAYS_OF_UP_TO_TWENTY_MINUTES”, “DELAYS_OF_UP_TO_THIRTY_MINUTES” seem like Effects, not severity, to me.
from transit.
Use case:
In Transit app, the severity of the alert changes the display in the app. There are two levels commonly used: info and warning.
Warning will display a warning sign in the "nearby" view, when info won't:
In the alert view, the same distinction is provided by either a warning sign (orange triangle) or an info sign (grey circle):
Please note here that the "Warning" level has been put on an alert which is "just" a closed entrance. If MBTA was able to set the severity, they likely wouldn't have put a warning level on this one.
from transit.
- The pedestrian walkway alert has severity 1
- The elevator alert has severity 3
from transit.
@paulswartz I'm assuming that the higher the digit, the higher the severity? Aka the elevator alert has a higher severity than the pedestrian walkway alert?
If that's the case, we just found the perfect argument for an official severity field!
FWIW, I'm personally in favor of the first option, aka “UNKNOWN_SEVERITY”, “OTHER_SEVERITY”, “INFORMATIONAL”, “ADVISORY”, “WARNING”, “CRITICAL”. But with less options. I would just keep:
- UNKNOWN_SEVERITY (as default and to be backward compatible)
- INFORMATIONAL or ADVISORY (just one of them, I personaly don't see the difference)
- WARNING
- CRITICAL
This maps the usual INFO / WARNING / ERROR tryptic most of us are used to.
As guidelines (I say guidelines, not rules) I would say:
- INFO: It should just be displayed to the user in a section along the informed entity, but shouldn't have to be put in a prominent way.
- WARNING: The fact that there is a warning should be displayed along the informed entity in every single of its occurrences (e.g. trip planner result, list of lines...). Notifications should be offered to the users of the informed entity.
- CRITICAL: To use only in case of emergency (e.g. life threatening event like a bomb alert in a subway station, system wide shutdown for snowstorm or hurricane). Should be displayed prominently across the app / site / consumer service. Notification should be offered to any user of the system.
from transit.
@LeoFrachet's enums roughly align with how alerts are displayed in OneBusAway. OBA uses SIRI's SituationExchange model internally, but this gets mapped to three values for the UI:
- INFO
- WARNING
- SEVERE
INFO are colored coded with app theme colors (green) and require user action to reveal them (they aren't immediately visible in the main arrivals view).
WARNINGS and SEVERE get flagged in the users main view, with WARNINGs coded yellow and SEVERE red.
EDIT - As mentioned below in code SEVERE
is actually referred to as ERROR
.
Example:
More OBA screenshots and implementation details are here - OneBusAway/onebusaway-android#714
from transit.
Reading through these comments, it seems that there is agreement that a severity enum field is useful.
The specific use case for IBI is that the agency we are working with relies on a severity field to determine whether an alert should be displayed prominently on top of its trip planner.
The general consensus on enum values is:
UNKNOWN_SEVERITY
INFORMATIONAL
WARNING
CRITICAL
Any other thoughts on these values?
from transit.
If people find it useful to explicitly declare the severity instead of inferring it from Cause/Effect, then I agree with @LeoFrachet's response. Paralleling the INFO / WARNING / ERROR log levels common in software, and reusing what is apparently already used by One Bus Away and standard in SIRI SX, a good option seems to be INFO / WARNING / SEVERE, plus UNKNOWN for backward compatibility. Subjectively, I would lean toward SEVERE rather than CRITICAL, and not add the suffix "_SEVERITY" on only one of the enum values.
However looking at your link @barbeau I don't see any mention of severity. Digging further into SIRI specs, SIRI seems to follow the TPEG Pti26 severity enumeration (https://laidig.github.io/siri-20-java/doc/schemas/siri_situationClassifiers-v1_1_xsd/simpleTypes/SeverityEnumeration.html)
These levels are: unknown / verySlight / slight / normal / severe / verySevere / noImpact / undefined
This is probably too many levels, and doesn't include "warning" or "info". @barbeau can you clarify the connection between SIRI and the OBA enum you mentioned?
Even if it doesn't exactly match SIRI, I think @barbeau's values are a good choice, plus the UNKNOWN for backward compatibility.
from transit.
@abyrd Yes, unfortunately the OBA docs don't currently do a good job of explaining this (hence my open issue of creating better docs :) ).
Here are the possible values that can be set in the OBA server (using a web admin console to create an alert) and returned by the OBA server API:
String SEVERITY_UNKNOWN = "unknown";
String SEVERITY_NO_IMPACT = "noImpact";
String SEVERITY_VERY_SLIGHT = "verySlight";
String SEVERITY_SLIGHT = "slight";
String SEVERITY_NORMAL = "normal";
String SEVERITY_SEVERE = "severe";
String SEVERITY_VERY_SEVERE = "verySevere";
Looks like these match the values you dug up for the TPEG Pti26 severity enumeration.
In OBA Android we then collapse these down to the three buckets I mentioned for the three ways we display alerts in the UI:
if (ObaSituation.SEVERITY_NO_IMPACT.equals(mSituation.getSeverity())) {
return TYPE_INFO;
} else if (ObaSituation.SEVERITY_SEVERE.equals(mSituation.getSeverity())
|| ObaSituation.SEVERITY_VERY_SEVERE.equals(
mSituation.getSeverity())) {
return TYPE_ERROR;
} else {
// Treat all other ObaSituation.SEVERITY_* types as a warning
return TYPE_WARNING;
}
As shown above we actually use ERROR
instead of SEVERE
as the constant in the OBA Android code, but SEVERE
seems like a better enum value to me.
from transit.
Thanks for the clarification @barbeau. So OBA is mapping the 7 TPEG values onto 3 buckets and any other software that handles SIRI could easily perform the same mapping. So I'd agree with @ibi-group-team's comment above on the general form of the severity enum. I do think we should avoid namespacing prefixes or suffixes (SEVERITY_
or _SEVERITY
) especially if they only appear on some enum values. I see this convention as a holdover from defining integer enum constants in a big C header. Most languages and data formats we're using these days will have enum types as a language feature, which provides natural scoping and context for the value names.
Combining with the approach @barbeau describes in OBA, I would therefore suggest:
UNKNOWN
INFO
WARNING
SEVERE
@ibi-group-team does this work for you? Any other comments? It seems like this one could rapidly move to a pull request.
from transit.
We are ok with using the enum value SEVERE instead of CRITICAL. However, for alerts with unknown severity we recommend including the suffix ‘SEVERITY’ (i.e. UNKNOWN_SEVERITY) to maintain consistency with the Cause and Effect enum values (i.e. UNKNOWN_CAUSE and UNKNOWN_EFFECT).
We will open a pull request with a full proposal and call for a vote soon.
from transit.
That makes sense to me: UKNOWN_SEVERITY
just for consistency with the rest of the spec. I think there's agreement on this proposal.
from transit.
Just as a side note, in our Urbiplan alerts product we already have this severity level. We use 3 levels: INFO, WARN, CRITICAL. +1 for the change.
from transit.
I will also be happy to see SeverityLevel incorporated in the standard and (hopefully) used by providers. When there are alert(s) relevant to a stop, I display an exclamation mark at the top of the listings as shown in the first image. The color of the surrounding box is purely based on how recent the newest alert is with it being red for anything very new, yellow for anything older than a week and a gradient from red->yellow for times in between. The thinking is that for somebody looking up the same stop on a regular basis, the color change when a new alert is available will attract their attention.
The problem with this of course is that you are showing red for minor delays as seen in the second image. When severity is available, I will probably display color based on this and fall back to the existing mechanism when it is not (probably use different colors though).
Ex1
Ex2
from transit.
Proposal has been adopted. So I'm closing the issue.
from transit.
Related Issues (20)
- Add rider_category_id to fare_products.txt
- Add maximum waiting time to transfers.txt HOT 2
- Documentation: inconsistencies between gtfs-realtime.proto
- GTFS-Fares v2: Improvement of filling with stops of a certain area HOT 2
- Move Dataset Publishing and General Practices from Best Practices to the spec HOT 10
- Add recommended presence: reconciling confusion between best practices and spec HOT 10
- Thoughts on forbidding "subfolder inside zip"? HOT 8
- TripDescriptor.start_date matching between GTFS-RT + GTFS-static HOT 2
- GTFS-Flex: Service Discovery HOT 11
- Add rule_priority field to fare_leg_rules.txt HOT 6
- Add fare_media_type=1 to fare_media.txt HOT 8
- GTFS-Fares v2: Add networks.txt & route_networks.txt HOT 13
- GeoJSON in GTFS? (Or the future of GTFS serialisation) HOT 20
- Phone number international format in GTFS HOT 2
- stop_times.shapes_dist_traveled shouldn't be defined if the trip doesn't have shapes associated HOT 7
- GTFS changes - voting agents HOT 12
- Moving Schedule Best Practices into the Spec: Phasing Plan HOT 5
- [GTFS-Flex] Remove referencing location.geojson ids in stop_areas.txt (formerly location_groups.txt)?
- [GTFS-Flex] Replace areas.txt/stop_areas.txt with locations.geojson MultiPoint feature to describe collections of stops? HOT 11
- GTFS-fares v2: Fare Leg Rule "Scope" Support
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from transit.