Location Data

Your own location data

Store your business's places on Orvia — branches, warehouses, customers, drivers — with your own fields, then query them by properties and location in one API call.

How it fits together

Collection

A category of your points — warehouses, stores, drivers — with its own schema.

Fields

The schema: each property's name and type (string, number, boolean, date), plus required, allowed values and an index.

Point

One record: title, description, location and properties that follow the schema.

Query

Filter by properties and by location (radius or bounding box) in one request, sorted by any field or distance.

Collection: warehouses
  ├── fields:  status (string, one of active/inactive/maintenance, indexed)
  │            capacity (number, indexed) · manager (string) · opened (date)
  └── points:  { title, location: { lat, lng }, properties: { status, capacity, … } }

Base map + optional collections

The base map and your data are separate resources. /api/v1/tiles never contains customer data, and no collection loads by itself: your app decides which collections to show — one, several or none — and loads each from its own endpoint.

Base map            GET /api/v1/style.json · /api/v1/tiles/{z}/{x}/{y}.pbf
   +
Your collections    GET  /api/v1/collections/{name}/features?bbox=…   (map viewport, GeoJSON)
(only if you ask)   POST /api/v1/collections/{name}/query             (properties + location)

Orvia keeps only what location queries need. Your listings, photos, documents and users stay in your own database — store their id (e.g. a listing_id field) on each point and look the details up there.

Why a schema

Every property is checked against the collection's fields: unknown keys, wrong types and values outside the allowed list are rejected with a 400. Your data stays consistent, queries can compare values reliably, and indexed fields stay fast as a collection grows to millions of points.

In four calls

POST /api/v1/collections                         → create "warehouses" with its fields
POST /api/v1/collections/warehouses/features     → add points (one, or up to 100 at once)
POST /api/v1/collections/warehouses/query        → "active, capacity > 1000, within 5 km"
GET  /api/v1/collections/warehouses/export       → everything as GeoJSON

You can also manage collections, fields, indexes and points without code in your account under Location Data.

Usage units

Location Data calls draw on the same monthly usage units as the rest of the API, weighted by how much work they do (see all unit costs):

Operation	Calls	Units
Location read	List collections, read a feature	1
Schema change	Create a collection, add a field or index	1
Location write	Create, update or delete a feature	2per feature
Spatial query	Query by properties and location, viewport (bbox) reads	5
Export	Whole collection as GeoJSON	10

Plan limits

Plan	Collections	Stored points
Growth	2	1,000
Startup	10	50,000
Business	50	1,000,000
Enterprise	Unlimited	Unlimited

Going over a limit answers 403 with the limit in the message; nothing is deleted.