Utvecklarhandledning

Från Open Data Wiki Umeå
Hoppa till: navigering, sök

Denna sida är under arbete


På denna sida samlar vi diverse förslag om hur man som utvecklare och vidarutnyttjare på ett bra sätt förhåller sig till öppna data i allmänhet och OpenUmeas data i synnerhet.

Innehåll

Rådata

En sak värd att ägna lite tanke åt är att data som publiceras på http://openumea.se/ är i "råformat". Det har alltså inte gjorts någon efterbehandling på dessa data och de är publicerade i så rått format som möjligt. Detta för att data ska vara så opåverkad och så lik källmaterialet som möjligt.

Detta innebär att som vidareutnyttjare behöver man ofta efterbehandla och/eller konvertera data för att få dem i ett format som passar just sin applikation.

Exempel

Koordinatformatet som används i dataset för anläggningsdata är så kallade LU-koordinater. Detta på grund av att det är det format som används internt på Umeå kommun. För att exempelvis föra denna information vidare för att kopplas till Google Maps så behöver dessa LU-kordinater konverteras till WSG84 som Google Maps använder sig av.

I exemplet http://openumea.github.com/Facilities-example/ har vi använt oss av en konverteringsfunktion skriven av http://mellifica.se/konsult/.

//Set gausskruger parameters to what we expect from data

swedish_params("sweref_99_2015");


//Convert from grid

var geodetic = grid_to_geodetic(LU_X, LU_Y);


Det finns också konverteringsalgoritmer till/från SWEREF99 i kodform som kan vara intresse för den som vill växla mellan olika koordinatsystem.

Tillgång

Hur man gör sig tillgång till öppna data beror en del på av vilken natur dessa data är. Här nedan resoneras det lite kring exempel och tankar kring hur man kan se på sitt eget vidareutnyttjande av öppna data.

Ändras formatet ofta eller är formatet stabilt?

Levereras data automatiskt och ska konsumeras automatiskt eller är konsumtionsprocessen manuell?

Här kan vi bara hänvisa till de metadatabeskrivningar som finns för varje dataset i OpenUmea. Är något otydligt eller bör förtydligas så skriv ett mejl till den som står som maintainer för just det datasetet, eller till [[1]].

Data vars format ändras

Det finns dataset som i sin natur är föränderliga. I dessa fall är det upp till varje tillämpning att avgöra hur detta bör hanteras.

En strategi kan vara att varje gång importera enbart de data man känner till och ignorera data som import-systemet inte vet hur de bör hanteras. Detta kan vara en bra strategi där viss information är bättre än ingen.

En annan strategi kan vara att varje import där import-systemet hittar data som den inte vet hur de bör hanteras så slår den stopp, och kräver att någon talar om för import-systemet hur dessa data bör hanteras. Detta kan vara en bra strategi där total korrekthet är viktigare än delvis korrekthet.

Exempel

Om Umeå Fritid skulle lägga till ett fält "policydokument" på varje anläggning, för att exempelvis hänvisa till vilket policydokument som styr verksamheten på en viss anläggning så kanske det nya fältet inte påverkar hur guiden över alla konstgräsplaner i Umeå ser ut.

Däremot om Umeå kommuns budget har ändrat fält, och den är strukturerad på ett nytt sätt, så kanske det inte är lämpligt att skapa en visualisering ifrån partiella data, då de kan vara missvisande.

Sällan uppdaterade data

Om man konsumerar öppna data som i sin natur inte uppdateras så ofta, eller att i just den här tillämpningen inte har behov av "färska" data hela tiden kan det lämpa sig att man laddar ner de relevanta resurserna för hand och sedan bara använder dem. På detta sätt kan man enkelt omarbeta data till just det format som passar tillämpningen bäst.

Exempel

Om man vill ha en lista över alla Umeå Fritids konstgräsplaner så kanske det räcker med att man tar fram dessa data en gång och inkluderar dem som en statisk resurs i sin tillämpning. Antalet konstgräsplaner förändras nog inte signifikant ifrån dag till dag, utan det kanske räcker att man uppdaterar sin lista någon gång per år.

Ofta uppdaterade data

För data som uppdateras ofta är det rekommenderat att lägga ner arbetet på att producera en automatisk process för att importera nya data. För mer formation om hur det kan gå till, läs mer om det i stycket Programmatisk access till data.

Exempel

Sidan Facilities-example visualiserar den senaste resursen i datasetet "anläggningsdata".

För att se hur det går till, se nedan om Programmatisk access till data.

Programmatisk access till data

Om man har behov av programmatisk tillgång till resurser som finns på http://openumea.se/ görs det enklast genom att använda sig av CKAN:s API (Application Programming Interface). API-endpointen för OpenUmea finns på http://openumea.se/api/.

Exempel

För ett enklare exempel hur detta kan göras, finns det på github.com/openumea.

Där känner vi i förväg till namnet på datasetet vi är intresserade av. Då kan vi igenom API-anropet package_show få reda på alla resurser knutna till detta dataset. Då tittar vi i listan och väljer den nyaste resursen där och hämtar den ifrån URL:en som är kopplad till resursen.

I den här exempelapplikationen förlitar den sig på att webläsarens cache minimerar antalet hämtningar av filen. Om konsumtionen av filen sker på något annat sätt så är det starkt rekommenderat att använda sig av en cache för att öka tillgängligheten och minska svarstiden.

Därefter hur man tolkar själva resursen får man använda metadata-dokumentationen till, i det här fallet Metadata/Information om anläggningsdata

Personliga verktyg
Namnrymder

Varianter
Åtgärder
Navigering
Verktyg