bäst vore om ni också skapade baden på Open Street Map direkt eftersom många använder deras karta som Apple etc. exempel hur jag skapade Järva badet förra året skrik till ni behöver hjälp
skapa lite data med några bad så blir det enklare att kommentera min erfarenhet är att när man börjar leverera data och det används det är då man lär sig saker…
Jag försöker få till en dialog med Tillgänglighetsdatabasen och gjort en POC på en enkel koppling Wikidata <-> Tillgänglighetsdatabasen - min tro är att saker som detta idag inte passar i Wikidata medan Open Street Map har lite trevliga saker som ett gränssnitt wheelmap.org. Får dock en känsla av att det OSM saknar bra data för Sverige…
Ja vi har kommunicerat kring detta på DIGGs community oxå, vi kommer att stryka ref till open street map och behålla ref till Wikidata i form av ett Q-kods-fält till entiteten i Wikidata. Det blir kopplingen så här lång för att inte göra det för avancerat för våra dataproducenter tror jag. Många kommer sakna Wikidata-kod, vilket ju är trist, men bra, för då kanske man skapar en så att de svenska badplatserna får entries i wikidata och att det underhålls!
diff idag vad vi har i Wikidata (även hundbadplatser) jmf med det som skickats till Hav lista / karta
att ha en tydlig persistent unika identifierare för alla bad är grunden för att man skall kunna felrapportera som vi gör och förstå vilket bad man pratar om se lista
Hur menar du att vi tänker fel ? Vad är det som vi missat?
HoV-myndighetens databas är bra, absolut att alla bad skulle finna där - det har vi inte i Dataportal Väst mandat att besluta, flera kommuner publicerar bara bad där som är vattenprovade, dvs uppmätta värden - man väljer att från kommuners håll exkludera bad som inte mäts (mätning förenat med kostnad).
Jag kommer att uppmana alla som deltar att publicera alla badplatser i HoV-databasen, oavsett om de är mätta eller inte, det ingår i min rekommendation till publicisten/dataproducenten. Jag kommer även uppmana till att se över datat i Hav-databasen, då den som du säger uppenbarligen har flera fel i sig. Lämpligen underhåller man datamängderna tillsammans.
Unik identifierare har jag bett om hjälp att hitta på en men ingen har kommit med något konkret förslag, så jag får hitta på en egen, det blir en kombination av kommunkod, badplatsens namn och ett löpnummer. Eller menar du med att vi tänker fel i att vi inte ska ha en ref till Wikidata utan bara till Havs- och vattenmyndigheten eller tvärtom ?
Jag var osäker på att om ni skulle köra all-in på att alla bad skall ha Havs unika identifierare… har alla baden den så behöver ni inte ha någon mer unik identifierare i specen. Bra är om alla websidor etc. har med detta ID och även att andra databaser som Tillgänglighetsdatabasen vaknar till liv och identifierar sina bad med detta ID se lista vad jag hittat idag … gärna att dom har en URL där man kan skicka med detta ID för att se deras post om badet…
Aha, ja vi kommer nog inte kunna kräva att alla som vill använda vår dataspecifikation lägger alla baden i Havs databas, men vi har med fältet som ref och hittar på en egen identifierare bestående av kommunkod och namn, sedan får man vara lite klyftig och se till så att namnen blir unika. Blir de inte det, får vi som konsumerar uppmärksamma kommunerna på det och be dem ändra namnet.
Vi kommer i vår skrivelse till kommunerna uppmuntra dem att publicera alla bad på Havs webbplats, eftersom, som du konstaterar Hav själva vill det.
Ja om TD vaknar till liv och provisionerar ut IDn på alla objekt som kan addresseras i ett URI vore ju toppen, typ t-d.se/object/[id] för som det är nu känns det lite yxigt med namnen på platserna. Dock har jag fått svar från dem att de URL som finns är stabila över tid, dock inte garanterat, det är “extremt sällan de ändras, om någonsin”, ungefär så löd svaret.
Då är vi “klara” med version 1.0 och jag hoppas att den kommer att bli nyttjad. Vi kommer att påbörja revision i höst och förhoppningsvis kanske vi har en version 2.0 ute till nästa säsong. Vi har många idéer och förbättringar som kan tillföras för att göra specifikationen ännu bättre!
Tipsa era kommuner och publicister att använda denna specifikation om ni vill dela data om badplatser. Självklart behöver man inte, men det ger mervärde till en konsument om data för Sverige finns i liknande format.
Tipsa mig gärna om du kommer på saker som fattas eller behöver kompletteras inför nästa version!
Vi kan även fortsätta en “meta-dialog” här i tråden eller uppdelat i andra trådar utöver Issues på GitLab. Välkomnar alla i VGR och svenska kommuner att använda och bidra till specifikationen och publicera badplatser som datamängd enl. spec!
Hej @mattias och @tomas.monsen
Jag började att jobba med publicering av vår badplatser enligt specifikationen ovan, av slump hittade jag en tråd på dataportal som ni säkert känner till
Hur ska man förhålla sig till denna diskussion? Om jag har förstått tråden träd rätt så verkar specifikationen frikopplade från den som används av Havs och Vatten myndigheten och på EU-nivå. Det skrivs en del negativa åsikter om specifikationer som tas fram av olika ‘projekt’, jag har inte kunskap att bedöma sanningen i det men har själv märkte några inkonsekvenser mellan specifikationerna som finns här
Några exempel:
På specifikationerna för lekplatser och grillplatser ska kolumnnamn ‘source’ vara organisationsnummer utan bindessträck medans för utegym kan ‘source’ vara SCBs kod eller organisationsnummer (med bindessträck). Datatyp anges som heltal men exemplen är en sträng “21 20 00-12 64”. På skoldata kan ‘source’ bara vara SCBs kod.
På specifikationen för lekplatser och grillplatser ska ‘wheelchair’ anges som yes/no/limited medan för badplatser är ska det vara boolean.
Som ‘ny’ inom öppna data världen vill man veta att det finns en specifikationen som alla följer för att informationen ska vara användbar. Det tar en del tid att bygga om data enligt en specifikation, hämtar och fyller i alla attribut, ersätter lagret i alla kartor och tjänster, sätter upp skript för uppdatering. Osäkerheter gör att man avvakta med att komma igång i ett försök att undvika dubbelarbete.
@williamw God förmiddag! Precis det stämmer att det är lite uppdateringar som behöver göras och det är på gång. Kul att du är aktiv och noterar detta. Justeringen för utegym är gjord sedan tidigare och har bara inte uppdaterats på lankadedata.se. Senaste version hittar du på gitlab och vill du bidra på gitlab med issues kan du göra det här - Länkade Data · GitLab.
Vi har kikat närmare på specifikationen för Badplatser. Idag finns det följande fält för att ange länkar för, 38 temp_url, 39 extra_url och 40 visit_url i specifikationen.
Vi känner att specifikationen behöver se över om fält fält 39 extra_url behöver kompletteras, då kan kopplas till en fritt vald vald länk alternativt API. Det tycker att det kan vara aktuellt att ta fram ett nytt särskilt fält till specifikationen. Vi vill lägga till posten API.url till specifikationen för att ha en särskild länk kopplat till våra API länkar api.sodertalje.se. Går vår önskan att lösa?
Hej, bra idé, det tycker jag vi ska kunna lägga till i en ny version av specifikationen. Att lägga till nya fält är inte lika “farligt” som att ta bort eller förändra. Vi får diskutera i arbetsgruppen kort hur vi gör uppdateringen, men jag ser inga hinder att släppa en version 1.1 med denna uppdatering. Den som då har en datamängd enligt äldre specifikationen behöver inte automatiskt uppdatera, och de som konsumerar data behöver inte (nödvändigtvis) få trasig implementation på grund av detta extra fält.
Vad säger ni, @mattias@alex och @FilipDijak ska vi ses kort och diskutera (eller ta nästa inplanerade arbetsmöte) och fundera över hur vi släpper en patch av spec? Det kan ju finnas andra synpunkter som vi behöver se över oxå!
Tanken var ju att “temp_url” skulle användas för bland annat länkning till API, men eftersom den lika gärna kan länka till en grafisk visning av temperatur på en extern webb, och det inte finns något bra sätt att peka ut i specen VAD som finns bakom temp_url är det ju lämpligt att lägga till en för API.
Det var precis så vi tänkte att temp_url lämpligast används för att länka till en visualisering av temperaturen och att en separat kolumn behövs för ett eventuellt API. Det går ju såklart att lägga API:ets url under extra_url men då försvinner ju möjligheten att få in annat under den.
Sen är det ju bra med tydlighet i specifikationen om vad som ska ligga under vilken kolumn så att det är enkelt att förstå.
