Community på Sveriges dataportal

Hej!
Tänkte bara skryta lite - vi lanserar idag vår gemensamma karttjänst för ledig tomtmark i Skaraborg - 15 kommuner har enats om att dela data enligt den nationella specifikationen för ledig tomtmark och en av kommunerna står som värd för en karta driven av denna data.

Beställare är Business Region Skaraborg som tidigare har karttjänst för verksamhetsmark men som på begäran av näringslivet och entreprenörer och organisationer som vill verka i regionen även önskade dela mark för byggnation av villor och flerbostadshus.

Alla 15 kommunerna i Skaraborg har därför etablerat ÖD-förmåga och skaffat datakatalog och publicerat sin datamängd. En fin samverkan och faktiskt samarbete, där vi i sann Skaraborgsanda har hjälpt varandra med allt från att etablera förmåga, skaffa katalog, förankra i kommunledning och nätverk samt hacka ihop datasets och publicera dessa.

Jag är lite stolt över att vi lyckats med något som känns unikt i Sverige och vi hoppas att detta är startskottet på många fler samarbeten kring digitalisering och Öppna Data i Skaraborg - vi pratar redan om vad vi ska ha på kartan härnäst

Läs nyheten och hitta till kartan här;

https://skaraborg.se/var-verksamhet-ny/Regional_utveckling/nyheter-regional_utveckling/lediga-tomter/

Hej vad betyder det grönmarkerade? "Organizations on editera"?

Jag har hämtat detta från https://admin.dataportal.se/status/overview

Kan man få till en klickbar länk för att ta sig direkt till den publicerande organisationen också kanske?

Mvh
Tomas

Det kanske går att lösa med Sparql eller nåt sånt, vet inte, inte så bevandrad i det tyvärr, men på nåt sätt skulle jag vilja kunna programmatiskt komma åt innehåll utan att behöva veta ändpunkter för varje kommuns unika katalog. Filar på en valideringstjänst nu för "Ledig tomtmark" och en sån funktion på dataportal.se skulle underlätta en hel de.

Hej ursäkta sena svar, roligt att specifikationen diskuteras så aktivt.
Version 2 har påbörjats som skiss, men jag har under början av året bytt jobb, så det har hamnar lite på väntlistan.
Hoppas att kunna komma med utkast under våren eller till sommaren - vi kommer att försöka organisera oss smartare kring framtagning av specifikationer, något som kommer påverka hur och var specifikationen byggs.

Ser att ni kommit med fler idéer om fält och utformning och jag ska försöka sammanställa detta inför det fortsatta arbetet. Jag vill ju gärna att det blir så bra som möjligt, men ändå greppbart för dataägare - kan ju säga att det jag vet om kommuner hittills är att den här typen av data hanteras av verksamheter där den digitala mognaden inte alltid är på topp vilket är del av anledningen att vi valt ett platt format i tabellform.

Är det lämpligt att föra vidare diskussion om vidareutvecklingen här på forumet, vad tycker ni?

Hej hårdtestar sökfunktionen idag och hittar lite intressanta "buggar" som att en del organisationer förekommer flera gånger. Finns det flera skördningskällor som orsakar detta eller vad beror det på? Se nedan två exempel;

samt

Kan det vara så att den där katalogen "free" synkar över fler organisationer som redan har en katalog på något vis? Generellt, de dubletter jag hittat, har en med data och organisationer i, och en annan som är "tom".

Tack det återknyter lite till det jag frågat om också - hur får man "poäng" i utvärderingen och kan jag få se "under huven" på vad som anses vara fel, inte bara en procentsats. Länkrapporten går att ta ner men inget annat.

Jag precis som du, @Andreas-Sundberg anser mig följa det som följas bör och vill så klart ha cred för det via 100% uppfyllnad !

Tack, ser ut att funka som jag förväntar mig

Hej kan man programmatiskt via API bläddra i själva datakatalogen?
Jag menar ett API med tillhörande dokumentation för att kunna söka på "Lediga tomter" och få svar där jag kan jobba vidare mot organisationer, specifikationer, datamängder och distributioner, utan att behöva använda GUIt på dataportal.se?

Jag söker efter nåt sånt här alltså;

https://dataportal.se/api/v1/get-entities?organizational_units=kommuner+filter=has_publications

...och då får jag en lista över organisationer (organizational_units=kommuner) och med filtret "has_publications" dvs de har data publicerat.

Skulle va smutt för att kunna göra lite statistksammanställningar/leaderboards lokalt för att se hur våra kommuner ligger till.

Det här kanske finns, men jag hittar det inte - tycker jag klickat "på allt" nu
Eller ligger det här dolt bakom "admin.dataportal.se" nånstans där jag inte kan se det?

Hej, jag tänker att det skulle vara intressant om det gick att bläddra/söka efter vedertagna grupper av utgivare av data - exempelvis för mitt fall "Skaraborg".

Vad jag tänker är att det skulle gå att söka efter "Skaraborg" som utgivare/organisation och då få träff på alla kommuner, bolag osv som hör ihop i Skaraborg? Ett relativt vedertaget begrepp som innefattar 15 kommuner. Går det? Det kanske blir ohållbart att administrera, men då kanske man kan tänka sig att jag skapar en sådan compound-sökning själv och sparar för återanvändande när jag återkommer till sidan? Där jag kan sätta ihop organisationer själv och återanvända det sökbegreppet?

Hej jag tycker att sökfunktionen behöver trimmas, alternativt att den som publicerar artefakter kan tagga upp dem med alternativa sökord. Här försöker jag hitta specifikationen för badplatser;

0 träffar. Trist.

Sen prövar jag:

...och då får jag min träff.

Går det skruva lite kanske?

Hej, korta svar på detta, ska beakta dina andra inputs inför arbete med ny version.

@ChristerOlsson sa i Vägledning för att publicera data om grillplatser:

Började dåligt med att jag skulle titta på specifikationen och länken är bruten. https://dataportal.se/specifications/grillplatser/1.0 resulterar i en 404.

Verkar vara pågående störning, arbete pågår.

Stabila URLer är också ett starkt önskemål. Jag har känslan av att när någon publicerar en ny version av en csv på dataportalen så blir det en ny URL. Kan någon bekräfta eller dementera? Kanske inte en del av standarden men något som ändå bör poängteras.

Det är en handhavandefråga - man kan sätta ett alias på ex.vis ett autogemererat API, då behålls det namnet. Nog inte många som gör. Lägger man till en ny fil och tar bort den gamla = namnen bryts. Byter man ut en redan publicerad fil = identifieraren behålls. Jag har testat lite olika varianter. Misstänker att en vägledning kring detta vore önskvärt. Naturligtvis är persistent identiferare a och o.

Det bör skapas en validator någonstans där man kan skicka in en endpoint och validera om man följer specifikationen. Om ingen annan vill så kan jag skapa en sådan för geojson.

Ja det tror jag hade varit mycket bra, som validerar mot schemat. Jag tänker mig att en sådan validerare skulle kunna byggas on the fly, alltså suga i sig ett schema och kunna matcha mot vilka datamängder som helst. Det här skulle ju vara en fin feature i dataportal.se som hjälper till vid publicering "app app app din uppladdade källa värderar inte sant på alla attribut, här är fellistan: " osv.

@nsmart sa i Vägledning för att publicera data om grillplatser:

Hej!

Toppen specifikation som vi på kommer att börja med på vår kommun som testdatamängd för öppna data Här kommer en fråga om definitionen av ett av attributen:

I stadsmiljöer kan det finnas cykelparkering, elsparkscykelparkering, m.m. Parkering är såklart en helt värld och skapar starka känslor "nedströms" för mottagare av otydlig eller inkorrekt information. Jag utgår från att i dagens bilcentrisk värld att man (till nackdel för cyklister) menar bilparkering med nedanstående definition:

"Beskriver om det i närheten till grillplatsen (kortare än 100 meter) finns en parkeringsplats till vilken besökare av grillplatsen har tillgång."

Däremot framgår det inte. Skulle ni som utvecklar specifikation vilja precisera där?

/Nicholas

Hej, det finns tyvärr ingen mer precision på attributet än det som står i specen. Jag får erkänna att den här specifikationen skrevs med något unga och oförstörda ögon. Jag trodde mig kunna beskriva en parkeringsyta i specen, utan att beskriva parkeringsytan...

Nu i efterhand är det klart att man ska undvika det här - en parkeringsyta är en egen datamängd, inget som man nog borde beskrivas i relation till ett annat objekt INUTI det egna objektet.

Är det aktuellt att veta om man kan parkera bilen inom 100 meter från badplatsen?

• Troligen

Är det aktuellt att beskriva parkeringsplatsens storlek?

• Kanske

Är det aktuellt att beskriva kostnaden, storleken på rutorna, antal platser för rörelsehindrad, om det är bom, tillåtet camping på parkeringen osv...

• Nej. Det behöver nog beskrivas i en egen spec.

Vad man borde göra är ju att bygga nån sorts länkning/kunskapsgraf så att data över en badplats eller grillplats länkar till en datamängd som beskriver glasskiosk, parkeringsplats, lekplats osv.

Specen är skriven naivt (av yours truly) och hade jag skrivit den idag hade jag inte haft med attributet parkering alls. Kanske att jag ersatt det med en länkmöjlighet till en annan datamängd som beskriver parkering som ett eget objekt.

@nsmart sa i Vägledning för att publicera data om grillplatser:

@Björn-Hagström sa i Vägledning för att publicera data om grillplatser:

På dataverkstad.se står det att man inte får lägga till egna fält utöver de i specifikationen (om man ska kunna säga att man följer specifikationen). Jag undrar om det är så viktigt? Kan man inte göra specifikationen utbyggbar? Den som hämtar data får då slå ihop den med samma data från andra kommuner och matcha kollumnnamnen. Redan idag finns det inget som hindrar att kolumner kommer i olika ordning från olika kommuner så det krävs ändå ett jobb att matcha för att kunna samköra data.

En stor anledning till att jag frågar är att vi i Varberg jobbar för att publicera detta automatiskt utifrån att vi har det som geodata och visar den i vår webbkarta. Det är enkelt för oss att skapa osv och json genom en WFS men vi får automatiskt med två fält som inte finns i specen och det är FID (ett internt id) och GEOM (geometri). Vi har nyss upptäckt detta och fortsätter undersöka om vi kan ta bort dem. Vi vet att vi kan ta bort geom men då får vi lite problem med att publicera samma data med mer data än specifikationen pekar på (tar vi bort geom för vi det för alla distributioner).

Någon med mer erfarenhet om Geoserver och dessa fält kanske har tips på hur vi kan gå vidare?

Fantastisk fråga som Solna stad arbetar med i talande stund. Vi har "fid" och "geom" som behövs i vårt nuvarande upplägg då datamängden är lagrad i en MSSQL-databas. Hur har andra kommuner kommit runt problemet?

Jag tror det blir svårt att ändra specen så att attribut från namngivna system kan läggas till, FID (gissningsvis FeatureID?) och GEOM (gissningsvis GEOMetry, beskriver en yta som polygon?) är ju fält som absolut behövs för att köra det egna systemet, men det blir bökigt att få med dem i en spec - vad händer när nästa system kommer med ett nytt eget attribut?

Jag förstår utmaningen - Geometriservern kan exportera i det format som efterfrågas OCH med dessa två ytterligare attribut. En datapublicist som inte har tillgång till verktyg där dessa fält kan skalas bort stöter på problem - datat från Geometriservern/källsystemet måste transformeras - särskilt jobbigt om det ska ske "on the fly" med strömmande data från ett API - det skulle kräva någon sorts API-wrapper som få kommuner kan skaka fram eller bygga själva.

Jag kan bara se den lösningen - transformation, men det kanske finns fler?. Om det inte rör flödande data från API (inte behövligt(?) i fallet Grillplats, kanske en offline-transformering kan ske med script eller tredjepartsprogramvara innan publicering?

Har läst RFC7946 för GeoJSON och kan inte se att FID eller GEOM är några reserverade namn som ingår som fasta attribut för GeoJSON-objekt, varför det inte går att peka på den standarden heller för att tillåta dessa två (proprietära?) attribut.

Om data lagras i en SQL-server kan man (troligen) skriva en vy där de extra attributen utesluts och på denna vy kan man istället ställa frågan, men det kräver ju som sagt något utöver det vanliga...

När någon ska konsumera en datamäng för att plotta saker på karta, kan denne implementatör så klart välja att bara ignorera (drop) de attribut i specen som inte möter förvätan. Jag misttänker att det kan orsaka nya eller andra problem. Här är min kunskap svagare då jag inte byggt några lösningar baserat på sådan data.

Hej allesamman, nu har det gått en tid och jag ser glädjande att specifikationen för Grillplatser används lite här och där.

Jag kommer försöka samla ihop allt ni skriver om utökade fält, utökade möjligheter i fält och troligen skulle det behöva skapas en version 2 av specifikationen grillplatser.

Är man smart behöver den som publicerat enligt version 1 inte ändra något, den kan ligga kvar och nyttjas som förut, och att version 2 har samma baskonfiguration men tillåter annat innehåll i vissa attribut (om jag läst till mig rätt i tråden) samt lägga till ett antal (frivilliga) attribut för att bland annat hantera bild och tydligare precisera adress.

Följande har jag identifierat från diskussionen hittills;

Föreslagna nya fält:

• image_url: URL till en bild av grillplatsen, med licens för bilden angiven som CC0.
• report_phone: Telefonnummer för frågor, synpunkter och/eller felanmälan.
• report_url: Länk till en tjänst för frågor, synpunkter och/eller felanmälan.
• street: Gatuadress till platsen, exempelvis "Havsvägen". Mappar mot Open Street Maps "addr:street".
• housenumber: Gatunummer eller husnummer med bokstav, exempelvis "1" eller "42 E". Mappar mot Open Street Maps "addr:housenumber".

Diskussion om befintliga fält:

• Några exportsystem (GIS) använder ID som internt namn. Kan specen ändras så att t.ex. UID används istället.

Synpunkter på specifikationen i övrigt:

• Kan specifikationen tillåta extra fält utöver definierade?
• Kan fältet för uppdateringsdatum ändras från obligatoriskt till rekommenderat, eftersom inte alla kommuner har denna information tillgänglig.
• Avstånd till parkeringsplats: Vilken typ av parkering hänvisar man till, bil, cykel osv.

Har jag fångat det någorlunda inför att inleda ett nytt utkast?

@Matself

Hej, för framtida specifikationer och publicerade datamängder, skulle det vara till någon hjälp om man som publicist kan ange vilket koordinatsystem och format som man vill ange, och kunna välja vilket som helst, eller borde man enas om att WGS84 ska vara obligatorisk standard i egna specifikationer och att den som önskar kan lägga till Sweref99TM med koordinatsystem specificerat vid sidan av? Att dataobjektet kan beskrivas med både ett geoJSON-standard-format och ett valfritt annat eget format/koordinatformat vid sidan av?

@Magnus

Hej ber om ursäkt att det dröjt, har inte fått någon notis om detta, men vi fick ju kontakt på mejl istället.

Jag har uppdaterat men ser att publikationen inte verkar ha slått igenom, får fortsätta mina försök. Du har helt rätt och exemplet borde ändras för att motsvara det du påpekar!

/Tomas

@jonor sa i Vägledning för att publicera data om grillplatser:

@FredrikEriksson

Exempelvis i Mariestads kommun underhåller man datamängden i en Sharepoint-lista eller ”Microsoft Lists” i Office 365. Det här gör att man ute i fält kan köra Microsoft Lists-appen och enkelt och överskådligt sköta uppdatering av egenskaper när man befinner sig på platsen.

I Mariestads kommun som exempel, har vi skapat listor i Office 365 i appen ”Lists” som motsvara attributen i datamodellen.

Genom appen ”Lists” som går att ladda ner till mobiltelefon, kan personer ute i fält inventera och uppdatera informationen och attributen som beskriver platsen direkt. Appen skapar ett enkelt och lättläst ”formulär” av den tabulära datan.
Det gör att datat blir enklare att underhålla och lätt att uppdatera. Det krävs ingen särskild utrustning annat än en mobiltelefon och behörighet/licens för Office365.

Om alla köper in programvarulicenser för Office 365 så är problemet löst? Eller är det kanske en given förutsättning att all offentlig förvaltning i Sverige redan har gjort det? Kan det tänkas finnas alternativa verktyg för att lösa dessa uppgifter?

Halloj, som @FredrikEriksson menar är exemplet med Office365 och "Lists" ett sätt att jonglera informationen innan den blir öppen data.

I MTG har vi valt lägga badplatser, grillplatser och lite annat som Sharepoint/Lists för att det är ett verktyg vi har, som finns hos de flesta i vår organisation och som har en (faktiskt rätt så okej) app som stödjer snygg redigering "i fält". Man kunde lika gärna använt ett Excelblad, eller en textfil.

Fördelen med en Lists är att den går att sätta lite formatkontroll på (typ latitud måste skrivas med formatet NN.XXXXXX, annars får man ett felmeddelande och kan inte spara) samt att det går att behörighetsstyra enkelt, bygga vyer etc. Lists har även stöd för bilder och andra datatyper som man kan lägga till hur man vill - bara man ser till att man i själva exportögonblicket bara får med det data som specifikationen kräver.

På så vis kan en dataspecifikation för exempelvis Grillplatser innehåller mycket mer data och användas på många fler sätt OCH användas som bas för öppen data. Lägger man till egna attribut som "vem som tömmer soporna" eller "senast tillsyn" i form av en personväljare i Office eller ett datum, så kan man ju skippa ta med dem i exporten till ÖppnaData-katalogen då specifikationen inte har dessa fält.

Det här gör även att man kan svenska rubriker och namn på saker i Sharepointlistan som man sen översätter i exporten.

Vi testar lite nu men än så länge ser funktionen bra ut och vi kommer säkert börjar smyga in detta på andra datamängder som är relativt statiska och som flera personer behöver underhålla över tid - även sådan datamängder där det idag saknas en specifikation som ex. fontäner, parkbänkar osv.

Lists är inte lämpligt för viss typ av data och därför prövar vi så klart innan vi börjar använda det som verktyg.

Hej jag instämmer med övriga. Det är svårt eller omöjligt att ta höjd för alla system med reserverade ord, i en är ID reserverat, i ett annat system är "latitude" och "longitude" reserverade.

Jag är lite osäker på hur exakt konflikten sker, men nån form av transformation kanske man kan få till?

Uppstår konflikten då ni tänker er att datat om en grillplats ska läsas i realtid från en tabell via ett API i ert GIS-system?

Jag tänker att man kan döpa tabellen i GIS-systemet annars till vad som helst och när man som @Ainali skriver byta det namnet vid export. Så gör vi i Töreboda/Mariestad/Gullspång när vi hanterar grillplatser i en sharepointlista eller Excelblad - där heter kolumnerna "Badplatsens fullständiga namn" men när datat exporteras till vår datakatalog transformerar man namnet till "name".

Jag sparkar ju in öppna dörrar kanske, har det löst sig, kom ni på nån lösning som du kan dela med dig av?

Ser inga problem att ändra i specifikationen heller, vi måste till slut börja versionshantera dem, så det är ju lika bra att träna på något "enkelt" och "ofarligt" som grillplatser

För alla andra börjar jag närma mig slutet på arbetet med korrektur på specifikationen och tar tacksamt emot synpunkter och inputs hur den kan bli bättre! Passa på, för jag önskar försöka bli klar iaf absolut senast första veckan i maj

Här är specen, kommentera gärna och notera ifall du vill (eller inte vill) synas i Contributors. Du kan kommentera anonymt/som gäst.

https://docs.google.com/document/d/1OE_SR5cIzz7-ryeq6JiVExcHmY5vecPdCWAv7fSqnpY/edit?usp=sharing