Parking Inventory Management

Created for Parking - Austin Transportation Department

The new Parking Inventory Management Data that resides on GISMAINT1 must be viewed and edited using ArcGIS Pro. It is not accessible in ArcGIS 10.x since Attribute Rules within ArcGIS Pro have been set on all feature classes and table. Once the feature classes and table are exported from GISMAINT1, the data is accessible by ArcGIS 10.x.

Parking Data

  • Feature Dataset

    • Feature Classes

      • Block Segments (line)

        • ATD_ADMIN.block_segments

      • Parking Paystations (point)

        • ATD_ADMIN.parking_paystations

      • Parking Spaces (point)

        • ATD_ADMIN.parking_spaces

      • Parking Zones (line)

        • ATD_ADMIN.parking_zones

    • Geodatabase Topology

      • ATD_ADMIN.Parking_Topology

        • Feature Classes

          • ATD_ADMIN.parking_spaces (rank 2)

          • ATD_ADMIN.parking_zones (rank 1)

        • Rules

          • ATD_ADMIN.parking_spaces - Must Be Covered By - ATD_ADMIN.parking_zones

          • ATD_ADMIN.parking_zones - Must Not Self Overlap

          • ATD_ADMIN.parking_zones - Must Not Self Intersect

    • Relationship Classes

      • Block Segments related to Parking Zones

        • ATD_ADMIN.block_segments_zones_rel_class

      • Parking Zones related to Parking Restrictions

        • ATD_ADMIN.parking_zones_restrictions_rel_class

      • Parking Zones related to Parking Spaces

        • ATD_ADMIN.parking_zones_spaces_rel_class

  • Table

    • Parking Restrictions

      • ATD_ADMIN.parking_restrictions

Attribute Rules

  • Unique ID Field

    • A Unique ID Field is required for all data that will reside on GISDM (not OBJECTID)

    • When a new feature is added to any feature class or table, the Unique ID field for that layer is automatically coded.

    • An Attribute Rule has been created on each feature class and table to code the Unique ID field using a database sequence table (atd_parking_data_sequence).

    • The database sequence table increments by 1 each time and is triggered when a new feature is created in all feature classes and table listed below.

      • ATD_ADMIN.block_segments - BLOCK_SEGMENT_ID

      • ATD_ADMIN.parking_zones - PARKING_ZONE_ID

      • ATD_ADMIN.parking_restrictions - PARKING_RESTRICTION_ID

      • ATD_ADMIN.parking_spaces - PARKING_SPACE_ID

      • ATD_ADMIN.parking_paystations - PARKING_PAY_ID

  • Parking Restrictions Rules

    • Time Limit

    • Monday Hours

    • Tuesday Hours

    • Wednesday Hours

    • Thursday Hours

    • Friday Hours

    • Saturday Hours

    • Sunday Hours

  • Spatial Features can be related 2 ways

    • Example: Create a new Parking Zone, it will need to be related to a Block Segment

      • Add Selected Record to Relationship

        • Parking Zone is selected, select the Block Segment that the Parking Zone will be related to, right click Block Segments relationship that is under Parking Zones in the Attribute Table Window, Add Selected to Relationship.

      • Manually

        • Enter the BLOCK_SEGMENT_ID for the Block Segment that the Parking Zone is located along to manually create a relationship in the Parking Zone Attribute Table.

  • Tabular Data - Parking Restrictions Table related to Parking Zones

    • Select Parking Zone, right click on Parking Restrictions relationship that is under that Parking Zone in the Attribute Table Window, Add New to Relationship.

      • A new record will be created in the Parking Restrictions table that is related to the selected Parking Zone. Code the attributes for the Parking Restriction using the Attribute Table Window.

  • Automatically Selecting Related Data

    • Within the Layer Properties for each feature class and table, related data can be automatically selected. This choice is available under Selection.

    • Having this box checked on all feature classes all the time may cause confusion as some feature classes are related to multiple feature classes (ex: Parking Zones are related to Parking Restrictions and Parking Spaces).

    • Example below Parking Zones are set to Automatically Select Related Data

      • 1 Parking Zone is selected

      • All relationships are available with the Status set to show Active and Retired records

      • A definition query can be set to hide Retired records or visa-versa.

Tracking Changes

  • All feature classes / table have the STATUS_TYPE field included in the attribute schema, which can be coded to Active, Inactive or Retired.

  • When a new record is created in all feature classes / table, the STATUS_TYPE field is automatically coded to Active.

  • When a record is no longer valid, change the STATUS_TYPE field to Retired and code the Retired Date in the RETIRED_DATE field.

  • Records are never to be deleted so a history of the parking data remains in tact for reporting and analysis.

    • Parking Restriction only change (tabular):

      • Current Parking Restriction in table is set to Retired, date of retirement recorded

      • New Parking Restriction is created, related to Parking Zone, and set to Active

    • Parking Zone change of any type - splitting or combining

      • All must be Retired - Parking Zone(s), Parking Restriction(s), Parking Space(s) in order to keep the relationships in place.

      • Parking Pay Stations and Parking Meters only need to be retired if they are moved or removed as they are not related.

Last updated