1

Statewide Centerline Initiative Pilot Kick-Off Meeting MnDOT District 3A Headquarters, Baxter, Minnesota Monday, May 13, 2013, 9:00 AM – 3:00 PM Summary Meeting Notes

Notes for Clarity: Items highlighted in red would be a likely candidate for a use case; Items highlighted in blue are foundational assumptions about the project and work flow; Items highlighted in violet may be categorized as project requirements;

Attendees: Perry Clark, Carver County Gordy Chinander, Metropolitan Emergency Services Board Dan Falbo, ESRI Kelvin Howieson, MnDOT Matt Koukol, Ramsey County Teresa Leiste, Benton County Brent Lund, MnGeo Geoff Maas, MetroGIS Chad Martini, Stearns County Peter Morey, MnDOT Jesse Pearson, MnDOT Paul Peterson, MetCouncil/MetroGIS Nate Rose, Stearns County Dan Ross, MnGeo Dawn Sherk, White Earth Nation Jocelyn Stein, MnDOT Gary Swenson, Hennepin County Burny Tibbets, White Earth Nation Paul Weinberger, MnDOT Brad Wentz, North Dakota State University Gary Waters, ESRI Tom Brenneman, ESRI (remote access)

1 ) Meeting Introductions Participants introduced themselves and the agency they represented.

2 ) Brief Overview: Project Context and Progress Up To The Pilot MetroGIS Coordinator Maas welcomed and thanked the participants for their attendance and interest and presented some context as to how the project originated and developed to its current status.

3 ) ESRI Overview and Tool Demonstration Dan Falbo (ESRI) prefaced the tool demonstrations with encouragement to the participants about how Minnesota is addressing the centerline issue: as a comprehensive asset management strategy, working in a spirit of collaboration, deploying technology solutions for multiple agencies to work with and how approaching the problem in the way that we are is revolutionary on the present national scene.

Gary Waters Presentation: Gary Waters (ESRI) provided a presentation on the lead up to the tool development; Waters referred to the statewide centerline solution that meets all the expressed needs of the user communities as the ‘Holy Grail’, difficult, challenging and something to strive for.

2

Waters cited the importance of the recent MAP21 Legislation; by June 15, 2015 state transportation agencies must report all public roadways. These requirements combined with MnDOT’s desire to improve its data capture and business processes have been the strong initial drivers of the project. In February 2012, the first ESRI ‘redlining’ products were introduced; since then ESRI has been continually working to address and deal with functional issues faced by users such as is the data time aware; able to capture past, present, future roadway assets? Working to address ways to more easily integrate data and keep data synchronized; syncing up the business systems with the linear referencing systems

Key Goals of Redline Tool Approach:

Even though it is still in refinement, it will serve to provide a solid set of tools for GIS users of any skill level, but also support the work of more sophisticated and experienced GIS users;

Serve as a gateway for a local user to synchronize their data with MnDOT; allows a non-persistent integration system. Verification > last sync data > respond back with all the new routes > pass back the route and measure changes; allows a non-persistent integration system;

The ‘time stamp’ features will allow you to see what the road network looks like at any time in the past;

Emphasis on services-oriented architecture;

Highly configurable; COTS Business System Integration;

Provide capability to drag-drop spreadsheets;

ESRI Partner Vendors: ESRI identified several of its business partners assisting with the tools: Transmetic: Traffic counts, Auto Traffic Recorder data (business partner) VueWorks, Agile Assets, Transcend Spatial Solutions; providing add-ons, etc. will keep end users from having to build additional tools;

Data Model Considerations: Envisioning a multi-user, multi-contributor data repository; The data originates at the locals and feeds up to the federal level; Ability to house all the ‘raw data material’, large body of data for many functions; Enables users to extract what is needed to perform routing/geocoding/etc. Collaborative environment for building a solution for the needs of the local, county, regional, state, federal users;

Tom Brenneman: Tool Demonstration Presentation: Tom Brenneman (ESRI) provided a demonstration of the ‘red line’ tool interface as well providing an overview of the ArcGIS Server Extension for Roads and Highways: key features enable the editing of events along routes, web application functionality and the standard GUI tools such as pan, zoom, etc.; diverse kinds of attachments (pictures, legal documents) can be added to the work flow;

3

Other functionality includes the ability to modify attributes, provide time-stamping, the intention of the tool is for the work to be quick and intuitive.

Configured Permissions: Configured permissions editing menu can be set up for allowing editing access only authorized users; The data can be visible by all users, but not edited by all users, several levels of security and control can be established; can be refined for the unique requirements of the user/agency; Clear ability to lock down “who can edit what”;

Local and state roles: Local jurisdiction would create the redline/upload its geometry, add in the relevant data/attributes; MnDOT would then ingest/conflate/adhere to the LRS, etc. Clear roles for ‘who does what’ from start to finish There will be many levels of interaction from a user using the red line interface to the back and forth verifications, conflating and adding data, discrepancy resolution, returning the data to the locals to test, long-term single system integration;

Workflow Manager, Data Reviewer and Production Mapping; These are built and supported by ESRI

Provide prompting after a task for the next task to be executed;

Ensure continuity of process and work flow;

Return messaging when tasks are completed;

Clear path to next task/eventual completion; Work Flow Manager: Toolset for the automation of business processes Automated notices for starting/continuing workflow; Data Reviewer: Provides quality control processes, automation of quality checks and controls Production Mapping: Set of cartographic tools for data visualization and output;

Comments: Eventually the Federal Transportation Administration will require more info about roads than they presently do; Ability to capture Certified Mileage in this data model would be helpful; Pilot project will help set up what attributes are to be tested and what domains they need; At what point will address ranges be added and will there be the ability to recalculate address ranges? Most desired outcome: Only the authoritative source would be allowed to enter and edit address data, however, everyone would be able to output/use that data. Local ranges may turn into an event (on the LRS) when pushed to the state level.

4

Fundamentally it can be thought of as a “cloud’ environment” MnDOT will host the environment; Locals will edit and promote their data to that system; Controls will be in place to ensure the authoritative sources/locals are editing the data they control; You work together, but retain the rights to manipulate and control your own (agencies) data; Local jurisdictions will have different needs for their own data The Statewide Centerline is the ‘common denominator’ of interaction among participating agencies. Core attributes are entered by the authoritative jurisdiction. Essentially there will be two editing work flows in play: Attribute set: Data from multiple tables is drawn together in one interface; Editing set: Will have a different work flow; The editing environment is likely not the same as the reporting environment; The technology is not a problem, the tools are getting more usable and sophisticated and MnDOT will host the entire piece, a key task we need to define in this early phase is defining the workflows presently in place with the local participants and what level of sophistication they are operating from. Features class will have ‘to and from’ dates on it; provides the ability to query historic data/conditions;

4 ) Pilot Project Roles and Responsibilities Paul Peterson (MetroGIS) and Brent Lund (MnGeo) provided an overview of the roles of the participating agencies to date and their anticipated roles moving forward.

Remaining and on-going work for the project managers;

Working to pin down the specifics on what the locals need to participate fully;

Data loading and retrieval;

How to collect and address feedback from the participants;

Ensuring local participants internal IT resources are satisfactory;

Setting up project requirements;

Meeting and check-in schedule for all participants; Jocelyn Stein (MnDOT) provided an overview of the project timeline as currently understood; General acknowledgement that there are some significant unknowns and ambiguity in the schedule; MnDOT has applied for additional funding for internal consultants and for outreach work Peter Morey (MnDOT), Matt Koukol (Ramsey County) and Dan Falbo (ESRI) described the three levels of use of the participant user groups: (1) Non-GIS Level This would apply to cities and counties with no current or very limited GIS capability including those who Cities/Counties: with no GIS, still interact with paper mark-up maps in reporting to MnDOT. The redline tool would offer them the functionality and options to enter, edit, correct, attribute and promote their data to MnDOT.

5

(2) Intermediate Level: This would apply to small or emerging GIS departments; they can augment their existing work with the red line tools; (3) Advanced Level This would apply to large or advanced GIS departments who have the ability to register their own data to the LRS and manage their own LRMs in the system; advanced users may require additional tools (this remains to be determined)

Project Time Line Discussion: Present priority is the Transportation Information System to Linear Reference System (TIS to LRS) conversion; this conversion is a pre-requisite for significant aspects of the Centerline Initiative; The internal MnDOT LRS needs to be solidly in place before the external ones can be added to the project. The present timeline of July 2013 for locals to have their data included was generally agreed upon to be too soon, a September or later goal might be more workable. While MnDOT desires that the data coming in from the local participants be as clean as possible, they will take it wherever its quality is. Key re-occurring questions are: What are the work flows? A better understanding of how the local governments perform, verify and attribute their data. This will not be consistent among all local units; to be documented as part of the pilot/proof of concept; Testing use cases (addresses, adding features, amending features, etc.) during the pilot will reveal how different they are among the local jurisdictions. State Aid Length and TIS Lengths are different; resolving this would be very beneficial to the locals. There is no longer a need for separate lengths; for calculated versus actual lengths; How does the data come back to the locals? Will we covert all of our data to a standard statewide coordinate system? Data needs to be submitted to MnDOT in UTM Zone 15 N Extended (or include a projection file in not in UTM Zone 15 N Extended)

6

5 ) Core Data Items Geoff Maas (MetroGIS) and Peter Morey (MnDOT) detailed for the group the list of HPMS (Federal Reporting) requirements that MnDOT needs to meet and the full list of desired attributes which emerged from the prior workshops, meetings and discussions Group discussion on the ability of MnDOT/local jurisdictions to collect, complete and provide those attributes if they are going into the state system. Emphasis turned toward the ‘core’ requirements: the ‘must have’ (foundational core) versus the ‘nice to have’ (desirable, but not required for federal reporting or core functionality).

6 ) Tool Requirements At present either marked-up paper maps or vector geometry are submitted to MnDOT for reporting; If locals are maintaining their own data, how do they keep their changes reconciled?

Requirements Identified: 1 ) All local actors need a consistent way of registering their local data to the tool; 2 ) The need for replication tools; 3 ) Some locals actors already have the ability to manage a local LRM

What is the present process for counties process to get data to MnDOT

Old method (paper maps reporting) Red Line (Submitted via to the redline toolset) Sophisticated Method (redline toolset or something more advanced)

New tools would bring everyone up to at least the same minimum level, with better data as the result. Benefits to counties: Ideally, as a participating county you would not have additional work, but would gain additional capabilities because more data would be available to your system. Essentially, MnDOT is asking you to take control of the data, but asking you to then ‘park’ that data in a centralized environment; this is a departure of current practice. During pilot project, we will need to fully understand the current business processes in the counties This is key to understanding what is required to get us where we need to be; it’s ok if things aren’t perfect at the local level, we just need to know how things work there; Lots of potential for the redline tool approach, may wind up in the hands/use of various departments and professionals: red line for pavement management, for safety considerations, etc. etc. Ideally you want roads in the system before they are built (planned, platted) for 911 response. As soon as a road is open to traffic it needs to be in the system for safety/crash reporting; does not need to be perfect, the geometry and attributes can be corrected later. Date stamping upon introduction into the system, date stamping corrections, etc.

7

With communications and noticing, making use of the Workflow Manager is crucial, perhaps engaging in Level of Service Agreements with clear descriptions of response timelines to keep things moving: Possible examples of Workflow Manager notices: URGENT : 24-48 hours to respond; road to be added to emergency response network; COMPLETE: 2 weeks to respond; Construction about to finish, ‘road open’ date is known; PLATTED: 3 months to respond; plats are filed/approved, construction is imminent; PLANNED: 6 months to respond; road in planning phase; final geometry not needed yet; Etc.

Acknowledged Shortcomings of the Pilot Project as presently under discussion: The ideas and the energy for the project is all well and good, however, in reality: We are discussing tools that are still under construction; We are talking about workflows that are vague and undefined; We are talking about a volume of work that is large in scale, needs to be made more realistic; We need to define and deliver a reasonable and workable scope that can be enhanced later; We need workflows that are realistic and fit the needs; We first need to test if we can submit our updates to MnDOT in a way that we do not presently do them. Example: Can a county go in and edit five or six attributes and then pull them out and look at them again and verify that changes we’re made and the data is usable; Do we need to differentiate between what aspects of this project are only good for MnDOT and which ones directly benefit the local users? Locals have to do addressing, but MnDOT has no business need to do it, however, we all benefit by doing it well and carrying it forward as part of the final resource. See this as a great opportunity to add in functionality to add business practices for future capacity for all users of road data; counties and cities would have the functionality of the LRS available to them.

Use Cases: Non-Public Roads: Does the collection and publishing include getting all roads components, entering private roadways, trailer park routes, mall roads, other special routes that do not show up in the system. We need to develop some basic use cases: Identify the basic steps based on what you do in your ordinary business process What do the engineering departments do? What do they need back? What role do the surveyors play in adding to the system? What do they need back? What aspects are entirely within the GIS department? What does public safety do? What do they need back? How do you add your addressing/routing data in? Etc.

8

For a revised scope, the project team will need to select and define some specific use cases to work on with a longer term vision; need a core set of functional use cases to build upon. Variety of use cases, need to pick when we work on them: All locals have to submit data for the HPMS (HPMS Use Case) Locals need to manage addresses in the system (Address Use Case) State Aid Roads need to be dealt with (State Aid Use Case) Creation of a new road feature (New Road Feature Use Case) Modification of existing road feature geometry (Geometry Modification Use Case) Modification of a road name, lengthy, route (Data Modification Use Case) Transfer of a local road to state control or state to local control (Owner Transfer Use Case) Dealing with platted, proposed and retired roadways (Use Cases) MnGeo will be assigning a Business Analyst to specifically work on defining the use cases. Three major considerations to guide the project moving forward: (1) Is it providing timely access to the data to meet your internal business need? (And what does timely entail? May be very different depending on what is needed…) (2) Maintaining and assuring the autonomy of the locals to work and retain control of their data; Assuring that those who should have access do, and quality control to ensure it remains in the hands of those who are responsible for it. (3) Elimination of redundant processes. Locals do not benefit by having to submit the data and then not be able to capture it back enhanced and have to maintain a local system as well.

Needs Discussed: Need to provide examples of how adopting and using an LRS will benefit each county

What are the benefits of an LRS to each participant?

Project team needs to improve the communication and the outreach;

Project team needs to reduce and tighten up the project scope;

7 ) Data Conflation Issues MnDOT Has developed some scripts to conflict route ID and measure onto the local geometry. Code to automate that, MnDOT calibration onto the local system, can do it visually. Not a huge process to conflate the remaining counties Data conflation leads to the need to clarifying the assumed roles of the authoritative sources;

State will maintain the geometry of Interstate, U.S. Trunk Highways, State Trunk Highways;

Local jurisdictions will maintain their road networks;

Special jurisdictions (Tribal Units, National and State Forests, etc.) will maintain their networks;

Need clarity on responsibility for private roads, special road instances (park districts, etc);

MnDOT would retain control of the point where a local or other system road accesses a state road (locals in some cases may have better control points available)

9

MnDOT would likely need to assume responsibility where two county roads touch (edge match) or where a road forms a county boundary.

In Maryland, the state maintains the touch points; need a clear standard practice for carrying forward and resolving discrepancies;

Key Point: Conflation may arise as the most resource-intensive in the entire project; Standardized approach to the morphology of road features will impact the conflation process: Need to have the discussion of uniform treatment of features in the system Dual Carriageways: We will need to define a standard for divided and undivided roads This is part of the new HPMS requirements and we need to define it statewide; avoid having many unique situations, minimizing special cases to the extent possible. Intersections: Need clarification and standardized approach to defining how intersections are handled Simple and complex intersections, roundabouts, clover leaf, etc. ESRI has a robust intersection tool; complex intersections are dealt with as a series of segments. Gary Waters (ESRI) indicated in his research there are seven (7) different methodologies at work in various states so far on how features are represented, something to work on as we progress; End user consumption of road linework/networks may differ than inputs; Gordy Chinander (MESB) suggested that emergency dispatch agencies generally make use of single-line features in their computer aided dispatch. Need a clear, defined set of conflation rules as we move forward; may not an easy thing to develop from the beginning without tackling a few real-world examples, it may need to develop organically as we encounter the issues; There are other layers of data completely outside of roads that will be dependent upon how the roadways turn out (Census data, school district boundaries, etc.), many other layers could potential impact or be impacted by the roadways. The ability to conflate state and local data together would be very beneficial long-term, saving us all a lot of extra work; need to develop these rules so they maintain the integrity of the system, are consistently applied but are flexible enough to accommodate situations as we encounter them; Gary Waters (ESRI) suggested the group consider the conflation tools offered by GeoCom GEONIS Street Network Manager: http://geocom-informatik.de/en/geonis-street-network-manager GeoCom Contact: Kees Van Loo, k.vanloo@geocom-informatik.de

10

8 ) Final Discussion Issues Note: Agenda Item 8 was originally designated for ‘Processes’ however, many lingering questions, needed points of discussion and clarification led the group to change it to an open discussion and presentation of key questions. Testing for Use Cases and Attribution: Suggestions for Use Cases: Perhaps we only test one attribute per participant to keep things manageable: For example we only test addressing in one participants’ dataset; perhaps they partner with DPS/Emergency Services to make sure it meets that need; Another example: perhaps we only test edge-matching in Stearns and Benton Counties; Caveats:

Legally defined border is in the river;

Do we treat bridges as an event?

Where on the bridge do we place the boundary? Even with simple examples such as this, we very quickly get ‘into the weeds’ on how to define things; Edge-matching in concurrent jurisdictions is important too (White Earth Nation/Mahnomen County) Disagreement on that Approach: Eventually we all have to work with the data, might be best if we all test each use case example even if we don’t’ need it immediately ourselves, supports the larger project aims. Even if you have no one way streets or roundabouts in your jurisdiction, it is still valuable for you to create them, test the tools and report on how they work; we will all have to edge match, we will all have to deal with addresses, etc. Local vs. State Practice: Managing Differences: How do we handle local attributes that will not be boosted or hosted on the state system, has values to the locals, but not to be managed/stored in the state system? As we work with locals to understand their current business needs/practices we need to carefully document how they align and how they differ with MnDOT. Final Assumptions and Moving Forward: We are really talking about two separate, parallel but ultimately related projects: The TIS to LRS Project is one, the Pilot/Proof of Concept Centerline Initiative is the other.

11

Dan Falbo (ESRI) indicated that we may be better served by re-defining the project as a ‘proof of concept’ rather than a full ‘pilot’; a proof of concept gives you the change to explore the assumptions without risk; a pilot should be dovetailing into final production; The first six months does not have to yield any final data, we should just be testing the data, testing the tools, documenting what we find in terms of what works, what doesn’t; just getting the lay of the landscape in terms of what the obstacles are and listing them out to be dealt with later. General agreement that simplicity, clarity and a small and useful scope are vital in the initial phases: First, we agree that there are three sets of users groups, Non-Tech/Non-GIS, Intermediate and Advanced; we get an understanding of their internal processes, needs and present data condition, get them the tools and get them comfortable with working with them; Second, we select the core attributes we want to try out and work with; perhaps we are best served by just focusing on the HPMS requirements for the first phase of the proof of concept Third, participants use and test the redline tools and the Roads and Highways in the test environment, perhaps not even using data intended for final upload to MnDOT, just get some data in there to try things out, doesn’t have to be final or perfect, just workable. After determining the ‘high points’ of that exercise, we can put together a more detailed set of instructions and requirements back to ESRI on how to modify their tools and to MnDOT on what to expect. Key remaining questions and issues: What is the pilot trying to accomplish? Partners and participants can see the value of the final product; however, it is presently unclear how we are going to get there. We see the value, but there are more questions than answers based on what we’ve seen today. Are the locals just engaged in this project simply to replace our current process with MnDOT? Can the locals work with MnDOT to better assess where they are and confirm for us better what we need to do? We (local jurisdictions) are excited at the prospect of the project and its implications, however, based on today’s discussion it is not clear how we are going to get there. Questions to/Tasks for the project team:

Develop better outreach materials for what an LRS is and how a local jurisdiction would benefit from using it;

Clearly list the high level goals that all the participants understand and can see the benefits of;

Tighten the project scope into more manageable sections;

Develop some concrete goal and objective language for the various phases of the project;

12

Gary Waters (ESRI) encouraged the project team to get their goal and objective language completed as soon as possible, this will help ESRI’s work in meeting the stated needs.

ESRI/MnDOT to have the ‘parallel environment/test area’ up and ready for locals to test and work with

Develop a list of needed what kinds of issues need to be standardized statewide o Geometry/Topology considerations o Addressing and Road Naming Conventions o Edge matching rules that apply statewide for consistency