Geometry

Geometry

Several Fastighetsbenchmark resources carry spatial geometry. You can filter by a spatial region and opt into GeoJSON geometry in responses. All coordinates are WGS 84 (SRID 4326) — longitude/latitude in degrees.

Geometry applies to the three geo-bearing resources: property-units, samlingar, jamforelseobjekt.

Filtering by region

Three GET-friendly shapes plus a POST escape hatch for large inputs.

Bounding box

?bbox=minLon,minLat,maxLon,maxLat

curl -H "X-Api-Key: $SEDIS_API_KEY" \
  "https://api.sedis.se/v2/fastighetsbenchmark/property-units?bbox=17.8,59.2,18.2,59.4"

Note — densification. A bounding box is a rhumb (constant-latitude) rectangle, but SQL Server reads polygon edges as great-circle arcs — so a naive wide box would bow and clip rows near its southern/northern edges. The API automatically densifies the constant-latitude edges of ?bbox= into small segments before the spatial test, so the box behaves like the rectangle you drew. (This is the SED-891 great-circle fix.) Only the ?bbox= shorthand is densified — a ?wkt= polygon or a POSTed GeoJSON polygon is honored verbatim as the exact shape you supplied.

Point + radius

?nearLon=X&nearLat=Y&radiusM=N

radiusM is metres (clamped to a sane maximum). The server builds a circular buffer around the point.

curl -H "X-Api-Key: $SEDIS_API_KEY" \
  "https://api.sedis.se/v2/fastighetsbenchmark/property-units?nearLon=18.07&nearLat=59.33&radiusM=2000"

Arbitrary polygon (WKT)

?wkt=POLYGON((...))

SRID 4326 assumed. Good for small/medium shapes that fit in a URL.

Large shapes — POST search

URLs cap out around a few thousand characters; large polygons / MultiPolygons / GeoJSON Features blow past that. POST the geometry instead, to the matching /search endpoint:

curl -X POST -H "X-Api-Key: $SEDIS_API_KEY" -H "Content-Type: application/json" \
  "https://api.sedis.se/v2/fastighetsbenchmark/property-units/search" \
  -d '{
        "geometry": { "type": "Polygon", "coordinates": [[[17.8,59.2],[18.2,59.2],[18.2,59.4],[17.8,59.4],[17.8,59.2]]] },
        "propertyType": 1,
        "pageSize": 100
      }'

The body accepts either a GeoJSON geometry or a WKT string, plus the same named filters / page / pageSize / sort / fields you'd use on the GET. The response envelope and item schema are identical to the GET — you only changed the transport. POST search responses are not HTTP-cached (Cache-Control: no-store, no ETag).

Getting geometry back (opt-in)

Geometry is omitted by default (it's heavy and most benchmarking workloads are tabular). Opt in with sparse fieldsets:

curl -H "X-Api-Key: $SEDIS_API_KEY" \
  "https://api.sedis.se/v2/fastighetsbenchmark/property-units?sedisId=PU-1&fields=sedisId,name,geometry"

{
  "data": [
    {
      "sedisId": "PU-1",
      "name": "Example property",
      "geometry": { "type": "Polygon", "coordinates": [[[18.06,59.32],[18.07,59.32],[18.07,59.33],[18.06,59.33],[18.06,59.32]]] }
    }
  ],
  "page": 1, "pageSize": 50, "totalCount": 1, "totalPages": 1
}

• Output is GeoJSON, SRID 4326.
• Geometry is server-simplified (a small tolerance) to keep payloads lean — it is a faithful but slightly generalized outline, not survey-grade precision.

Sending a location

You can give a property unit its location when you create or update it — a GeoJSON Point, [longitude, latitude] in WGS 84 (or [easting, northing] in SWEREF 99 TM with geometryCrs). See Writing data → Sending a location.

How filtering and tenancy combine

The tenant filter (Multi-tenant isolation) applies first, then the geometry filter narrows your already-scoped rows. A spatial query can never surface another customer's property.