Working with your data — PostGIS, GeoServer & HTTPS

Local uploads vs published layers

In the app, Add Layers lets you upload GeoJSON or a Shapefile ZIP for the current map session. That is useful for quick checks and drafting. Small local vectors may be saved with the map; large files, failed inlines, or sources that never persisted will not reliably reopen on another computer or browser.

For maps that must travel with your team, publish authoritative data with PostGIS → GeoServer (WMS / WMTS / WFS), then add those OGC URLs in Globe (My servers or From URL). Globe does not become the warehouse for your enterprise data.

Esri File Geodatabase (FGDB)

Globe does not upload File Geodatabases in the browser. Treat FGDB as a desktop/source format and convert into the stack Globe already works with:

Convert FGDB feature classes to PostGIS (or to an intermediate format GeoServer can read).
Publish layers in GeoServer from that store.
Add the GeoServer WMS, WMTS, or WFS endpoint in Globe.

Common conversion tools (pick what your team already uses):

QGIS — open the FGDB layer, then export / DB Manager into PostgreSQL.
GDAL / ogr2ogr — scripted loads into PostGIS (FileGDB or OpenFileGDB drivers).
GeoPandas / Fiona — Python workflows into PostGIS.
Esri tools — if you already export to PostGIS or open formats your org supports.

Once features live in PostGIS (or another GeoServer store), the Globe path is the same as any other published layer.

GeoJSON and Shapefile

Quick path: Add Layers → Local files → use on the map for this session.
Durable path: load into PostGIS (QGIS, ogr2ogr, GeoPandas, etc.), publish in GeoServer, add the OGC service in Globe.

GeoServer can also serve some file-based stores; many teams still prefer PostGIS as the system of record and GeoServer as the publisher. See Map builder for PostGIS and GeoServer for how Globe fits that stack.

Already running ArcGIS Server?

You do not have to move data into PostGIS or GeoServer just to use Globe. If your organization already runs ArcGIS Server, enable the OGC services you need—typically WMS, WMTS, and/or WFS—on the map or feature services you want to share, then add those service URLs in Globe (My servers or From URL) the same way you would for GeoServer.

ArcGIS Server remains your publisher; Globe is the browser map builder that consumes those OGC endpoints. The same HTTPS and certificate guidance below applies: if Globe is on HTTPS, give it an https:// ArcGIS OGC URL the browser trusts.

Typical path into Globe

Prepare once on your servers; compose and share maps in the browser.

1. Prepare data

Clean attributes and geometry in your GIS tools; load into PostgreSQL / PostGIS when you need a durable store.

2. Publish OGC services

In GeoServer, create a store and publish layers (often under /geoserver/…). Or, on ArcGIS Server, enable WMS / WMTS / WFS on the services you already run. Note the service URLs Globe will fetch.

3. Serve over HTTPS

Expose those URLs with a certificate the browser trusts (public CA or internal/self-signed). See below.

4. Add in Globe

Sign in → open a map → Add Layers → My servers or From URL → fetch → add selected layers. In-app help: Add Layers documentation after you open the app.

Why your GIS server often needs HTTPS

The hosted Globe app is served over HTTPS. Modern browsers treat requests from an HTTPS page to an HTTP GIS endpoint as mixed content and block them. Capabilities fetch, WMS/WMTS tiles, and WFS feature requests can fail in Globe even when the same GeoServer or ArcGIS Server works in its own web UI or on an HTTP-only page.

Fix: give Globe an https://… endpoint for your GeoServer or ArcGIS OGC services (or a reverse proxy in front of them). Globe does not terminate TLS for your GIS servers; that stays under your control.

Certificate options

Choose based on who must open the map and where GeoServer lives:

Public hostname + public CA (e.g. Let’s Encrypt, commercial CA) — best when users outside your org open maps in normal browsers without installing anything.
Organization CA — common on corporate networks; machines already trust the internal CA.
Self-signed certificate — fine for labs, demos, and locked-down networks if every user’s browser (or OS trust store) trusts that cert or your internal CA that signed it. Without trust, the browser will warn or refuse connections and Globe cannot load layers.

Self-signed is a valid way to unblock HTTPS↔HTTPS for testing; for production audiences, prefer a CA your users already trust.

Ways to put HTTPS in front of GeoServer

Most teams leave GeoServer listening on HTTP internally and terminate TLS at a reverse proxy. You can also enable HTTPS on Jetty. ArcGIS Server is often already published through IIS or another HTTPS edge— use that public https:// OGC URL in Globe when it is available. Below are options for GeoServer—not a single mandated architecture.

Reverse proxy (recommended pattern)

Browser → HTTPS on proxy → HTTP (or HTTPS) to GeoServer on localhost or a private network. Configure proxy headers so GeoServer generates correct HTTPS capability URLs (proxy base URL / forwarded headers; see GeoServer’s reverse-proxy documentation).

IIS on Windows

Install the certificate in IIS (self-signed for lab, or a trusted cert for wider use).
Use Application Request Routing (ARR) and URL Rewrite to reverse-proxy https://your-host/geoserver to GeoServer’s HTTP port (often 8080).
Useful when Windows / IIS is already your edge web server.

Microsoft docs cover ARR reverse proxy and IIS HTTPS bindings; pair those with GeoServer’s proxy base URL settings.

nginx

Listen on 443 with ssl_certificate / ssl_certificate_key (self-signed or CA).
proxy_pass to http://127.0.0.1:8080 (or your GeoServer host).
Forward Host, X-Forwarded-Proto, and related headers; set GeoServer’s proxy base URL to the public HTTPS origin.

Apache HTTP Server

Enable mod_ssl and mod_proxy / mod_proxy_http.
Virtual host on 443 with your cert; ProxyPass / ProxyPassReverse to GeoServer.
Same idea as nginx: HTTPS at the edge, correct forwarded proto, GeoServer proxy base URL.

Jetty HTTPS (GeoServer’s embedded server)

Configure an HTTPS connector in GeoServer’s Jetty config and point it at your keystore (self-signed or CA-signed).
Fits smaller installs that do not already run IIS/nginx/Apache.
You still need browsers to trust the certificate, and you still need CORS configured for browser map clients.

Other edges

Load balancers, API gateways, and cloud HTTPS listeners follow the same pattern: terminate TLS where you already manage certificates, keep GeoServer on a private port, and advertise the public https:// service URL in Globe.

Self-signed certificates — practical notes

Generate a key + cert (OpenSSL, IIS self-signed, or your org’s PKI tools).
Install the cert on the proxy or Jetty keystore.
Trust it on each client that will open Globe (OS trust store, browser settings, or MDM). A one-off “Advanced → proceed” click is not enough for reliable tile/API use in every browser.
In Globe, paste the https:// GetCapabilities or service URL (not the old http:// URL).
Confirm CORS on GeoServer (or the proxy) so the browser allows cross-origin WMS/WMTS/WFS from https://globegeospatial.com (or your app origin). Without CORS, layers and thumbnails can fail even when HTTPS is correct.

For public pilots, move from self-signed to a CA your users already trust as soon as the hostname is stable.

Checklist before adding layers in Globe

Service URL starts with https:// when Globe is on HTTPS.
Certificate is trusted in the browser you use for Globe.
GetCapabilities opens in that same browser without certificate errors.
CORS allows the Globe origin for the OGC endpoints you use.
GeoServer proxy base URL (if behind a reverse proxy) matches the public HTTPS URL.

Stack overview: PostGIS & GeoServer map builder. Product tour: Product. Access today is by invitation — Request an invitation