Abstract:
A system for managing incidents for a transit agency is disclosed, comprising an incident manager, configured to enable establishment and storage of one or more user profiles for one or more users, each profile indicating characteristics of transit incidents the user wishes to be notified of, create a transit incident having one or more incident characteristics, determine which users are to be notified of the transit incident based on their user profiles, and provide one or more notifications to the users that are to be notified.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims the benefit of U.S. Provisional Application No. 61/623,991 filed Apr. 13, 2012, the contents of which are herein expressly incorporated by reference. 
     
    
     COPYRIGHT NOTICE 
       [0002]    A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. 
       BACKGROUND 
       [0003]    Although many tools exist for building websites, tools for quickly building and maintaining transit websites—and the data and functionality required to make such websites useful for agencies&#39; riders—do not exist. Accordingly the following invention is directed at addressing some of those current limitations. 
       SUMMARY OF THE INVENTION 
       [0004]    In one aspect there is a system for managing incidents for a transit agency comprising an incident manager, configured to enable establishment and storage of one or more user profiles for one or more users, each user profile indicating characteristics of transit incidents the user wishes to be notified of, create a transit incident having one or more incident characteristics, determine which users are to be notified of the transit incident based on their user profiles, and provide one or more notifications to the users that are to be notified. 
         [0005]    The incident manager may be further configured to receive information to create a transit incident having one or more incident characteristics, and such information may be provided by an administrator via one or more user interface elements. The incident manager may be further configured to allow characterizing of the transit incident, by the administrator, according to pre-defined tags. 
         [0006]    The notification may be auto-generated from the pre-defined tags. 
         [0007]    The system may further comprise one or more transit data servers configured to provide transit functionality, via one or more functionality modules, for the transit agency, and communicate information to create a transit incident with the incident manager. 
         [0008]    The one or more transit data servers may be users and have user profiles. Each of the one or more users may have a user type and mediums preference and the notifications may be different for each user type and sent according to the users&#39; mediums preferences. 
         [0009]    In another aspect there is a method for managing incidents for a transit agency, the transit agency having an incident manager and one or more transit data servers providing transit functionality to the transit agency, the method comprising enabling establishment and storage of one or more user profiles for one or more users, each user profile indicating characteristics of transit incidents the user wishes to be notified of, creating a transit incident having one or more incident characteristics, determining which users are to be notified of the transit incident based on their user profiles, and providing one or more notifications to the users that are to be notified. 
         [0010]    The method may further comprise receiving information to create a transit incident having one or more incident characteristics. 
         [0011]    The receiving may be from an administrator via one or more user interface elements. 
         [0012]    The method may further comprise characterizing, by the administrator, the transit incident according to pre-defined tags. The notifications may be auto-generated from the pre-defined tags. 
         [0013]    The receiving may be from a transit data server. 
         [0014]    The one or more transit data servers may be users and have user profiles. 
         [0015]    Each of the one or more users may have a user type and mediums preference and the notifications may be different for each user type and sent according to the users&#39; mediums preferences. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    The invention is illustrated in the figures of the accompanying drawings which are meant to be exemplary and not limiting, in which like references are intended to refer to like or corresponding parts, and in which: 
           [0017]      FIG. 1  is a diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention; 
           [0018]      FIG. 2  is a further diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention; 
           [0019]      FIG. 3  is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention; 
           [0020]      FIG. 4  is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention; 
           [0021]      FIG. 5  is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention; 
           [0022]      FIG. 6  is a diagram of a system for configurable and automated transit agency content creation and dissemination according to a non-limiting embodiment of the present invention; 
           [0023]      FIG. 7  is a diagram of a method of creating incidents according to a non-limiting embodiment of the present invention; 
           [0024]      FIGS. 8-12  are screenshots for incident creation, review and dissemination according to a non-limiting embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0025]      FIG. 1  is a diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention. 
         [0026]    Transit agency  26  may have one or more data sources  10  that are controlled by the agency and one or more external data sources  12  (such as weather data, general traffic data, GIS data, and the like, that may not be controlled by agency  10 ). Transit agency  26  further may have one or more vehicles  16  and mobile devices  18  (that may be tablets, phones, etc and may be used by drivers or located on vehicles, etc). Transit agency  26  may also have one or more computing devices  14  that may be used by schedulers, content handlers, supervisors, maintenance staff, and other employees and contractors of the agency. 
         [0027]    Transit agency  26  may further have transit agency data sinks or content sinks, that may include user devices  30   a / 30   b  and may also include computing devices  14 , vehicles  16  and mobile devices  18 . Such transit data sinks may receive content from agency  26 , such as via websites, social media, SMS messages and the like as described herein. 
         [0028]    Transit agency  26  may further have one or more transit data databases  22  (TDD) and transit data servers  24  (TDS) that may interact with TDD  22  to read and write data to perform functionality required by agency  26 , and to be provided to transit data sinks Transit data sources and sinks may interact with TDD  22  directly or through one or more TDS  24 . Exemplary TDDs  22  may include route databases, asset databases, schedule adherence databases, maintenance databases, user profiles databases, alert category databases, and trips databases. Of course each of these may have many datasets and each may be combined with one another as needed or desired, for performance issues for example. 
         [0029]      FIG. 2  is a further diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention. 
         [0030]    TDS  24  may have one or more functionality modules  100 . Each module may provide different functionality that one or more transit data sinks may need, such as trip planning, service advisories, elevator status (for wheelchair access to transit locations), system maps, client registration and alert configuration, alerts and notification generator and publisher (for example for agency employees such as schedulers or content managers), demand response functionality (such as booking trips, paying for trips, and the like). 
         [0031]    Each module may have an identifier  102  one or more UI components  104 , processing/TDD integration components  106  (PTDDIC), and customization parameters  108 . Identifier may simply identify module  100 . 
         [0032]    UI components may be the way transit data sinks will see the functionality (size, look, feel, what data is displayed, and through what techniques such as screen shots for web pages, text for SMS messages, the social media view, etc). UI components may be different for each transit data sink that may use such functionality (such as based on screen size, audience, etc, and based on specified parameters). 
         [0033]    PTDDIC  106  may allow TDS  24  to interact with TDD  22  to access the data (such as transit datasets) required for the functionality and may further provide the data processing and business logic to carry out the functionality of module  100  (such as accepting inputs from users or the agency to describe the functionality or data requested, building queries to TDD  22 , getting the data out of TDD  22 , and processing and returning the results to be displayed). For example, module  100  may be a service advisory alert. Data source  10  may provide data to TDD  22  to indicate that bus stop  492 A is not operable due to construction and has been moved to a temporary stop  492 T. Service advisory module  100  may then query TDD  22  to see what stops, if any, are currently affected. Receiving back “ 492 A has been moved to  492 T”, service advisory module  100  may determine which routes may be affected (possibly via interacting again with TDD  22 ), determine what transit data sinks may be affected, which forms of publishing may be required (such as websites, social media, SMS, etc—where such may be based, for example, on how major the service disruption is, as may be determined by module  100 ), and which specific users have requested to receive service advisories. Various UI components  104  may then be invoked to publish the service advisory as required. 
         [0034]    It is to be understood that modules  100  may be provided pre-programmed to operate when the proper transit database and/or dataset is available to the module requiring it. As such, functionality and modules may be considered plug and play—not requiring major technology development to implement new features for transit data sinks. 
         [0035]    Customization parameters may allow a user to specify exactly what data can be served to riders or other transit data sinks, and how that should look and operate. 
         [0036]    It should be noted that various modules  100  may be present at agency  26  and may be usable if the proper data is obtained from data sources  10  (and/or stored in TDD  22 ), as described herein. Further, performance or accuracy of modules  100  may be increased as more data is obtained. For example, if no real-time data is ingested by TDD  22 , then a module  100  providing real-time schedule information cannot be used. As such, screenshot  300 , and operator module  100 , may begin by querying TDD  22  to determine what modules  100  may be offered based on data sources  10  that are available (or possibly were available). 
         [0037]    Operator tool module  100  may allow an operator at agency  26  to handle transit data and functionality, such as selectively publishing content, making functionality available to transit data sinks, and the like. Portions of operator tool module  100  may be substantially as shown in  FIGS. 3-5 . 
         [0038]      FIG. 3  is a screenshot  300  for a configurable transit agency content management system according to a non-limiting embodiment of the present invention, which may be described as a webpage design module, or a part thereof. 
         [0039]    In  FIG. 3 , a user of module  100  may be able to select which modules  100  to expose on a web site (external or intranet) of agency  26 , via module selector  302 . Preview portion  304  may provide a preview of the particular page of the website, as determined by the modules selected in module selector  302 , parameters specified (as described herein), by dragging and dropping UI components of the various modules (not shown, but substantially as dragging and dropping is known in the art). 
         [0040]    Module selector  302  may include all modules  100  that may be available in general, or may include all modules  100  that may be available to agency  26  based on, for example, the data sources that provide data or datasets to one or more TDD  22 . When more data sources  10 / 12  are plugged into TDD  22  (such as via a “plug and play” type of arrangement), or more TDD  22  become accessible, more functionality modules  100  may become available—resulting in more icons in module selector  302 , or more icons being selectable. Such determinations of which functionality can be offered may be made in real-time upon accessing screenshot  300  (such as by querying TDD  22  on the back end before showing screenshot  300 ). 
         [0041]      FIG. 4  is a screenshot  400  for a configurable transit agency content management system according to a non-limiting embodiment of the present invention. 
         [0042]    In  FIG. 4 , further configuration of a particular module may be possible. Module ID  102  may be shown in module name field  402 , with configurations for such module shown and selected in configurations screen  404 . A user of this screenshot (which may be a transit operator, for example) can select which user inputs to allow (route selection textbox being selected in  FIG. 4 ), which outputs will be provided on the UI component (daily performance stats not being shown), parameters to specify (such as whether to include fixed routes and/or demand response routes when searching for real-time schedule information), and aspects of font and other parameters. Of course the parameters and configurations shown are exemplary only. Different parameters may be possible for the module  100  shown, and for other modules, as required, and between different transit data sinks. Such parameters may affect the specific data from TDD  22  that may be required or accessible by transit data sinks (such as riders). Some parameters may not be available too, if the required data is not present in TDD  22 . 
         [0043]    Screenshot  400  may be used to alter the currently displayed UI component for a given functionality module  100 , which may result in changes to the web page in screenshot  300  (if such module  100  was part of the web page). It is thus to be understood that users can alter parameters (inputs, outputs, fonts, etc) and view all effects such may have. 
         [0044]      FIG. 5  is a screenshot  500  for a configurable transit agency content management system according to a non-limiting embodiment of the present invention. Screenshot  500  may then allow a user to add content (where ‘content’ may be considered transit content), or publish content, to one or more sources for consumption by transit data sinks, and may assist in generating the desired content based on data from data sources  10 / 12  (as described herein). Screenshots may also be considered ‘dashboards’, providing main landing places providing an overview of particular features or functionality. 
         [0045]    A user of screenshot  500  may be an operator or content administrator for agency  26 . The functionality depicted and described may form part of operator module  100 . 
         [0046]    The user may specify what type of transit content they wish to publish in content specifier  502  and may then be allowed to define some parameters about that content type in  504  (such as alert priority, picture size, web page expiry date/time, and the like). Screenshot  500  may then provide UI features to allow the user to develop or create the content. In the present example, an alert is selected in  502 , causing alert categorization  510  and alert preview  508  to display on screenshot  500 . The user may then specify elements that define the alert; such defining may allow alert preview  508  to display auto-generated content, draft content, that alert module  100  (and in particular PTDDIC  106 ) provides to operator module  100  for display in a content preview portion of screenshot  500 . A user may amend the draft content and/or approve or accept it for publishing. 
         [0047]    Using content mediums  512  and sink target  514  a user may select which media to publish the content to and which transit sinks should receive the content, respectively. Such selections may dictate statistics about who will, or may, receive or view the created transit content. 
         [0048]      FIG. 6  is a diagram of a system for configurable and automated transit agency content creation and dissemination according to a non-limiting embodiment of the present invention. 
         [0049]    Incident manager  24   a  may be responsible for the creation, ingestion, and dissemination of incidents. Incident manager  24   a  may be configured to allow the creation of incidents by one or more operators of transit system  20 , which may be accessed via, or be part of, computing devices  14 , as described herein. Incident manager  24  may be configured to ingest incidents from one or more of asset manager functionality  24 , trip planning functionality  24 , traveler information  24 , operations functionality  24  or other transit data servers  24  that may be part of transit system  20 . 
         [0050]    Incidents, or transit incidents, may include any occurrence having relevance for transit agency  26 , such as weather occurrences, car accidents, power outages, buses finishing their runs, drivers changing shifts, supervisors approving new routes or short-turns, and the like. Occurrences or events may only become incidents if they meet one or more thresholds for importance, as described herein. 
         [0051]    Incident manager  24   a  and other transit data servers  24  may cause new incidents to be created, by allowing a user to intentionally create an incident (which may be a user initiated trigger) or by transit data servers  24  creating an incident in response to triggers occurring in the transit data servers  24 . Below is a list of exemplary triggers that may lead to an incident being created by various transit data servers  24 : 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Exemplary Triggers 
               
             
          
           
               
                 Functionality/ 
                   
                   
               
               
                 Transit 
               
               
                 Data Server 
                 Trigger 
                 Description 
               
               
                   
               
               
                 Asset Manager 
                 Maintenance person 
                 An incident may be created to 
               
               
                 Functionality 
                 indicates bus #139 is 
                 indicate that bus #139 cannot be 
               
               
                   
                 out of service. 
                 driven and/or should be 
               
               
                   
                   
                 replaced on its route (such route 
               
               
                   
                   
                 either being in progress of 
               
               
                   
                   
                 scheduled for later). 
               
               
                 Incident 
                 Rider sends email 
                 An administrator may 
               
               
                 Manager 
                 complaint or “tweets” 
                 determine the email or 
               
               
                   
                 about transit agency 
                 communication to be an 
               
               
                   
                 26. 
                 incident and enter it via incident 
               
               
                   
                   
                 manager 24a. 
               
               
                 Traveler 
                 A rider calls the call 
                 A call center agent, which may 
               
               
                 Information/ 
                 center, or submits via 
                 be a different or the same 
               
               
                 Call Center 
                 their mobile device, to 
                 administrator, enters the 
               
               
                   
                 report poor conditions 
                 information in call center 
               
               
                   
                 on board a bus. 
                 software (transit data server 24), 
               
               
                   
                   
                 which may end up in incident 
               
               
                   
                   
                 manager 24a. The mobile 
               
               
                   
                   
                 device may communicate with 
               
               
                   
                   
                 transit data server 24, which 
               
               
                   
                   
                 may result in an incident in 
               
               
                   
                   
                 incident manager 24a. 
               
               
                 Operations 
                 A transit supervisor 
                 The supervisor may enter the 
               
               
                 Functionality 
                 has witnessed a traffic 
                 information via a Road 
               
               
                   
                 accident. 
                 Supervisor transit data server, 
               
               
                   
                   
                 which may result in an incident 
               
               
                   
                   
                 in incident manager 24a. 
               
               
                   
               
             
          
         
       
     
         [0052]    Incident manager  24   a  may, in creating, ingesting, amending and resolving incidents, create incident data structures (not shown) to store data relating to an incident. Incident data structures may include but are not limited to the type of incident (e.g., service disruption, route diversion, planned construction), a description (e.g., bus  123  diverting around King St. due to a watermain break), the priority (e.g., low, medium, high), the status (e.g., pending confirmation, awaiting resolution, resolved), the affected part of the schedule (e.g., bus stops, lines, pattern, blocks), the effective date and time (e.g., Weekday mornings from 6:00 am to 11:00 am, or until resolved), the creator of the incident, the date and time the incident was created, and in what transit data server the incident was created. 
         [0053]    Transit data servers  24  provide the functionality required of transit system  20 , each may provide one or more aspects of such functionality. Transit data servers  24  may communicate with incident manager  24   a,  as described herein, for example to communicate incidents. 
         [0054]      FIG. 7  is a diagram of method  700  of creating incidents according to a non-limiting embodiment of the present invention. 
         [0055]    Method  700  begins at  702  where an event or incident occurs in the real-world of transit agency  26 . At  702  the event could be anything that has any relevance for transit agency  26 , such as weather occurrences, car accidents, power outages, buses finishing their runs, drivers changing shifts, supervisors approving new routes or short-turns, and the like. 
         [0056]    Method  700  then continues to  704  where a query is made whether another transit data server is capturing the event. This may essentially mean that the event will implicate one or more transit data servers  24 , and likely that such one or more transit data servers  24  will determine whether the event is an incident (further in method  700 ). Whether another transit data server  24  is capturing the event may depend on many factors, such as:
       (a) What transit data servers (or functionality) transit agency  26  has enabled. If real-time bus stop updates are not part of transit data servers  24  then a bus being late is not an event, for example.   (b) How severe the event is, where such severity may be determined by any of transit data server  24 , incident manager  24   a,  an operator, and the like. A bus hitting a curb but continuing on its route would be less severe than a bus hitting a car and having to wait for the accident to be handled.       
 
         [0059]    If  704  is affirmative method  700  continues to  706  where the functionality of transit data server  24  is used. As can be imagined,  706  can encompass a very broad range of functionality and transit data servers. Essentially at  706  the particular workflow, use, interaction with, or transaction contemplated by one or more users or one or more transit data servers  24  may be largely completed, or adequately completed to allow method  700  to continue, as described herein. A few examples may include:
       (a) A supervisor determines that a bus needs to short-turn instead of completing the entirety of the route it was to be driving. Using a scheduling functionality, for example in Transit Planning Functionality, the bus&#39; route is updated, its sign is updated, and any affected electronic stop signs are updated. For the Trip Planning Functionality transit data server  24  the change is largely complete.   (b) A driver having a particular license type calls in sick and there is no replacement driver. The scheduler may, for example via Operations Functionality  24 , remove the driver from the list of available drivers. Once the driver, and possibly the specialized vehicle, are removed, the change may be largely complete.       
 
         [0062]    Returning to method  700 , at  708  a query is made whether the event is an incident that needs to be provided to incident manager  24   a.  This determination may be based on many factors, which may be different and configurable between transit agencies  26  and transit data servers  24 , and may also be subjectively determined by a user/operator. Exemplary factors may include:
       (a) How significant is the impact of the event? How widespread is the impact?   (b) How long will the impact last?   (c) Are riders likely to be affected? Transit agency operators?   (d) Will stakeholders (operators, drivers, riders, schedulers, etc) benefit from being made aware of the event?   (e) Have any stakeholders signed up to receive alerts relating to this type of event?       
 
         [0068]    In one embodiment transit data servers  24  may make the determination, either automatically (based on logic therein) or via an operator of the functionality making a determination. In another embodiment the query may be made by incident manager  24   a,  meaning that  708  may occur after  710 , for example. 
         [0069]    If the event is determined to be an incident at  708  then method  700  continues at  710  to create and communicate an incident data structure (as described herein) to incident manager  24   a.    
         [0070]    Creating the data structure may be substantially as known in the art, assembling various pieces of data and storing them together. The incident data structure definition in each transit data server  24  may be the same or different, and may indicate which fields of the data structure are required or optional. Such requirements may vary between transit data servers  24  or may be the same and may be set by incident manager  24   a.  It may be preferable for as many fields as possible by inserted into the data structure so that incident manager  24   a  has a nearly-complete incident upon receipt. 
         [0071]    At  712  incident manager  24   a  may ingest the incident data structure and place it in its queue of incidents. This may put the incident in line to be reviewed, amended or completed. The queue may comprise one or more incidents from one or more transit data servers  24 , including incidents being created within incident manager  24   a.    
         [0072]    At  714  the incident is reviewed and possibly amended. The review may be automatic, such as by logic within incident manager  24   a,  or may be done by a user of incident manager  24   a  (such as a administrator) via one or more screens displayed on computing device  14 , such as those shown and described herein. In one embodiment incidents may be characterized using one or more pre-defined tags, such as shown in  510 . 
         [0073]    At  720  the incident is created in incident manager  24   a.  Prior to this creation, the event may only be a potential incident, and for example not to be distributed or disseminated to content sinks. By  720 , amendments to the data stored in the incident data structure may be complete (to the extent required) and accurate (to the extent required and as may have been confirmed by an administrator). Incident manager  24   a  may amend or enhance the incident at  720 , for example using transit data in TDD  22  and accessed via functionality modules  100  of transit data servers  24 . In one example, an incident may relate to a bus stop on a particular route. Via transit data servers  24 , incident manager  24   a  can determine the other stops on the route, and mark them as being potentially affected. Further, if the stop is part of more than one route, then other routes (and their stops) may also be marked as being affected. Without transit data servers  24  this may not be possible. 
         [0074]    At  722  content sinks, that are to receive notification of the incident, are determined. As described herein, stakeholders may create profiles and “sign up” to receive various content (including alerts, notifications and incidents), where such content may be described using various fields or attributes. Stakeholders&#39; sign ups may be for general messaging (weather, system outages, and the like) or more specific (particular routes, buses, time periods and the like) or other qualities of the incident. When the incident is described and characterized, as described herein, various fields and information that are part of incident data structure may be allow content sinks to be identified—for example by noting which incident fields are part of the content fields that are part of the sink&#39;s alerts. 
         [0075]    Various content sinks may receive different information about the same incident, for example based on the preferences in their profiles (specifying they want all details or only a few), what type of user stakeholder they are (an executive of transit agency  26  may be entitled to view information relating to remediation, whereas a rider may not), what device the sink is using (PCs may receive more information than bus-stop signs or mobile devices), and the like. 
         [0076]    Transit data servers  24  may also be content sinks. For example, an incident may have been created in asset manager functionality  24  (such bus #1234 is undergoing unexpected maintenance), and trip planning functionality  24  may be a content sink for that incident so that it does not insert bus #1234 in a schedule until it is fixed. 
         [0077]    At  724 , follow-up is performed, if required. This may involve updating the incident, and its data structure, and subsequently updating transit data server  24  that captured the event initially. Although many follow-up options are considered, a few notable examples include:
       (a) If a rider tweet became an incident, a tweet (or other form of communication) from transit agency  26  may identify that the incident has been noted, or that the incident has been resolved.   (b) If a traffic light was out, leading to an incident, but is fixed, then an update may be created. Of course this may lead to another communication to content sinks.       
 
         [0080]    Returning to  708 , if the event is not an incident then method  700  ends at  718 . This could be substantially similar to the situation if incident manager  24   a  did not exist and transit data servers  24  simply operated on their own. 
         [0081]    Returning to  704 , if no transit data server  24  is capturing the event then method  700  continues to  716  where a query is made whether the incident is to be captured in incident manager  24   a.  Similar assessments may be made at  716  to  704 . Alternative ways for the event to be captured may exist at  716 , such as phone calls, weather details, events that an administrator (or other stakeholders) may have heard about, and the like. These may then be added as incidents by the administrator, such as via functionality described herein and screenshots herein. While being added in incident manager  24   a,  transit data servers  24  may also be used to create or specify the incident. By way of example, an administrator may learn that Main St, heading north, is closed, and may add that to a new incident. Incident manager  24   a  may take the location (address, GPS coordinate, and the like), along with “road closure” and query transit data server  24  providing routing functionality to determine and provide the route numbers that are affected. The administrator may review and accept such routes. 
         [0082]    At  716  if the event is not an incident then method  718  ends at  718 . Otherwise method  700  continues at  720 , then  722  and possibly  724 , which all may be substantially as described herein. 
         [0083]    The above method  700  was described largely in relation to creation of the incident. It is to be understood however that updating, responding to, and closing incidents may also be part of system  10  and the methods described herein. 
         [0084]      FIGS. 8-12  are screenshots  800 / 900 / 1000 / 1100 / 1200  for incident creation, review and dissemination according to a non-limiting embodiment of the present invention. Such screenshots may be, or comprise, one or more user interface elements that allow a user to interact with system  10 , for example to achieve functionality required by transit agency  26 . 
         [0085]    Screenshot  800  may be a dashboard or landing page for accessing, viewing and initiating functionality of incident manager  24   a.    
         [0086]    Screenshot  800  may allow a user to search for incidents by inputting text into search box  802  and selecting search button  804 . This may perform a full text search of incidents, for example, and return an incident for viewing or other operations. 
         [0087]    A user may be able to view one or more incidents in incident display  808 . Filter selectors  806  may allow a user to select a filter to apply to the incident queue, such as “view all”, “view live incidents”, “view expired” and “view pending approval”. The “view pending approval” may be the list of events or incidents that either have not had all information entered or have not yet been approved as incidents instead of events, and may be the same or a separate queue from the incidents queue. Different fields from an incident data structure may be displayed, those displayed in  806  are exemplary only. 
         [0088]    A user may select an incident from incident display  808  and have the incident details appear in incident details  810 . The user may also elect (such as by double-clicking) to jump into a screen (not shown) where they can edit, amend, or update an incident. 
         [0089]    From dashboard screen  800  a user may also elect to create a new incident via create incident button  812 , where a screen such as screenshot  900  may appear. 
         [0090]    In screenshot  900  a user may begin to create an incident, for example by defining the various aspects of the incident, which may be saved into fields of the incident data structure. This may include selecting a type, category and importance level from  902 . Exemplary types and categories include:
       (a) Types: Route Diversion, Service Disruption, Elevator Repair, Service Changes, Bus Repair, and the like.   (b) Categories: Bus Stops, Lines, Patterns, Blocks, Geographic Areas, and the like.       
 
         [0093]    Date ranges to capture the duration of the impact may be captured using  906 . 
         [0094]    Map/route display  904  may allow transit agency  26  routes to be selected as being impacted. Of course other such user interface elements may allow a user to select and specify other aspects of transit agency  26 , such as their assets, employees, and the like, to better define the incident. 
         [0095]    Selecting the “Next” button  908  (which may also be on screenshots  1000 ,  1100 , and  1200 ) may allow the user to continue to define the incident in the next screenshot. This may also save the information entered in the various fields into an incident data structure. 
         [0096]    In screenshot  1000  the incident may be further defined by entering a description in  1004  (which may be automatically translated between languages), or a predefined message may be selected. In some cases, a description may be all, or substantially all, that may be required or that may be obtained from transit data servers  24  when they provide incident manager  24   a  a new incident. 
         [0097]    In screenshot  1100  various modes of disseminating the incident may be selected and previewed using  1104  and  1106 . Different previews may exist based on the different information to be communicated, to different stakeholders for example, as described herein. In another embodiment of screenshot  1100 , as the incident is being created and defined the stakeholders that are to receive the information may be determined so that they may be displayed or summarized on screenshot  1100 . 
         [0098]    In screenshot  1200  a summary of the incident may be seen, with the ability to edit the incident via one or more “Edit” buttons  1206 . Each of fields  1202  may be aspects of the incident that have been specified using screenshots, automatically generated by incident manager  24   a,  or having been received from one or more transit data servers  24 . Screenshot  1200  may be used as a starting point for reviewing, amending or following up on an incident, including, for example, when an incident data structure is received for review from transit data servers  24  from  710 / 712 / 714 . The text entered in description  1004  may be the “Body” field  1204 , and may also be part of preview  1106 . 
         [0099]    It is to be further understood that one of modules  100  may allow users (such as riders) to select which content they wish to receive or be made aware of. In doing so they may “subscribe” to various content types having various parameters or categories. This may also form part of generating the statistics about who will receive or view the created content in  506 . 
         [0100]    It will be understood that any of the systems or entities that are part of system  10  may have one or more computing devices, such as servers, mobile devices, personal computers and the like, and required network technology, configured to allow the performance of the functionality described herein. Each of such systems or entities, and such computing devices, may have one or more computer-readable storage medium, that may be transitory or non-transitory, that may contain a set of programming instructions that may be executed by the computing devices. 
         [0101]    It will be apparent to one of skill in the art that other configurations, hardware etc may be used in any of the foregoing embodiments of the products, methods, and systems of this invention. It will be understood that the specification is illustrative of the present invention and that other embodiments within the spirit and scope of the invention will suggest themselves to those skilled in the art. All references cited herein are incorporated by reference.