Community på Sveriges dataportal
Vägledning för att publicera data om grillplatser
-
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?
-
@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.
-
@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.
-
Här kommer mina erfarenheter och åsikter såsom den största (?) konsumenten av grillplatsdata och även tyckare i den första versionen av specifikationen.
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.
Eftersom det diskuteras parkering - jo det skulle vara bra men då skall den ligga inom rimligt avstånd. Och vem bestämmer vad som är rimligt? Det är anledningen till att jag inte själv har med den informationen.
Namnet table som finns krockar med ett reserverat namn i något system. Lomma har därför exporterat det som table_ . Något att ta med sig då man väljer namn för fält. Finns vad jag förstår ändå ett högst begränsat antal leverantörer av GIS i Sverige.
Angående nya fält.
report_phone är jag med på.
report_url likaså.
Båda måste vara opersonliga (GDPR vet ni) alltså inget telefonnummer eller mail som pekar ut en person.
Jag har ingen åsikt om street och housenumber.
UID får mig att tänka på User ID men det är jag. UID, GID, FID etc fungerar. GID kanske skall sparas till den dagen det finns en globalt unik identifierare. Undvik dock gärna GPID...
image_url - se text om foton längre ner.
Extra fält - jag måste erkänna att jag inte gillar tanken. Risken är dessutom att det i senare version av specifikationen blir en namnkrock. Jag har dock använt standarder inom andra områden som tillåter egenspecificerade utökningar men då är det specificerat hur detta skall göras. Å andra sidan så ser jag hellre data med extra fält som jag kan ignorera än inget data alls.Jag ser lite olika varianter på hur man sätter värdena för de booleanska attributen. Jag kan nämna sant, ja, yes, falskt, no, nej, "". Tror att jag har sett någon felstavning av dessa dessutom och kanske lite olika casing. Ur min synvinkel vore det ultimata an enda variant. Dessutom anser jag starkt att om fältet finns med men saknar värde (null) så betyder det att information saknas. Samma om fältet inte finns med. Så med andra ord "true", "false" och "null" helst inte som strängar utan som en nullable bool.
När det gäller foton tänker jag en lista av foton. För varje foto bör det finnas länk licens (spdx-identifier se https://spdx.org/licenses/) och eventuell attribution. Sedan kan man tänka sig bildtext och en syntolkning av fotot också.
Några fält som inte gäller för den enskilda platsen utanför datasetet skulle kunna vara license (spdx-identifier), eventuell attribution, version av specifikationen som följs.
Jag vet att specifikationen började med tanken excel-ark. Jag tror ändå att version 2 bör vara lite mer struktur i - tänk listan av foton.
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 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.
-
@ChristerOlsson Gällande den brutna länken, så orsakas det av ett fel på Sveriges dataportal som vi håller på och åtgärdar. Förhoppningsvis är det fixat den här veckan.
-
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.
-
Detta inlägg är raderat!
-
Något nytt om version 2?
-
@lmdaniel finns det persistenta identifierare på Geoplattformen för grillplatser eller kan man se till att skapa det? @ChristerOlsson har > 7500 grillplatser i Sverige och är utan tvivel den bästa källan.....
-
OSM har 5729 noder och 99 ways för nwr(area.boundaryarea)["leisure"="firepit"]; nwr(area.boundaryarea)["amenity"="bbq"];
-
min lilla test på Wikidata Grillplatser
-
-
@Magnus-Sälgö,
Grillplatser finns dessvärre inte som en fastslagen datamängd för Nationella geodataplattformen, NGP – och tillhandahålls därigenom inte än genom den infrastrukturen. Men om dessa hade funnits tillgängliga hade de haft ett UUID som det kunnat gå att koppla annan information till. -
Behov av "Mönster att jobba ihop" - vi vill vara del av
@lmdaniel En fundering: När projekt som NSÖD och Dataverkstaden definierar sina PDF-specifikationer, borde de ha en dialog med Nationella geodataplattformen för att undersöka om deras dataset kan bli en del av infrastrukturen. Hur ser processen ut? Det borde finnas en möjlighet att "ställa sig i kö", kanske enligt modellen jag skissade på "Mönster att jobba ihop".
Annat behov av "Mönster att jobba ihop" - vi vill att ni...
Jag lyssnade på AI Sweden podcast #72 med @PierreMesure om deras AI jobb där dom har enorma problem att samla in dokument pga. all länkröta och även dålig metadata... dessa problem borde systematiseras av ESV och ange per organisation... verkar idag som Internet Archive är en bättre källa för myndighets dokument än att hämta hos myndigheterna själva - jmf hur EU skapat en fattigmanslösning med EU Web känns som kanske ESV är en aktör som lider av detta och kan skapa en sådan läsning - det naturliga vore att Riksarkivet tog på sig den rollen
-
@Magnus-Sälgö, samverkan har till viss del skett mellan aktörerna. Det som ligger närmast till hands vad gäller grillplatser är ju arbetet med storskaliga geodata. Här har det bedrivits ett Smart Built-projekt inom det området.. Ett arbete har också påbörjats inom Lantmäteriet i samverkan med andra parter – men det har pausats för att göra omtag framöver.
-
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?
-
@tomasmonsen sa i Vägledning för att publicera data om grillplatser:
Är det lämpligt att föra vidare diskussion om vidareutvecklingen här på forumet, vad tycker ni?
Är det inte bättre att skapa ett GITHUB rep och att @ChristerOlsson kan vara med att ratta detta han lägger ned flera 1000 timmar på grillplatser.nu och kan nog ratta ihop en bättre spec på 5 minuter
-
-
Intressant är att Stockholmsstad kommer att sätta upp QRC skyltar för att felrapportera utegym dvs. det blir i telefonen en URL dit man kan felrapportera känns som ok mönster att börja med
- eftersom telefonen är inställd på ett språk så borde informationen visas på samma språk som telefonen har...
Andra ställen det används QRC koder
- Avrådan för bad Stockholmsstad #118#issuecomment-2387275607
- Skärgårdsstiftelsen #34
Det snygga med detta mönster
Här får vi unika förhoppningsvis persistenta URL:ar för objekt som utegym och badplatser....
Med badvatten problemet har Havsmyndigheten en koppling till EU bad och det betyder att det finns även en samma som koppling till EUBathingWaterIdentifier = dd.eionet.europa.eu/dataelements/99263
-
Koppla friluftsaktivitet till att åka kommunalt finns det en tanke
Jag gör nu massa aktiviteter på Swedish Archipelago Trail mina virriga tankar på video / bilder jag samlar - på en karta / github och där är det buss färja för att komma till platserna.
Fråga Finns det en tanke hur en plats kopplas till att ta sig dit kommunalt.... att ta bilen till Swedish Archipelago Trail går oftast inte
- Se hur Google Map levererar och har alla Sveriges hållplatser, bryggor som båtar lägger till vid.... med unika persistenta identifierare so, do, sedan kopplar till realtidsinformation när båt buss tåg går
- exempel hur dom även har bra (inte perfekt) koll på restaurangerm när dom är öppna
- lista jag gjorde 2024 på trevliga platser på Gotland
Exempel hur bilderna presenteras på en karta
