Tour IMPDB Web Map and discuss Access / Moped project data

[amenity]

From NW:

MOPED Team,

We have now published the Interim Mobility Project Database Webmap that I previewed at the last MOPED sprint to ATD and shared with Mobility Annual Plan (ATD, CPO, and PWD) AGOL users. Dylan on our team did an amazing job building up the viewer.

I think it would be good to walk the MOPED team through the tool (if you dive in to the tool make sure to play with the filters by project phase, sponsor, personnel, mode, etc.). I would also like to talk about and talk about the implications on MOPED regarding the scale of current tabular and GIS data on projects across divisions, migration strategy, visual presentation of mapped data and interactivity, and current business processes in use by programs. Having all this GIS data easily accessible online in an interactive format makes both the value of the data and the sensitivities with the migration more transparent.

Would y’all be up for setting up a meeting to discuss? I didn’t have access to JD’s calendar and I’m guessing that there are some others on the team that are working on the visual presentation/mapping piece as well that would be good to include.

Thanks,

Nathan

[amenity]

@mateoclarke, adding you as optional here — feel free to pass to another dev or bow out.

@johnclary should Jaime join as well?

cc/ @zappfyllc — this is happening and you're excused. ;)

[amenity]

Layers

• Most project data is maintained by ATSD, 10 designers, and include data to establish and track metrics, e.g. "widget counting"

• 99% of projects in IMPD are mapped

  • Use project extents where individual facilities aren't mapped

• Existing Bike Facilities doesn't always match other Access data; maintained by DTS

• Vulnerability to Gentrification — from Planning and Zoning (?)

• TED lapsed into spreadsheet mode in Excel and not mapping projects; Dylan caught them up and they re-on-boarded

• Safe Routes — Aleksina maintaining, clustered by project

Move to AGOL

• Editing locks problematic on file Geodatabase
• Realtime join doesn't hold up
• Access controled via AGOL permissions group — not connected to Outlook.

Concerns with polygon geometries

• Cartographic representation
• Should be able to click on something and see the whole thing; with polygons would have to concatenate
• Presentation purposes, e.g. PIO, is need maps that more closesly depict real world infrastructure
• Need to be able to freehand draw no matter what to document potential projects

Concerns with freehand drawing

• Not ideal for signals, crossings, etc.
• Data quality
  • Could have regular audits and/or involve DTS Geo Team
  • Point layer that's editable and instructions to users on

Project limits vs facilities components

• 2016 Bond learning: every program works differently
• Workaround of "Project Limits" as a component type avoids redundant/conflicting data

Concerns with data coming from Moped into Viewer

• Project development will ratchet up significantly w/ Prop B will increase spend rates 2x peak spend for sidewalks, bikeways, etc.

• Filters work well without custom programming if everything is on the same layer

• Merging projects is a nightmare; Manuel only maintains part of the data

• Current application meets all needs

• Projects cross divisions, analysis and reporting is done w/ TXDOT and CTRMA data

So ... What can be moved out of Moped MVP scope?

• Cost estimates
• Geometry definition via authoritative geometry

[amenity]

Debrief with @zappfyllc @johnclary 10/7 Instead of onboarding users for production work in Moped Alpha & Beta, get everyone into Access and then performa mass migration.

Risks:

• The more people we bring into Access, the higher the
  • Complexity of the ETL
  • Volume of data
  • Immediate, simultaneous user support needs when we go live
• Worst part of VZ system is reconciliation between various databases — this needs to be a migration, not an integration

Mitigation:

• Continuous usability testing with a diversity of users
• "Freeze" IPDB data model

Points vs Polygons vs Lines

• Representing signals as lines (currently done as circles) is not ideal
• Can't store points and lines in a single layer; would need a shared table, affects performance
• Could train people to use snapping to center

Thinking about Signals going into AMD... Will be interesting to see if this can meet Renée's needs.

• Can components can belong to multiple projects?
• Can projects belong to projects?