Community på Sveriges dataportal

Något nytt om version 2?

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.

@josefinlassi Tack för svaret, skapa gärna en issue i er backlog för detta - jag hjälper gärna till att skriva en. Som konsument av data känns det onödigt att manuellt behöva göra samma sökning regelbundet för att se om det finns några förändringar bland resultaten. Är detta backloggen för dataportalen? https://github.com/diggsweden/dataportal-web/issues?q=is%3Aopen+is%3Aissue

Jag söker regelbundet efter nya datakällor genom att söka med olika nyckelord. Tyvärr är det inte lätt att avgöra när det har kommit nya om sökorden ger många träffar. Finns det något sätt att prenumerera på förändringar och därigenom få notifieringar när det kommer nya träffar? Dvs en bevakning på förändringar av mina sökningar.

@Björn-Hagström Det är rimligt att det är så. Det är dock inte alltid så lätt att lista ut som utomstående hur parametrarna skall se ut. Verkar finnas några varianter.

@Matself Jag kan bara instämma. Kommer inte ihåg på rak arm var det var men jag stötte på ett api förra året där man som en query-parameter kunde ange vilket projektion/koordinatsystem som skulle returneras. Fungerade för mig

Att data tillhandahålls i ett format behöver inte betyda att det inte kan tillhandahållas i andra format.

Personligen älskar jag dataportaler där:

• det är lätt att hitta vilka datamängder som finns
• det finns flera alternativa metoder att hämta data
• det går att välja dataformat
• man redan vid källan kan filtrera vad man vill ha både i fråga om objekt-typer och fält
• allt är väl beskrivet
• licensformen är tydligt angiven.

@Björn-Hagström Även jag har stött på det vid ett par tillfällen. Försökte få dem att öppna upp för de IP-adresser jag använde men utan framgång.

Rent krasst så antar jag att man ser det som ett sätt att skydda sina API:er och att man antar att alla konsumenter är i Norden. Man tänker inte på att även svenska konsumenter kan ha sina servrar utomlands, i mitt fall Holland.

@tomasmonsen @maomao @Matself
Jag har förstås några åsikter i frågan

1. Geojson är en standard och därmed gäller wgs84. Själv använder jag https://github.com/bamcis-io/GeoJSON för att hantera Geojson och eftersom det är Open Source så har detta paket numera (på min begäran) en möjlighet att användas även om det råkar ligga SWEREF i filerna.

2. Geojson är ett smidigt format med stort stöd inom open source världen till skillnad från exempelvis shp.

3. Den nogrannhet som får med WGS84 är tillräcklig inom det område jag rör mig dvs friluftsliv.

4. Jag har full förståelse för att upplösningen för WGS84 inte är tillräckligt bra för en del ändamål.

5. crs är numera bortplockat från standarden. Personligen tycker jag detta är synd.

En lösning som jag vet att exempelvis Sundsvalls kommun har är en flagga som när man anropar deras API anger om man vill ha koordinater i WGS84 eller innehåller SWEREF.

@Ainali Värt ett försök. Men visst arbetas det på en ny platform? Eller har jag drömt?

@Ainali Och i praktiken?

@mattias @Björn-Hagström Ursäkta sent svar.

En annan aspekt när väl en licens är angiven. När jag filtrerar på CC BY-SA som licens får jag fyra träffar. Varav två egentligen är CC0! Jag tror det är ett fel i filter-funktionen på dataportalen. Hur anmäler man buggar?

En annan sak är att CC BY-SA kommer i olika smaker. Tio varianter för att vara mer exakt varav åtminstone några torde vara applicerbara i vår del av världen. Jag hade gärna sett att man hade med SPDX identifieraren för den licens som man använder. Se gärna. https://spdx.org/licenses/ . Hur kommer man med förbättringsförslag?

@mattias Tack förlänken! Den förklarar en hel del. Intressant att man särskiljer åtkomst och licens. Uppenbarligen måste man inte ange en länk till någon licens då det finns tämligen nya källor som inte har det inlagt vilket är synd.

@Maria-Söderlind

Tack,

ja det skulle kunna vara den som menas. Kanske inte den roligaste licensen i världen men men. Tooltipen ger
Publicly accessible by everyone. Usage note: Permissible obstacles include registration and request for API keys, as long as anyone can request such registration and/or API keys.

Någon annan kanske har insikt hur man tänkte när denna licens-variant lades in i Dataportalen?

Eftersom jag är konsument av data som jag hittar via dataportalen.se så funderar jag på de olika licensformerna.

CC Zero liksom CC By är etablerade och lätta att förstå. Det finns dock andra frågetecken.

På väldigt många datakällor anges Public och då undrar jag förstås vad detta betyder egentligen. Någon som vet? Finns det någon definition som jag inte har hittat?

På andra datakällor finns ingen licens angiven alls. Men det kan stå någonstans "öppna data". Hur tänker vi där?

@Johan_Bard Kan bara hålla med om att ett json-schema kan vara rätt väg. Möjligen kan det vara ännu bättre att använda geojson eftersom det då finns gott om färdigskriven kod för att läsa och tolka innehållet.

Det sagt så är ändå json väldigt mycket bättre än csv.

@almeta Denna alltså?

https://www.iana.org/assignments/media-types/application/geo+json

Nu är jag konsument av data och inte publicent så jag vet inte hur det ser ut. Jag tänker ändå att geojson borde vara med i listan över geografiska mediatyper. Är det något ni har planer på?

@Björn-Hagström Angående om det finns fält utanför specifikationen så spelar det en viss roll. Några scenarios:

• Jag ignorerar tilläggen - vilket gör att informationen inte utnyttjas = waste

• Om alla 290 kommuner gör ett eget tillägg för att rapportera fel så behöver jag som konsument hantera 290 varianter.

Själv är jag glad för allt som publiceras men samtidigt ser jag stora vinster med att alla publicerar på samma sätt enligt en gemensam definition. Används samma fältnamn, samma betydelse, geojson via rest-api så kan jag ha en gemensam inläsningsfunktion. I dagsläget har jag behövt skapa ett inläsningssteg som är unikt för varje datakälla.

@Björn-Hagström Jag syftade på om Varberg har något öppet api.

@Johan_Bard En tanke angående fee.

Jag tänker att denna med fördel kan delas upp i en boolean som är lätt att tolka maskinellt och ett text-fält med detaljer om kostnaden om en sådan finns.

Annars kommer någon att skriva "Ingen kostnad", "gratis", "Free" eller dylikt som inte gör någon som försöker tolka det hela automatiskt glad.

Angående URL. Jag har lärt mig den hårda vägen att inte alla inser att den bör vara fullständig som https://site.com/sida utan att de skriver site.com/sida. Så detta kanske kan förtydligas?

@Björn-Hagström By the way: Har ni något api där det går att hämta grillplats-data nu för tiden?