Grillplatser som öppna data - hur du publicerar enligt specifikation

Alla kommuner har någonstans grillplatser. Under 2022 önskade MTG-kommunerna inventera och upprätta förbättrad register och skötselplan för sina grillplatser i kommunen.

Inom ramen för projektet Nationell Dataverkstad har vi på MetaSolutions samordnande att ta fram en specifikationer. I detta fall hjälpte @tomas.monsen och vi tog tillsammans fram specifikationen för hur informationen om grillplatser bör publiceras som öppna data. Arbetet påbörjades redan 2021. Under arbetet med specifikationen för en sådan datamängd, kontaktades webbtjänsten grillplatser.nu med tanke om att skapa en specifikation som kan nyttjas för att dels beskriva grillplatser på denna tjänst, för kommunens egna behov och för allmänhetens intresse.

Specifikationen som blev resultatet lanseras och har tagits fram inom ramen för samverkansprojektet “Dataportal Väst”.

Om du aktiverat skördning till dataportaler som dataportal.se kan du enligt DCAT-AP visa upp att du publicerat enligt specifikationen - lättare för tagare!

Genom det gemensamma arbete med specifikationen har flera kommuner också börjat sina publiceringar. Del i arbetet har flera kommuner inom offentlig sektor och tagare varit inblandade för att det ska vara möjligt för dem att stödja specifikationen.

Det finns en del utmaningar när denna information ska publiceras och vi har försökt ta höjd för dessa i arbetet och lagt till mer information i rekommendationen.

Diskutera gärna alla aspekter kring datamängden och denna specifikation här i tråden. Både hur den kan och bör publiceras samt tankar och synpunkter du som användare av informationen har.

Specifikationen finns publicerad här och är tillgänglig att välja på den nationella dataportalen dataportal.se och går att importera enkelt därifrån till EntryScape.

Specifikationen består av följande resurser:

Specifikation för publicering av grillplatser
Här finns beskrivning av specifikationen och en guide för vad som behöver göras för att publicera grillplatser som öppna data. Detta är ofta det bästa dokumentet att läsa först. Finns här.

Källkod - validering
Här finns den tekniska källkoden som ligger till grund för hur grillplatser ska publiceras. Vilken information som ska publiceras och definitionen av varje datapunkt. Källkod finns på GitLab här.

Mall för data i CSV-format
Ett exempel på hur den tekniska rekommendationen kan se ut när man implementerat den i JSON-format. Finns här.

Dataschema (schema i CSV)
Ett exempel på hur den tekniska rekommendationen kan se ut när man implementerat den i JSON-format. Finns här.

Grillplatser - DCAT-AP-SE
Ett förslag på metadata enligt specifikationen DCAT-AP-SE som används för att göra information sökbar på Sveriges dataportal dataportal.se. Viss metadata bör vara gemensam för alla som publicerar denna information som öppna data och viss information är specifik för respektive publicerande organisation.

Se relaterade trådar:

En synpunkt om specifikationen för grillplatser - den innehåller attributnamnet ‘table’ som är ett reserverat ord för Esri’s geodatabaser.

Det tog mig en stund att komma på problemet när jag skulle läsa från en sde databas och skriva, enligt specifikationen, till en .gdb med FME.

https://community.safe.com/s/article/attribute-table-in-arcgis-could-not-load-data

När man importerar/exporterar en csv till en .gdb via ArcGIS lägger den automatiskt till en understreck i slutet av attributnamnet så det blir ‘table_’.

Jag skulle vilja lagra data enligt samma specifikation i en sde databas oavsett om det används internt hos oss, externt i våra kartor eller publiceras som öppna data.

1 Like

@williamw Jättebra återkoppling! Kopplar in @alex och @tomas.monsen i tråden här som skrev specifikationen. :slight_smile:

Hej ja det var ju olyckligt och inget vi tänkt på eftersom vi inte anser oss kanske kunna ta hänsyn till alla upptänkliga systems reserverade ord, men i det här fallet borde vi kanske fundera på en annan lösning då just “table” torde vara ett ord som kan reserveras i flera andra språk och system, faktiskt inte så bright av oss…

Frågan är hur vi gör, @alex om vi ska lägga till en ny version där vi funderar över något annat mer passande namn än “table” för “bord” .

Sen undrar jag om det inte ändå går att jobba sig förbi det här genom att quotea namnet som i SQL där jag kan ha en tabell med namnet FROM (som ju är ett reserverat ord) om det quotas som ‘‘FROM’’ eller [FROM].

Exempel
SELECT [FROM] FROM myTableName ? Det är ju väldigt fult, och säkert helt emot best practice, men möjligheten finns ju där?

2 Likes

Noterat. Vi undersöker detta vidare! Tack för input @williamw - vill du delta i utvecklingen vidare hittar du projektet på https://gitlab.com/lankadedata/spec/grillplatser

1 Like

Hej @alex jag är inte riktigt säkert på hur jag gör på gitlab om jag är ärlig! Jag har nog inte fler synpunkter på grillplatser ändå.

Något som jag tycker att det hade varit bra om det stod på alla specifikationer är EPSG koden för koordinatsystemet samt kanske en anteckning, på samma sätt som med csv filer att om man har datorn inställd på svenska, att decimal punkten blir en komma (i vissa system) och då blir det fel i till exempel Leaflet.

Hej @williamw du har helt rätt, vi har noterat EPSG-behovet vid specificering av koordinater och kommer att revidera detta samt ta med oss det på kommande specifikationer - troligen gör vi en mindre revision på de vi redan har publicerat oxå, där detta saknas.

Vi bör väl ange att det är EPSG 4326 vi avser, håller du med baserat på de specifkationer och det du kan härleda över våra koordinatexempel som publicerats?

1 Like