Indledende understøttelse af tidsserieberegninger

[busstoptaktik]

Præmatur checkliste (rationale etc. nedenfor)

Med inddata punktgruppe-id og observationsperiode:

• punktgruppe-id er identisk med Jessenpunktidentifikatoren, altså et tal af formen 81nnn
• Observationsperiode er den periode vi vil se på observationer fra. Hvis udeladt: Gæt på seneste 6 måneder.

Gør dette:

• Udtræk punktgruppemedlemmer, p.t. ved at finde alle punkter, der har en kote i systemet sridid for srid = 81nnn. Dvs. et unique på koordinattabellens rækker med pågældende sridid
• Find i samme udtræk fra koordinattabellen (kote, tid) for alle tidsserieskridt og alle involverede punkter (og sorter efter punkt og tid)
• Find Jessenpunktet, dvs. punktet med ident 81nnn
• Find Jessenpunktets DVR90-kote (@Aslak-Meister: Hvilken kote - det må være den oprindeligt tildelte DVR90?)
• Find i observationstabellen alle nivellementsobservationer (geometriske og/eller trigonometriske, dvs. observationstypeid in [1, 2]), fra den valgte periode, som har et punktgruppemedlem som både fra og til punkt (hhv. opstillingspunktidog sigtepunktid). Relevant kode i info.py
• Skriv beregningsdefinitions-XML-fil og kald GNU Gama. Relevant kode i regn.py. Eneste fastholdte punkt er Jessenpunktet
• Læs output fra GNU Gama og opdater tidsserierne. Relevant kode i ilæg_nye_koter.py
• Plot
• Tilsæt menneskelig intelligens og rør rundt
  • Hvis menneskelig intelligens siger OK: Gem nye tidsseriekoter og dokumentation (Gama input- og outputfiler) i databasen
  • Ellers: Kast dig på gulvet og råb og skrig.

Husk

• Den anvendte Jessenkote skal nok være anført i den kommende punktgruppetabel
• @Aslak-Meister: Hvad var det, den virkeligt gode grund til ikke bare at sætte Jessenpunktets kote til 0 var?
• Mere information om fra/til punkt ovenfor
• Tests (i første omgang ikke i CI):
  • Kendt punktgruppe: Får vi de rette punkter ud
  • Rette DVR90-kote (tricky pga. eventuelle opdateringer)

Rationale

I FIRE "minimum viable"-produktet var succeskriteriet at kunne opfylde eksisterende kontraktforpligtelser - det vil primært sige kommunalt vedligehold, og i mindre grad opgaver for KDI og DMI.

Det kommunale vedligehold kræver både erfaring og fingerspidsfornemmelse mht. vurdering af observationskvalitet og udvælgelse af fastholdte punkter, men følger i øvrigt et ret fast skema, mens K(DM)I-opgaverne også kan inkludere håndholdte elementer. Derfor var fokus på kommunalt vedligehold, understøttet af et workflow, der er anvendeligt i marken.

Nu, hvor vi skal til at understøtte mere generelt geodætiske opgaver, vil det være fornuftigt (i det mindste konceptuelt) at opdele måleopgaveflowet i (mindst) to dele:

1. Observationer: Opmåling, kvalitetskontrol ("kontrolberegning") og databaseilægning af observationer
2. Beregninger: Endelig beregning og databaseilægning af opdaterede koter

Med en let variation af standardproceduren:

# Sagsadministration
fire niv opret-sag andeby_2020 "Vedligehold Andeby"

# 1. Observationer
fire niv udtræk-revision andeby_2020 K-99 102-08
fire niv ilæg-revision andeby_2020
fire niv ilæg-nye-punkter andeby_2020
fire niv læs-observationer andeby_2020
fire niv regn andeby_2020     #  <- kontrolberegning
fire niv ilæg-observationer andeby_2020

# 2. Beregninger
fire niv regn andeby_2020     #  <- endelig beregning
fire niv ilæg-nye-koter andeby_2020

# Sagsadministration
fire niv luk-sag andeby_2020

Når en opmålingskampagne specifikt har til formål at overvåge en punktgruppe kan vi i første omgang nøjes med trin 1 (opmåling, kvalitetskontrol, observationer i database), hvorefter selve beregningen kan foretages af dertil indhyrede studentermedhjælpere i et separat arbejdstrin. Dette arbejdstrin kan benytte til formålet mere egnede metoder end den Excelbaserede kommunal-vedligeholdelsesarbejdsgang.

Specifikt er der bl.a. større behov for integreret plot af tidsserierne (det er næsten umuligt at vurdere tingenes tilstand uden at have dem plottet som en tidsserie) end der er i tilfældet kommunal vedligeholdelse. Til gengæld er der meget færre fri parametre involveret: Fastholdt punkt er givet på forhånd, og observationerne er kvalitetskontrolleret på forhånd. Derfor er der ikke behov for at vælge fastholdt punkt interaktivt, og kun i mindre grad behov for at frasortere observationer.

Derfor giver det god mening at formgive arbejdsgangen som en Jupiter NoteBook (og måske i første omgang som et sæt simple fritstående Pythonscripts).

Arbejdsgangen er (idet vi antager at de ny tabeller til definition af punktgrupper er på plads):

1. Inddata: Punktgruppenavn og opmålingsperiode
2. Udtræk information om involverede punkter og Jessenpunkt fra DBen
3. Udtræk eksisterende tidsseriekoter for hvert af de involverede punkter
4. Udtræk DVR90-koten for Jessenpunktet
5. Udtræk alle nivellementsobservationer for de involverede punkter i den specificerede opmålingsperiode
6. Skriv beregningsdefinitions-xml-fil
7. Regn (GNU Gama)
8. Læs output fra GNU Gama og opdater tidsserierne
9. Plot
10. Tilsæt menneskelig intelligens og rør rundt
    • Hvis menneskelig intelligens siger OK: Gem nye tidsseriekoter og dokumentation (Gama input- og outputfiler) i databasen
    • Ellers: Kast dig på gulvet og råb og skrig.

Uafklaret, Sagsstruktur:

• Del af målesagen
• Sæsonvise tidsserieopdateringssager
• En evighedssag for hver tidsserie
• En sag for hver beregning