Bygg databas

[ChrisofAllTrades]

• [x] Fixa utvecklingsmiljö
  • [x] PostgreSQL server
  • [x] pgAdmin
• [x] Databasschema
  • [ ] Databas för grupperingar
• [x] Script för att seeda databas
  • [ ] Expandera till hela datasetet

[ChrisofAllTrades]

Behövs inte för PoC.

[ChrisofAllTrades]

Jobba mig uppåt i komplexitet. Använd endpoints för export som utgångspunkt för skala och begär bara data när det är rimligt:

• [x] 100 obsar (PoC)
• [x] 25 000 obsar
• [ ] 2 000 000 obsar
• [ ] Samtliga obsar

[ChrisofAllTrades]

SOS API är byggt kring MongoDB som är document-relational, vilket är användbart då det finns enormt många attribut i databasen där många har null-värden i en given query. Vi behöver inte använda så många (och de vi har kommer som regel att ha ett värde) så det lämpar sig bättre med ett relationellt DBSM. Valet landar inledningsvis på PostgreSQL, som både är FOSS och pålitligt.

[ChrisofAllTrades]

PostgreSQL-servern är uppe och kör och går att komma åt (lokalt) genom pgAdmin. Gjort en testdatabas som ska seedas med taxa från Taxon List Service API (TLS API). Har också skrivit ett script som hämtar data från TLS och skickar det till databasen.

Gjorde det tidsödslande misstaget att importera till csv när strukturen i API:n är i json. Det gav stora problem att konvertera datan till något Pandas kunde använda. Till sist insåg jag att det var bättre att importera till json direkt istället.

[ChrisofAllTrades]

Error 400 BAD REQUEST vid hämtning av data betyder oftast att det är för många rader i queryt. Begränsa sökningen mer.

[ChrisofAllTrades]

Tre olika operatorer i SOS API kan användas för att seeda och uppdatera databasen:

• Observations_ObservationsBySearch (max 1000 obsar, går att ange exakt antal)
• Exports_DownloadCsv (max 25 000 obsar)
• Exports_OrderCsv (max 2 000 000 obsar)

Nackdelen med de två sista är att om en förfrågan överskrider maxantalet obsar returneras ett fel. Vid automatiserad nedladdning av data så måste sökningen därmed begränsas så pass mycket att det aldrig inträffar. För att ta reda på hur många obsar som förväntas under en given tidsperiod hittade jag statistik för 2022 och 2023 på Artportalen. Den visar att i genomsnitt så rapporteras (avrundat till närmaste hundratal):

| **2022**  | **2023**   |
| 19 400    | 22 800     | per dag
| 135 600   | 159 600    | per vecka
| 591 000   | 695 500    | per månad
| 1 773 100 | 2 086 500  | per kvartal
| 7 073 000 | 8 323 100* | per år

*extrapolerat över hela året baserat på de 6 658 500 rapporter hittills i år (förmodligen i överkant då vintern har mindre aktivitet)

Eftersom 2023 överstiger 2 000 000 för ett genomsnittligt kvartal och även det genomsnittliga månadssnittet är närmare en miljon anges rimligen en (1) månad som tidsintervall för att seeda databasen (och kan möjligen ökas inkrementellt bakåt i tiden då frekvensen av rapporter har ökat länge).

Och eftersom genomsnittet per dag 2023 närmar sig gränsen på 25 000 obsar vore det säkrare att dela upp det i tidsintervall och skicka flera förfrågningar per dag (m.h.a. TimeRangeDto[Morning , Forenoon , Afternoon , Evening , Night] t. ex.). Det har också fördelen att databasen hålls mer uppdaterad. Dessutom är Exports_OrderCsv är olämplig här eftersom den mejlar en länk för nedladdning av fil, vilket är svårt att automatisera.

[ChrisofAllTrades]

Det visar sig att ändpunkterna Exports_DownloadCsv och Exports_OrderCsv inte inkluderar tidpunkt i event.startDate och endDate. Jag skickade en fråga om det till SLU som svarade att de skulle undersöka om det var en bugg men att det fungerar med GeoJson. Modifierar koden till att hantera det formatet istället.

En effekt av formatet är dessutom att location följer med i en egen kolumn (jag tror det är gjort för att lätt kunna hanteras i GIS) men den är i lat/long-format istället för Sweref99. Jag tror inte att det innebär några problem (annars skulle de väl inte använda det) men behöver stämma av med teamets visualiseringsexpert först.

[ChrisofAllTrades]

Separerade göromålet att utveckla funktion för att uppdatera databasen till ett eget issue. Det behövs inte för att uppnå MVP.