Gällande fritext är det som med mycket annat på temperatur.nu inte genomtänkt från start... Jag kan hålla med om att det vore _mycket_ bättre att använda det standardiserade formatet. Problemet är att om formatet skall bytas måste alla mätpukternas information uppdateras, och det är ett ganska stort jobb. Iofs så skulle man kunna sätta upp nya databaser och sedan köra fritextmatchning mot den gamla när man uppdaterar.
Gällande teckenkodningen så har jag dålig koll på hur man _ska_ göra och latin1 har hängt med sedan starten för 10 år sedan...
Det största problemet är att jag är rätt kass på att programmera.
Vad menar du med stort jobb? Uppdateringen av databasen känns som ett litet jobb, det borde vara lätt att generera SQL-skript för att skjuta in rätt koder och det är ju bara några hundra mätstationer så jobbet borde köras fort. Eller ligger platsinformationen på varje mätvärde? Jag trodde att uppdateringen av API-koden skulle vara den bökiga delen.
PHP är tyvärr inte min starka sida, så där kan jag inte hjälpa till så mycket =)
Som det ser ut nu ligger det två tabeller med kommun/länsdata:
Kommuntabellen: kommunkod (som jag inte vet var den kommer ifrån), kommunnamn och länskod (som jag inte vet var den kommer ifrån).
Länstabellen: länskod och länsnamn
I temperaturdatabasen ligger sedan kommunid inlagt på alla stationer.
Vad som skulle behöva göras är helt enkelt att länka om kommunid mot en ny tabell med korrekta kommunid. Och denna mappning får man köra med fritextsökning när man byter.
Borde inte vara så svårt egentligen... Ska fundera lite på det så kommer jag nog på en smidig lösning som inte tar så lång tid att genomföra.
Med lång tid menar jag den tid jag måste lägga ner. Själva körningen lär inte ta många ms.
Nu har en signeringsfunktion för urlerna lagts tills. Detta är en ändring som i mitten av 2011 kommer att krävas för att att ett clientid frekvent skall kunna hämta information.
I nuläget ligger funktionen endast i version 1.9 och någon begränsning ligger inte inlagd, men funktionen kommer successivt att läggas in även i äldre versioner av apiet.
Nu är version 1.10 släppt
En kort summering av nyheterna i de senaste versionerna:
1. URLerna skall signeras. Om ca 6 månader kommer signering att krävas. Detta för att styra upp användningen och stävja missbruk.
2. Det går nu att hantera information om vilken version av klientmjukvaran som är den senaste via APIet. Denna funktion kan användas för att i klientmjukvaran detektera om det finns någon uppdatering att ladda ner.
Nu är version 1.11 släppt. En stor uppdatering.
Nya funktioner:
Det går att fritt speca tidsperspektiv för grafer
Det går att i textformat hämta min/max/medel, tidsperioden specas på samma sätt som för graferna.
Signering krävs för att använda APIet vid fler än 20 accesser per timme.
Temperatur.nu API 1.5 - Din url är inte korrekt signerad, clientnyckeln kan tillfälligt blockeras
Måste jag få en signerad nyckel för alla städer eller gör jag anropen fel, för 20 st anrop/h står det det ska fungera om man inte har en signerad nyckel.
Någon som har lite kod på hur man implementera detta enklast i C# så är jag enormt tacksam.
Temperatur.nu API 1.5 - Din url är inte korrekt signerad, clientnyckeln kan tillfälligt blockeras
Måste jag få en signerad nyckel för alla städer eller gör jag anropen fel, för 20 st anrop/h står det det ska fungera om man inte har en signerad nyckel.
Någon som har lite kod på hur man implementera detta enklast i C# så är jag enormt tacksam.
stefank skrev:Du går gärna skicka ett exempel på koden ifall du vill.
Jag antar man ska läsa ner xml länken och presentera det på lämpligt sätt sedan i applikationen.
Tänkte ta och sitta med det mot helgen, all hjälp är uppskattad.
Jag håller på med ett litet bibliotek för att underlätta integration mot APIet. Det är inte så pass färdigt att jag vill visa upp det öppet men om du meljar eller PMar mig din adress så kan jag skicka över en betaversion. Borde räcka för att ge lite tips om ett sätt att lösa det på.
elf98 skrev:Ja, stängen kan inte vara längre än 15 tecken. Det borde räcka...
Ja, det lär räcka.
Ett problem dock, i wikin beskrivs "ClientVersionSet" som "Visar status i samband med att informationen om klientversionen uppdaterats." Vad jag kan se när jag testade så är ClientVersionSet alltid samma som den ClientVersion jag skickade in. Dvs, skickar jag in en sträng på 16 tecken så får jag samma 16 tecken tillbaka, men kör jag en sedan Version så får jag en version trunkerad till 15 tecken. Så ClientVersionSet kan inte användas till något just nu. Jag föreslår att du antingen ändrar ClientVersionSet till en riktig statuskod där t.ex 1 betyder att versionen blev ändrad, och 0 att den inte var giltig, eller att det som returneras i ClientVersionSet alltid är den versionen som blev satt (dvs den trunkerade i mitt exempel).
Jag skulle föredra alternativ 1, eftersom jag då inte kan hamna i ett läge där versionen är satt till något jag inte avsedde.
Jag har uppdaterat v1.11 så den version som visas är den faktiskt satta. Den läses tom in från databasen och trunkeras inte bara. Det som visas är därmed den info som finns i databasen.
