Data Conversion, Maintenance and Scale

Notes on the Breakout Group
Kevin Curtin, Janine Gottlieb



 

Participants

Marion Storey (City of Philadelphia, Streets)
Robert Cheetham (City of Philadelphia, MOIS)
Jim Querry (City of Philadelphia, MOIS)
Bjorke Brun (ScanRail Consulting)
Lee Samson (Wisconsin DOT)
Jay Sandhu (ESRI)
Peter Morey (Minnesota DOT)
Kevin Curtin (UCSB)
Todd Crane (GDT)
Frank Winters (NY DOT)

3 Main Points were generated by this breakout group:

1.  Diagram

Initial Data Maintenance Object Model

 2.  Characteristics of a maintainable data model:

 3.  Inverse relationship between table complexity and graphic complexity

Other notes from breakout session:

Brainstorming/Figuring out priorities and issues

 *metadata
  model
  data
 *scale
  content (aggregate/disaggregate)
  precision
  generalization
  use visualization analysis
  cartography scale dependency and/or analysis scale
dependency
  analysis on a different scale than you're rendering

 *"does an intersection object know how to draw itself at different scales?"
 *"do we need to think about data models that work at different scales? i.e. data models that are smart enough to handle different
renderings?"
     or:
 *"do we just worry about whether or not an intersection object knows how to represent itself?"
 *"do we just have a data model that is more simplistic?"

 *where does CAD leave off and GIS take over? is this something we need to be concerned with?

 *route calibration tools ------> LRS

 *how to address that the way in which things are modeled determines whether or not something's dynamic

Definitions

Maintenance
  model must support or produce tools that promose/allow edits to features and relationships between features (and this will go to scale)

Example:

Issues: Possible solutions for the centerline file problem? Question:

  Robert Cheetham -- do each of the segments of the model need a time stamp on them?

What data are we trying to model? i.e., what's on your basemap

 1. Capital Improvement  2. Roadways  3. business data
  eg. 5 tables with 100's of pieces of info about each bridge
  *****maintain hooks to the business data****

Change Group Model (for making changes to a base map)

Problem:


The slider bar example -- table complexity and graphic complexity:

 there is an inverse relationsihp between table complexity and graphic complexity
  simple geometry w/ very complex attributes -- e.g. turn tables for bridges, 1 way streets, divided highways, etc.
  complex geometry w/ simple attributes -- e.g. turn tables only for "no left turn" and other arbitrary road restrictions
 which way do we want to go?
 

Metadata

Object level metadata (transaction log at object level) vs. layer level metadata (level currently supported by ESRI)

UNETRANS home