Mountaineer Consulting inc.
About us Platforms Clients Staff
  Clients Oncor Eversource SRP SRP City of Chandler, AZ City of Mesa, AZ Nye County, NV Contact us
About Us


  • Oncor
  • Eversource
  • TEP
  • SRP
  • City of Chandler
  • City of Mesa
  • Nye County

    Contact Us

  • Mountaineer Consulting at City of Chandler, Arizona:

    City of Chandler Home

    GIS Landbase Database:

    • Delivered a logical and physical GIS landbase database design after performing requirements discovery. The design is very nearly fully normalized for ease of data maintenance. It is Parcel-based and models all cadastral features of the City's interest including situs addresses. Features are related using many-to-many intermediate join tables and one-to-many foreign key relates. The design is flexible enough to model all cadastral phenomena that the City must study - it models the cadastre "the way it is" rather than "how it should be".
    • Wrote functional specifications and developed an object model for an application designed to maintain the delivered GIS landbase data model.
    • Designed and documented a landbase data maintenance process which is integrated with pre-existing City processes dealing with paper and electronic cadastral data as well as City - County interaction, i.e. developer plan approval and recording processes.
    Powered by MapObjects

    Implemented System Design:

    The system utilizes ESRI's Spatial Database Engine (SDE) on an underlying Oracle RDBMS running on Windows NT. The maintenance application employs ESRI's MapObjects and Microsoft's Visual Basic.

    System Features:
    • Modularity: The landbase maintenance functionality resides in a DLL comprised of Landbase Objects (Class Modules) and Object Editors (Forms) corresponding to each landbase feature with common and utility functionality residing in modules (Standard Modules) organized by functionality type. The GUI is an executable that acts as a container for the Landbase DLL and the CityMapViewer which is a MapObjects component (OCX).
    • Long Transaction Management: Data is pessimistically locked into WorkSets which are children of Projects that can have any number of subordinate WorkSets. Data in WorkSets are in separate tables that are posted to the Master tables after a series of State Changes. Afterward, there is a post-final state at which a Project and it's WorkSets are Retired. Upon retirement, the WorkSet data is posted to Master again and also posted to History tables. Only data maintainers can view WorkSet data. The City GIS users view only the Master data. There are plans to utilize the History data when it becomes significant.
    • Automatic Relationships: Feature relationships are forged based upon spatial relationships. Except for a few ambiguous cases where a human must make a decision, the data maintainer only needs to locate features accurately to correctly establish feature relationships in the database.
    • Coordinate Geometry: A COGO panel interface interacts with a local Access database to insert, update and delete COGO calls. All types of calls are supported including non-tangent arcs. Traverse closure is calculated. There is a traverse viewer that annotates the Point of Beginning and numbers each call with its ID from the panel. The user can create and place traverses where each call is a separate object. In addition, the user can create and place single objects where all calls are combined into one line string.
    • Automated Parcel Numbering: A regularly scheduled executable connects to the Maricopa County Assessor's Office FTP site and downloads pertinent data files that describe parcel splits and combines in terms of "was" parcels and "is" parcels with their Assessor Parcel Number (APN). The program then uses the data files to update the City's Oracle database. Within the GIS, the user can query for a subdivision by County Recorder Number (MCR). If the MCR is found, then the user only needs to have a Lot Number object placed within each Parcel Polygon object and then invoke an APN loader. The loader will match the APN's to the Lot Numbers and place Parcel Point objects at the centroid of the Parcel Polygons that contain the Lot Numbers. Tract APN's can be populated by temporarily placing a Lot Number whose value is the tract ID.
    • Validation: Functionality is provided to validate data relationships and certain attribute restrictions. The validation functions can be invoked at the users' discretion and is automatically run as part of the Post and Retire processes. Once validation has completed, reports are available where offending features are listed. The features' Object Editors can be launched by double clicking the list items.

    Application Extension - SDE Annotation:
    • Using the SDE C API, C++, and COM, we developed and implemented a DLL to extend the landbase maintenance system. The extension provides the capability to create and maintain feature linked SDE Annotation. Visual Basic and MapObjects alone are incapable of this functionality.

    Data Translation:
    • Used Safe Software's Feature Manipulation Engine (FME) to write data translators to help Chandler migrate purchased data into their GIS. The code translates Smallworld data into Shape files that are as close to Chandler's data model as possible. The Shape files are post-processed to complete the data translation.

    Technology Transfer:
    • Performed technology transfer to a young, inexperienced GIS staff.
    • Delivered end-user training to a data maintenance crew who had never used GIS nor maintained Landbase data.

    System Integration:
    • Integrated GIS landbase with City Permitting System (Accela Permits Plus).
    • Integrated GIS landbase with City Utility Billing System (Hansen Information Technologies).
    Powered by MapObjects

    Jurisdiction Maintenance Application:

    The application co-exists with the landbase in the enterprise database on the ESRI platform: SDE on Oracle on Windows NT. Developed with ESRI's MapObjects and Microsoft's Visual Basic.

    With an approach similar to that of the landbase data maintenance system, the jurisdiction maintenance system has the same modularity, similar long transaction management, and automatic relationships.

    Annexation Process:
    • Jurisdictions, proposed annexations, and historical annexations are represented with polygonal objects.
    • When an annexation is proposed, the area in study is enclosed with a Proposed Annexation Object. As the ordinance moves through City Council's process, progress is tracked with date and status attributes of the Proposed Annexation.
    • When City Council adopts the ordinance, and sets an effective date, the application automatically notifies landbase data maintainers via e-mail of the impending jurisdictional changes.
    • Upon the effective date of the ordinance, the jurisdiction data maintainer invokes a promotion process:

      1. The area of the proposed annexation is subtracted from the jurisdiction polygon(s) that it overlaps. The area is then added to the jurisdiction polygon that represents the City of Chandler.

      2. All of the Address objects in the enterprise database that are contained by the proposed annexation polygon are collected and their jurisdiction attributes are updated.

      3. All of the Street Centerline objects in the enterprise database that are contained or overlapped by the proposed annexation polygon are collected and their jurisdiction attributes are updated.
      4. The Proposed Annexation object is changed into a Historical Annexation object.

    • The application provides a cancellation process in support of any event that a proposed annexation is cancelled or denied by City Council. The result of the application's cancellation process is that the Proposed Annexation object is changed into a Historical Annexation object whose status reflects the action taken by City Council.
    Powered by MapObjects

    Pavement Section Maintenance System:

    The application co-exists with the landbase in the enterprise database on the ESRI platform: SDE on Oracle on Windows NT. Developed with ESRI's MapObjects and Microsoft's Visual Basic.

    With an approach similar to that of the landbase data maintenance system, the Pavement Section Maintenance System has the same modularity, and similar long transaction management.

    System Process:
    • As street centerlines are maintained in the GIS enterprise landbase, street macro-spans, called street sections, are automatically maintained.
    • When a landbase workset is posted to the master database, changes to the street sections are copied to a separate data layer called section transactions and viewed in terms of transaction type: insert, update, or delete.
    • The user of the Pavement Section Maintenance System interacts with the transactional data layer and on a case-by-case basis, has the choice of either executing the same transactions that occurred in the landbase, or dismissing the transactions.
    • The pavement section objects and editors are designed and built to facilitate interaction with the section transactions.
    • Pavement sections may be edited independently of the section transactions.
    • Pavement sections are linked to records in the city's Pavement Management Application.

    about us  |  platform experience  |  clients  |  staff  |  sitemap  |  contact us
    © 2000 Mountaineer Consulting inc. All Rights Reserved  |  terms of use
    page by