# Available services
The endpoints each service exposes, and how they map back to your project layers.
Every endpoint on this page is relative to your project's service URL, which is shown on the Publish GIS services administration page - see Publish a layer as a service. Where you see {service URL} below, substitute that address.
Opening the service URL in a browser gives you a portal page listing the three services available for the project.
# Choosing a service
| You want to | Use |
|---|---|
| Read 3D features with their attributes, filter them, or export them to a file | OGC API - Features |
| Draw a fast, styled vector basemap in ArcGIS Online, ArcGIS Pro or a web map (2D only) | ESRI Vector Tile Service |
| Display published aerial or scanned imagery | WMTS |
# Output formats
Most endpoints can return either a human-readable page or machine-readable data, selected with the f query parameter:
f value | Returns |
|---|---|
html | The browsable portal page |
json (or pjson) | JSON |
pbf | A vector tile |
png | An image tile or sprite sheet |
qlr | A QGIS layer definition file |
mapbox | A Mapbox GL style document |
wmts | WMTS capabilities XML |
If you leave f off, the service picks a sensible default: browser-facing paths redirect to html, and data paths such as /oapif/collections and /items default to json. A file extension on the path works as well as the parameter, so /oapif/collections.json is equivalent to /oapif/collections?f=json.
Feature data from /items is always returned as GeoJSON.
# OGC API - Features
OGC API - Features is the modern, REST-based successor to Web Feature Services (WFS (opens new window)). It is the right choice when you need the actual geometry features and their attribute values.
Vector layers only. A layer appears here once it has been published and contains at least one feature.
# Endpoints
| Endpoint | Purpose |
|---|---|
/oapif | Landing page - links to everything below |
/oapif/conformance | The OGC conformance classes this service implements |
/oapif/api | The OpenAPI description of the service |
/oapif/collections | List of available collections |
/oapif/collections/{collectionId} | A single collection and its extent |
/oapif/collections/{collectionId}/schema | The collection's attribute schema |
/oapif/collections/{collectionId}/items | The features, as GeoJSON |
/oapif/collections/{collectionId}/items/{featureId} | A single feature |
/oapif/collections/{collectionId}/styles | Styles for the collection |
# Collections and collection IDs
A Civillo layer usually contains more than one kind of geometry, and OGC API - Features requires a single geometry type per collection. Publishing therefore splits each layer into up to four collections, identified by an internal Civillo layer ID and a two-letter geometry suffix:
| Collection ID | Geometry |
|---|---|
L{layerId}PT | Points |
L{layerId}LN | Lines |
L{layerId}PY | Polygons |
L{layerId}TX | Text |
For example a layer with ID 28 that contains lines and polygons is published as L28LN and L28PY. The collection title carries the readable layer name and geometry type, such as Services-line, so that is what you will see in the collections list and in client applications.
Collections are only created for geometry types the layer actually contains.
# Query parameters on /items
| Parameter | Notes |
|---|---|
bbox | Four comma-separated numbers, minx,miny,maxx,maxy. Supply it once only. |
bbox-crs | Coordinate reference system of bbox. Only 4326 (the default) and 3857 are accepted. |
limit | Features per page. Default 1000, maximum 10000. |
offset | Number of features to skip. Use with limit to page through a collection. |
properties | Comma-separated list of attributes to return. Names must exist on the layer. |
sortby | Attribute to sort by. Must be one of the returned properties. |
f | Output format. |
Responses include self, next, prev and first links that carry your parameters through, so a client can page a whole collection without rebuilding URLs.
Feature coordinates are always returned in EPSG:4326 (WGS 84 longitude/latitude). To get the data in another projection, use the file export described in Using published services in other applications.
Where a layer holds 3D geometry, the z ordinate is preserved: GeoJSON positions come back as [longitude, latitude, z]. Clients that only read the first two ordinates will ignore the elevation, but it is there for those that can use it.
WARNING
Temporal filtering is not supported. Sending a datetime parameter returns an error rather than being ignored, and there is no CQL filter parameter - filter spatially with bbox, or filter in your client.
# ESRI Vector Tile Service
The ArcGIS-compatible service serves your vector layers as styled vector tiles. It reports itself as ArcGIS REST API version 11.2 and is tiles-only - it draws quickly and carries styling and attribution, but it is not a Feature Service and cannot be queried or edited.
Vector layers only.
# Endpoints
| Endpoint | Purpose |
|---|---|
/arcgis/rest/services | List of published services in the project |
/arcgis/rest/services/{serviceName}/VectorTileServer | The service description, tile info and levels of detail |
/arcgis/rest/services/{serviceName}/VectorTileServer/resources/styles/root.json | The default style |
/arcgis/rest/services/{serviceName}/VectorTileServer/resources/sprites/sprite.json | Sprite index (also sprite@2x.json, and .png for the sheet) |
/arcgis/rest/services/{serviceName}/VectorTileServer/tile/{z}/{y}/{x}.pbf | Vector tiles |
# Service names
The service name is the letter L followed by Civillo's internal layer ID. For example, a layer with ID 28 publishes as service L28.
Unlike OGC API - Features, the whole layer is one service regardless of how many geometry types it holds. The service list shows the readable layer name alongside the L{layerId} identifier, and clients such as ArcGIS Online will initially name the layer L28, so it is worth renaming it on the way in.
# Tile characteristics
| Property | Value |
|---|---|
| Tile size | 512 × 512 |
| Tile format | pbf (gzip compressed) |
| Spatial reference | EPSG:3857 (Web Mercator) |
| Zoom levels | 0 – 23 |
| Capabilities | TilesOnly |
| Style version | Mapbox style spec 8 |
# WMTS
Web Map Tile Service serves pre-rendered raster map tiles. This is how uploaded imagery layers are published.
# Endpoints
| Endpoint | Purpose |
|---|---|
/wmts | Browsable list of published imagery services |
/wmts/1.0.0/WMTSCapabilities.xml | The capabilities document - this is the URL to give a client |
/wmts/{serviceName}/{TileMatrix}/{TileRow}/{TileCol}.png | A single tile |
Requests are RESTful only; the key-value-pair (?request=GetTile&...) form of WMTS is not supported.
# Tile matrix and formats
| Property | Value |
|---|---|
| Tile matrix set | CivilloTileMatrix |
| Supported CRS | EPSG:3857 (Web Mercator), Google Maps compatible scale set |
| Tile format | image/png |
| Style | default |
# GDA2020 and GDA94
For Australian customers. Several web applications assume GDA94 where the datum is not specified. To cater for this, each Australian imagery layer is advertised twice in the capabilities document, once per datum:
{layer name} (GDA2020)- the default.{layer name} (GDA94)- the same imagery reprojected, requested with?datum=GDA94on the tile URL.
Pick whichever matches the datum the rest of your data is in. For background on datums and projections in Civillo, see Spatial reference systems.
# Finding a layer quickly
The OGC API, ArcGIS Services and WMTS links on the Publish GIS services page add a search parameter to the listing page URL, which filters the list down to the layer you clicked. The listing pages also have their own search box. This filtering applies to the browsable pages only; it has no effect on JSON responses.