Fel antal k-värden i pdf vid export

[Peter]

Hej!

I Nyköping håller vi på och testar QGYF i ett projekt. Vi verkar ha upptäckt två buggar i verktyget. Jag har bifogat flera bilder för att lättare illustrera vad jag menar men dessa tror jag inte går att ladda upp här på forumet. Jag fick svar från er support att bilderna finns lagrade på er OneDrive så ni kan komma åt dem där i alla fall.

Bugg 1:
I vårt testområde har vi ett antal ytor som sammanlagt har fått 65 st k-värden. Dessa k-värden finns tydligt uppradade under fliken ”Klassificera” och alla ligger inom det röda beräkningsområdet. Jag har dubbelkollat flera gånger så att k-värdena faktiskt har en koppling till ytorna vilket de har. I rapporten som skapas visas dock bara 53 rader. Det här kan ni se i bilder och pdf som jag bifogat.

Eftersom rapporten inte skriver ut korrekt antal rader blir vi osäkra på om vi fått rätt GYF-värde i vår rapport och om alla k-värden räknats med. Jag vill tro att programmet räknat med alla k-värden och att felet ligger i hur rapporten genereras för på den sista raden (i bifogad pdf) ser det ut som att den försöker fortsätta skriva men att det bryts. Men det är bara en teori.

Så min fråga är om det kan finnas någon bugg i skapandet av rapporten?

Bugg 2:
Jag har två polygoner som ligger ”kant i kant” med varandra. Det finns inget överlapp utan de delar gräns. När jag räknar ut GYF på polygon 1 får jag även med alla k-värden som ligger på polygon 2 vilket blir fel. Beräkningsområdet följer polygon 1 exakt men ändå följer värdena från polygon 2 med i rapporten. Enda sättet att bara räkna på GYF i polygon 1 utan att få med värden från polygon 2 är att lägga beräkningsområdet en liten bit innanför polygon 1. Men när jag gör det så får jag inte med hela ytan som ska beräknas.

Kan det vara någon form av bugg där begränsningsområdet tar med alla ytor som den korsar och inte kör ”completely within”? I bilderna jag bifogat syns det här tydligare.

Vänliga hälsningar
Peter

[Elena Marchenko]

Hej Peter och tack för ditt inlägg!

Vi har även fått bilderna och jag har kollat snabbt på de upptäckta problem.

Bugg 1: Du har det helt rätt. Det är en bugg som rör bara rapporten och inte påverkar beräkningarna. Verktyget skapar inte en till sida av rapporten om tabellen är lång och bryter bara tabellen. Vi hoppas att åtgärda buggen i den närmaste tiden.

Bubb 2: Det är en bra observation. Vertyger kör ’intersect’, inte ’completely within’. Men jag tror inte att det påverkar beräkningarna som utgår ifrån intersectionsyta som blir 0 i fall det är bara gränsen som överlappar. Mem det är fel att radet kommer in i rapporten. Den ser ut att vi måste redovisa den här delen av koden som genererar tabellen från alla perspektiv.

Jag säger till när vi åtgärdar de här grejerna. Vi uppskattar din hjälp att förbättra QGYF:en!

[Elena Marchenko]

Hej!
Vi har publicerat en ny version av QGYF (1.5) där de rapporterade buggarna har blivit åtgärdat.

[Peter]

Hej!

Tack för att ni jobbat med buggarna! 🙂

Tyvärr så verkar problemen kvarstå för mig. Jag uppdaterade först pluginet men det blev ingen skillnad. Sedan avinstallerade jag det och installerade på nytt och testade att göra helt nya projekt men ingen skillnad. Kan det ha blivit något knas när ni la upp den nya QGYF-versionen?

Mvh
Peter

[Elena Marchenko]

Hej Peter!

Gäller det både av buggarna?

Elena

[Peter]

Hej!

Japp, det gäller båda buggarna.

Mvh
Peter

[Elena Marchenko]

Hej Peter!

Du har det helt rätt. Tack för din observation!
De senaste ändringarna har inte kommit med vid pluginens publicering. Jag har uppdaterat QGYF v.1.5 med de nya filerna just nu. Testa gärna att ominstallera pluginen och återkom om det funkar eller inte. Det borde vara ok nu.

Bästa hälsningar,
Elena

[Peter]

Hej!

Nu fungerar det. Tack så mycket för hjälpen! 🙂

Mvh
Peter

[Författare]

Inlägg