Lagring af koordinater, spredning og anden statistik for GNSS beregninger

[kbevers]

Det er ikke muligt at gemme alle de informationer vi gerne vil om en GNSS-observation/koordinat i FIREs Koordinat-tabel. Her har vi kun mulighed for at gemme referenceramme (SRID), observationstidspunktet, x, y og z samt tilhørende spredninger. Herudover er der behov for at lagre varianser og kovarianser fra kovariansmatrixen og observationslængden. Desuden er der udtrykt ønske om at kunne gemme antenne- og radometype (inkl. serienumre). Sidstnævnte er ikke muligt men kan evt. håndteres med sitelogs i stedet. Håndtering af kovariansmatrix og observationslængde kan betragtes som en observation der kan knyttes til den tilhørende koordinat med en beregning.

Konkret er der behov for oprettelsen af en ny Observationstype der kan rumme kovariansmatrix og observationslængde. Først og fremmest skal en række tilføjes i tabellen observationstype. Det skal være en observationstype med 7 værdier og intet sigtepunkt. Observationslængden er formentligt smartest at gemme som decimaldøgn.

En GNSS-beregning, fx fra 5D-opmåling, af fem punkter bør da udmunde i fem observationer, fem koordinater og en beregning. Noget i stil med:

beregning = Beregning()
koordinater = læs_koordinater_fra_bernesefiler()
observationer = læs_observationer_fra_bernesefiler()

beregning.observationer = observationer
beregning.koordinater = koordinater

# efter indsættelse i db bruges de fx på følgende måde
observationslængde = koordinater[0].beregninger[0].observationer[0].obslængde
spredning_x = koordinater[0].sx

Ovenstående er i sin rå form som umiddelbart er understøttet ved indførelse af en ny observationstype. Det er nærliggende at også tilføje støttefunktioner, der gør det lettere at trække information fra observationen ud sammen med koordinaten.

[kbevers]

For at oprette en ny observationstype skal der indsættes en ny række i tabellen observationstype, som definerer hvordan observationstypen skal forstås. Mere herom i dokumentationen. Herunder er et eksempel. sql/ddl.sql skal udvides med et nyt insert statement og efterfølgende indsættes rækken på FIRETEST databasen og på FIREPROD når vi er helt tilfredse med løsningen.

https://github.com/SDFIdk/FIRE/blob/edfa7fd30239ec0cf5252f1044d4acc3329fcda3/sql/ddl.sql#L1705-L1746

SQLAlchemy modellen skal udvides. Det gøres ved at nedarve fra Observation. Herunder er den relevante sektion i koden hvor Observation defineres, samt en lang forklaring på hvordan teknikken for nedarvning i SQLAlchemy virker.

https://github.com/SDFIdk/FIRE/blob/edfa7fd30239ec0cf5252f1044d4acc3329fcda3/fire/api/model/punkttyper.py#L514-L665

Og her et eksempel på en konkret implementering af en observationstype

https://github.com/SDFIdk/FIRE/blob/edfa7fd30239ec0cf5252f1044d4acc3329fcda3/fire/api/model/punkttyper.py#L667-L711

[larsnaesbye]

Skal jeg kaste mig over DDL?

[kbevers]

Prøv lige at vent lidt med det, jeg grubler lidt over hvordan vi bedst tager hånd om situationen hvor der ikke er kovariansmatrix og residualer til gængelige. Der er groft sagt to veje at gå i forhold til observationstyper. Enten laver vi observationstyper der rummer alt der er tilgængeligt for den enkelt beregning, eller vi splitter det op i mindre, men mere generiske, observationstyper.

Scenarie 1. GNSSLøsning der indholder observationstid og begge kovariansmatricer til de situationer hvor det hele er tilgængeligt og en Observationslængde der kan lagre observationslængden når kovariansmatricerne ikke er der. Her knyttes altid kun en observation til en koordinat.

Scenarie 2. Vi splitter informationerne op i Observationslængde, KoordinatKovarians og ResidualKovarians og lader hver koordinat have en til tre observationer.

Jeg tror scenarie 2 er det rigtige men jeg vil lige prøve et par ting af før jeg lægger mig helt fast på det.