Utvecklare

För att använda plattformen finns det API:er tillgängliga för både konsumenter och producenter. Nedan beskrivs API:erna för att hämta information från plattformen och för att publicera information på plattformen.

Tekniska beskrivningar

Här hittar du tekniska beskrivningar för alla datamängder, hur mottagning fungerar, kommunernas uppladdning med mera.

För konsument finns tre API:er:

  • Sökning
  • Visning och
  • Nedladdning.

För producent finns två API:er:

  • Uppladdning och
  • Uppdatering.

API för konsument

Sökning och Visning bygger på:

  • OGC standarder,
  • OGC API for Features samt
  • WMS.

I sökning och visningstjänsten visas referensobjektet som är en delmängd av domänobjektet, anpassat för att hitta information. Det kan därför innehålla förenklad och aggregerad data. Syftet med referensobjektet är att hitta data i plattformen. Hela domänobjektet kan sedan laddas hem via nedladdning.

Geodatakatalog Sökning – sök referensobjekt för domänobjekt och resurser

Geodatakatalog Visning

Geodatakatalog Nedladdning - ladda ner domänobjekt och resurser

API för producent 

För publicering finns två API:er: Uppladdning samt Uppdatering. Uppladdning används för att ladda upp eller registrera tillhörande dokument till plattformen, så kallad tilläggsinformation. API:et för Uppdatering används sedan för att ladda upp domänobjekt och publicera dem.

Geodatakatalog Uppladdning - ladda upp resurser

Geodatakatalog Uppdatering - ladda upp domänobjekt

Scheman för informationsmodeller

Utbytesformatet för domänobjekt definieras av tekniska scheman (JSON-schema) som återspeglar aktuell informationsmodell. Dessa används för validering av uppladdade domänobjekt.

Övergripande teknisk information

Mediatyp

Varje modellversion har en egen mediatyp som ska anges när domänobjektet laddas upp i Geodatakatalog Uppdatering. Mediatypen återfinns i länken till domänobjektet i Geodatakatalog Sökning och i Content-Type- headern från Geodatakatalog Nedladdning, så att klienter vet hur de ska läsa filen på rätt sätt.

Tilläggsinformation

I vissa domänmodeller finns utrymme att länka in tillhörande dokument i objektet, t.ex. planeringsunderlag för detaljplan. Uppladdningstjänsten kan användas för denna sorts tilläggsinformation. Dessa filer blir då tillgängliga för konsumenter via Nedladdningstjänsten. Varje uppladdat dokument tilldelas en stabil unik identifierare som ska infogas på utpekad plats i domänobjektet innan det skickas in för publicering.

Inget annat än tilläggsinformation får laddas upp eller registreras i Uppladdning. Om inget publicerat domänobjekt hänvisar till en uppladdad fil kan den komma att rensas.

Objekt och underobjekt

Vissa informationsområden har flera sorters domänobjekt. De är i så fall arrangerade i en hierarki, med ett huvudobjekt och ett antal underobjekt. T.ex. i informationsområdet detaljplan finns huvudobjektet ”detaljplan” och underobjektet ”planbestämmelse”, där en instans av en detaljplan kan ha flera bestämmelser.

Alla objekt som hör till samma hierarki ska ligga ihop i samma fil - en fil per objektträd. Roten i filen är en GeoJSON Feature Collection, där varje ingående objekt är en Feature. En uppdatering av ett objekt betyder alltså att hela filen måste uppdateras.

På varje Feature bör attributet ”id” sättas. Om attributet är satt så ska värdet vara objektidentiteten. Om Featuren har en geometri bör även attributet ”bbox” sättas.

Geometri

I domänobjekten används GeoJSON för att beskriva en företeelses utbredning. Formatet har dock ett antal begränsningar och egenheter som plattformen har regler för.

Geometrier i plattformen har metadata knutet till sig i en geometrimodell där själva geometrin sätts i attributet ”position”. I en GeoJSON Feature förespråkas istället att geometrin sätts i attributet ”geometry” i roten på objektet. En Feature kan dock bara ha en geometri, vilket är ett problem för vissa informationsmängder. Plattformen använder därför dessa regler för att placera geometrin: Om företeelsen bara kan ha en geometri ska ”geometry” användas och ”position” ska inte sättas. Om företeelsen kan ha flera geometrier ska ”geometry” sättas till null och ”position” användas istället. Även om en viss instans endast har en geometri ska ”position” användas om modellen tillåter flera geometrier. I detta fall tvingas ”geometry” till null i JSON-schemat.

GeoJSON tillåter normalt endast referenssystemet WGS 84. I ett tidigare utkast av standarden kunde attributet ”crs” sättas i en geometri eller Feature för att ange ett annat referenssystem. Detta används dock INTE av plattformen. Istället anges referenssystemet i attributet ”koordinatsystemPlan” (och ”hojdsystem”) i plattformens geometrimodell.

Geometrimodellen tillåter geometrityperna kropp och multikropp även om inte GeoJSON gör det. En kropp implementeras med en MultiPolygon, där varje yta är en av kroppens sidor. Alla ytor tillsammans måste forma en sluten kropp. En multikropp implementeras med en GeometryCollection, där varje ingående geometri är en kropp i form av en MultiPolyon.