Replies: 3 comments 8 replies
-
|
Vedr. punkt 1: Som jeg husker samtale med Majbritt om dette, så er det den "lægtekalibrerede fil" man skal regnevidere på (så det er outputfilen fra rodkali.py, der skal anføres som inputfil i regnearket. Lyder det plausibelt? |
Beta Was this translation helpful? Give feedback.
-
|
Jeg ved ganske lidt om lægtekalibreringen, men jeg ved da at vi har koden til det her: https://github.com/Kortforsyningen/rodkali Jeg er i tvivl om hvor i hele processen det gøres, men tilsyneladende før vi tager fat på beregninger osv med
Især det sidste tænker jeg der er fidus i, da det lyder som om at der i de fleste tilfælde ikke skal gøres yderligere efter kalibreringen er foretaget. Så kan vi lige så godt bygge et workflow hvor man kun skal gøre noget i tilfælde af kalibreringen ikke lever op til kravene. |
Beta Was this translation helpful? Give feedback.
-
|
Jo, jeg mener egentlig også at det bare skal oprettes som issue, når vi er færdige med at diskutere det her. Men det skal prioriteres eksplicit hvis vi skal tage fat på det: Vi har et arbejdsflow der virker (med mindre jeg husker snakken med Majbritt forkert), og vi har nok ikke store mængder geometrisk nivellement i arbejdsporteføljen fremover? |
Beta Was this translation helpful? Give feedback.
-
|
Det sidste må være et spørgsmål til opmålingsteamet - jeg aner det ikke. Men mon ikke @ErikLysdal eller @ReneTandsbjerg kan svare på det? |
Beta Was this translation helpful? Give feedback.
-
|
Jes, du husker rigtigt :) Output fra rodkali skal være input i regnearket, så dur workflow som normalt. Men hvis det kan inkorporeres i regnearket, som Evers foreslår, så vil det jo være nemmest for brugeren. Man definerer alligevel at inputfilen er af typen "mgl", så den info bør vel være nok til at en rodkali-agtig funktion påføres råfilen.. Der kommer nok masser af mgl-måling fremadrettet også, da mtl-metoden ikke er god nok i punktgrupper og ved korte sigter. Og så er der også det aspekt at det af og til at meget nemmere at hive Dini'en frem og måle med, end at skulle bakse med de store instrumenter og pc'er og halløj.. Især sådan op på bagsiden af en kirke eller rundt på havneområder ved vandstandsmålerne... Man kan så sikkert regne på hvor meget korrektionerne rent faktisk betyder i disse tilfælde, hvor det alligevel er over kort tid (og dermed formentlig samme temperatur) og med korte sigter og få målinger, og dermed hvor meget det haster at få fikset sådant et issue inden vi kører fuld beregning og resultater i db... Det var ikke for at blande mig, men nu havde du trods alt nævnt mit navn et par gange ;) |
Beta Was this translation helpful? Give feedback.
-
Tak, @majbrittws - jow, jeg havde nævnt dit navn, men udeladt at tag'e @majbrittws, fordi du da ikke skulle føle dig forpligtet til at tage fat i noget du har sluppet ansvaret for. Men det er dejligt at høre fra dig, og fedt at du gider tage del! |
Beta Was this translation helpful? Give feedback.
-
|
Vedr. punkt 3: Tjek af journalside fejl. så ser vi denne som løst ved brug af funktioner i Excel Arket |
Beta Was this translation helpful? Give feedback.
-
|
Vedr. punkt 1 (lægtekalibrering): Her er så vidt jeg kan se ikke nogen forskel på den gamle og den nye fremgangsmåde: Man lægtekalibrerer sin målefil, og indtaster navnet på den kalibrerede fil i regnearkets faneblad @ErikLysdal , @ReneTandsbjerg: Ser I nogen problemer i dette? |
Beta Was this translation helpful? Give feedback.
-
|
@majbrittws har svaret ovenfor, så denne er løst |
Beta Was this translation helpful? Give feedback.
-
|
Hvordan ved vi at FIRE bruger kalibrerings filen og hvor ser vi afvigelserne?? Herunder et eksempel på en en obsfil med korrektioner. 17 ; Corrections calculated at Mon Nov 11 17:37:28 2019 |
Beta Was this translation helpful? Give feedback.
-
Man ser afvigelserne på samme måde som i dag: I den kalibrerede fil. Og man ved at det er den kalibrerede fil der bruges, fordi det er dens navn man selv har indført i inputfiloversigten, så |
Beta Was this translation helpful? Give feedback.
-
Skrevet Palle.
1. Indsættelse af lægtekalibreringskorrektioner
Når der skal beregnes på geometriske målinger skal observationerne først korrigeres med resultatet fra den seneste lægtekalibrering.
Den seneste og aktuelle kalibrering er fra d. 01.02.2017, se med rødt i skærmdump herunder.
De nederste 6 linjer i outputtet angiver størrelsen af de korrektioner rodkali.py har påført rå-data. Først er gennemsnittet af korrektionerne, spredningen af korrektionerne samt den maksimale korrektion angivet i mm, dernæst er de samme størrelser angivet i ne.
Hvis værdierne på de nederste 6 linjer i outputtet er lavere end ca. 0,2 mm og 0,2 ne, er korrektionen forløbet ok.
Hvis der forekommer korrektioner større end 0,2 ne, vil outputtet fra rodkali.py indeholde advarsler om store korrektioner svarende til eksemplet nedenfor. Hvis disse advarsler forekommer, skal det konkret vurderes, om de påførte korrektioner kan være korrekte samt noteres i QC-arket - gerne med angivelse af eventuel årsag til de store korrektioner.
Herunder et eksempel på en en obsfil med korrektioner.
Linje 21 er den originale måling, ”;” så den ikke læses…
Linje 22 er måling med korrektioner
2. Kontrol af at der findes både en frem- og tilbagemåling.
Ifm. oversættelse af obs-filen til et format som regneprogrammet kunne læse blev denne kontrol fremstillet. Kontrollen fanger de steder hvor der rent faktisk er glemt at måle både frem- og tilbage, og den vil også finde den fejl hvor man har noteret rigtige punktnumre den ene vej, men et forkert den anden vej, så vil de blive vist som 2 enkeltstrækninger. Typisk fejl ved nyetablerede punkter hvor punktnumre indtastes manuelt.
Hvis der fremkommer enkeltstrækninger vil det være en hjælp hvis der bliver oplyst start- og slutpunkt på målingerne, så er de lige til at finde og rette, hvis det vel og mærke er punktnummerfejl.
Der skal tages højde for at der i visse punktgrupper måles 2 frem- og 2 tilbagemålinger, altså 4 målinger i alt.
Output af kontrol i REFGEO:
I en test har jeg fjernet en måling, og jeg kan regne hele vejen igennem uden problemer og uden fejlmelding. Ved manuel kontrol af fanebladet ”Observationer” kan jeg konstatere at målingen mangler, jeg tænker det er i denne fane der skal laves en kontrol, og det skal være en kontrol af at når der er målt fra A til B, så skal der også ligge en måling fra B til A.
3. Tjek af journalside fejl.
Der skal tjekkes at der ingen journalsidefejl er, -resultat.xlsx vil man i fanebladet ”Observationer” (som kopieres til –xlsx) under kolonnen ”Journal” kunne se alle journalnumre i rækkefølge. Da journalnumrene typisk er fortløbende vil evt. fejl dukke op enten i top eller bund af kolonnen.
Men der skal fremstilles en kontrol af at der ingen dubletter er.
4. Tjek af at der er beskrivelse til alle målte punkter
Primært et tjek af at tekster til nyetablerede punkter er opdateret.
5. Kontrol af at der ikke er målt til et punkt som er tabtgået
Fejlen forekommer typisk ved et punkt er konstateret tabt i en punktrevision, og at en nyetablering er foretaget i samme område, så er der mulighed for at markere det tabtgået punkt i mtl-softvaren under opmålingen, da punktdatabasen på opmålings pc´erne typisk kun opdateres en gang om året.
Det kræver selvfølgelig det tabtgåede punkt er blevet opdateret i databasen.
6. Hvis 2 punkter der er målt til indbyrdes fastholdes i en beregning
Jeg har endnu ikke nået denne test, men hvis 2 punkter der er målt til indbyrdes fastholdes i en beregning, så skal det fremgå af plottet at der ingen måling er imellem de 2 punkter, og er det ene et endepunkt i en målelinje skal det samtidig fremstå som singulær.
Beta Was this translation helpful? Give feedback.
All reactions