Information & Technology

Transcription

1 Information & Technology 1

2 Digital Wayfinding Mission Many visitors of NPS sites have and use mobile and other forms of technology to navigate. Given this opportunity, the mission statement for technology in CHB is to provide the foundation for the development of tools that allow visitors of NPS sites to personalize their travel experience by interacting with relevant information provided in an aggregated and easily navigated form. The tools could range from smart phone applications, to websites, to kiosks displaying information on screens. The goal is not to produce a single tool for CHB, but to enable the creation of many different tools that serve the various needs of different users. CHB Needs Additional relevant wayfinding information available in geocoded format Consolidated location for multiple information sources Capability to selectively view the most relevant information for users individual needs and preferences Customizable routing options between transit and NPS sites in an interactive format Data Solutions This appendix outlines three models to consolidate and distribute data: Developer Portal Enhanced Developer Portal Multimodal Itinerary Portal The appendix also outlines a Developer Challenge as a model to build momentum for creating applications from the coordinated data. 2

3 Developer Portal 3

4 Developer Portal Vision To provide a consolidated location, or centralized source of information, for developers and other users to publicly access data relevant for CHB, consisting of existing available datasets, new datasets created as a part of CHB, and existing realtime datasets. Facilitate the creation of a variety of applications at no additional cost to the City. Need/Motivation Many pieces of information could be relevant to assisting in wayfinding between NPS sites and transit in Boston, such as information about routes, the food outlets along different routes, the availability of transit, etc. In fact, depending on the preferences of an individual or group visiting NPS sites, very different information might be relevant. For example, some visitors might prefer scenic routes, and so information on views and sites along the way would be important for them, while for other visitors it might be important to reach the NPS site with a minimal walk, and for them information on the most direct, most easily accessible route might be important. Currently, there are many sources of data with varying levels of quality in terms of documentation and access. There is a need to create a single source of information for developers of wayfinding tools for CHB. Specific needs addressed by this concept: Makes data needed for wayfinding tools easily available in a single location Hosts new data developed by CHB and existing data not previously easily accessible by the public Provides documentation on data, including primary source, data format, and update frequency Detailed Description Developer portals provide a single location where developers and other users can access the data they need to create tools, such as smart phone or web-based applications. Datasets come in numerous formats and structures. Simple files can be tables stored in different formats such as MS Excel (comma separated values, text files, or others). More complex datasets can be databases which consist of a set of linked tables, commonly stored as MS Access files, SQL database files, etc. Lat Long Restaurant Cool Café NJ s Deli 4

5 Developer Portals can be provided in a variety of formats, which have varying degrees of benefits and costs. The most basic, lowest cost, and most easily maintainable way is to create a single location on the web where datasets can be linked to or hosted. Most simply, this would consist of a webpage hosted on an existing agency website. An example is the MBTA s developer webpage. The Developer Portal would include documentation on the dataset format and structure, instructions on downloading the datasets, and guidance on using them effectively. It would also include a way for MassGIS or the Office of Geographic Information of Massachusetts provides the public with access to a comprehensive, statewide database of spatial information for mapping and analysis, through their website. The spatial information includes resources for supporting emergency response, environmental planning and management, transportation planning, economic development, and numerous others. other agencies or the public to submit new datasets or update existing datasets, and a way for the submissions to be approved. Finally, the Developer Portal would provide links to examples of how to use the datasets to encourage creation of tools that are relevant. Because of the open nature of this approach, these datasets could be used to create tools that serve uses beyond CHB, and this type of entrepreneurship can provide added value to the concept. For datasets that are already publicly available and hosted on another site, such as MassGIS, links would be provided to the datasets and accompanying documentation. Datasets that were created explicitly for use by CHB or that were obtained as part of CHB but were never made easily available to the public would be hosted on the Developer Portal. Links would also be provided to existing realtime datasets, such as the MBTA vehicle location and arrival prediction information. 5

6 Developer Portal Concept The diagram illustrates the different methods by which developers/users would access data through the Developer Portal: Developers could download static datasets hosted by the portal. Developers could navigate to, and then download, static datasets hosted at other websites. The portal would provide a link to the websites. Developers could navigate to, and then access, real-time datasets hosted at other websites. The portal would provide a link to the websites. Documentation for data would be hosted either on the Developer Portal or would be available on the linked websites. High-Level Requirements The Developer Portal would have the following components: A webpage for data providers A webpage for system administrators A webpage for developers The webpage for data providers would: Allow data providers to register for, and login to, accounts Allow data providers to upload datasets or provide links to datasets, along with associated information (source, date of upload, agency name, etc.) and documentation (data format and structure) 6

7 Allow data providers to update previously uploaded datasets, links, and associated information and documentation The webpage for system administrators would: Allow system administrators to view and approve uploaded data or links, and associated information and documentation Allow system administrators to view, and selectively remove for display, all previously approved data links and associated information and documentation displayed on the webpage for developers The webpage for developers would: Display approved uploaded or linked data, and associated information and documentation Allow developers to download uploaded data, navigate to linked data, and view associated information and documentation User Narratives These narratives are intended to provide a better understanding of how the Developer Portal would work for various users. Users include agencies with relevant datasets (data providers), the administrators managing the Developer Portal, and developers who use the datasets to make tools such as smart phone and web-based applications. All narratives are hypothetical and are not meant to represent real people, agencies, or datasets. 7

8 Data Provider A bicycle advocacy organization recently created a GIS shapefile with an associated dataset of its bicycle-friendliness ranking of all streets in the City of Boston. These ratings are based on a variety of information about the bicycle-related infrastructure on each street segment, traffic volumes, nearby bicycle parking, safety statistics, and other factors. The files have been shared on the organization s website, but staff at the organization have heard of CHB and believe that the data would be particularly helpful in creating tools that compare travel options between modes. A staff person visits the Developer Portal online, registers, and submits information about the agency organization, the contact person, and the dataset through a web-based form. She provides links to the dataset and accompanying documentation. After a period, she receives an that the dataset has been confirmed to be relevant to the goals of CHB, and that it has been accepted. She is informed that the dataset will be linked to on the Developer Portal and that she should contact the administrator or use a web-based form if any updates are made to the datasets, links, documentation, or associated information. Developer Portal Administrator An administrator receives a notification that a new dataset has been submitted for inclusion in the Developer Portal. The administrator reviews the information in the form, the dataset, and the documentation, and approves the new dataset after determining that the information is relevant for the goals of CHB and of a reasonable quality. A notification is automatically sent to the data provider that the dataset has been accepted will be included. The Developer Portal is automatically updated with the new dataset, including links to the data and documentation. The administrator regularly checks to ensure that the dataset and associated information is kept reasonably up-to-date, that the links are still valid, and whether significant changes have been made that might affect data quality or relevance for CHB. 8

9 Developer A developer has decided to make a smart phone application (app) that allows visitors to Boston to pick whether to walk, take transit, or bike when visiting National Park Service sites and other important historic Boston sites. He has heard about an easy, consolidated location for getting data related to wayfinding in downtown Boston. He goes to the CHB Developer Portal online, and sees from a list of datasets that he will be able to gather information here about all modes of transportation in Boston. He explores the available datasets and documentation in more detail, finding links to transit arrival information, bicycle rental locations and availability, and bicycle and pedestrian infrastructure information. He downloads some datasets directly from the Developer Portal, and navigates to the source agency s website for others. Having downloaded all relevant datasets, and explored the documentation, he starts developing his app. Implementation Steps 9

10 Stakeholder Meetings The first step in implementing the Developer Portal is to achieve stakeholder consensus on the high-level system requirements. This ensures that the objective, alternatives, and constraints are thoroughly discussed and made clear at the very outset. Development of High-Level Requirements The second step is developing High-Level Requirements, which describe the overall system functionality without going into specific details. After stakeholder discussions, the High-Level Requirements will be written, reviewed, and will go through multiple iterations before being finalized. The finalization will happen only after a detailed discussion between major stakeholders to ensure that all needs are adequately covered by the system. Development of Use Cases The development of Use Cases is necessary to both refine the High-Level Requirements and to inform the detailed Software Requirements and Specifications. They identify the role of major stakeholders through graphic/text descriptions of how each stakeholder will use the system. Software Requirements and Specifications The Software Requirements and Specifications will involve writing detailed text descriptions and requirements that convey the system functionality in detail and inform the development of software. This stage will also involve making decisions on development software and hosting software, as well as developing hardware specifications. Software Development After the Software Requirements and Specifications have been finalized, full software development can start. The software development team may follow different development methods depending on the stakeholder requirements and constraints. Software Testing and Debugging The Software Testing and Debugging stage is vital to ensure that software is tested at every stage and faults and errors are identified and rectified. Software Deployment on Production Servers The final step, once software has been completely tested and debugged, is to deploy the software on production servers. This allows for stakeholders to test it prior to it going live to the public. Population with Data/Seeding The database will be populated with data to provide developers with data prior to going live. Go-live The Developer Portal will Go-live and be open to the public. 10

11 High-Level Opinion of Probable Cost What follows is a preliminary, high-level opinion of costs, which can vary widely depending on the ultimate design of the system based on the complexity of user and system requirements. Capital Costs: Software Design and Specifications Development: $10,000-$20,000 Software Development Costs: $40,000-$75,000 Hardware Costs: $0 (assumed to be hosted on existing web servers) Annual Operating and Maintenance Costs: Staff Administration Costs: $7,000-$12,000 Hosting/Maintenance Costs: $4,000-$7,500 Ongoing Roles and Responsibilities Host Agency The host agency would provide a system administrator staff person who would have the following responsibilities: Vetting potential new data sets for relevance/quality Maintaining a database of datasets and a schedule of updates Managing data provider accounts and maintaining contact information for data providers Maintaining relationships with agencies hosting datasets to ensure up-todate data Setting a regular schedule to check data links, make updates, and confirm thatcontracts are still valid The host agency would provide a webmaster staff person who would have the following responsibilities: Maintaining and updating the website Providing bandwidth Data Providers The data providers would provide a primary contact person who would have the responsibility of notifying the host agency when datasets are updated. 11

12 12

13 Enhanced Developer Portal 13

14 Enhanced Developer Portal Vision At a consolidated location, or centralized source of information, for developers and other users to publicly access data relevant for CHB, provide the additional functionality of accessing disaggregate and cross-cutting data across multiple static datasets using a common API (Application Programmer Interface). This concept is intended to be an add-on to the Developer Portal concept, which is a consolidated location of links to or downloads of existing available datasets, new datasets created as a part of CHB, and existing realtime datasets. It is intended to facilitate the further creation of a variety of applications at no additional cost to the City. Need/Motivation The data that are relevant to assisting in wayfinding between NPS sites and transit in Boston exist in many different formats and locations. This Enhanced Developer Portal concept provides a consistent way to access data in a standardized, well documented format. It allows developers to not only access aggregate data (e.g. all Hubway locations), but also to request and access data that is specific to their needs (e.g. subset of Hubway locations within a half-mile of my location) as well as to combine data from multiple sources (e.g. subset of Hubway locations within a halfmile of MBTA stops). This concept further empowers developers to make interesting tools that meet user needs. Specific needs addressed by this concept: Wayfinding is the concept of navigating between locations. This is aided by numerous kinds of data maps, route markers, points of interest, landmarks, transit routes, etc. The Enhanced Developer Portal brings together a number of these datasets under one roof and makes it easier for app developers to provide the public with access to this data. Makes it even easier for developers to build wayfinding tools that take advantage of multiple data sources Improves ease/feasibility of developing tools for wayfinding over multiple modes with multiple preferences Allows some influence on the types of tools that might be developed by facilitating certain types of cross-cutting of data Detailed Description This concept builds on the existence of a Developer Portal a webpage that hosts or links to datasets by providing additional functionality for select hosted datasets. Select static datasets would be accessible via a common API accessible through the web. APIs allow software systems to talk to each other, and in this case, would allow users to access aggregate, disaggregate, and even cross-cut data across 14

15 multiple data sources. An example of such an approach is WMATA s Transparent Data Sets API. Source: Without this API, developers making tools (e.g. smart phone applications) that use subsets of data (e.g. food trucks within a certain radius of a location) or crosscutting data (e.g. comparing multiple modes of travel and their cost between two points) have to develop their own method of mining aggregate datasets. Providing a common API for select datasets would make it easier for developers to work with those datasets in ways that are most relevant for the goals associated with CHB. Using a common API, developers would, in effect, be able to interact with a single consolidated data source instead of downloading and working with multiple datasets. Developers would register for an API key in order to use the API. This would enable identification of users and monitoring of data use. The Developer Portal would be enhanced to allow developer registration and to provide documentation regarding the use of the API. At first, a group of datasets that have been identified as important for making tools for CHB would be made accessible using the API. This would involve adding these datasets into a database and developing the API to retrieve data from the database in response to specific user requests. The database and API could later be extended as new datasets are identified, developed, or submitted. When the content of a dataset is updated, it would need to be updated in the database, but the API would not need to be changed. If the structure of an already included dataset changes, however, changes would need to be made to both the database and API. Therefore, this concept requires more resources for ongoing maintenance than would be included in a simple Developer Portal that only hosts or links to datasets in their original format. 15

16 Connect Historic Boston Information & Technology The diagram illustrates the different methods by which developers would access data through the portal. The first three methods are as available through the Developer Portal (defined separately): Developers could download static datasets hosted by the portal. Developers could navigate to, and then download, static datasets hosted at other websites. The portal would provide a link to the websites. Developers could navigate to, and then access, real-time datasets hosted at other websites. The portal would provide a link to the websites. The last method is enhanced functionality provided only by the Enhanced Developer Portal: Developers could access aggregate, disaggregate, and cross-cutting data from select static datasets hosted by the portal. Documentation for data would be hosted either on the Enhanced Developer Portal or would be available on the linked websites. 16

17 High-Level Requirements The Enhanced Developer Portal would have the following components: A webpage for data providers A webpage for system administrators A webpage for developers A Common API to allow developer-created tools to access data hosted by the Enhanced Developer Portal through the web, provided that they have a valid API key The Enhanced Developer Portal would provide all features and functionality of the Developer Portal (defined separately). In addition, the webpage for system administrators would: Allow system administrators to use pre-defined data import scripts to validate datasets and add them to a Structured Query Language (SQL)- based database Allow system administrators to update datasets in the database and edit pre-defined data import scripts Allow system administrators to monitor data usage via the Common API Allow system administrators to block API keys and cancel developer accounts In addition, the webpage for developers would: Allow developers to register for an account and API key in order to use the Common API Allow registered developers to access documentation regarding the use of the Common API Allow developers to access aggregate, disaggregate, and cross-cutting data from select static datasets made available through the Common API User Narratives These narratives are intended to provide a better understanding of how the Multimodal Itinerary Portal would work for the various users. In this case, users include those that interact with the front-end system (e.g. visitors, residents, etc.) and developers that use the data to make tools such as smart phone applications. All narratives are hypothetical and are not meant to represent real people, agencies, or data. 17

18 Enhanced Developer Portal Administrator The administrator identifies some datasets, including the location of NPS sites, Hubway locations and T entrances, for inclusion in the database and Common API based on their relevance and importance in terms of the goals of CHB. He contacts the data providers to inform them of the intention to include their datasets in the database and Common API, and hearing no objections, provides them to the system administrator. System Administrator A system administrator receives the datasets for inclusion in the database and Common API from the administrator. The system administrator develops and executes data import scripts to add the identified datasets into the database. She also modifies the Common API to access these datasets and the associated documentation. Developer A developer wants to add a feature to his wayfinding smart phone application to display the closest NPS sites and other places of interest from the user s location. From previous experience, he knows that the NPS dataset and other location information are linked to on the Developer Portal. When using the Developer Portal, he sees that there is a Common API available that provides access to the location of NPS sites, and that it provides access to NPS locations as well as other data in a very easy manner. In fact, the API provides exactly the cross cutting data that he is looking for it retrieves the location of the five closest places (e.g. NPS sites, Hubway stations, and food trucks) in response to a user s location and provides information on the specific kinds of places. Excited to get access to the data, he registers for a developer account and an API key. He reviews the documentation in detail and then focuses his efforts on building an even more advanced feature for his application the ability to toggle on and off display of interesting places around the user s location. 18

19 Implementation Steps Stakeholder Meetings The first step in implementing the Developer Portal is to achieve stakeholder consensus on the high-level system requirements. This ensures that the objective, alternatives, and constraints are thoroughly discussed and made clear at the very outset. Development of High-Level Requirements The second step is developing High-Level Requirements, which describe the overall system functionality without going into specific details. After stakeholder discussions, the High-Level Requirements will be written, reviewed, and will go through multiple iterations before being finalized. The finalization will happen only after a detailed discussion between major stakeholders to ensure that all needs are adequately covered by the system. Development of Use Cases The development of Use Cases is necessary to both refine the High-Level Requirements and to inform the detailed Software Requirements and Specifications. They identify the role of major stakeholders through graphic/text descriptions of how each stakeholder will use the system. 19

20 Software Requirements and Specifications The Software Requirements and Specifications will involve writing detailed text descriptions and requirements that convey the system functionality in detail and inform the development of software. This stage will also involve making decisions on development software and hosting software, as well as developing hardware specifications. Software Development After the Software Requirements and Specifications have been finalized, full software development can start. The software development team may follow different development methods depending on the stakeholder requirements and constraints. Software Testing and Debugging The Software Testing and Debugging stage is vital to ensure that software is tested at every stage and faults and errors are identified and rectified. Software Deployment on Production Servers The final step, once software has been completely tested and debugged, is to deploy the software on production servers. This allows for stakeholders to test it prior to it going live to the public. Population with Data/Seeding The database will be populated with data to provide developers with data prior to going live. Go-live The Developer Portal will Go-live and be open to the public. High-Level Opinion of Probable Cost What follows is a preliminary, high-level opinion of costs, which can vary widely depending on the ultimate design of the system based on the complexity of user and system requirements. The costs listed below assume that a Developer Portal for linked and hosted datasets has already been built without the API functionality. Capital Costs Software Design and Specifications Development: $30,000-$75,000 Software Development Costs: $105,000-$270,000 Hardware Costs: $0-$30,000 Annual Operating and Maintenance Costs Staff Administration Costs: $10,500-$16,000 Hosting/Maintenance Costs: $10,500-$30,000 20

21 Ongoing Roles and Responsibilities Host Agency The host agency would provide a system administrator staff person who would have the following additional responsibilities to the Developer Portal: Maintaining relationships with data providers and requesting updated data for input into Enhanced Developer Portal Managing development of data import scripts Validating datasets using data import scripts Managing developer accounts and API keys Managing, maintaining, and updating the Common API Monitoring data usage Administering web services The host agency would provide a webmaster staff person who would have the following responsibilities: Maintaining and updating the website Providing bandwidth Data Providers The data providers would provide a primary contact person who would have the responsibility of notifying the host agency when datasets are updated. Developers The developers would provide a contact person who would have the additional responsibility of managing the developer account and obtaining the API key. 21

22 22

23 Multimodal Itinerary Portal 23

24 Multimodal Itinerary Portal Vision To provide a back-end system and a demonstration front-end tool that allows users to create, share, and provide feedback on multimodal itineraries. The back-end system would include the ability to host the itineraries created by users, as well as to modify, organize, and rate them. A webpage front-end would provide the initial ability to interact with the system, performing all functionalities described. This system would be open and accessible using an API (described below), to allow for developers to create additional tools such as smart phone applications. Need/Motivation There are currently a wide variety of tools available with functionality related to wayfinding, route creation, and itinerary creation, as well as the ranking of routes or itineraries. Some examples include the following: The NPS app allows visitors to create their own itineraries and provides walking directions between sites Map My Run allows users to create and rate running routes and track their fitness Trip Advisor allows certain users to develop trip itineraries that can be rated OpenTripPlanner is an open source platform for multimodal trip planning and analysis Source: NPS Boston App for iphone Source: 24

25 Source: Source: 25

26 While these smart phone and web-based applications offer some functionality included in this concept, none of them provide all of the functionality in a single tool. The Multimodal Itinerary Portal would be a way of creating and saving multimodal routes between locations based on individualized itineraries. It would also allow users to compare routes based on preferences. The social aspect of sharing itineraries creates awareness and excitement around wayfinding and visiting sites in Boston. The Open Source philosophy ensures that any users of the data can freely use it for different purposes as long as they comply with some rules and restrictions. This allows easier access to the data by a larger population, and allows smaller businesses to viably develop great resources for the public. The specific needs addressed: Facilitates the creation, storing, and viewing of individualized, multimodal routes connected with destinations Generates interest and excitement around CHB s mission through social/interactive tool to review, assess, and rate Improves ease/feasibility of developing tools for wayfinding over multiple modes with multiple preferences Strongly influences type of tools that might be developed Detailed Description This concept allows users to create, share, and provide feedback on multimodal itineraries. The itineraries would include both locations visited and the routes used to get between them. The system includes two components: a back-end system and front-end tools. The back-end system, which would include a database and Application Programming Interface (API), would store and allow access to individualized multi-modal routes. The routes would also include relevant information such as origin and destination, modes taken, places visited, duration, etc. The front-end tools, which could take the form of websites or smart phone applications, would provide means to interact with the routes stored in the backend system using the API. As part of this concept, one tool, a web-based portal, would be built. The Map My Run website is an example of such a web-based, front-end tool. The portal for this concept would include a web interface where users can create and save routes, edit routes, and view routes created by other users. The functionality when creating a route would include the ability to mark the path on a map, the modes taken, places visited, and other relevant information. Additionally, users would be able to tag routes in order to organize them (similar 26

27 to how images are organized on Flickr or how videos are organized on YouTube). An API, or Application There would be search functions allowing Programming Interface, allows the user to find and view other users software systems to talk to each routes. Certain information would be other. In this case it would enable entered or calculated that could also the storing and display of this provide a way to assess routes such as information, as well as provide number of restaurants or sites passed by, access to this information by presence of stairs (indicating accessibility), developers. and cost per person. Finally, users would be able to rate and comment on other users routes. Users would need to register for an account and login to access the web-based portal. This system would be open and accessible using an API, so that other developers could create additional tools based on the system. In order to spark interest, initial seed routes could be created by partner agencies and made available, such as the Freedom Trail and the Black Heritage Trail, and itineraries like those accessible through the NPS app. Going forward, two further enhancements could be made to the system: 1) enable important routes (e.g. Freedom Trail) to be highlighted so that they are displayed prominently, and 2) allow users to pay to highlight or promote certain routes (e.g. a hotel tour, or a museum tour). 27

28 High-Level Requirements The Multimodal Itinerary Portal would have the following components: Back-end system that includes a database, server, API, and web-based administrator portal Web-based front-end tool The database would: Store itineraries including geographic route information, route starting location, end location, places visited, mode(s) taken, etc. Store tags, ratings, and comments for each itinerary Store user details and itineraries created by them The API would: Allow the front-end tools to communicate with the database. Only tools with a valid API key would be allowed to use the API Allow the following functions: create and edit user accounts; create, retrieve, or edit itineraries; and add or remove tags, ratings, and comments from itineraries 28

29 Limit functionality by pre-defined rules. For example, only logged-in users would be allowed to create, edit, tag, or comment on itineraries; users would only be allowed to edit itineraries created using their account; etc. The web-based administrator portal would: Provide a graphical user interface (GUI) with the following functionality for administrators: manage user accounts; manage developer accounts and API keys; and monitor data usage via the API Provide a GUI with the following functionality for developers: register for an account and API key; and allow registered developers to access documentation regarding the use of the API The web-based front-end would: Provide a GUI with the following functionality for users: create and edit user accounts; draw the geographic route for an itinerary on a map and enter itinerary details (such as starting location, end location, places visited, mode(s) taken, etc.); edit itineraries created by the specific user; view, search for, rate, tag, and comment on, itineraries User Narratives These narratives are intended to provide a better understanding of how the Multimodal Itinerary Portal would work for the various users. In this case, users include those that interact with the front-end system (e.g. visitors, residents, etc.) and developers that use the data to make tools such as smart phone applications. All narratives are hypothetical and are not meant to represent real people, agencies, or data. Front End User A visitor is planning her trip to Boston and is searching online for popular places to visit. She has some preferences: she is particularly interested in sites near water for the added benefit of ocean and river views; has limited time; and won t have access to a car. In her search she encounters a tool that is advertised as providing personalized itineraries that include transportation information. She visits the webbased front-end for the Multimodal Itinerary Portal and finds an itinerary called Boston Historic Sites and Ocean Views. The itinerary only includes sites near the waterfront and provides walking and biking routes to get from site to site. She follows the itinerary and has a wonderful time. She highly rates the itinerary the next time she is online. 29

30 Developer A developer is interested in making a new tool for visitors to Boston. She has heard of a system where it is possible to enter and store itineraries for visiting sites in Boston and the method of travel in between. After using the web-based front-end for the Multimodal Itinerary Portal, she thinks that it would be valuable for visitors to be able to track their route and locations visited in real-time on their smart phones rather than having to go to a website to enter their itineraries after the fact, by memory. She sees that the Multimodal Itinerary Portal provides an API and documentation. She requests and receives a developer account and an API key, reviews the documentation in more detail, and then starts developing her smart phone application. In her application, she builds functionality to allow users to utilize the GPS tracking capability on smart phones to automatically map routes, estimate modes, and identify stops, all of which can be updated and modified by the user. Implementation Steps 30

31 Stakeholder Meetings The first step in implementing the Developer Portal is to achieve stakeholder consensus on the high-level system requirements. This ensures that the objective, alternatives, and constraints are thoroughly discussed and made clear at the very outset. Development of High-Level Requirements The second step is developing High-Level Requirements, which describe the overall system functionality without going into specific details. After stakeholder discussions, the High-Level Requirements will be written, reviewed, and will go through multiple iterations before being finalized. The finalization will happen only after a detailed discussion between major stakeholders to ensure that all needs are adequately covered by the system. Development of Use Cases The development of Use Cases is necessary to both refine the High-Level Requirements and to inform the detailed Software Requirements and Specifications. They identify the role of major stakeholders through graphic/text descriptions of how each stakeholder will use the system. Software Requirements and Specifications The Software Requirements and Specifications will involve writing detailed text descriptions and requirements that convey the system functionality in detail and inform the development of software. This stage will also involve making decisions on development software and hosting software, as well as developing hardware specifications. Software Development After the Software Requirements and Specifications have been finalized, full software development can start. The software development team may follow different development methods depending on the stakeholder requirements and constraints. Software Testing and Debugging The Software Testing and Debugging stage is vital to ensure that software is tested at every stage and faults and errors are identified and rectified. Software Deployment on Production Servers The final step, once software has been completely tested and debugged, is to deploy the software on production servers. This allows for stakeholders to test it prior to it going live to the public. Population with Data/Seeding The database will be populated with data to provide developers with data prior to going live. Go-live The Developer Portal will Go-live and be open to the public. 31

32 High-Level Opinion of Probable Cost What follows is a preliminary, high-level opinion of costs, which can vary widely depending on the ultimate design of the system based on the complexity of user and system requirements. Capital Costs: Software Design and Specifications Development: $57,000-$106,000 Software Development Costs: $200,000-$365,000 Hardware Costs: $30,000-$60,000 Annual Operating and Maintenance Costs: Staff Administration Costs: $35,000-$80,000 Hosting/Maintenance Costs: $23,000-$43,000 Ongoing Roles and Responsibilities Host Agency The host agency would provide a system administrator staff person who shall have the following additional responsibilities to the Multimodal Itinerary Portal: Maintaining relationships with mapping agencies and ensuring base-maps are regularly updated Managing developer accounts and API keys Managing, maintaining, and updating the API Monitoring data usage The host agency would provide a webmaster staff person who would have the following responsibilities: Maintaining and updating the website Managing user accounts Providing bandwidth Developers The developers would provide a contact person who would have the following additional responsibilities: Managing developer account and obtaining API key 32

33 Developer Challenge 33

34 Developer Challenge Vision To host a challenge for the people and teams (developers) who can create the tools to realize the mission for technology in CHB. The Developer Challenge would inspire and facilitate the creation of demonstration projects and tools that show what can be done with available data to assist in wayfinding between NPS sites and transit stops. Need/Motivation This concept both inspires and facilitates the creation of tools that meet the needs of CHB, at the very least for demonstration purposes, as well as generates awareness and excitement around the availability of data and need for these tools. It would not only spark the interest of the developers of the tools, but also of funders and other partner agencies. Specific needs addressed by this concept: The Open Data movement s goals are to ensure that certain data are made available to the public freely and can be used for different purposes, as long as users comply with some basic rules and restrictions. This allows easier access to information by a larger population, and allows smaller businesses to viably develop great resources for the public. Promotes the development of tools relevant to CHB Generates interest, awareness, and excitement around the available data and tools being created with that data Detailed Description The Developer Challenge would be a competition targeting developers who create interesting and useful tools such as websites and smart phone applications (apps). These types of competitions typically take place over a short period, during which developers are tasked with creating a tool to solve one or potentially one of several specific questions or problems. Datasets relevant to answer those questions, as well as associated documentation, is typically provided as part of the challenge. Developer challenges have been held by numerous organizations, including institutions like Massachusetts Institute of Technology (MIT), agencies like the Massachusetts Bay Transportation Authority (MBTA) and Massachusetts Department of Transportation (MassDOT), and large companies like Google. 34

35 Source: Source: d=about The Developer Challenge would consist of a kick-off event to provide developers with all the information needed to participate in the challenge, a time period during which participants develop tools, and an awards ceremony. The kick-off and awards ceremonies would include speakers of interest and prestige, if possible, and would be promoted through media, social media, and lists. Partner organizations would be valuable assets in organizing the Developer Challenge. For example, an educational institution could provide space and resources for hosting the event as well as generate interest among students. 35

36 In order to generate interest and participation, prizes would be offered for the apps that best meet the criteria set forward in the challenge questions. Cash prizes, if possible, are appealing and can be seed money to further develop a tool. If cash is not available, in-kind donations from partner agencies, such as transit passes or Hubway memberships, could be pursued. Winners would be determined by a panel of judges who are familiar with the goals of CHB as well as have the technological knowledge to be able to assess developers' work. Because of the short timeframe of the Developer Challenge, the websites or apps created as part of the challenge need not be fully developed, complex tools immediately available to the public. Instead, the challenge would bring to the forefront a range of possible solutions to the questions. The best would be selected and showcased on the CHB website. From there, full-fledged tools could be created. The publicity around the event could help deepen the market for that tool, or inspire further development and refinement. Example of an App Showcase on the MBTA.com website (only a few of the showcased apps are shown): 36

37 Source: 37

38 High Level Requirements The developer challenge would: Be based on up to three (3) questions that are relevant to the goals of CHB and that are geared towards using available or provided data Be held during a time when developers with full-time jobs would be able to participate Be restricted to a pre-defined time period Include incentives, such as prizes Be publicized with the assistance of partner organizations and through the press The datasets provided for the challenge would: Be provided at the beginning of the event in electronic format or via links Be accompanied by documentation explaining the structure, format, and content of the datasets Include a mixture of different types of data, including transportation and points of interest data at a minimum The results of the challenge, including the tools created and the winners, would be showcased through the CHB website. Developer Challenges The following are two challenge concepts or questions that could be presented to developers at this event. These concepts should be modified before holding the event to reflect changes in the prioritization of goals related to CHB and data availability. 1. Comparing Modes What is the best way to travel between South Station and Faneuil Hall? Transit, walking, Hubway, a little of each? Google Maps provides the route and time for each mode separately, but does not allow easy comparison between them based on selectable criteria (such as time, cost, calories burned, etc.). Other real-time or preferential factors might be considered, such as whether there are actually any Hubway bikes available, or what a more attractive or pleasant walk might be (e.g. along the Greenway, even if it is a longer route). Challenge: Develop a website or smart phone application that can compare modes based on selectable criteria, using the following data provided as part of the challenge: National Park Service sites and historic points of interest MBTA station locations Links to MBTA real-time data Link to Hubway real-time data Sidewalk appeal 38

39 2. Where to Now? Some tourists are in the North End walking the Freedom Trail. They decide that they have had enough history for one day and they are ready to sit down for a movie or a bite to eat, or to do a little shopping before returning to the hotel. Some questions they might have are: Where are the busiest bars nearby? Where is the best shopping on the way back to the Green Line? And what is the best way to get there? Challenge: Develop a website or smart phone application that can answer multiple questions about where to go and how to get there using the following data: Same data as provided for challenge question #1 above Links to appropriate Twitter, Four Square, Scene Tap, Facebook, Yelp, Urban Spoon, event calendars at NPS, Bostonian Society, BSA, feeds for real-time suggestions of destinations Implementation Steps In order to carry out the Developer Challenge, these high level steps would need to occur: Refine questions and obtain data, links and associated documentation Finalize logistics of event (location, refreshments, schedule, etc.) Identify and obtain commitments from speakers Hold event Assess results Award prizes Showcase results High-Level Opinion of Probable Cost What follows is a preliminary, high-level opinion of costs, which can vary widely depending on the final details and logistics of the Developer Challenge. Staff time used for organizing event and updating website: $6,000-13,000 (assume full-time staff person for one to two months (may be spread parttime over longer period) Miscellaneous costs associated with event (publicity, location, refreshments, prizes): $1,000-$3,000 Ongoing Roles and Responsibilities The agency in charge of organizing the logistics for the Developer Challenge would have the following responsibilities: Providing a staff person with the primary responsibility of planning and promoting the event Developing relationships with partner organizations for hosting, promotion, and prizes Updating CHB website to include showcase results 39

40 Type of Description of Data / Data Name Information Notes Transportation Traffic Extensive traffic Information information is (counts, etc.) available upon request from the BTD and CTPS, including outputs from traffic sensors as well as modeling efforts. Transportation Signal location Locations and details and about signal information information in the City of Boston, available upon request form the BTD. Transportation Street Classification of Classifications streets and nodes based on certain criteria such as connectivity, multimodality Transportation Location of Locations of the stops Trolley Stops of the privately operated tourist trolleys. These are geocoded. Transportation Bicycle routes / Available from trails multiple sources, including Toole Design Group (TDG). Transportation Bicycle rack Online map showing locations the locations of bicycle racks installed in the City of Boston. Transportation Bicycle parking This is historical, not location and real-time data, about utilization (not bicycle parking in real-time) at around MBTA MBTA stations stations. Transportation Taxi Stop Map Simple map showing the various stops on City Water Taxi website. Unknown if available in other format Transportation Transportation Transportation Transportation Station locations and availability RMV crash database Flight information Water Transport Real-time information on number of available docks and bicycles at Hubway locations Detailed information on crashes in the City of Boston, used for metrics related to safety. Available in Excel format, not geocoded. Online, up to date information regarding flights for tourists. Maps and schedule information online to and from Logan Airport. Agency / Data Source Boston Transportation Department Boston Transportation Department City of Boston City of Boston Frequency of Update Ease of Availability Format of Data Moderate Moderate List / Document / Synchro Moderate Moderate List / Document / Synchro Relatively Static Relatively Static High High GIS GIS City of Boston Moderate High GIS City of Boston Moderate High GIS City of Boston MPO / CTPS City Water Taxi Moderate High GIS Moderate Unknown Image online Hubway Real-time Moderate Unknown MassDOT Moderate High Excel Massport Real-time Low- Moderate Massport Moderate Low- Moderate Online Online 40