QGIS and ArcGIS Integration with Datgel View

Datgel View for QGIS and ArcGIS users. Connect your gINT borehole data to QGIS and ArcGIS Pro through the modern OGC API — tiles for fast pan and zoom, and live vector features for analysis. No plugins, no data exports.

OGC API endpoints

Every Datgel View deployment exposes its authorised projects through the modern OGC API standard. Two complementary endpoints — raster tiles and vector features — covering both the "show me a fast basemap of every borehole" workflow and the "give me the actual points so I can run analysis" workflow.

Tiles   : https://your-deployment/api/ogc/tiles/WebMercatorQuad/{z}/{y}/{x}?apikey=YOUR_KEY
Features: https://your-deployment/api/ogc/key/YOUR_KEY/features
          https://your-deployment/api/ogc/key/YOUR_KEY/features/collections/project_{GdmsId-or-ProjectId}/items

Tiles render as 256×256 PNGs in WebMercatorQuad (EPSG:3857). Features return GeoJSON in WGS84 (EPSG:4326) with full attributes (PointID, Type, Elevation, Project) per RFC 7946.

Where the API key goes. For Features, put the key in the URL path — /api/ogc/key/YOUR_KEY/features. QGIS drops the query string when it builds the internal /conformance and /collections requests it uses to discover what a connection offers, so a ?apikey= connection URL loses its key on exactly those requests and the collection tree stays empty. A key in the path survives them. The ?apikey=YOUR_KEY query form still works — existing connections keep working, and it is fine for scripts, one-off requests and single-layer adds. For Tiles, always use ?apikey=YOUR_KEY: a tile URL is a fixed {z}/{y}/{x} template with no discovery step, and the key-in-path form applies to Features only.

One collection per project — and one for everything

  • project_all — a virtual collection that aggregates every project you have access to into one feature set. Connect once, see everything. Feature IDs are {projectId}:{pointId} so they stay globally unique.
  • project_{GdmsId} — per-project collections now use the GDMS ID by default (e.g. project_DTB-7.02.0-si). Spaces and URL-unsafe characters are auto-sanitised. Numeric project_{ProjectId} still resolves as a fallback so existing connections keep working.
  • project_locations — the shapes that mark where each project physically is: points, lines and polygons drawn, bulk-imported or geocoded by your admins, exposed as their own Features collection. Useful for a national portfolio view alongside the individual test locations.

What you get in your desktop GIS

  • Pre-rendered tiles with the same PointType symbols as the web map — fast pan and zoom even at country scale
  • Live vector features with click-through attributes: PointID, type, elevation, project
  • One feature collection per gINT project — toggle on the projects relevant to your current job
  • BBOX, paging, and limit support on the Features endpoint for filtered queries
  • Per-project transparency, ordering, and styling alongside your other layers
  • File enclosures on every feature — the /items response includes a files[] array with download links for each attached PDF log or site photo
  • Per-column units in a pointUnits map on every /items response — render values with the right metres / kPa / SPT-N units in QGIS field calculator or pop-ups
  • Full PROJECT metadata returned on /collections/{id} — project name, client, location, contractor, all the gINT PROJECT columns — without a second request
  • Per-user, scoped API keys with optional expiry — revoke instantly, no shared credentials

Connecting QGIS 3.30+

For tiles (fast basemap):

  1. Get an API key. Sign in to your Datgel View deployment and visit /account/api-keys. Choose the tiles scope. The plaintext is shown once at creation; copy it immediately.
  2. Add an XYZ Tiles connection. Browser panel → right-click XYZ Tiles → New Connection.
  3. Paste the URL: https://your-deployment/api/ogc/tiles/WebMercatorQuad/{z}/{y}/{x}?apikey=YOUR_KEY
  4. Drag the connection onto your map.

For features (analysis):

  1. Get an API key with the features scope (or use a single key with both scopes).
  2. Add an OGC API - Features connection. Browser panel → right-click OGC API - Features → New Connection.
  3. Paste the URL: https://your-deployment/api/ogc/key/YOUR_KEY/features — the key goes in the path, not as ?apikey=, so QGIS keeps it on the collection-discovery requests.
  4. Connect — you'll see project_all, project_locations, and one collection per gINT project you have access to. Drag the ones you want onto your map. If the tree stays empty, re-check that the URL is the /api/ogc/key/… path form.

Connecting ArcGIS Pro 3.2+

For tiles:

  1. Get an API key with the tiles scope.
  2. In ArcGIS Pro: Insert → Connections → New XYZ Tile Connection or add via the Catalog pane as a tile layer.
  3. Paste the URL with the ?apikey=... query parameter. ArcGIS writes the template as {level}/{row}/{col} rather than {z}/{y}/{x} — the meaning is the same.

For features:

  1. Get an API key with the features scope.
  2. In ArcGIS Pro: Insert → Connections → New OGC API Server Connection.
  3. Paste the URLhttps://your-deployment/api/ogc/key/YOUR_KEY/features and add the project collections to your map. The ?apikey= query form also works here, but we recommend the key-in-path form for any OGC API - Features client — a key in the path cannot be lost on a discovery sub-request.

Other clients

The OGC API standard is supported by GDAL/OGR, FME, MapInfo Pro 2023+, Global Mapper, and any other modern GIS client. The same per-user API keys work everywhere.

Beyond GIS — Leapfrog Works

The same per-user API keys also power Datgel Leapfrog Sync, a Windows companion app for Seequent Leapfrog Works. It pulls your authorised boreholes from Datgel View's drillhole export API and writes Leapfrog-ready collar.csv, survey.csv and per-interval-table CSVs (e.g. lithology.csv) into a folder you choose, reprojected into your dataset's CRS. Map the columns once in Leapfrog; every refresh after that is "run Sync, click Reload Data". A command-line companion (datgel-leapfrog-sync) supports scripted and scheduled runs for an always-current model.

Where the keys come from

Every signed-in user can mint their own API keys at /account/api-keys — no admin involvement needed. OrgAdmins can manage keys for any user in their organisation at /admin/apikeys. Keys are scoped (tiles only, features only, or both), can be set to expire, and can be revoked instantly.

You can also pin a key to a specific subset of projects when minting it. A pinned key always shows the intersection of the pinned set and the owner's live access — useful for handing a client a key scoped to their job only, or for a CI pipeline that should never widen beyond one project.