How to Upload an Esri File Geodatabase to a Web GIS

To upload an Esri File Geodatabase to a web GIS, zip the geodatabase folder (the one ending in .gdb) and upload the ZIP through the project's upload dialog. The platform ingests the contents as an ingestion job and tracks the outcome, including partial failures, so one problem feature class does not have to mean losing the whole upload. In Geosys AI, you then check the coordinate system of each layer and work with the results next to your other project data.

This guide walks through preparing the ZIP, what to expect during ingestion, what to do when only part of it succeeds, and how to check the result.

What is a File Geodatabase?

A File Geodatabase is a folder-based format from Esri that stores many datasets in one place. It can hold feature classes, which are the spatial layers, along with tables, relationship classes and other items. Because the .gdb is a folder full of small binary files, you cannot upload it as a single file. Zipping it is the standard way to move it around.

Step 1: Prepare the ZIP

Before uploading, tidy the source:

• Zip the whole .gdb folder, not just the files inside it. Keeping the folder name inside the ZIP avoids confusion later.
• Remove copies, backups and lock files you do not need. A geodatabase left open in desktop software may contain temporary lock files, and they only add noise.
• Note the coordinate system of each feature class you care about. You will want to compare it with what the platform reports.
• Consider how large the ZIP is. Very large archives take longer to upload and to process, so keep only the feature classes the project needs.

Geosys AI also accepts shapefiles, GeoJSON, GeoPackage and GeoTIFF rasters. ZIP uploads are scanned for spatial files, and one ZIP can produce more than one dataset. Ask us if you are unsure whether your geodatabase contents are covered, since some geodatabase items, such as relationship classes and domains, may not translate into a web layer.

Step 2: Upload and let ingestion run

Upload the ZIP into the project. The platform keeps a record of File Geodatabase ingestion from ZIP uploads as an ingestion job, with a status and the archived upload. That job record is what lets the platform report on the outcome instead of leaving you with a silent failure.

While the job runs, keep working elsewhere in the project. Larger geodatabases take longer, and the datasets appear as they are processed.

Step 3: Handle partial failures

A geodatabase often holds many feature classes, and it is common for one or two to have a problem, such as an unsupported geometry type or a damaged table. The ingestion job is designed with partial-failure tracking, which means the outcome is recorded per upload rather than as a single yes or no.

When some layers do not arrive:

1. Check which feature classes did appear in the project.
2. Compare that list with the source geodatabase.
3. For each missing feature class, export it from your desktop software as a shapefile, GeoPackage or GeoJSON and upload it on its own.
4. If a specific class keeps failing, send us the details and the dataset so we can look at it.

Exactly how the failure details are shown in the interface can differ, so if a layer is missing and you cannot see why, ask us. The important point is that a partial result is still a usable result: what did arrive can be checked and used while you fix the rest.

Step 4: Check the coordinate system (CRS)

Once layers appear, the first thing to verify is the coordinate system. Each dataset stores its CRS, bounds, feature count, geometry type and attribute metadata after upload, so you can compare them with the source.

Check these for every layer:

• The EPSG code matches the geodatabase. A geodatabase with no defined coordinate system is the usual source of layers that land in the wrong place.
• The bounds make sense for your area. A layer that appears near the coordinates 0,0 usually has a missing or wrong CRS.
• The feature count matches what you expect.

Raster uploads work differently and require you to confirm the EPSG before they are processed. Our guide on viewing point clouds online describes the same confirm-first habit for LiDAR data.

Step 5: Work with the layers

After ingestion, each feature class behaves like any other dataset in the project:

• Style and label it, and toggle it on the map.
• Look at the attribute table and filter it.
• Ask questions in plain language, such as how many features meet a condition, or which features fall inside a boundary.
• Share the project with clients through a read-only link, as described in how to share a GIS project with clients without accounts.
• Connect an assistant to the project through MCP, where that is enabled for your organization.

If the source data changes, replace the dataset file instead of starting again. The update keeps the dataset's metadata continuity, preserves descriptions for matching columns and flags new columns that need a description.

Tips for smoother uploads

• Upload one geodatabase per ZIP, and name the ZIP clearly.
• Keep a list of the feature classes you expect, so you can verify quickly.
• Fix invalid geometries in your desktop software first if you already know about them.
• Do a small test upload before sending a whole enterprise export.

You can see the wider set of upload and analysis capabilities on the features page.

FAQs

Can I upload a File Geodatabase directly? Zip the .gdb folder and upload the ZIP. The platform ingests File Geodatabase content from ZIP uploads and tracks each ingestion.

What happens if some feature classes fail to load? Ingestion tracks partial failures, so the feature classes that succeed remain available. Upload any missing ones separately as a shapefile, GeoPackage or GeoJSON, or contact us.

Does every geodatabase item become a layer? Not necessarily. Feature classes are the spatial layers you should expect. Other geodatabase items may not translate, so check the result against your source.

How do I know the coordinate system is right? Compare each layer's EPSG code and bounds with the source, and check a known location on the map. A layer far from your project area usually has a missing or wrong CRS.