11-Appendix G.pdf

Appendix G - Enterprise Geographic Information Systems (GIS)

Data Analytics and Business Intelligence Department’s Enterprise Geographic Information Systems (DBI/EGIS)

**EGIS is nested inside of DBI**

This appendix provides the DBI/EGIS standards to be adhered to for all bids, Requests for Proposals (RFPs), Requests for Competitive Sealed Proposals (RFCSP), grant programs, and volunteer non-profit efforts of the City. It also applies to any business partners’ solutions leveraging location-based GIS technology. These standards are intended for all parties submitting data and/or delivering geospatial solutions that will, or potentially could, rely on or be dependent upon the City’s GIS.

GIS Software Integration and Compatibility

1. Integration with the City’s GIS Infrastructure:

o All solutions must integrate with existing systems and platforms.

o Version Compatibility: Proposals must include compatibility details for the proposed GIS solution with the most current stable release of GIS software brand being used by the City. This proposed version can be more current, but cannot be an older version than the most current stable version of GIS technology being used by the city

• Any proposed versions of GIS software that have reached a ‘mature support’ state should not be considered.

• The proposer must provide a plan and timeline for migrating to a version of GIS software in ‘general availability’ when GIS software enters ‘mature’ or ‘extended support’.

o Platform Upgrade and Support Model: The proposer must provide a proposed plan for system upgrades. These upgrades should not rely upon software in ‘extended’ or; mature’ support

Proposed Architecture: The proposer must submit a detailed diagram of the solution’s architecture, including the communication channels, type of communication (read, read/edit) and ports used.

Software as a Service (SaaS) GIS Infrastructure and Interaction with City GIS environment.

2. Proposed solutions that use a cloud-based approach and would integrate or interact with the City’s GIS environment are required to interact with and adhere to the City’s ITS Security requirements and have a clear plan documented before project kick-off commences.

1. The software cloud servers that maintain the City’s information must remain in the 48 contiguous states for security purposes.

2. Among the considerations, geographic locations of all cloud assets, and sharing of configuration files for maintenance including a testing sandbox environment for testing and troubleshooting as needs arise.

3. New solutions will not be deployed and or integrated directly to the City GIS environment without a consideration of traffic load and impact to the existing environment.

4. Proposed integrations shall include a human readable description of the way that the proposed technology will interact with the City’s GIS environment

5. The proposer will be expected to provide technical documentation for all proposed integration steps working with existing City GIS systems

6. Additionally, if the Proposer intends to integrate their technology solution with or in partnership with the City’s online geospatial infrastructure, the proposal must include a clear outline of how their software will interact with the City's online GIS platforms, such as ArcGIS Online or Enterprise Portal GIS. This should include details on how data will be shared, maintained, and secured within the City's environment, ensuring compatibility and seamless integration.

7. If the Proposer intends to consume publicly available content from the City's ArcGIS Online (AGOL) organization, they will be expected to provide technical integration steps for testing this functionality.

Security Considerations

• The City requires a robust security framework for all GIS-related systems. The proposer must demonstrate how their solution will integrate securely with the City’s GIS, following the City’s approved security protocols.

• Access Control: Ensure role-based access control (RBAC) and multi-factor authentication (MFA) to limit access to sensitive geographic data.

• Encryption: Require end-to-end encryption for data at rest and in transit.

• Privacy Compliance: The software must comply with local and national data privacy regulations (e.g., HIPAA, GDPR, CCPA).

• Single Sign-On (SSO): Support for SSO via Active Directory (AD), to streamline authentication.

• Network Segmentation: Implement firewall rules and virtual private networks (VPNs) to protect internal GIS services.

• Data Backup and Incident Response: Ensure automated, regular backups. The GIS vendor should provide a well-documented plan for data breaches and cyber incidents.

• Overall, the Proposers must provide clear documentation on security practices, including authentication, access control, and data protection.

User and Service Account Management

• Proposals must specify the number of user and service accounts required to integrate the solution with the City’s GIS infrastructure.

• Account Types and Roles: Details on account types (e.g., Administrator, User, etc.), roles, and their minimum permissions must be outlined, with an emphasis on compliance with the City’s security requirements.

• Provisioning and de-provisioning: Automated user account creation and removal via integration with Active Directory

• Permission Settings: Users should only have access to GIS data and services necessary for their job functions.

• Third-Party Access: Verify and provide documentation of how external services authenticate and interact with the GIS System.

• Account Management: A plan for user account management should be provided.

GIS Metadata –

The City has adopted the FGDC Content Standard for Digital Geospatial Metadata (CSDGM) as the documentation or "metadata" format for all data included in the City GIS database.

• Participating parties are responsible for providing metadata in FGDC-compliant format for geospatial data products. This applies to data produced through partnerships, suppliers, grants, or contracts. Departments must verify compliance before obligating funds. These standards apply to data collected or produced directly or indirectly, including data from grants, partnerships, or other entities.

• Schema Customization: Ability to extend metadata schemas to include local government-specific attributes.

• At minimum metadata must include the following information: dataset title, abstract or brief description, purpose of the dataset, when the dataset was last updated and if it will be updated in the future, citation of who collected the data, and the methology used to collect or produce the data.

• Interoperability: Metadata should be compatible with common GIS platforms (e.g. Esri ArcGIS and Open Data Portals).

• Tags, Quality Control, and Versioning: The system must show that tags can be added for data sensitivity, track changes, and maintain historical changes for accountability and rollback. The system must also enforce metadata completeness checks before publishing datasets.

Projection (Projected Coordinate System[PCS]) Requirement

• All geospatial data must be delivered in the City’s standard PCS: State Plane North American Datum 1983, North Central Texas, FIPS 4202, GRS 80 Spheroid, Units feet

(SRID 2276).

Digital GIS Data

• Digital data submitted for inclusion in the City’s GIS database must be topologically clean and free of errors. All points, lines, and polygons must have a unique user-ID number (Long Integer).

• Data must be free of:

o Overshoots o Slivers o Open polygons (e.g., undershoots) o Label errors o Unresolved node errors o Unresolved line segment intersections

• Contiguous features should be edge-matched or closed.

• Line segments (arcs) that intersect the boundaries of a coverage/layer must be accurately edge-matched with corresponding datasets.

• Map features should not extend beyond prescribed dataset boundaries.

• Field names should include field name aliases easily understood by the general public.

• All spatial data must include valid coordinates based on the Projection Coordinate

System covered in section I.1.6.

• It is the Provider’s responsibility to provide the City with documentation detailing the date when the data was created or collected. This should include any methods and standards used to calculate values.

• The Proposer can keep any proprietary methodology confidential, but the City and it’s personnel are not responsible to explain or replicate those methods in the future.

Raster (Image) Data

• All geospatial image (raster) data must be delivered in one of the following formats:

o Ortho-rectified TIFF/Tagged Image (.tif) with accompanying Text World File

(.tfw) o Ortho-rectified JPEG/JPG with accompanying JPEG/JPG World file (.jgw) o Ortho-rectified MrSID with accompanying World file (.sdw) o In addition to the imagery the Proposer must provide documentation on when the imagery was collected and provide documentation on the methods and equipment used in the collection process.

Attribute Coding Accuracy

• If data is found to contain errors, the data provider is responsible for correcting them.

• The City GIS Services Division will not verify attribute accuracy for delivered data. It is the responsibility of the data provider to confirm the accuracy.

• Attributes should not include any abbreviations or code classification without coded domains that provide users with values that can be understood by the general public.

Attribute Coding Requirements

• Data and codes should be consistent and well-documented in the metadata or data dictionary.

• Attribute coding schemes should be well defined and in common use.

• Names of new datasets should not overlap with existing dataset names in the City GIS database unless they are replacing the old dataset.

• Datasets, item names, and attribute codes should begin with a letter, and should not contain any punctuation (e.g., hyphens, pound signs, or periods).

• Define items according to their intended use (e.g., numeric data types for statistical data).

• It is the Proposer’s responsibility to provide a table with all attribute codes and their meanings (must be understood by the general public).

o The Proposer can provide this data as coded domains in the data.

Address Validation Requirements

• Validation of addresses and geocoding: All parties must use the City-approved standard locator service(s), as specified by business requirements. The URL for the locator service(s) will be provided upon request.

• Usage of ‘non-City’ approved locators is not permitted.

City GIS Infrastructure and Associated Technical Requirements

• The contracted Proposer must leverage the City’s Enterprise GIS infrastructure without modification (as-is), including the version of the infrastructure in use at the time of implementation.

o The City’s standard for data sharing is the ArcGIS REST API or comparable technology.

o The City’s public REST endpoints https://egis.dallascityhall.com/arcgis/rest/services/ https://gis.dallascityhall.com/arcgis/rest/services/ o It is incumbent on the proposer to ensure that their code and infrastructure is compatible with existing infrastructure.

https://egis.dallascityhall.com/arcgis/rest/services/ https://gis.dallascityhall.com/arcgis/rest/services/ o Any server-side code-base and configuration files will need to be shared with DBI/EGIS staff for trouble shooting over the life of the use of the proposed software.

• The configuration of the City’s GIS infrastructure will not be modified to support the technical requirements of a proposed system. Any necessary customizations must be managed by the Proposer via a separate GIS web application or database instance.

• If the proposed application requires Web Based GIS Infrastructure or integration with Dallas’ Online (or comparable technology), the proposer must provide the subscription and sufficient Named Users, with costs listed as separate line items. The City cannot use its ArcGIS Online Organizational account for third-party systems.

• Under no circumstances should it be assumed that the City’s DBI/EGIS will support a proposed system without prior approval from the CDO (Chief Data Officer), or the CIO (Chief Information Officer).

• The publication of standard read-only REST services to support a business need may be requested, provided that the City has the data to support the services and that no custom functionality or non-standard configurations are required.