2026 U.S. State GIS Software Inventory

State GISEnterprise GIS & IT
Written By Adam Simmons
Geospatial Frontiers • Project Geospatial

2026 U.S. State GIS Software Inventory

Who actually runs America’s state geospatial infrastructure? A 50-state examination of documented software, operational responsibility, and the information needed to assess public value.

Article revised October 2, 2026 · Evidence baseline September 24, 2026 · Working edition

State geospatial infrastructure is public digital infrastructure. The services documented in this inventory publish parcel records, imagery, boundaries, basemaps, and other geographic information that people and institutions can use beyond the office that produced it. Behind those services are software platforms, databases, processing tools, hosting arrangements, and organizations responsible for keeping them available. Understanding that infrastructure requires looking beyond the map on the screen. [46] [56] [60] [65]

Yet a public portal rarely answers the larger questions on its own: Who actually operates the service? Which technologies prepare, store, and distribute the data? Does the central state GIS office run the system, or does an agency, university partner, or contractor carry that responsibility? What is covered by a statewide agreement, and what must individual programs pay for separately? These are questions about the stewardship of public infrastructure as much as they are questions about software.

The 2026 U.S. State GIS Software Inventory is Geospatial Frontiers’ effort, through Project Geospatial, to assemble a systematic, source-backed record across all 50 states. We are bringing information from service endpoints, official documentation, technical repositories, strategic plans, and purchasing records into a common table. The purpose is to connect the software we can document to the organization and function it supports—and to make the remaining questions explicit.

This approach addresses a practical reporting gap: individual announcements, product stories, and public maps provide fragments of an operating picture. A comparable inventory allows those fragments to be examined together. A resident can see what is known about their state’s systems. A researcher can trace a claim to its source. A neighboring government can identify an implementation worth learning from. Vendors and service providers can better understand documented requirements and responsibilities. State GIS teams can correct incomplete descriptions and explain choices that a public portal alone cannot convey.

Our organizing question is “Who actually runs America’s state geospatial infrastructure, and what do they use to do it?” Answering it requires attention to Esri deployment, open-source use, other commercial software, enterprise GIS, cloud and hosting infrastructure, imagery services, public portals, open-data platforms, procurement visibility, and statewide coordination. These are the dimensions the inventory is intended to illuminate. This edition establishes some of them more clearly than others: the table documents software and services where evidence exists, while comprehensive hosting, coordination, utilization, and cost information remains work for subsequent verification.

Transparency matters because software decisions commit public resources beyond the initial purchase. To assess a choice responsibly, readers need to understand the service being delivered, who maintains it, the resources required to sustain it, and the options available when needs change. A license agreement cannot answer all of those questions. Neither can a product’s open-source status. Public value depends on the relationship between operating cost, capability, access, reliability, and continuity.

Our aim is to make those choices explainable and open to informed scrutiny. The inventory should help establish a factual basis for asking whether technology serves the public well and whether expenditure is justified by the benefits delivered. It should also give offices a useful way to show their work: identify the software, explain its purpose, name the responsible organization, and provide documentation that others can inspect.

The report therefore combines a 50-state evidence table with analysis of what that evidence can support, examples of documented implementations, and a proposed standard for future disclosure. We are also outlining a correction process so the people operating these systems can improve the record. The result is a foundation for original reporting on government technology, procurement, and economics that can become more complete as state-specific evidence is added.

What this edition represents. This is a desk review of public documentation, not a completed survey of state offices. An unresolved field identifies a limit in our research; it does not establish that an office withheld information, uses no other software, or spends inefficiently. The report covers all 50 states, but it does not yet provide a complete inventory of every agency or a comparable account of state GIS spending. Individual sources may describe earlier operations or future plans.

What the inventory establishes

Esri appears across the research through operational services, program documentation, procurement arrangements, and technology standards. Those evidence types answer different questions. A published ArcGIS service establishes a service; a purchasing agreement establishes access to a procurement mechanism. Neither supplies a complete inventory of an office’s technology.

Four state entries—Connecticut, Massachusetts, Texas, and Utah—contain concrete examples of Esri alongside open-source components. Minnesota has an additional historical example through CKAN documentation from 2022. In the other 45 entries, the research does not establish enough about additional components to characterize the overall combination of software. Those entries cannot fairly be called “Esri only.” [9] [29] [32] [57] [58]

50State entries in the inventory
69Sources for inventory and analysis
4Entries with documented mixed-software examples
45Entries whose other components remain unresolved

What our evidence can currently distinguish

2026-09-25T01:47:35.963933 image/svg+xml Matplotlib v3.10.8, https://matplotlib.org/ 0 10 20 30 40 50 State entries · 50 total Esri + open-source components documented Historical open-source evidence; recheck needed Other stack components unresolved 4 1 45

Figure 1. All 50 entries: four with documented mixed-software examples, one with historical open-source evidence, and 45 with other components unresolved. These are classifications of this research baseline—not market share, office transparency scores, or measures of technical quality. Published code does not by itself confirm the current production configuration.

The gap is a reason to improve the record. Readers should be able to distinguish a confirmed deployment from a contract, a training offering from staff use, and a planned migration from a completed one. Offices should also be able to correct the record without having to defend a software category.

The 2026 inventory: software, organizations, and evidence

The table separates public portals and services, desktop tools, databases and processing, and procurement. It names the organization supported by each source. A central GIS office, a transportation department, and a university clearinghouse can have different responsibilities and software. Evidence about one should remain attached to that organization.

Reading the table: “Not verified” means the review did not establish the fact. Historical and planned evidence retains that qualification. A contract or standard does not prove deployment; client compatibility does not prove employee use. On a small screen, scroll horizontally to read all seven columns.

2026 inventory · evidence reviewed September 24, 2026
State / organizationPortal / servicesDesktop / analysisDatabases / processingProcurementEvidence / sourcesGaps / scope
Alabama
Statewide GIS / Alabama GeoHub
Other stack components unresolved		ArcGIS portalNot verifiedNot verifiedNot verifiedPublic portal [1]Confirm central office ownership and internal tools.
Alaska
Alaska Geospatial Office
Other stack components unresolved		ArcGIS map, feature and imagery servicesNot verifiedNot verifiedNot verifiedDeployment [2]Desktop, processing and database tools.
Arizona
AZGeo
Other stack components unresolved		ArcGIS Enterprise portalNot verifiedNot verifiedNot verifiedDeployment [3]Internal desktop and database stack.
Arkansas
Arkansas GIS Office
Other stack components unresolved		ArcGIS basemap servicesNot verifiedNot verifiedNot verifiedDeployment [4]Database and automation tools.
California
CDT / State Geoportal
Other stack components unresolved		ArcGIS Hub; ArcGIS Online contentNot verifiedNot verifiedNot verifiedVendor case study [5]; state documentation [6]Central-office QGIS/PostGIS not established; separate agency evidence from CDT.
Colorado
Governor’s OIT GIS program
Other stack components unresolved		GIS services; precise portal stack not establishedNot verifiedNot verifiedEsri licensing via master purchasing agreementService catalog [7]QGIS/PostGIS not established. CU Boulder OIT is a different organization.
Connecticut
CT GIS Office
Mixed documented		ArcGIS HubQGIS training documented; production desktop mix unverifiedOperational Python and R; commercial Esri, FME and remote-sensing tools2024–25 plan: enterprise licensing feasibility workDeployment and strategy [8] [9]; training [10]Plan confirms Python/R use; public GitHub was unfinished then. Recheck current status.
Delaware
DTI / FirstMap
Other stack components unresolved		FirstMapNot verifiedNot verifiedEsri enterprise license agreementService documentation [11]Database and open-source processing.
Florida
GIO / DEP
Other stack components unresolved		Specific service architecture unverifiedNot verifiedNot verifiedGIO/DEP shared Esri enterprise agreementProgram documentation [12]Internal deployments and agreement scope.
Georgia
GEMA/HS; central GIO not established
Other stack components unresolved		GEMA/HS ArcGIS Online portalNot verifiedNot verifiedNot verifiedAgency deployment [13]Verify central GIO separately from emergency management.
Hawaii
Statewide GIS / OPSD and ETS
Other stack components unresolved		Esri infrastructure; products unspecifiedNot verifiedNot verifiedNot verifiedProgram statement [14]Product inventory, database and current licensing terms.
Idaho
INSIDE Idaho, University of Idaho; IGO partner
Other stack components unresolved		Clearinghouse searches ArcGIS Online groupsNot verifiedNot verifiedState Esri purchasing contractClearinghouse [15]; procurement [16]IGO internal deployment remains unverified.
Illinois
DoIT procurement; ISGS services separately
Other stack components unresolved		ISGS ArcGIS servicesNot verifiedNot verifiedFY2024–FY2026 Esri solicitation; current renewal unverifiedProcurement [17]; deployment [18]Separate DoIT and ISGS. GeoServer not established.
Indiana
Indiana Geographic Information Office
Other stack components unresolved		Supports ArcGIS Enterprise deploymentsNot verifiedNot verifiedNot verifiedOffice statement, January 2026 [19]Database, desktop and processing tools.
Iowa
State purchasing program
Other stack components unresolved		Clearinghouse software not establishedNot verifiedNot verifiedState Esri contractProcurement [20]Contract does not establish central GIS office deployment.
Kansas
DASC / Kansas Geological Survey, University of Kansas
Other stack components unresolved		ArcGIS Online / Geoportal HubNot verifiedNot verifiedState Esri enterprise agreement documentedProgram documentation [21] [22]Desktop, databases and processing libraries.
Kentucky
Division of Geographic Information
Other stack components unresolved		ArcGIS Server servicesNot verifiedNot verifiedNot verifiedOffice documentation [23]Internal desktop and data processing stack.
Louisiana
DOTD; LSU Atlas is separate
Other stack components unresolved		DOTD ArcGIS boundaries and imageryNot verifiedNot verifiedNot verifiedAgency deployment [24]Central coordinating-office and Atlas stacks need separate confirmation.
Maine
MEGIS / MaineIT
Other stack components unresolved		Enterprise GIS infrastructure; ArcGIS identifiedNot verifiedNot verifiedEsri enterprise license agreementService catalog [25]Product versions, database and open-source components.
Maryland
DoIT
Other stack components unresolved		Centrally managed ArcGIS OnlineArcGIS ProNot verifiedCentrally provided licensing serviceService catalog [26]Backend and processing libraries.
Massachusetts
MassGIS
Mixed documented		ArcGIS Server/Online; GeoServer; custom MassMapper uses Leaflet and Esri basemapsArcGIS Pro; QGIS connection guidanceGeoServer confirmed; database products unverified hereNot verifiedDeployment [27] [28]; source code [29]Do not label MassMapper as ArcGIS Online. Oracle/PostGIS and internal QGIS need distinct evidence.
Michigan
DTMB / Center for Shared Solutions
Other stack components unresolved		ArcGIS Enterprise administration documentedNot verifiedNot verifiedNot verified2023 strategy [30]Reconfirm current architecture; separate procurement evidence required.
Minnesota
MnGeo / Geospatial Commons
Historical open-source evidence		CKAN documented in 2022; present stack needs recheckNot verifiedPostGIS/GeoServer not establishedMnGeo administers Esri enterprise agreementProcurement [31]; historical architecture [32]Confirm current CKAN deployment and other open-source tools.
Mississippi
MARIS
Other stack components unresolved		ArcGIS EnterpriseNot verifiedNot verifiedNot verifiedDeployment [33]Database, desktop and processing software.
Missouri
Office of Geospatial Information
Other stack components unresolved		Esri desktop/server standardEsri suite; exact current products unverifiedNot verifiedPublished standard; contract terms unverifiedPolicy [34]Standard does not rule out supplementary tools.
Montana
Montana State Library
Other stack components unresolved		ArcGIS services; 2026 cloud migrationNot verifiedNot verifiedNot verifiedService-change documentation [35]Current databases, desktop software and contract scope.
Nebraska
OCIO / Geographic Information Office
Other stack components unresolved		ArcGIS enterprise softwareNot verifiedNot verifiedNot verifiedService definition [36]Open-source components and precise deployment scope.
Nevada
Division of Environmental Protection
Other stack components unresolved		Esri GIS web applicationsEsri desktop analysisEsri spatial database management; underlying DB unverifiedNot verifiedAgency statement [37]Agency evidence does not establish a central statewide office stack.
New Hampshire
NH GRANIT, University of New Hampshire
Other stack components unresolved		ArcGIS Hub statewide clearinghouseNot verifiedNot verifiedNot verifiedClearinghouse documentation [38]Central state-government desktop and database software unverified.
New Jersey
Office of GIS / NJGIN
Other stack components unresolved		ArcGIS Online basemap transition plannedNot verifiedNot verifiedEsri software contract 25-TELE-82239 listed by NJGIN; terms not reviewedProcurement [69]; planned transition [39]Confirm completion and present services before classifying the transition as deployed.
New Mexico
DoIT / NMGIS
Other stack components unresolved		ArcGIS map servicesNot verifiedNot verifiedNot verifiedDeployment [40]Internal desktop, databases and processing.
New York
ITS Geospatial Services
Other stack components unresolved		ArcGIS Hub and REST services; Enterprise migration documentedQGIS client guidance; internal use unverifiedNot verifiedNot verifiedServices [41]; migration [42]Supported clients do not establish staff deployments.
North Carolina
NCDIT / CGIA
Other stack components unresolved		Exact deployment not established by license pageNot verifiedOpen-source evaluation guide; deployment unverifiedPublished 2021–2025 state Esri ELA description; separate local-government MPA; current terms need confirmationProcurement [43]; evaluation [44]Identify actual production tools, distinguish ELA from MPA, and confirm current agreement dates.
North Dakota
NDIT / State Geospatial Committee
Other stack components unresolved		GIS Hub ArcGIS Online servicesNot verifiedNot verifiedNot verifiedDeployment [45]Desktop, databases and processing stack.
Ohio
OGRIP
Other stack components unresolved		ArcGIS boundary and imagery servicesNot verifiedNot verifiedNot verifiedDeployment [46]Internal tools and contracting.
Oklahoma
OMES
Other stack components unresolved		ArcGIS state standardArcGIS standard; deployment specifics unverifiedNot verifiedTechnology standard; contract unverifiedPolicy [47]A standard does not establish every agency’s actual deployment.
Oregon
Geospatial Enterprise Operations
Other stack components unresolved		ArcGIS servicesNot verifiedOpen-source community support; internal deployment unverifiedAdministers state Esri enterprise agreementOffice statement [48] [49]Verify production open-source use separately from user-group support.
Pennsylvania
OA Geospatial Services; PASDA at Penn State separately
Other stack components unresolved		OA GIS services; PASDA ArcGIS servicesNot verifiedCurrent GeoServer/PostGIS deployment not establishedOA ArcGIS licensing serviceOffice [50]; clearinghouse [51]Dataset production metadata is not proof of PASDA hosting software.
Rhode Island
Statewide Planning / RIGIS
Other stack components unresolved		2025 report describes ArcGIS infrastructureNot verifiedNot verified2025 report describes Esri enterprise supportReport [52]Reconfirm operational status, deployment scope and current terms.
South Carolina
Revenue and Fiscal Affairs mapping services
Other stack components unresolved		ArcGIS integration offeredNot verifiedNot verifiedNot verifiedService offering [53]Exact enterprise architecture and open-source use.
South Dakota
State-hosted GIS services
Other stack components unresolved		ArcGIS service directoryNot verifiedNot verifiedNot verifiedEndpoint [54]Confirm operating office and deployment scope.
Tennessee
STS GIS Services
Other stack components unresolved		ArcGIS Online organization and TNMap servicesNot verifiedNot verifiedNot verifiedDeployment [55]Database, desktop and processing components.
Texas
TxGIO
Mixed documented		ArcGIS parcel servicesInternal desktop mix unverifiedPublished API: Django, PostgreSQL, GDAL/OGR; MIT-licensed repositoryNot verifiedDeployment [56]; source code [57]Do not extend TxGIO findings to Railroad Commission or port authority; confirm production versions.
Utah
UGRC
Mixed documented		ArcGIS Hub / SGID servicesQGIS and other client compatibility; staff use unverifiedOpen SGID: operational PostgreSQL/PostGISNot verifiedDeployment [58] [59]Verify Discover architecture separately; client guides do not prove internal tools.
Vermont
VCGI
Other stack components unresolved		ArcGIS basemap and imagery servicesNot verifiedNot verifiedNot verifiedDeployment [60]Database, desktop and processing components.
Virginia
VGIN / VDEM
Other stack components unresolved		ArcGIS servicesNot verifiedNot verifiedNot verifiedApril 2025 guidance [61]Internal processing and database technologies.
Washington
WaTech
Other stack components unresolved		ArcGIS imagery servicesNot verifiedNot verifiedNot verifiedDeployment [62]Verify central program desktop and database stack.
West Virginia
WV GIS Technical Center, WVU
Other stack components unresolved		ArcGIS REST servicesNot verifiedCurrent named open-source deployment unverifiedNot verifiedTechnical-center documentation [63]Keep technical center separate from coordinating-office internal stack.
Wisconsin
SAGIC; State Cartographer’s Office separately
Other stack components unresolved		SCO statewide parcels via ArcGIS servicesNot verifiedGeoData@Wisconsin technology requires primary-source confirmationSAGIC documents Esri master purchasing agreementProcurement [64]; deployment [65]PostGIS and GeoBlacklight deployment not confirmed here; separate organizations.
Wyoming
WyGISC, University of Wyoming
Other stack components unresolved		GeoHub ArcGIS servicesNot verifiedNot verifiedNot verifiedClearinghouse deployment [66]Central state-office internal stack remains unverified.

Why a software list needs operational context

A public map is the visible end of a longer process. An analyst may prepare the data in one tool, a database may store it in another, and a service may deliver it to a custom application. The public-facing brand can reveal only part of that chain. Our inventory separates these roles so that a reader can see what each documented component contributes.

Public applications

The interface readers open.
Example: MassMapper’s custom Leaflet application. [29]

Publishing services

The systems delivering map layers.
Example: MassGIS ArcGIS Server/Online and GeoServer. [27]

Databases

The systems storing and querying records.
Example: Utah Open SGID’s PostgreSQL/PostGIS. [58]

Analysis & automation

The tools preparing and analyzing data.
Example: Connecticut’s operational Python and R. [9]

Figure 2. Four software roles illustrated by different states. These cards do not depict one shared architecture. Desktop software and procurement are recorded separately in the inventory.

“Other software” also includes commercial products beyond Esri. Connecticut’s documentation names FME alongside Esri and open-source tools. An inventory that asks only whether an office uses ArcGIS or QGIS would miss that operational detail. [9]

What four state entries help explain

Massachusetts: identify the components behind the map

MassGIS documentation identifies ArcGIS services and GeoServer, while basemap documentation identifies ArcGIS Pro. The MassMapper repository describes a custom application using Leaflet and Esri basemaps. Together, these sources show multiple technologies performing different roles. They do not establish every database or staff desktop application used by the office. [27] [28] [29]

For public accountability, the follow-up is practical: which components support which services, who maintains them, and how are their operating costs allocated? Naming the components makes those questions possible.

Utah: explain how people can access public data

UGRC documents Open SGID as a PostgreSQL/PostGIS database and also uses ArcGIS Hub to share SGID resources. These access routes give the inventory more detail than a single platform label. Connection instructions for QGIS and other clients establish compatibility, while internal desktop use remains a separate question. [58] [59]

The public-value questions are whether these routes meet different users’ needs, how updates are kept consistent, and what each route costs to sustain. This edition establishes the documented technologies, not their comparative economics.

Texas: keep the evidence attached to the operator

TxGIO publishes ArcGIS parcel services. Its API repository describes Django, PostgreSQL, and a GDAL/OGR requirement and carries an MIT license. The repository makes part of the implementation inspectable, though its current production configuration still needs confirmation. These findings should not be extended to unrelated Texas agencies. [56] [57]

That distinction matters for cost as well as technology. An agency’s implementation and another organization’s purchasing agreement cannot be combined into a statewide cost story without evidence that connects them.

Connecticut: include the work behind routine services

The GIS Office’s 2024–2025 strategic plan update describes Python and R used operationally, including automation, alongside commercial tools. Its publishing guidance identifies ArcGIS Hub. The plan separately describes a public GitHub resource that was still being developed at that time. [8] [9]

Processing scripts belong in an inventory because they help explain how services are produced. A useful office update would clarify which workflows remain active, who supports them, and whether the planned public repository has since opened.

How a GIS platform becomes part of the state ecosystem

Esri’s established presence is an important part of this inventory. Understanding that presence requires examining the decisions around the software: how it was acquired, how employees learned to use it, which applications grew around it, and how responsibility for support was organized. The inventory shows documented use; explaining each state’s reasons for adopting or retaining a platform requires its decision records and the perspectives of the people responsible.

North Carolina provides a historical example of that relationship. Its State Government GIS Users Committee’s 2017–2018 work plan described an enterprise agreement as a basis for consistent, supported implementation and predictable annual license costs. The plan explicitly connected a long-term agreement with agencies’ ability to commit to developing applications. This is evidence of a stated institutional rationale at that time, not a finding about every subsequent renewal. [67]

Other records show the surrounding support structure. North Carolina’s agreement page, labeled July 2021–June 2025, describes software, maintenance, training, conference access, and a state help desk. Its GIS users committee also participates in enterprise-agreement negotiations and a services-contract program that supplements agency staff. New Jersey publishes separate purchasing routes for Esri software and GIS services. The dates and terms matter: an older agreement description should not be treated as confirmation of current pricing or coverage. [43] [68] [69]

Our interpretation is that these arrangements can make a platform easier to build upon. An office with access to software, trained colleagues, support, and an established purchasing route has reasons to consider those resources when choosing its next application. As workflows and integrations accumulate, a new product must be evaluated against a functioning operating environment. The importance of each factor will differ by state and should be tested through interviews and records.

Why keeping an established platform can make sense

Continued use can be justified when a platform meets the service requirement, staff can maintain it, partner systems work with it, and the agreement delivers value. Familiar workflows and existing integrations can reduce the work needed to deliver another service. A state may also prefer a defined support relationship for systems it must keep available. These are plausible decision factors, not motives established for every office in this inventory.

The economic question has two levels. For an agency already covered by a shared agreement, using another included capability may involve little additional license expenditure. For the state as a whole, the agreement still has a cost. A fair review should examine both the agency’s incremental cost and the statewide commitment, including utilization, support, and renewal terms. “Already available” is relevant to a project decision; it is not a substitute for periodic review of the broader agreement.

When continuity becomes dependence

The editorial question is whether renewal remains a considered decision. Existing applications, specialist skills, integrations, and contractual arrangements can make a change expensive or disruptive. That can justify staying. It can also leave an office with limited practical alternatives if those dependencies have never been documented or tested.

Money already spent cannot be recovered by switching, but it should not automatically justify future spending either. The useful comparison is forward-looking: what will it cost to continue, what would a transition require, and what service improvements or recurring savings would result over a comparable period? A migration assessment should include retraining, application redevelopment, data validation, parallel operation, and support responsibility. The same scrutiny should apply to proprietary and open-source systems.

What might motivate a state to change?

Potential triggers include a renewal that changes the economics, a capability gap, the retirement of a product, a requirement to serve more users, a change in hosting policy, or a need to exchange data more easily. Another tool may prove better suited to a particular processing, database, imagery, or publishing task. These are questions for state-specific reporting; this inventory does not establish a nationwide pattern of migration.

A change can also be incremental. The documented combinations in Massachusetts, Utah, Texas, and Connecticut show that several technologies can coexist. An office could evaluate a new component while continuing to use established services elsewhere. The existence of those combinations does not establish that the offices adopted them to save money or replace Esri; those reasons still need confirmation.

Is awareness of alternatives the missing ingredient?

Awareness is worth investigating, but it would be premature to assume state GIS staff do not know the competitive landscape. Knowing a tool exists is different from having staff time, procurement access, implementation support, and a realistic opportunity to test it. Conversely, a familiar platform should not be presumed optimal merely because alternatives have not received a comparable evaluation.

The transparency question is: what alternatives were evaluated, against which requirements, with what results? A useful public decision record would identify the options considered, the service requirements, the cost assumptions, the migration constraints, and the reasons for the final choice. It could demonstrate that an Esri renewal represents strong value, that another commercial or open-source tool fits a particular need, or that a mixed approach best serves the public. Publishing that reasoning would make procurement more understandable than a vendor label or a renewal notice alone.

Public value requires a fuller account of cost

This inventory does not yet contain comparable state operating budgets, license utilization, staffing costs, or service-performance measures. It therefore cannot rank states by efficiency or calculate savings from a change of platform. Its current value is to establish the software and organizational baseline needed for that reporting.

For future editions, our proposed comparison would hold the public service and reporting period constant, then identify all material costs. A managed service includes responsibilities that may fall to staff or contractors in a self-operated system. An open-source license may carry no acquisition fee while deployment, maintenance, training, and support still require resources. A commercial agreement needs to be evaluated against its scope, utilization, and delivered benefits.

What a comparable public-cost account should include

Acquire & renew

Licenses, subscriptions, support contracts, agreement terms, and actual utilization.

Operate & protect

Hosting, storage, administration, maintenance, backups, and security responsibilities.

Staff & deliver

Internal labor, contractors, training, integration, and ongoing application development.

Change & exit

Migration, data export, retraining, transition overlap, and replacement of integrations.

Figure 3. Proposed cost-reporting framework. No spending amounts or savings estimates are implied. Compare equivalent services over the same period and separate one-time from recurring costs.

Agreement scope deserves particular attention. North Carolina documents a state Esri enterprise licensing arrangement and a separate Master Purchase Agreement for local governments. Combining them under one generic licensing label would obscure who is covered and how software is obtained. [43]

Public value also needs a service outcome. How current is the published data? Can residents and partner organizations access it in useful formats? How reliably does the service operate? Can the office maintain it when staff or contractors change? Lower expenditure alone does not answer those questions, and a more expensive platform needs an explanation of the benefit it delivers.

A practical transparency standard for state GIS

Project Geospatial proposes a compact, regularly updated public record that connects software to purpose, responsibility, and cost. The aim is to make a state’s choices understandable and reviewable without requiring readers to reconstruct the architecture from scattered documents.

  1. Identify the software and its role. Name the products and projects used in production, and distinguish them from pilots, planned work, retired systems, and supported external clients.
  2. Identify the responsible organization. Explain whether a central office, agency, university partner, or contractor operates the service, and whether it is vendor-hosted or operated on behalf of the state.
  3. Explain the public purpose. Describe the services supported, the users served, and the reasons for selecting the approach.
  4. Describe the cost and scope. Publish available expenditure records or clearly labeled estimates, the period covered, relevant agreement terms, and major exclusions. Distinguish a contract ceiling from actual expenditure.
  5. Explain access and continuity. Describe public data access, interoperability requirements, support responsibility, and the ability to maintain or transition the service.
  6. Date and source the record. Provide supporting links, an accountable contact, a last-confirmed date, and a visible revision history.

This is our proposed editorial standard, not a statement that every jurisdiction has the same legal disclosure requirements. Useful public documentation can describe products, responsibilities, costs, and outcomes without publishing credentials, private endpoints, or sensitive system configurations.

The same discipline applies to our reporting. An empty cell is a question for further research, not a finding of misconduct. We will need to distinguish a lack of evidence in this review from a demonstrated failure to provide information. We should also make it easy for an office to supply information we missed.

An invitation to state GIS offices: improve your entry

State GIS offices, agency programs, and clearinghouse teams are invited to help make this record accurate and useful. The most valuable contribution is specific: identify the row, explain the correction, name the software and its operational role, and provide evidence that can be cited.

Submission form planned; not live in this draft. The proposed intake below shows what a future correction request would collect. This article does not currently receive or transmit submissions.
State, office, and contributorIdentify the responsible organization and a work contact for editorial verification.
Correction and public evidenceQuote the current entry, propose a replacement, and link supporting documentation.
Software, function, and scopeName the product, its workload, and the agencies or services covered.
Operational status and dateProduction, pilot, planned, retired, or external-client compatibility; last confirmed date.
Hosting and support responsibilityVendor-hosted, state-operated, or contractor-operated; identify who maintains the service.
Reason for the choiceDescribe the service need, alternatives evaluated, evaluation date, cost assumptions, pilot results, and reasons for renewal or change.
Cost and public outcomesWhere available, provide period-specific spending, inclusions and exclusions, and service measures. Distinguish estimates from actuals.
Publication permissionIdentify publishable facts and attribution. Work contact details should remain private unless separately authorized.

Proposed editorial review: Verify the contributor’s affiliation, assess the supporting material, reconcile conflicting evidence, and date the approved change. Office confirmation should be identified separately from independent public documentation. State rows and summary graphics should be updated together, with a public change log explaining material revisions. A submission would not automatically overwrite the inventory.

A complete public record will take contributions from the people responsible for these systems and careful verification from the people reporting on them. The purpose of this inventory is to make those contributions comparable: what a state uses, why it uses it, what it takes to sustain it, and how the public benefits. That is the transparency needed for an informed discussion about GIS and taxpayer value in 2026.

Methodology and limits of this edition

The baseline covers 50 states and excludes the District of Columbia and territories. The original baseline draws on 66 sources, including service endpoints, official program documentation, procurement records, published code, historical reports, policy documents, and a vendor case study. Evidence was reviewed for the September 24, 2026 baseline; the introduction and presentation were revised October 2. Three additional procurement and governance sources were reviewed October 2 for the platform-choice analysis. The North Carolina agreement page was also revisited; its displayed 2021–2025 term is historical. This targeted update does not constitute a new verification of every service or contract.

Rows are scoped to the named organizations. Dates and evidence types remain part of the interpretation. The four mixed-software examples identify documented components, not the extent of deployment or the share of staff using them. The historical category is separate. These classifications measure the evidence assembled here; they do not measure nationwide market share, disclosure quality, or value for money.

No state offices have been contacted for this baseline, and no entry is labeled office-confirmed. Additional software, hosting arrangements, support models, operating costs, and reasons for platform choice remain subjects for confirmation. Unresolved fields are carried forward openly so future corrections can improve the inventory without overstating what the first edition establishes.

Source register

Each source supports its associated claim. Historical, planned, and time-sensitive findings require confirmation before being described as current deployments. The public-interest standards and cost framework above are Project Geospatial’s editorial proposals.

  1. [1] FHWA state GIS portal directory
  2. [2] Alaska Geoportal service directory
  3. [3] AZGeo Enterprise portal
  4. [4] Arkansas GIS basemap service
  5. [5] California State Geoportal case study
  6. [6] CDT GIS Community of Practice, September 2024
  7. [7] Colorado OIT GIS service catalog
  8. [8] CT Geodata Portal publishing guidelines
  9. [9] CT Geospatial Strategic Plan 2024–2025 update
  10. [10] UConn CLEAR 2025 webinar library
  11. [11] Delaware DTI GIS support and ELA
  12. [12] Florida Geographic Information Office overview
  13. [13] GEMA/HS GIS program
  14. [14] Hawaii Statewide GIS program
  15. [15] INSIDE Idaho FAQ
  16. [16] Idaho Esri statewide contract
  17. [17] Illinois Esri FY24–FY26 solicitation
  18. [18] ISGS county boundaries service
  19. [19] Indiana IGIO enterprise and infrastructure staffing
  20. [20] Iowa Esri contract
  21. [21] Kansas Geoportal Hub sharing guidelines
  22. [22] DASC FY2025 annual report
  23. [23] Kentucky DGI services
  24. [24] Louisiana DOTD boundary services
  25. [25] MEGIS service catalog
  26. [26] Maryland GIS services
  27. [27] MassGIS ArcGIS and QGIS connection guide
  28. [28] MassGIS basemap production
  29. [29] MassMapper repository
  30. [30] Michigan statewide GIS coordination strategy
  31. [31] MnGeo technology coordination
  32. [32] MnGeo archiving pilot final report, March 2022
  33. [33] MARIS program and services
  34. [34] Missouri OGI software standard
  35. [35] Montana GIS web service changes
  36. [36] Nebraska enterprise GIS service description
  37. [37] Nevada DEP GIS resources
  38. [38] NH GRANIT overview
  39. [39] NJGIN program notices
  40. [40] New Mexico DoIT map service
  41. [41] New York ShareGIS
  42. [42] New York service migration
  43. [43] North Carolina Esri agreements
  44. [44] North Carolina open GIS software guide
  45. [45] North Dakota GIS web services
  46. [46] Ohio OGRIP boundary service
  47. [47] Oklahoma GIS standard
  48. [48] Oregon GEO overview
  49. [49] Oregon GIS community resources
  50. [50] Pennsylvania OA geospatial services
  51. [51] PASDA imagery service directory
  52. [52] Rhode Island statewide GIS report, February 2025
  53. [53] South Carolina RFA mapping services
  54. [54] South Dakota ArcGIS services
  55. [55] Tennessee STS GIS ArcGIS organization
  56. [56] TxGIO parcel services
  57. [57] TxGIO data API repository
  58. [58] UGRC Open SGID
  59. [59] UGRC sharing with SGID
  60. [60] VCGI basemap service
  61. [61] VGIN working with GIS services
  62. [62] WaTech statewide imagery service
  63. [63] WV GIS Technical Center web services
  64. [64] Wisconsin SAGIC procurement
  65. [65] Wisconsin statewide parcel data
  66. [66] WyGISC GeoHub service
  67. [67] North Carolina SGUC 2017–2018 work plan (historical rationale)
  68. [68] North Carolina State Government GIS Users Committee
  69. [69] NJGIN state software and GIS services contracts
Adam Simmons

Geospatial Industry Consultant | Founder, Project Geospatial

Adam Simmons is a geospatial technology liaison and strategic advisor with over 20 years of experience across the defense and commercial sectors. A veteran of the U.S. Air Force, he specialized in imagery analysis and order of battle before transitioning to executive leadership as the CEO of Midgard Raven, LLC and the founder of Project Geospatial, a 501(c)(3) dedicated to highlighting innovation within the geospatial ecosystem. Adam bridges the gap between technical development and market storytelling, leveraging his extensive background as a journalist and industry consultant to help companies navigate complex technology landscapes.

https://www.linkedin.com/in/adamsimmonsgeo
Next

NORTH AMERICA GEOSPATIAL EVENTS