Patent Publication Number: US-2023162102-A1

Title: Self organizing deployment of tod vehicles

Description:
RELATED APPLICATIONS 
     This application claims benefit under 35 U.S.C. 119(e) of U.S. Provisional Application 63/056,640 filed Jul. 26, 2020 and is a Continuation in Part of PCT International Application PCT/IL2021/050499 filed Apr. 30, 2021 and is a Continuation in Part of PCT International Application PCT/IL2021/050778 filed Jun. 24, 2021, and is a Continuation in Part of PCT International Application PCT/IL2021/050894 filed Jul. 22, 2021, and is a Continuation in Part of PCT International Application PCT/IL2021/050895 filed Jul. 23, 2021, the disclosures of which are incorporated herein by reference. 
    
    
     FIELD 
     Embodiments of the disclosure relate to managing vehicle resources to provide a modem population of users with Mobility as a Service (MaaS). 
     BACKGROUND 
     The increase in the global and national populations and the sophistication and variety of daily, leisure, and business activities in which modern populations regularly engage has reconfigured population distributions and transportation needs of the populations. Modern population distributions are characterized by densely populated cities that are associated with surrounding satellite regions of various types and usually evidence unparalleled growth in population density and geographical spread. The cities typically comprise a plurality of different regions characterized by different activities. The different regions may for example comprise a central transportation hub comprising a central train or bus station, high-density, high-rise residential zones, a financial district, a commercial downtown business district, shopping malls, and an entertainment district. Satellite regions of a city typically include residential areas inhabited by populations of various socioeconomic profiles, such as upscale suburbs, walled communities, rural and blue-collar suburbs, and all too often urban slums, and may include an airport and agricultural regions. The cities may themselves be part of a continuous urban or industrially developed area referred to as a “conurbation”. The various cities and satellite regions typically exhibit different diurnal, daily, monthly, and/or seasonal patterns of large and small, highly labile population movements into, out from, and within the regions, and inhabitants and visitors to the regions experience different transportation needs. 
     To serve the transportation needs of the “reconfigured” modern society, legacy mobility modes of transportation, such as active transport modes (walking and pedal bicycling), conventional public transportation systems (PTS), and privately owned vehicles, have been reinforced by a host of additional and varied, relatively new modes of transportation, and systems of making the new and legacy modes of transportation available to users. Today a modem mobility consumer may have available for use not only a privately owned vehicle, and a legacy public transport system (PTS), but various transport on demand (TOD) vehicles for hire such as taxis, limousines, buses, rickshaws and Jeepneys, and various types of personal dockless conveyances, such as e-bikes, e-scooters small dockless cars. 
     The density and ubiquity of the various modes of legacy and burgeoning new modes of transportation not only serve the needs of a modern population but also create new demands and burdens that stress the society that they serve and the environment in which they operate. Integrating and managing the various modes of transportation and associated mobility resources to serve the needs of society has led to understanding and managing the provision of transportation resources as mobility as a service (MaaS). Implementing the concept to provide a satisfactory quality of service (QoS) that answers the different mobility needs of society is a multivariate complex task. 
     SUMMARY 
     An aspect of an embodiment of the disclosure relates to providing a MaaS management system, also referred to as “Moovit-Man”, for managing the provision of TOD vehicles to service demands of a population of users. Moovit-Man comprises executable instructions and/or data, hereinafter also referred to as software, required to provide functions that Moovit-Man provides a user, and comprises and/or has access to any of various processors, memories, and communications network entities and systems required to support Moovit-Man functions. Optionally Moovit-Man is at least partially cloud based and may comprise a cloud based infrastructure of compute resources configured to support functions that Moovit-Man provides a user. 
     In an embodiment Moovit-Man comprises software executable to scan a geographical area of interest (GROI) and identify zones of interest (ZOIs) that exhibit transportation needs which may be serviced by and benefit from provision of TOD vehicles. A transportation need which may benefit from provision of TODs may by way of example be a time dependent need to reduce traffic congestion, a dearth of transportation options for a first or last mile service, or inadequate accessibility, for example as a result of meandering rather than direct routes for physically reaching a location of desired goods, services or entertainment. Scanning to determine a ZOI in a GROI for a given transportation need optionally comprises determining a spatiotemporal geofence that bounds the ZOI as a spatiotemporal volume whose geographic shape and size may be time dependent and within which the transportation need defining the ZOI may be considered to exist. A geofence is a spatial cross section of a spatiotemporal geofence at a given time and is a boundary surrounding a geographical area that at the given time exhibits the transportation need for which the spatial temporal geofence is defined. Unless otherwise indicated explicitly or by context, reference to a geofence is considered to reference a temporal cross section of a spatiotemporal geofence. Scale of time dependence of a spatiotemporal geofence may be hourly, daily, monthly, and/or seasonal. 
     In accordance with an embodiment, a ZOI geofence for a given transportation need may be determined heuristically and/or analytically. A heuristic geofence may be determined by adopting a neighborhood, municipal, administrative, or otherwise arbitrary boundary. An analytical ZOI geofence may be determined by processing a spatiotemporal service need feature (SNEF) vector optionally comprising a component providing a geographic location, a component providing a time stamp, and at least one component advantageous for determining a value of a metric that provides a measure indicative of the given transportation need. 
     In an embodiment an analytical ZOI for a given transportation need may be determined by clustering SNEF vectors as a function of their respective locations, time stamps, and a feature or features indicative of the need. A ZOI geofence for the transportation need may be determined as a boundary of a spatiotemporal volume that encloses an inordinately large concentration of the clustered SNEFs. In an embodiment processing a SNEF vector to determine a ZOI geofence may comprise tiling the GROI into a plurality of regular or irregular geographical tiles, also referred to as “gentiles”, and evaluating for each of the geotiles the SNEF vector. The geofence may be substantially coincident with a geographic isoline of a function of the SNEF vector and/or a derivative of a function of the SNEF vector. 
     In an embodiment Moovit-Man comprises software for provisioning TOD vehicles to users in a determined ZOI based on a dynamic map, optionally referred to as a “tempest map”. A tempest map maps current locations of TOD vehicles in the GROI, or GROI to which the ZOI belongs, and determines distances between a current, source location, of a given TOD vehicle in the ZOI or GROI and a destination location for the given TOD vehicle, in accordance with a trip cost metric (TRICOM). 
     A TRICOM may be a function of at least one or any combination of more than one of: a beeline distance, BEE-ΔD, between the source and destination locations; a Manhattan distance, MAN-AD, between the source and target locations; a trip time, TR-ΔT, to navigate the Manhattan distance; a vehicle operating cost, TR-CST, incurred in making the trip; a measure of inconvenience, MI, caused by making the trip to current passengers of the TOD vehicle and/or reservation passengers, (passengers who are not currently on the TOD vehicle but have reserved a seat on the TOD vehicle); and/or a trip priority (TR-P). An MI may be determined based on at least one or any combination of more than one of added travel time for current passengers, additional delay in pick-up time of reservation passengers, and/or crowding of the TOD vehicle. A trip priority may by way of example be determined as a function of at least one or any combination of more than one of a destination location for a passenger pick-up, drop-off, or passenger profile. A location of a passenger pick-up, or drop-off for a TOD vehicle is optionally referred to as a virtual stop. 
     In an embodiment Moovit-Man operates to determine QoS and/or effectiveness of a quantity and/or distribution of vehicles in a fleet of TOD vehicles made available to a ZOI in satisfying an identified transportation need associated with the ZOI. Effectiveness of the TOD fleet is optionally determined by monitoring and processing the SNEF feature vector used to identify the transportation need For example, the SNEF vector may repeatedly be evaluated for geotiles in the ZOI to determine if changes in a component or components of the SNEF vector evaluated for a geotile or geotiles in the ZOI indicate that the transportation need is being satisfactorily serviced by the TOD fleet. If the processed SNEF indicates that the traffic need is not responding as hoped for to the quantity and/or distribution of vehicles in the TOD fleet, the quantity and/or distribution of the vehicles may be changed. 
     In an embodiment, determined time dependent historical changes in the SNEF vector may be used by Moovit-Man to anticipate and undertake changes in the quantity and/or distribution of vehicles in the fleet of TOD vehicles to support satisfactory performance of the fleet in responding to the transportation need associated with the ZOI. 
     In an embodiment, Moovit-Man may operate to provide a GROI with a fleet, also referred to as a self-organizing fleet, of TOD vehicles that self-organizes a distribution of the TOD vehicles to service a transportation need experienced by users in the GROI 
     This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. 
    
    
     
       BRIEF DESCRIPTION OF FIGURES 
       Non-limiting examples of embodiments of the invention are described below with reference to figures attached hereto that are listed following this paragraph. Identical features that appear in more than one figure are generally labeled with a same label in all the figures in which they appear. A label labeling an icon representing a given feature of an embodiment of the invention in a figure may be used to reference the given feature. Dimensions of features shown in the figures are chosen for convenience and clarity of presentation and are not necessarily shown to scale. 
         FIG.  1 A  schematically shows a map of a neighborhood of Boston Massachusetts referred to as Roxbury as an example GROI that is tiled with gcotilcs and exhibits a ZOI having a first-mile/last-mile transportation need, in accordance with an embodiment of the disclosure; 
         FIG.  1 B  shows a flow chart of a procedure that Moovit-Man may execute to identify the ZOI exhibiting the first/last mile need shown in  FIG.  1 A , in accordance with an embodiment of the disclosure; 
         FIG.  1 C  schematically shows the neighborhood of Boston shown in  FIG.  1 A  having ZOIs that are determined by clustering without use of tiling in accordance with an embodiment of the disclosure; 
         FIG.  1 D  shows a flow chart of a procedure by which Moovit-Man may determine the ZOIs shown in  FIG.  1 C , in accordance with an embodiment of the disclosure; 
         FIG.  1 E  schematically shows spatiotemporal geofences for the Roxbury neighborhood determined using an algorithm based on that shown in the flow chart of  FIG.  1 C , in accordance with an embodiment of the disclosure; 
         FIG.  2 A  schematically shows a map of Boston Massachusetts and environs that exhibits a transportation need to improve, “boost”, transportation resources, and ZOIs determined for the transportation boosting need, in accordance with an embodiment of the disclosure; 
         FIG.  2 B  shows a flow chart of a procedure that Moovit-Man may execute to identify ZOIs in the Boston area shown in  FIG.  2 A  that may exhibit a need to boost PTS resources, in accordance with an embodiment of the disclosure; 
         FIG.  2 C  and  FIG.  2 D  show a flow chart of a procedure that Moovit-Man may execute to determine whether the ZOIs identified in  FIG.  2 A  by the procedure shown in the flow chart of  FIG.  2 B  have transportation boosting (T-Boost) need, in accordance with an embodiment of the disclosure; 
         FIG.  3 A  schematically shows a service area established for providing TOD services to the first/last mile ZOI shown in  FIG.  1 A , in accordance with an embodiment of the disclosure; 
         FIG.  3 B  shows a flow chart of a procedure that Moovit-Man may execute to determine a service corridor for a ZOI, in accordance with an embodiment of the disclosure. 
         FIG.  3 C  schematically shows a distribution of TOD vehicles and TOD service corridors along which the TOD vehicles travel in the TOD service area service area shown in  FIG.  3 A , in accordance with an embodiment of the disclosure; 
         FIG.  3 D  shows a flow chart of a procedure that Moovit-Man may execute to assign a TOD vehicle to pick up a user at a virtual stop, in accordance with an embodiment of the disclosure; 
         FIG.  4 A  schematically shows an initial, random distribution of TOD vehicles in a fleet of self-organizing TOD vehicles deployed to a GROI, in accordance with an embodiment of the disclosure; and 
         FIG.  4 B  schematically shows a subsequent distribution of the self-organizing TOD vehicles in the GROI to which the initial distribution has morphed responsive to at least one constraint governing allocation of TOD vehicle in the fleet to service transportation request received from users in the GROI, in accordance with an embodiment of the disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     In the discussion, unless otherwise stated, adjectives such as “substantially” and “about” modifying a condition or relationship characteristic of a feature or features of an embodiment of the disclosure arc understood to mean that the condition or characteristic is defined to within tolerances that are acceptable for operation of the embodiment for an application for which the embodiment is intended. Wherever a general term in the disclosure is illustrated by reference to an example instance or a list of example instances, the instance or instances referred to, are by way of non-limiting example instances of the general term, and the general term is not intended to be limited to the specific example instance or instances referred to. The phrase “in an embodiment”, whether or not associated with a permissive, such as “may”, “optionally”, or “by way of example”, is used to introduce for consideration an example, but not necessarily a required configuration of a possible embodiment of the disclosure. Unless otherwise indicated, the word “or” in the description and claims is considered to be the inclusive “or” rather than the exclusive or, and indicates at least one of, or any combination of more than one of items it conjoins. 
       FIG.  1 A  schematically shows a map of a GROI  20  for which Moovit-Man has by way of example identified a ZOI  40  that exhibits a first-mile/last-mile transportation need and established a geofence  42  that delimits the ZOI, in accordance with an embodiment of the disclosure. GROI  20  is by way of example a neighborhood named, “Roxbury”, that is outlined by a municipal border  22  and is part of the greater Boston area. The greater Boston area, only a portion of which is shown in the figure, may be considered a larger GROI, an “envelope” GROI enclosing the smaller Roxbury GROI  20 . Roxbury  20  is located between public transportation lines (PTS)  24  and  25  respectively having PTS stations  26  and  27 . In accordance with an embodiment Moovit-Man optionally identifies ZOI  40  and determines its associated geofence  42  by tiling a portion of the greater Boston area that includes Roxbury into a plurality of virtual tiles  44  and processing information for each of the tiles. 
       FIG.  1 B  shows a flow diagram  200  that illustrates a tiling procedure, also referred to by the label  200 , that Moovit-Man may execute to determine ZOI  40  and geofence  42 , in accordance with an embodiment of the disclosure. 
     In a block  202  of procedure  200  Moovit-Man receives a user request to determine if within a GROI  20  that is the neighborhood of Roxbury in the greater Boston area shown in  FIG.  1 A  there exists a ZOI characterized by a first/last mile transportation need. In response, in a block  204  Moovit-Man tiles at least a portion of the greater Boston area including Roxbury with virtual tiles  44  schematically shown in  FIG.  1 A . Tiles  44  are optionally identical regular hexagons, with each tile having a perimeter delimiting a region of Boston at a location given by a location of a center  45  of the tile and a tile dimension td equal to a distance between opposite sides of the tile. 
     Let a particular j-th tile  44  of a total of “J” tiles be represented by TILE(j,td,cc j ), also referred to as tile j , where cc j  represents a geographic location of center  45  of the tile. Optionally td ≤ ULD where ULD is an upper limit distance that is considered to be a distance that most people would not consider presents a last or first mile difficulty and would find reasonable to traverse by walking or using a dockless conveyance. By way of example ULD may be equal to about a half kilometer. 
     Optionally in a block  206  Moovit-Man determines a service need feature vector SNEF(F/L, j, fc i ) = {fc i :(l ≤ i ≤I)} having features fc i  for determining whether a given TILE(j,td,cc j )  44  indicates a first/last (F/L) mile need. By way of example, the set {fc i :(1 ≤ i ≤I)} may comprise at least one or any combination of more than one feature selected from:
     fc 1  = τ(a time stamp relevant to when features fc i  are evaluated for tile j);   fc 2  = Δ τ (duration of time interval during which features fc i  are evaluated);   fc 3  = Lc (location of tile center);   fc 4  = PTS-d (distance from Lc to a nearest PTS station);   fc 5  = nt (where fc 5  represents a set of binary feature that may be used to classify a tile as to neighborhood type, for example, residential, commercial, financial, industrial, rural);   fc 6  = ρ (tile population density);   fc 7  = IncM (population median income);   fc 8 = #Trp-PTS (number of trips to PTS station);   fc 9  = Avg-t (average trip time);   fc 10  = Avg-Cst (average trip cost);   fc 11  = TripModes (where fc 11  represents a set of mobility mode features, each mobility feature in the set giving a fraction of trips to the PTS station given by fc 8  made using a particular different mode of transportation);   fc 12  = AVO (fc 12  represents a set of mobility mode features that give values for average vehicle occupancy for corresponding modes of transportation given by fc 11 ); and/or   ...;   fc I .   
 It is noted that a set may contain any number of set members and may for example be a null set having no members or a singleton set having only one member.
     In a block  208  Moovit-Man determines a first/last mile attention weighting vector AW(F/L, w i ) = {w i : 1≤ i ≤ I) for which weights w i  determine a weight given to corresponding features fc i  in determining if a given tilc j  indicates a first/last mile need. For example, population density fc 6  may be heavily weighted by a relatively large value for w 6  and a rural neighborhood in the set of neighborhood type features represented by fc 5  by a low weight w 5  for determining first/last mile need. Optionally, in a block  210  Moovit-Man defines a first/last mile need function NEEDY(F/L, j, fc i , w i ) for a given tile j  equal to the scalar product SNEF(F/L, j, fc i )▪AW(F/L, w i ) = ∑w i fc i  . And in a block  212  evaluates NEEDY(F/L, j, fc i  w i ) for all tiles j . Optionally, in a block  214 , based on NEEDY(F/L,j,fc i ,w i ), Moovit-Man classifies TILE(j,td,cc j ) as indicating or not indicating a first/last mile need F/L. In an embodiment Moovit-Man determines that TILE(j,td,cc j ) exhibits a sufficient F/L need that warrants the tile being included in ZOI  40  if the need function NEEDY(F/L, j, fc i , w i ) has a value greater than a predetermined value. 
     In a decision block  216 , if TILE(j,td,cc j ) is classified in block  214  as not indicating a first/last mile need, Moovit-Man may determine in a block  218  that the tile does not belong to first/last mile need ZOI  40  ( FIG.  1 A ). On the other hand if TILE(j,td,cc j ) is classified in block  214  as indicating a first/last mile need, Moovit-Man includes TILE(j,td,cc j ) in ZOI  40 . In a block  222  Moovit-Man optionally determines geofence  42  for ZOI  40  as a polygon that includes the areas of all TlLE(j,td,cc j )s determined in block  220  to belong to ZOI  40 . It is noted that whereas an area within geofence  42  includes all TILE(j,td,cc j )s determined to belong to ZOI  40  it may also include TILE(j,td,cc j )s that are determined not to be part of ZOI  40 . For example, TILE(j,td,cc j )s individualized by labels 51, 52, 53, and 54 that are located within geofence  42  were determined in block  218  not to belong to ZOI  40 . 
     Whereas in procedure  200  a TILE(j,td,cc j ) is classified as belonging or not belonging to ZOI  40  based on a function NEEDY(F/Lj,fc i ,w, i ) that is a scalar product SNEF(F/L,j, fc i )▪AW(F/L, w i ), classifying a TILE(j,td,cc j ) as belonging or not belonging to a ZOI is not limited to determining and using a scalar product function such as NEEDY(F/L,j,fc i ,w i ). For example, a TlLE(j,td,cc j ) may be classified as belonging to first/last mile ZOI  40  by a neural network that operates on the feature vector SNEF(F/L, j, fc i ) for the tile. 
     In an embodiment Moovit-Man may identify routes that are traveled between locations in ZOI  40  and/or between locations in ZOI  40  and locations of PTS stations in and in the environs of ZOI  40  and use the identified routes to determine relatively heavily traveled traffic corridors between the locations. A traffic corridor, also referred to simply as a corridor, may be a route or bundle of nearby routes that supports or may be used to support a portion of trips between two locations greater than a threshold portion. For example, a route or bundle of nearby routes between a location in a particular tile of ZOI  40  and a location of a particular PTS station  26  or  27  over which a portion of trips between the locations is greater than a given threshold may be determined to be a corridor. A route or bundle of nearby routes between two locations in ZOI  40  or between a PTS station  26  and a PTS station  27  that passes through ZOI  40  may be determined to be a corridor. Routes may be determined to be nearby and suitable for bundling into a channel using any of various suitable temporal or spatial criteria. For example two routes between same locations may be determined to be nearby if a travel time and/or travel distance between the routes is less than a given fraction less than one of a respective travel time and/or distance between the locations. In an embodiment travel routes in a GROI or ZOI may be clustered using a clustering algorithm to identify travel corridors. 
     In an embodiment Moovit-Man deploys vehicles in a fleet of TOD vehicle to service F/L needs in ZOI  40  responsive to a pattern of corridors that Moovit-Man determines for ZOI  40  and optionally environs. 
     Whereas  FIGS.  1 A and  1 B  exhibit determining ZOIs that are associated with first mile and last mile, F/L, service needs based on geo-tiling, practice of an embodiment of the disclosure is not limited to determining ZOIs based on segmenting a GROI by apriori geo-tiling. For example, in an embodiment Moovit-Man may monitor vehicular traffic to generate a spatiotemporal traffic “activity map” for traffic in GROI  20  independent of predetermined apriori boundaries within the GROI. Moovit-Man may process the map to determine ZOIs and their associated geofences in the GROI that are relevant to different aspects of, optionally F/L, transportation needs. 
     By way of example,  FIG.  1 C  schematically shows a perspective, planar map of the Roxbury GROI  20  and environs shown in  FIG.  1 A  with an addition shown in  FIG.  1 C  of an overlying schematic vehicular traffic activity map that Moovit-Man may generate for the GROI in accordance with an embodiment of the disclosure. The activity map is labeled to indicate a transportation need for which the activity map is generated and by a pair of clock times that define a period of time for which the activity map is relevant. The activity map shown in  FIG.  1 C  is labeled and referred to by the label F/L(06:00-07:00) and indicates that the map is relevant for F/L traffic activity from 6 AM and 7 AM Boston time in the morning. 
     Activity map F/L (06:00-07:00) comprises diamond icons  499  that represent locations of trip starts or trip ends in GROI  20  and environs for vehicular trips monitored by Moovit-Man. Each icon  499  represents one or more trip starts and/or trip ends for monitored trips at which the icon is located in the map. A vehicular trip may be a trip undertaken using any type of vehicle. The vehicle may for example, be a private car, taxi, TOD vehicle, a PTS vehicle, e-bike, e-scooter or small dockless car. Traffic activity map F/L(06:00-07:00) schematically shows ZOIs,  501 ,  502 , ...,  507 , and their associated geofence boundaries  501 B,  502 B, ...  507 B that Moovit-Man determines for F/L transportation needs by processing monitored trips exhibited in GROI  20  and environs between the hours of 6 AM and 7 AM. ZOIs,  501 ,  502 , ...,  507  may be referred to generically by the number  500  and geofences  501 B,  502 B, ...,  507 B may be referred to generically by the number  500 B. Trip starts and trip ends  499  that are determined by Moovit-Man to be associated with F/L trips and contribute to determining ZOIs  500 , are shown shaded. Trip ends and trip starts  499  that are determined not to be associated with F/L trips are unshaded. Methods for distinguishing trips considered to be F/L trips from trips that are not considered to be F/L trips are discussed below. 
       FIG.  1 D  shows a flow diagram  550  of a procedure, also referenced by numeral  550 , by which Moovit-Man may generate traffic activity map F/L(06:00-07:00) and identify and delimit ZOIs  500  shown in  FIG.  1 C  that are relevant to F/L transportation needs, in accordance with an embodiment of the disclosure. 
     In a block  552  of procedure  550  Moovit-Man receives a user request to determine a traffic activity map and consequent ZOIs associated with F/L transportation for the Roxbury neighborhood GROI  20  of the greater Boston area shown in  FIG.  1 A . In response, in a block  554  Moovit-Man monitors vehicular trips in Roxbury and surrounding area. 
     Optionally, in a block  556 , for each trip in GROI  20  that Moovit-Man monitors, Moovit-Man optionally generates a service need feature vector SNEF(F/L,j,fc i ) = {fc i :(1 ≤ i ≤I)} having features fc i . Features fc i  are features that characterize the trip and may be advantageous for classifying the trip as a F/L trip and identifying and characterizing a ZOI in GROI  20  that is relevant for understanding an aspect of F/L needs in GROI  20 . In an embodiment the set {fc i :(1 ≤ i ≤I)} may comprise at least one or any combination of more than one feature selected from:
     fcn 1  = ID (assigned ID trip index n);   fcn 2  = τ(time stamp);   fcn 3  = TripMode (transportation mode: private vehicle, subway, bus, or cab);   fcn 4  = TripSt (location of trip start);   fcn 5  = TripEn (location of trip end);   fcn 6  = TripOcc (transportation mode occupancy for trip n);   fcn 7  - TripTime (trip duration);   fen 8  = TripCst (trip cost); and/or   ...;   fcn I     

     In a block  558  Moovit-Man processes feature vectors of monitored trips to determine whether or not they are F/L trips that may be used for generating a F/L traffic activity map between 6:00 AM and 7:00 AM for GROI  20 . Trips may be classified as F/L trips in accordance with any of various suitable criteria. For example, a trip may be classified as an F/L trip if it connects a trip start to or trip end from a PTS station  26  or  27 , if the trip duration is between predetermined lower and upper duration bounds, and/or the trip distance is between predetermined lower and upper trip distance bounds. A trip may be classified as an F/L trip by any of various classifiers operating on the SNEF(F/L, j, fc i ) feature vector that Moovit-Man determines for the trip. 
     Optionally, in a block  560  Moovit-Man processes trips that have been determined to be F/L trips to determine locations of clusters of trip starts and/or trip ends. In a block  562  Moovit-Man identifies clusters exhibiting a concentration of trip starts and/or trip ends greater than a threshold concentration as ZOIs  500  relevant to F/L service needs in GROI  20  and environs. Clustering may be performed using any of various clustering algorithms, for example, a nearest neighbor, k-means, or Gaussian mixture model (GMM). In a block  564  Moovit-Man optionally determines respective bounding geofences  501 B- 507 B (generically  500 B) for the clusters. Any of various criteria may be used to determine a geofence  500 B for a cluster. For example, a bounding geofence for a cluster may be determined as a convex hull of the cluster, or as a density isolinc responsive to a density of trip starts and/or trip ends  499  in the cluster, and/or as a spatial derivative isoline responsive to a spatial derivative of the density. For clustering using a GMM soft classification algorithm, a geofence boundary  500 B may be determined responsive to respective probabilities of trip starts or trip ends  499  belonging to the cluster provided by the GMM. 
     Optionally, in a block  566 , Moovit-Man pairs trip starts and/or trip ends  499  located in a given ZOI  500  with their respective trip ends and/or trip starts  499  in other of ZOIs  500  to determine highly traveled routes between the given ZOI and the other ZOIs. Highly traveled routes between a same pair of ZOIs may be aggregated, “bundled”, optionally in a block  568  to determine travel corridors between the ZOIs. Travel corridors between different ZOIs  500  are schematically represented by shaded bands  520  that extend between the ZOIs that they connect. 
     In an embodiment, Moovit-Man operates to continuously monitor traffic in a GROI, such as GROI  20 , to generate traffic activity maps for the GROI at different times and determine spatiotemporal geofences that define and bound a time dependent geographic ZOI, also referred to as a spatiotemporal ZOI, in the GROI. A given spatiotemporal geofence determined for a GROI is a spatiotemporal envelope that bounds in space and time a region of geography in the GROI considered to be a ZOI relevant to a transportation need which may be time dependent generally in size, shape, and/or possibly location. A cross section of the spatiotemporal geofence at a given time defines a geofence that encompasses an instance of the ZOI that is relevant to the transportation need at the given time, or for a time period including the given time during which the cross section of the spatiotemporal geofence may be considered substantially time invariant. A ZOI determined from a spatiotemporal geofence may have a temporal extent coincident with that of a traffic activity map determined for the spatiotemporal geofence. In an embodiment a period of time over which the spatiotemporal geofence extends is advantageously sufficiently long so that the spatiotemporal geofence can exhibit changes in traffic in the GROI as a function of time that are relevant for planning transportation services responsive to a transportation service need of the GROI. A spatiotemporal geofence may be considered a boundary of a spatiotemporal ZOI. 
     For example, a spatiotemporal geofence for a GROI may have a temporal extent of about a 24 hour day to exhibit diurnal changes in traffic activity of a GROI relevant for planning daily TOD services provided to the GROI. To provide data advantageous for planning weekly provision of TOD services, a spatiotemporal geofence may extend for a period of a week or several weeks. It is noted that a sampling rate at which Moovit-Man monitors traffic in a GROI may be time dependent. For example, the sampling rate may be greater during periods of time that are expected to exhibit relatively rapid changes in vehicular traffic and relatively smaller during periods of time during which traffic changes are expected to be relatively slow. 
       FIG.  1 E  schematically shows a sequence of F/L traffic activity maps for GROI  20  determined by Moovit-Man and spatiotemporal geofences that are defined from data that the activity maps exhibit for a period of time that extends by way of example from about 06:00 to 24:00 in accordance with an embodiment of the disclosure. The activity maps exhibit geofences of ZOIs which Moovit-Man determines for the GROI that are cross sections of the spatiotemporal geofences at different times. The sequence of F/L activity maps shown in  FIG.  1 E  includes activity map F/L(06:00-07:00) shown in  FIG.  1 C  and activity maps F/L(12:00-13:30), F/L(16:00-18:00), and F/L(22:00-24:00). As noted above with respect to activity map F/L(06:00-07:00), the time labels of activity maps in  FIG.  1 E  indicate time periods for which the activity maps are relevant. As indicated by the labels, the traffic activity maps are, optionally, determined for different duration time periods. The time period duration of a given activity map may for example be determined responsive to rates of change in traffic activity in GROI  20  that may be expected to occur between the different times that label the given activity map. ZOIs in different traffic activity maps that are associated with substantially a same geographic location and belong to a same spatiotemporal geofence are labeled by a same numeric prefix followed by a time stamp in parenthesis that distinguishes each of the ZOIs and indicates a time of the traffic activity map to which the ZOI belongs. In  FIG.  1 E  the time stamp of a given ZOI is the same as the first time labeling the traffic activity map in  FIG.  1 E  that includes the given ZOI. 
     Geofences of ZOIs that belong to same spatiotemporal geofence are cross sections of the spatiotemporal geofence and are connected by contour lines labeled by the letters “ST” followed by the common prefix labeling the ZOIs that belong to the spatiotemporal geofence. The contour lines of a spatiotemporal geofence indicate a contour and general shape in time and space of the spatiotemporal geofence. A given spatiotemporal geofence may be referred to by the label labeling its contour lines. Three spatiotemporal geofences in accordance with an embodiment are explicitly designated by contour lines in  FIG.  1 E . Contour lines ST501, ST506 and ST507 are explicitly shown and outline the shape of spatiotemporal geofences ST501, ST506 and ST507 to which ZOIs sharing the numeral prefixes  501 ,  506 , and  507  respectively belong. 
     As schematically indicated in  FIG.  1 E  spatiotemporal geofences have spatiotemporal shapes that are determined by the geographical shapes and time dependence of the ZOIs that they respectively envelope. Different spatiotemporal geofences may, and generally will, have different spatiotemporal shapes to reflect the different patterns of traffic activity that characterize their respective ZOIs. For example, spatiotemporal geofence ST507 has a temporal extent from 06:00 to 18:00 because F/L relevant traffic activity for ZOI  507  begins at about 06:00 and is absent after about 18:00. On the other hand spatiotemporal geofences ST501 and ST506 are F/L “traffic active” and have temporal extent from about 06:00 to about 24:00. Spatiotemporal geofence ST501 is also characterized by a relatively large spatiotemporal volume compared to the other spatiotemporal geofences. The large volume of ST501 reflects the relatively large and F/L traffic intensive ZOI  501 . ST501 also exhibits a relatively large decrease in F/L traffic activity in the morning hours between about 09:30 and 11:00 as indicated by a substantial narrowing of the cross section of ST501 between activity maps F/L(06:00-07:00) and F/L(12:00-13:30). The narrowing may reflect settling of traffic activity after commuter traffic to work has subsided . The relatively constant cross section of ST501 between the afternoon hour of about 13:30 and the early evening hour of about 18:00 may be reflective of a mix of errand running commercial traffic and homegoing commuter traffic. 
     In an embodiment Moovit-Man may acquire data for trips associated with traffic in a GROI that provide information sufficient to distinguish different types of trips that the traffic comprises and/or to provide a profile of a population generating the traffic. The identification of different trip types and/or a population profile may be used to understand the temporal and spatial changes, such as those noted above, that characterize a spatiotemporal geofence associated with the GROI and to improve adaptation of a TOD service to spatiotemporal traffic needs of the GROI. 
     The type of a trip may characterize a feature of the trip, purpose and/or circumstance for which the trip is undertaken or engaged in. For example, a trip may be classified responsive to a trip travel distance and/or typical duration, features of the location or characteristic of the trip start and or trip end a terrain over which the trip is taken or population density along a route of the trip. A trip may be classified as commuter trip, a tourist sightseeing trip, a shopping trip, or a trip to a mass event such as to a football game. A profile of a population generating traffic in a GROI may for example provide an age, occupation, or income distribution for the population. Moovit-Man may generate SNEF vectors for trips associated with the GROI comprising SNEF vector feature components fcn i  that may be used to indicate the types of the trips and/or to provide population profile data. Moovit-Man may use the type and/or profile SNEF vector components to segment the data and provide traffic activity maps and associated spatiotemporal geofences for a particular segment or segments of the traffic in the GROI. 
     In an embodiment one or more graph convolutional networks may be used to process traffic activity maps, such as the F/L traffic activity maps shown in  FIG.  1 E , to determine ZOls and spatiotemporal geofences for a GROI and/or to predict traffic activity for the GROI. 
     In an embodiment, Moovit-Man operates to deploy TOD vehicles in a GROI and/or a ZOI based on spatial and/or temporal features of a spatiotemporal geofence associated with the GROI and/or ZOI. For example, Moovit-Man may deploy TOD vehicles to a GROI based on a feature or features of the GROI, such as a number spatiotemporal geofences identified in the GROI, corridors connecting the spatiotemporal geofences, traffic density that the corridors exhibit, corridor carrying capacities, and/or respective temporal development of the feature or features. Moovit-Man may determine a number of TOD vehicles deployed to a particular ZOI for a particular time period responsive to a spatial extent of the ZOI, density, and/or total number of trip-ends and/or trip starts located in the ZOI during the particular time period. Deployment of TOD services may be determined based on the type of traffic in the GROI, and/or profile of a population generating the traffic. 
     In an embodiment Moovit-Man may process SNEF vectors associated with trips in a given ZOI to determine clusters of SNEF vectors and deploy a number of TOD vehicles dedicated to providing service only for trips in the given ZOI that are classified as being associated with SNEF vectors that are clustered in a particular cluster. For example Moovit-Man may determine to deploy a particular number of TOD vehicles for a given time period during the day dedicated to servicing only business trips between two particular locations in the ZOI during the given time period. Deploying a number of TOD vehicles dedicated to servicing trips “belonging to” a particular cluster of SNEF vectors in the given ZOI simplifies the decision process and time required for assigning TOD vehicles to trips in ZOI. 
     In an embodiment, Moovit-Man may process SNEF vectors associated with a given spatiotemporal geofence, for example ST501, ST502, ...ST507 of GROI  20 , to generate a time dependent TOD-Deployment vector to determine a number of TOD vehicles to assign to the spatiotemporal geofence and a GROI to which the spatiotemporal geofence belongs. If an m-th (1 ≤ m ≤M) spatiotemporal geofence in a GROI is referenced by an alphanumeric label STm, a time dependent TOD-Deployment vector for the spatiotemporal geofence for a time period of duration Δt at time t may be written TOD-Dep(STm,Δ t , t , dfc k ) = {clfc(t,4t) m,k :(1 ≤ k≤K}, where the features dfc(t,Δt) k  are time dependent feature components relevant for determining a number of TOD vehicle to be deployed to the spatiotemporal geofence STm. In an embodiment the set {dfc(t,Δ)t) m,k :(1 ≤ k≤K)} for the m-th spatiotemporal geofence may comprise by way of example at least one or any combination of more than one feature selected from:
     dfc(t,Δt) m ,  1  = N-TripSt(t, Δt) (a number of trip starts in the ZOI (i.e. the spatial cross section) of the m-th spatiotemporal geofence at time t for the time period of duration Δt);   dfc(t,Δt) m,2  = N-TripEn(t,Δt) (a number of trip ends in the ZOI for time t and Δt);   dfc(t,Δt) m,3  = B-TripSt(t,Δt) (number of trip starts of the N-TripSt that are business commuter trip starts);   dfc(t,Δt) m,4  = T-TripSt(t,Δt) (number of tourist trip starts of the N-TripSt);   dfc(t,Δt) m   ,5  = S-TripSt(t,Δt) (number of shopping trip starts of the N-TripSt);   dfc(t,Δt) m,6  = ME-TripSt(t, At) (number of mass event trip starts of the N-TripSt);   dfc(t,Δt) m,7  = P≤40-TripSt(t, Δt) (number of trip starts of the N-TripSt for people younger than 40);   dfc(t,Δt) m,8  = 40&lt;P≤60-TripSt(t,Δt) (number of trip starts of the N-TripSt for people between 40 &amp; 60);   dfc(t,Δt) m,9  = 60&lt;P≤80 -TripSt(t,Δt) (number of trip starts of the N-TripSt for people between 60 &amp; 80); and/or   ...;   dfc(t,Δt) m,K .   

     Optionally Moovit-Man determines a weighting vector DEPW(w m,k)  comprising a weighting factor w m,k  for each dfc(t,Δt) m,k . Moovit-Man may determine a number of TOD vehicles to be deployed to spatiotemporal ZOI bounded by a spatiotemporal geofence STm for a period of time Δt at a time t responsive to a scalar product TOD-Dep(STm,Δt,t, dfc k )▪DEPW(w m,k ) of the weighting vector and the deployment vector TOD-Dep(STm,Δt,t, dfc k ). Weights in weighting vector DEPW(w m,k)  may be determined to reflect any of various motives for providing a TOD service and/or how well the motives are served by the service. For example, the weighting vector may be configured to stimulate use of a TOD service by a particular segment of the population of users, encourage use of a particular type of TOD service such as short distance or long distance trip TOD service, improve quality of service between particular spatiotemporal geofences, or decrease road congestion between attraction and production (A&amp;P) hubs. 
     By way of example of relative weighting that weighting vector DEPW(w m,k ) may apply to components of a deployment vector TOD-Dep(STm,Δt,t, dfc k ), the weighting vector may weight the number of business commuter type trip starts dfc(t,Δt) m,3  greater than the number of tourist trip starts dfc(t,Δt) m,4  which in turn may be weighted greater than the weighting for shopping trip starts dfc(t,Δt) m,5 . The relative weighting may reflect the relative sensitivities of a population to trip delays of business, tourist and shopping trips. The relative weights may be geared to distributing traffic between A&amp;P hubs over increased or different periods of time. 
     In an embodiment the relative weighting may be configured to restrict services that a TOD vehicle provides to transportation needs associated with a particular ZOI or a traffic feature of the ZOI. For example, the weighting vector may restrict deployment of a TOD vehicle to provide transportation only for trips that have a trip start or trip end in the particular ZOI or only to people that are domiciled in the ZOI or have a place of work or study in the particular ZOI. Such a configuration of the relative weighting effectively dedicates the TOD to the given ZOI and may be advantageous in improving a QoS feature, such as response time or compute resource required to assign the TOD to a particular trip that the TOD vehicle provides. It is noted that different TOD vehicles belonging to a same fleet of TOD vehicles or assigned to a same GROI or ZOI may be associated with different weighting vectors DEPW(w m,k ). 
     In an embodiment Moovit-Man may assign portions of a total number of TOD vehicles deployed to a given spatiotemporal geofence at time t to each corridor that is “connected to” the given spatiotemporal geofence in proportion to a number of trip starts in the spatiotemporal geofence associated with trips “through the corridor”. 
       FIG.  2 A  schematically shows a map of a GROI  60  that is a portion of the greater Boston area for which, Moovit-Man identifies a plurality of ZOIs that are attraction and production (A&amp;P) transportation hubs characterized by a concentration of incoming and outgoing traffic . As discussed below Moovit-Man operates to determine whether the incoming and outcoming traffic indicates that PTS services available to the identified A&amp;P hubs are inadequate and in need of augmentation, optionally referred to as “boosting”, by additional transportation resources. 
     In  FIG.  2 A  A&amp;P transportation hubs, also referred to as transportation hubs, A&amp;P hubs, or simply hubs, identified by Moovit-Man in accordance with an embodiment are indicated by stippled regions A&amp;P-61, A&amp;P-62, A&amp;P-63, and A&amp;P-64. Various modes of transportation that service trips and journeys between hubs A&amp;P-61, A&amp;P-62, A&amp;P-63, and A&amp;P-64 and respective routes travelled by the modes of transportation are indicated by different stylized lines. Locations at which a journey starts or ends are indicated by four-pointed star icons  71 , and intermediate stops, also referred to as waystations, along a journey travel route between journey start and end locations are indicated by solid circles  72 . 
     A journey is a travel instance undertaken between a first location, a journey start location, at which a person initiates traveling to reach a “final” desired destination at a second location, a journey end location, at which the desired destination is located. A journey may comprise a plurality of trips which are portions of the journey between two locations, one of which locations is a waystation, along the journey route. A waystation is a location at which a person making a journey pauses traveling, for example to change modes of travel, freshen up, or meet a traveling companion. A journey comprising a single trip is a “degenerate journey” and may be referred to as a trip as well as a journey. Stylized lines,  81 ,  82 ,  83 , and  84  in  FIG.  2 A  represent travel by private vehicle, subway, bus, and cab, respectively. An individual stylized line,  81 ,  82 ,  83 , and  84  indicates a general direction of travel substantially “as the crow flies” and not the actual street routes, which may appear quite different from the crow flies trajectory, of a plurality of trips or journeys made using the mode of transportation that the stylized line represents. 
       FIG.  2 B  shows a flow diagram  240  of a procedure, also referenced by numeral  240 , by which Moovit-Man may identify and delimit attraction and production transportation hubs A&amp;P-61, A&amp;P-62, A&amp;P-63, and A&amp;P-64 shown in  FIG.  2 A , in accordance with an embodiment of the disclosure.  FIGS.  2 C and  2 D  show a flow diagram  280  of a procedure, also referenced by numeral  280 , by which Moovit-Man may determine whether traffic to and from hubs A&amp;P-61, A&amp;P-62, A&amp;P-63, and A&amp;P-64 indicate transportation boosting needs, in accordance with an embodiment of the disclosure. 
     With reference to procedure  240  shown in  FIG.  2 B , in a block  242  Moovit-Man receives a request to identify and locate transportation hubs in the greater Boston area and determine whether traffic to and/or from the hubs indicate a need to boost transportation resources available to travel to and from the hubs. In response, optionally in a block  244  Moovit-Man operates to acquire data for a plurality of N trips TRIP(T-Boost, n) 1 ≤n ≤N that are traveled in the greater Boston area for analysis to locate traffic hubs and determine a transportation “booster need” for the area, in accordance with an embodiment. Optionally in a block  246  Moovit-Man defines a SNEF feature vector SNEF(T-Boost, n, fcn k ) having K components fcn k , 1 ≤k ≤K that may be processed to identify traffic A&amp;P hubs and determine transportation booster (T-Boost) needs for the A&amp;P hubs. By way of example, a set {fcn k : 1 ≤k ≤K} may include at least one of any combination of more than one feature selected from:
     fcn 1  = ID (assigned ID trip index n);   fcn 2  = τ (time stamp);   fcn 3  = TripMode (transportation mode: private vehicle, subway, bus, or cab);   fcn 4  = TripSt (location trip start);   fcn 5  = TripEn (location trip end);   fcn 6  = TripOcc (trip transportation mode occupancy);   fcn 7  = TripTime (trip duration);   fcn 8  = TripCst (trip cost);   fcn 9  = From-ID (continuation from trip ID “n”);   fcn 10  = To-ID (continuation to trip ID “n”);   fcn 11  = JourSt (journey start location);   fcn 12  = JondEn (journey end location); and/or   ...   fcn K .   

     Optionally in a block  248  Moovit-Man defines a cluster weighting vector CW(T-Boost, cw k ) = {cw k :1 ≤k ≤K}. For CW(T-Boost, cw k ), optionally cw 2  = cw 4  = cw 5  = cw 12  = 1 may be used to weight features in feature vectors SNEF(T-Boost, n,fcn k ) for processing to cluster the feature vectors and identify transportation hubs in the greater Boston area. Optionally in a block  250 , Moovit-Man generates a weighted feature vector for each trip TRIP(T-Boost, n) by multiplying, element by element, components in SNEF(T-Boost, n, fcn k ) by components in CW(T-Boost, cw k ). In the block Moovit-Man may cluster the weighted feature vectors to determine spatiotemporal clusters SPAT-C(m) 1 ≤m≤M of trip start locations, fcn 4  = TripSt, and/or trip end locations, fcn 5  = TripEn. 
     In a block  252  Moovit-Man may determine a concentration of trip start locations (TripSt) and/or trip end locations (TripEn) and in a decision block  254  determines whether or not the concentration of trip start and/or end locations for a cluster SPAT-C(m) indicates that the cluster is a A&amp;P transportation hub. By way of example, a concentration of clustered trip start and/or end locations may indicate a hub if the concentration is greater than a predetermined threshold concentration. Alternatively, features of a cluster SPAT-C(m), such as a centroid, spatial spread, and/or a point cloud of trip start and end locations may be input to a neural network for processing to determine if the cluster warrants being considered a A&amp;P hub. If a hub is not indicated, optionally in a block  256  the SPAT-C(m) is not considered to be a A&amp;P hub. On the other hand, if the concentration does indicate a hub, optionally in a block  258  the spatiotemporal cluster SPAT-C(m) is considered to be a A&amp;P hub. In a block  260 , Moovit-Man may determine a spatiotemporal geofence for the SPAT-C(m) and thereby the A&amp;P hub. Determining for the spatiotemporal geofence a geofence at a given time or time period may comprise determining a convex polygon for the trip start and/or end locations in the cluster for the given time. 
     With reference to procedure  280  shown in  FIGS.  2 C and  2 D , Moovit-Man operates to determine if an A&amp;P  61 ,  62 ,  63 , or  64  identified by procedure  240  shown in  FIG.  2 B  exhibits a particular transportation need. In a block  282  Moovit-Man is directed to determine if a QoS provided by the PTS service of buses and subways in the Boston area shown in  FIG.  2 A  is unsatisfactory and in need of boosting. 
     In a block  284  Moovit-Man may define an attention weighting vector AW(T-Boost, aw k ) = {aw k :1 ≤k ≤K} for weighting components of SNEF(T-Boost, n, fcn k ), optionally determined by procedure  240 , to determine if trips TRIP(T-Boost, n) associated with identified A&amp;Ps  61 ,  62 ,  63 , and/or  64  indicate a transportation boosting deficiency. By way of example, weighting components, aw k , of AW(T-Boost, aw k ) for weighting corresponding components fcn k  of SNEF(T-Boost, n, fcn k ) may be assigned values:
     aw 1 (fcn 1 )=1 = weight for [ID (assigned ID trip index n)];   aw 2 (fcn 2 )= 1 = weight for [τ (time stamp)];   aw 3 (fcn 3 )=1 = weight for [TripMode (transportation mode)];   aw 4 (fcn 4 )=0 = weight for [TripSt (trip origin)];   aw 5 (fcn 5 )=0 = weight for [TripEn (trip end)];   aw 6 (fcn 6 )=1 = weight for [TripOcc (trip mode occupancy)];   aw 7 (fcn 7 )=l = weight for [TripTime (trip duration)   aw 8 (fcn 8 )=0 = weight for [TripCst (trip cost)];   aw 9 (fcn 9 )= 1 = weight for [From-ID (continuation from trip ID “n”)];   w 10 (fcn 10 )= 1 = weight for [To-ID (continuation to trip ID “n”)];   aw 1   1 (fcn 1   1 )=1 = weight for [JourSt (journey start location)];   aw 12 (fcn 12 )= 1 = weight for [JoudEn (journey end location)]; and/or   aw 13 (fcn 13 )=0 = weight for;   ⋮   aw K (fcn K )=0;   

     It is noted that weights aw 4 (fcn 4 ) for TripSt (trip origin)], aw 5 (fcn 5 ) for TripEn (trip end), and aw 8 (fcn 8 ) for TripCst (trip cost)] are, by way of example, set to zero. TripSt and TripEn, and TripCst may not be pertinent for a particular trip if values fcn 9  for From-ID, fcn 10  for To-ID, fcn 11  for JourSt, and fcn 12  for JourEn, which are weighted “1” in AW(T-Boost, aw k ) are known. And fcn 8  for TripCst (trip cost), while relevant for many different types of analysis of transportation needs may not be relevant for determining a boosting need. 
     In a block  286  Moovit-Man may filter SNEF(T-Boost, n, fcn k ) to select for analysis data optionally related to TRIP(T-Boost, n)s, having a JourSt (journey start location) in A&amp;P  62  and a JoiirEn (journey end location) in A&amp;P  63  or a JourEn in A&amp;P62 and a JourSt in A&amp;P  63 . In a block  288  Moovit-Man uses values from selected SNEF(T-Boost, n, fcn k ) vectors for ID trip indices n from components fcn 1 , time stamps τ from components fcn 2 , TripModes from fcn 2 , from From-IDs from fcn 9 , and To-IDs from fcn 10  to concatenate trips to provide transportation data for complete journeys between A&amp;P  62  and A&amp;P  63 . It is noted that a complete journey determined in block  288  may have been made using only a single mode of transportation or a mix of different modes of transportation. 
     Optionally in a block  290  Moovit-Man determines for each single mode and for mixed mode journeys between A&amp;P62 and A&amp;P 63: 1) an average journey duration; and 2) an average vehicle occupancy. And in a block  292  Moovit-Man may determine a ratio between an average journey time for journeys between A&amp;P  62  and A&amp;P  63  made at least in part by a PTS vehicle divided by an average journey time for travel between A&amp;P  62  and A&amp;P  63  by private vehicle. 
     In a decision block  294 , if the ratio determined in block  292  is less than a predetermined threshold Moovit-Man optionally proceeds to a block  300  and determines that PTS traffic between A&amp;P  62  and A&amp;P63 does not exhibit a transportation boosting need. On the other hand, if in block  294  the ratio is greater than the predetermined threshold, Moovit-Man proceeds to a block  296  to determine whether vehicle occupancy for journeys between A&amp;P  62  and A&amp;P  63  made by private vehicles is less that a predetermined occupancy threshold. If the occupancy is not less than the predetermined occupancy threshold Moovit-Man proceeds to block  300  and determines that traffic between A&amp;P  62  and A&amp;P63 does not exhibit a transportation boosting need. On the other hand, if in block  296  private vehicle occupancy is less than the occupancy threshold Moovit-Man may determine that traffic between A&amp;P  62  and A&amp;P63 does exhibit a transportation boosting need. 
       FIG.  3 A  schematically shows a service area  100  delimited by a service area boundary  101  established for providing TOD services to the first/last mile ZOI  40  shown in  FIG.  1 A , in accordance with an embodiment of the disclosure. TOD service area  100  includes ZOI  40  bounded by boundary  42  and optionally extends to include a PTS station  26  of PTS line  24  and two PTS stations  27  of PTS line  25 . By way of example, service area  100  includes three TOD travel corridors  104 ,  106 , and  108 , schematically represented by oppositely directed arrows bundled by an ellipse. TOD vehicles deployed in service area  100  may travel back and forth along roadways in and along corridors  104  and  108  to provide first/last mile service to users in ZOI  40  for travel to and from PTS stations  26  and  27  in service area  100 . TOD vehicles deployed in service area  100  may travel back and forth along roadways along corridor  106 , which may also be referred to as an internal corridor, to provide first/last mile service to users in ZOI  40  for travel within ZOI  40  along major thoroughfares of the ZOI. In accordance with an embodiment travel corridors  104 ,  106 , and  108 , are configured to include and provide access to main thoroughfares that support relatively efficient, unobstructed movement of TOD vehicles and to be relatively close to concentrations of populations in ZOI  40  that use TOD services. By way of example Moovit-Man may determine corridors  104  or  108 , which because the extend beyond ZOI  40  may be referred to as external corridors, for service area  100  and ZOI  40 , in accordance with a procedure  310  shown in  FIG.  3 B . 
     In a block  312  of procedure  310  Moovit-Man may determine PTS stations for a service area to be served. In a block  314  for each tile in the ZOI service area Moovit-Man optionally determines a potential number “NOU” of TOD users as function a service charge and time t (hour, day, date). Optionally in a block  316  for each PTS station Moovit-Man optionally determines a potential number NOU of TOD users as function service charge and time t (hour, day, date). In an embodiment, in a block  318  Moovit-Man determines a route from the PTS station that extends into the ZOI and in a block  320  may determine an end to end travel time for travel by a TOD from one to the other end of the route. In a block  322  if the end to end travel time is less or greater than a predetermined upper limit “E2E-UL” Moovit-Man may respectively lengthen or shorten the route and in a block  324  segments the route into segments of optionally predetermined lengths. 
     Optionally in a block  326  Moovit-Man determines for each segment “nearby tiles” for which access time from the segment to virtual stops in the tiles is less than a predetermined upper limit “AT-UL” and proceeds to a block  328  to determine for the route a total user potential “TUP” equal to a sum of NOUs for all tiles determined to be “nearby”. In a block  330  if TUP is greater than a predetermined lower limit “TUP-LL” the route is included as a corridor route. In an embodiment Moovit-Man determines a corridor for the PTS station and the ZOI that is optionally a bundle of all corridor routes for which the TUP is determined in block  330  to be a corridor route. 
     In a block  334  Moovit-Man optionally determines a number of TOD vehicles to be distributed along the corridor so that an average response time µ AvR  for requests for service from the ZOI is less than or equal to a predetermined advantageous average response time having a standard deviation σ AvR  less than or equal to a desired standard deviation. 
     Internal corridor  106  may be determined based on at least one attraction production A&amp;P hub internal to ZOI  40 , heavily traveled thoroughfares in the ZOI, and/or or to provide connection to external corridors  104  and  108  using a procedure similar to that used to determine external corridors  104  and  108 . 
     It is noted that in accordance with an embodiment of the disclosure the potential number of users, NOUs, of TOD services in a ZOI tile is time dependent. As a result, Moovit-Man may dynamically determine a number and geometry of corridors in a service area of a given ZOI, or quantities or distributions of TOD vehicles along the corridors as functions of time. Optionally, Moovit-Man processes time resolved historic data characterizing NOUs to determine functions representing the NOUs in a ZOI as a function of time. In an embodiment Moovit-Man uses the functions to anticipate changes in demand for TOD services in the ZOI, and in response to an anticipated change may adjust at least one or any combination of more than one of a number of corridors determined for the ZOI, their respective geometries, or quantities or distributions of TOD vehicles associated with the corridors. 
     In accordance with an embodiment Moovit-Man uses a tempest map and an associated allocation algorithm to allocate TOD vehicles from a fleet of TOD vehicles  120  deployed to service users in ZOI  40 . A tempest map optionally comprises for each TOD vehicle in the TOD fleet a substantially real time location of the vehicle, passenger occupancy, a current route that the TOD vehicle is intended to travel and associated virtual stops at which the vehicle has been committed to stop to let off or take on passengers. By way of example,  FIG.  3 C  schematically shows a tempest map  119  showing an enlarged portion of service area  100  shown in  FIG.  3 A  and TOD vehicles  120  in the service area that are tracked by the tempest map, in accordance with an embodiment of the disclosure. A user at a virtual stop near the Washington Park area in ZOI  40  has requested that Moovit-Man provide a TOD vehicle  120  to take the user to PTS station  26  ( FIG. ,  3 A ). 
     In response to user 140’s request Moovit-Man operates to allocate a TOD vehicle  120  to take user  140  to PTS station  26  ( FIG.  3 A ), optionally in accordance with an allocation procedure illustrated in a flow diagram  340  shown in  FIG.  3 D . 
     In a block  342  of allocation procedure  340  Moovit-Man optionally ranks user  140  as to whether or not the user is located in ZOI  40 , and if the user is not within ZOI  40  ignores the request. It is noted that ZOI  40  does not include areas indicated by tiles  51 ,  52 ,  53 , and  54 . In a block  344  Moovit-Man may determine an, optionally circular, region of opportunity (ROPP) indicated by a circular dashed boundary  150  shown in  FIG.  3 B . In accordance with an embodiment of the disclosure Moovit-Man considers only TOD vehicles located within ROPP  150  as candidates for a TOD vehicle  120  to pick up user  140 , and in a block  346  determines for each TOD vehicle in ROPP  150  a feature vector having cost components cf p  (1 ≤p≤P) that may be used to determine a cost for the TOD vehicle  120  to service the user  140  request. Assuming that there are, “V”, TOD vehicles in ROPP  150 , a cost component feature vector for a v-th TOD vehicle may be written, COCOM(v, cf p,v ) = {cf p,v :(1≤p≤P)}, where (1 ≤v≤V). 
     In an embodiment the set of COCOM(v,cf p,v ) cost components {cf v,p :(1≤p≤P)} may comprise the following components:
     cf v,   1  = v (assigned vehicle ID #);   cf v,2  = τ (time stamp);   cf v,3  = VLoc (vehicle location);   cf v,4  = D2Vbs (travel distance to virtual stop (Vbs));   cf v,5  = T2Vbs (travel time, latency, to virtual stop (Vbs));   cf v,6  = D2Ret (travel distance to return from Vbs);   cf v,7  = T2Ret (travel time to return from Vbs);   cf v,8 = DDiv (travel distance diversion) = (cf v   ,   4 +cf v   ,   6 );   cf v,9 - TDiv (travel time diversion) = (cf v,5 +cf v,7 );   cf v   ,10  = RDPlan (remaining travel distance of current planned route);   cf v,   11  = RTPlan (remaining travel time duration of current planned route);   cf v,12  = VoC (vehicle occupancy);   cf v,   13  = (TDiv)/(RT/Plan) = cf v,9 /cf v,11 ;   cf v,14  = (DDiv)/(RD/Plan) = cf v,8 /cf v   ,   10 ;   cf v,15  = MI 1  (measure of inconvenience 1) = DDiv·VoC = cf v , 8 ·cf v , 12 ;   cf v,   16  = MI 2  (measure of inconvenience 2) = TDiv . VoC = cf v , 9 ·cf v , 12 ;   cf v,17  = MI 3  (measure of inconvenience 3) = cf 13 ·VoC = cf v,13 ·cf v,12 ;   cf v,18  = MI 4  (measure of inconvenience 4) = cf 14 ·VoC = cf v,13 ·cf v,12 ; ⋮;   cf v,P .   

     Optionally, in block  348  Moovit-Man defines a cost feature weighting vector, CW(cfw p ) = {cfw p :1 ≤p ≤P}, and in a block  350  optionally determines a service cost weighted vector WeServC(v, cf v,p , cfw p ) for each TOD vehicle “v”, where WeServC(v, cf v,p , cfw p ) = {cf v,p ·cfw p : 1 ≤p ≤P}. In a block  352  Moovit-Man uses the cost vectors WeServC(v, cf v,p , cfw p ) to select a TOD vehicle to pick up user  140  and bring the user to PTS station  26 . 
     In using WeServC(v, cf v   ,p , cfw p ) to determine allocation of a vehicle for user  140  Moovit-Man may assign relatively large weight factors cfw p  to measures of inconvenience, such as at least one or any combination of more than one of MI 1 , MI 2 , MI 3 , and/or MI 4 . The MI components are sensitive to a number of passengers inconvenienced by a deviation from a given TOD route plan and indicate an amplified cost if a relatively large number of TOD riders suffer a given inconvenience caused by the deviation As a result, MI components may be heavily weighted so that empty TOD vehicles in ROPP  150  may be favored over occupied TOD vehicles in the ROPP for assignment to user  140 . An MI is also expected to be sensitive to whether or not a user has been led to expect a particular feature of service provided by a TOD vehicle. In accordance with an embodiment Moovit-Man may therefore weight an MI associated with a given service feature with a larger weight if the given service feature has been assured. For example, an onboard passenger of a TOD vehicle who has been assured arrival at his or her destination by a given time is expected to be substantially more annoyed than if he or she had not been assured of the time of arrival. Moovit-Man may therefore weight cf v,16  = MI 2  (measure of inconvenience 2), which is responsive to an increase in travel time to planned virtual stops, with a substantially larger weight if an onboard passenger has been promised arrival at a destination by a given time than if the passenger had not been promised the time of arrival. Or an MI for a TOD vehicle that is a function of a cost component for example cf v,   12  = VoC (vehicle occupancy), that affects crowding may be heavily weighted if a passenger has been promised seating adjacent an empty seat 
     It is noted that whereas  FIG.  3 B  shows and the above discussion refers to a single ROPP  150 , practice of embodiments of the disclosure are not limited to a single ROPP to select a TOD to service a given client request For example, Moovit-Man may define different size ROPPs of different sizes and or distances from a given virtual stop to assign as functions of vehicle occupancies VoC. For example for TOD vehicles occupied by smaller numbers of riders, Moovit-Man may define ROPPs that are larger than and/or farther from a given virtual stop than ROPPs for vehicles occupied by larger number of riders. 
     Using the cost vectors WeServC may comprise determining a scalar product CW(cfw p )·COCOM(v,cf p,v ) and selecting a TOD vehicle having a smallest scalar product to service user  140 . Optionally, a neural network may be used to process vectors COCOM(v, cf p,v ) and/or WeServC(v, cf v,p , cfw p ) to select a TOD vehicle to serve the user. 
     There is therefore provided in accordance with an embodiment of the disclosure a method for deploying a fleet of transportation on demand (TOD) vehicles for a geographical region of interest (GROI), the method comprising: monitoring trips in the GROI; determining a traffic activity map for the GROI for each of a plurality of different times; processing the traffic activity maps to identify time dependent zones of interest (ZOIs) in the GROI that exhibit a given transportation need; determining traffic corridors that support or may be used to support trips between the identified ZOIs; determining spatiotemporal geofences responsive to the time dependent ZOIs; and deploying TOD vehicles based on the spatiotemporal geofences; wherein deploying TOD vehicles in the GROI comprises deploying TOD vehicles responsive to spatiotemporal shapes of the spatiotemporal geofences. Optionally deploying TOD vehicles in the GROI comprises deploying TOD vehicles responsive to a number of the spatiotemporal geofences determined for the GROI. Alternatively or additionally, deploying TOD vehicles in the GROI may comprise deploying TOD vehicles responsive to a number of traffic corridors connecting the spatiotemporal geofences. 
     In an embodiment the method comprises deploying TODs to a given spatiotemporal geofence for a given time period responsive to at least one feature characterizing the spatiotemporal geofence for the given time period. Optionally, the at least one feature comprises a size of a geographic area of the GROI delimited by a geofence of the spatiotemporal geofence at the given time. Alternatively or additionally, the at least one feature may comprise a number of trips starts and/or trip ends located within the geofence during the given time period. 
     In an embodiment the at least one feature comprises a time derivative of a number of trips starts and/or trip ends located within the geofence during the given time period. 
     In an embodiment determining the traffic activity map comprises classifying each of the monitored trips according to a type of trip from among a plurality of trip types. Optionally, the plurality of trip types comprises at least one or any combination of more than one of a: commuter trip; connecting trip; sightseeing trip; shopping trip; or trip to a scheduled event. Alternatively or additionally, deploying TOD vehicles comprises deploying TOD vehicles responsive to a number of monitored trips classified to each of the plurality of trip types. Optionally, deploying TOD vehicles responsive to a number of monitored trips comprises providing a weighting vector that associates a weight for each trip type and deploying TOD vehicles responsive to a number of trips classified to each trip type multiplied by the weight associated with the trip. In an embodiment the method comprises determining a distribution of trip types based on the classification of trip types and deploying a TOD vehicle responsive to the distribution. 
     In an embodiment determining the traffic activity map comprises determining at least one population profile characterizing a population generating the monitored trips by a distribution of values for at least one profile parameter. Optionally, the at least one population profile comprises at least one or any combination of more than one of an age profile, occupation profile, income profile. Alternatively or additionally, the at least one profile parameter comprises at least one or any combination of more than one of age, occupation, income, location of residency. In an embodiment deploying TOD vehicles comprises deploying the vehicles responsive to the distribution of values for the at least one profile parameter. Optionally, deploying responsive to the distribution of values for the at least one profile comprises weighting values of the distribution and deploying TOD vehicles responsive to the weighted values. 
     In an embodiment the plurality of different times span a period of at least a day. 
     In an embodiment, Moovit-Man may operate to provide a GROI with a fleet, also referred to as a self-organizing fleet, of TOD vehicles that self-organizes a distribution of the TOD vehicles to service a transportation need experienced by users in the GROI. To provide the GROI with the self-organizing fleet Moovit-Man operates to provide the GROI with a plurality of TOD vehicles spatially distributed in the GROI, in first, optionally arbitrary, spatial distribution. Moovit-Man constrains the TOD vehicles by at least one constraint that governs how a TOD vehicle in the self-organizing fleet may be allocated to respond to a request by a user in the GROI for a TOD vehicle. In an embodiment the at least one constraint may require that, the TOD vehicles service only requests that fall within a particular segment of the transportation needs characterizing transportation in the GROI. A transportation need segment may by way of example be a need for provision of trips having travel distances less than 2 km (kilometers), or between 5 and 10 km, or provision of transportation to a particular population of users, for example users in the GROI that are over 65 years of age. And a TOD vehicle that is dedicated to service trips having distances less than 2 km will not pick up users requesting trips of greater than 2 km. The at least one constraint may require that a TOD vehicle in the self-organizing fleet be allocated to a respond to a user request only if the TOD vehicle is withing a limited range of the user. Subject to the at least one allocation constraint, repeated allocations of TOD vehicles to service user request in the GROI operate to relax the initial distribution to a second distribution. The second distribution is configured by the constraints and a spatiotemporal distribution of the user requests that improves QoS that the self-organizing TOD fleet provides to the GROI relative to that provided by the fleet in the first distribution. 
       FIG.  4 A  schematically shows a first initial distribution of a self-organizing fleet of TOD vehicles provided by Moovit-Man to the Roxbury GROI  20  and environs as shown in  FIG.  1 C  overlain with the activity map F/L(0600-0700). Vehicles in the self-organizing fleet are schematically represented by asterisks  600  and are shown as distributed substantially randomly. Let diamond icons  499  in the figure represent locations of trip starts or trip ends in GROI  20  and environs of trips for which users in GROI  20  request TOD vehicles. Allocation of TOD vehicles  600  to service the user requests and provide the requested trips subject to at least one constraint in accordance with an embodiment of the disclosure rearranges the initial random distribution of TOD vehicles to a second distribution of TOD vehicles  600  schematically shown in  FIG.  4 B . As shown schematically in the second distribution TOD vehicles tend to be clustered in neighborhoods of ZOIs  501 ,  502 , ...,  507  in which trip starts and ends are clustered. It is noted that in morphing of the first distribution to the second distribution it is assumed that the distribution of trip starts and trip ends represented by icons  499  is relatively constant during a period of time it takes for the first distribution to morph to the second distribution. 
     There is therefore provided in accordance with an embodiment of the disclosure, a method for providing a fleet of transportation on demand (TOD) vehicles to service transportation needs of users in a geographical region of interest (GROI), the method comprising: segmenting user transportation needs in a GROI into a plurality of user transportation need segments, each segment defined by at least one distinctive segmentation feature which characterizes user trips that generate the transportation need segment; providing a first spatial distribution of a fleet of TOD vehicles in the GROI that are dedicated to servicing a particular transportation need segment of the plurality of transportation need segments; receiving user requests for transportation services that the fleet of TOD vehicles is dedicated to provide; allocating TOD vehicles from the fleet of TOD vehicles to service the requests; and allowing the first spatial distribution to relax to a second spatial distribution of the fleet in the GROI responsive to trip starts and trip ends of user trips characterized by the distinctive segmentation feature that the TOD vehicles in the fleet have been allocated to provide. 
     Optionally the method comprises constraining the allocation of TOD vehicles from the fleet to satisfy at least one constraint that affects a configuration of the second spatial distribution and/or a rate of relaxation of the first spatial distribution to the second spatial distribution. 
     Optionally, the second distribution is characterized by a quality of service (QoS) that the TOD vehicles in the second distribution of the TOD vehicles provide users in the GROI, and if the at least one constraint results in an unacceptable value of a component of the QoS, modifying the constraint and/or a number of vehicles in the TOD fleet. 
     Optionally, the at least one constraint comprises allocating a vehicle from the TOD fleet to service a user request of the received user requests only if the allocated vehicle is expected to reach the user that made the request within a response time from a time at which the user request was received that is less than a predetermined upper bound response time. An average response time experienced by the users may be a component of the QoS and modifying the constraint comprises changing the upper bound response time. 
     In an embodiment the at least one constraint comprises allocating a vehicle from the TOD fleet to service a user request of the received user requests only if the allocated vehicle is expected to reach the user that made the request having a passenger occupancy less than or equal to an upper bound passenger occupancy. Optionally, an average passenger occupancy for allocated vehicles is a component of the QoS and modifying the constraint comprises changing the upper bound passenger occupancy. 
     In an embodiment the at least one constraint comprises allocating a vehicle from the TOD fleet to service a user request of the received user requests only if the allocated vehicle is located within a predetennined limited area of the GROI. Optionally, modifying the constraint comprises modifying a size of the predetermined limited area. Additionally or alternatively modifying the constraint may comprise modifying a location of the predetermined limited area. 
     In an embodiment the at least one constraint comprises allocating a vehicle from the TOD fleet to service a user request of the received user requests only if allocating the vehicle does not generate a measure of user inconvenience (MI) expected to be experienced by users serviced by the TOD fleet that exceeds an upper bound degree of expected user inconvenience. Optionally, a component of the QoS is an average MI experienced by users serviced by the TOD fleet and modifying the component comprises changing the upper bound degree of expected user inconvenience. 
     In an embodiment if the at least one constraint generates an unacceptable value for a parameter characterizing operation of the TOD fleet in the second configuration the method may comprise modifying the constraint. 
     In an embodiment the distinctive segmentation feature that defines the particular transportation need segment is trip travel distance and the TOD fleet is dedicated to providing transportation services only for user requests for trips having travel distances in a particular range of travel distances. Optionally, the trip travel distance is travel distance as the crow flies. Alternatively the trip travel distance is road travel distance. 
     In an embodiment the distinctive segmentation feature that defines the particular transportation need segment is trip type and the TOD fleet is dedicated to providing transportation services only for user requests for a particular class of trip types. Optionally, the trip type is a first/last mile trip. Optionally, the trip type is a tourist trip. In an embodiment the distinctive segmentation feature that defines the particular transportation need segment is a feature characterizing users making the user requests. Optionally, the characterizing feature is business commuter. Optionally, the characterizing feature is school children. Optionally, the characterizing feature is tourist. 
     In an embodiment the first distribution is a spatially random distribution. 
     In the description and claims of the present application, each of the verbs, “comprise” “include” and “have”, and conjugates thereof, are used to indicate that the object or objects of the verb are not necessarily a complete listing of components, elements or parts of the subject or subjects of the verb. 
     Descriptions of embodiments of the disclosure in the present application are provided by way of example and are not intended to limit the scope of the disclosure. The described embodiments comprise different features, not all of which are required in all embodiments of the disclosure. Some embodiments utilize only some of the features or possible combinations of the features. Variations of embodiments of the disclosure that are described, and embodiments of the disclosure comprising different combinations of features noted in the described embodiments, will occur to persons of the art. The scope of the invention is limited only by the claims.