QGIS V3 erg trage opstart met BGT/BAG/BRK in PostGIS

Geo4kant · 25 juli 2020 om 11:59

Als (bijna) dagelijks QGIS gebruiker wil ik toch een keer melden dat ik nog steeds gemengde gevoelens heb bij versie 3… Dit komt eigenlijk alleen omdat ik ook een fervent gebruiker ben van de maandelijkse PostGIS dumps van de BGT, BAG en BRK, eerst via NLExtract en inmiddels via GeoToko.nl.

Maar gebruik van deze Postgis databases in QGIS V3 levert toch een wel een flinke drempel op, waarvan ik me afvraag of die ook valt te vermijden?

Iedere keer als ik een project open met een uitgebreide opzet van genoemde 3 basisregistraties (totaal zo’n 80 themalagen), dan heeft dit initieel zo’n 5-7 minuten nodig om te laden… Dit terwijl een vergelijkbaar project in QGIS 2.18 in 5-10 seconden opent…(!)

Dit heeft me er toch weer toe gebracht om meer met QGIS 2.18 te gaan werken, omdat die initiële drempel wel erg irritant is, zeker als je even snel iets aan iemand wil laten zien…
Maar werken met 2.18 valt steeds moeilijker vol te houden met alle vernieuwingen van interessante en nuttige plugins (PDOK, RP, Streetsmart,…). Want die werken alleen nog maar op basis van QGIS V3.

Ik vroeg me af of iemand hier ook last van heeft en wellicht ook een passende oplossing weet?

Op zich ben ik niet de eerste die dit specifieke probleem heeft geconstateerd, zie ook deze bugmelding

Maar ik had gehoopt dat er met de doorontwikkeling van V3 hier toch enige verbetering in zou worden bereikt. Daarom versie 3.14.0 maar eens beetgepakt en de opening van een vergelijkbaar BAG/BGT/BRK-project getimed en vergeleken met de opening van dezelfde opzet in versies 3.8.3 en 2.18.0

En helaas blijkt dit niet de goede kant op te gaan. Door dit project extra zwaar te laten openen (alle lagen aan) geeft dit een nog hogere drempel dan eerder genoemd:
Bij V3.14.0 duurt dit uiteindelijk 17 minuten en 16 seconden!
Bij V3.8.3 - 15 minuten en 37 seconden
Bij 2.18.0 - 58 seconden

Opmerkelijk ook dat hier dus ook weer zo’n 10% extra vertraging zit tussen versie 3.8 en 3.14.

En ja, deze initiële drempel valt natuurlijk te versnellen door niet alle lagen open te laten staan bij het opslaan van je project en verder ook slimmere presentatie-instellingen te kiezen (schaalafhankelijke presentatie etc).

Maar als je slechts een beperkt aantal lagen opent bij de start, heb je later toch weer mogelijke vertragingen als je extra lagen open wil zetten. Dit kan soms wel een minuut per laag zijn.

In die zin was ik ook getriggerd om nog eens wat Postgis-lagen te laden in een kaal project in V3.14.0 Dit gaf laadtijden die variëren van ruim 20 seconden (bij puntobjecten zoals nummeraanduidingen) oplopend ca. 1,5 minuut (BGT-wegdelen).

Ja, ik weet het. Dit zijn lagen met ieder miljoenen records, dus wat verwacht je hier dan ook van…?

Nou ja, eigenlijk heel simpel, een performance die ik gewend was bij QGIS 2.18 … Daar duurt het toevoegen van zo’n enkele Postgis laag minder dan 1 seconde…!

Uiteindelijk geeft de vooruitgang met QGIS v.3 op dit punt dus een vertragingsfactor, die kan oplopen tot bijna 100 …(!)

Het kan natuurlijk zijn dat ik iets gigantisch over het hoofd zie, dus dan hou ik me aanbevolen voor een oplossing of een handige tip!

raymondnijssen · 27 juli 2020 om 15:07

Zelf ik heb ik geen ervaring met qgis projecten met zoveel grote postgis-lagen. Een aantal ideeen:

Je postgresql-connectie heeft een aantal opties die je met vinkjes aan en uit kunt zetten. Misschien breik je daar wat mee? In sommige gevallen gaat het laden van lagen dan plotseling veel sneller, bijvoorbeeld als je niet alle geometrien gaat lezen om te zien of ze wel allemaal van hetzelfde type zijn.

Geef ook feedback op het issue waarnaar je verwijst, waar iemand anders het probleem ook al heeft gemeld. Je brengt het probleem dan opnieuw onder de aandacht bij de ontwikkelaars waardoor de kans groter wordt dat ze het oppakken.
Dit is ook een probleem dat niet zo makkelijk te reproduceren is. QGIS ontwikkelaars hebben niet allemaal een BAG/BRK/BGT database (of iets vergelijkbaars) beschikbaar natuurlijk. En er wordt ook gevraagd om in de log van postgresql te kijken wat het verschil in queries is tussen 2.x en 3.x, misschien kun jij dat aangeven?
Als het je echt wat waard is, kun je een ontwikkelaar te betalen om dit probleem te fixen. Jij en je collega’s zijn dan van jullie probleem af, en je hebt een bijdrage geleverd om QGIS voor iedereen beter te maken. Als je hiervoor kiest, wil ik je wel helpen de juiste ontwikkelaar te vinden.

willemhoffmans · 10 augustus 2020 om 08:52

Mijn ervaring is dat de traagheid bij inladen vooral zit in de “actueelbestaand” views van de BGT en de BAG (van de NLExtract dumps). Laad je de tabel zelf in (b.v. pand i.p.v. pandactueelbestaand), dan gaat inladen wel snel zoals ik gewend ben.

Voor de BGT heb ik dat zelf opgelost, door na binnenhalen van de dump alles wat niet “actueelbestaand” is uit de tabellen zelf te gooien, en vervolgens de bijbehorende views ook overboord te kieperen. Voor mijn gebruik heb ik eigenlijk altijd alleen maar actueelbestaande objecten nodig.

Wellicht helpt je dat verder?
Sowieso wordt dat probleem natuurlijk steeds groter, naarmate de basisregistraties verder groeien, met steeds meer historie als ‘ballast’.

Groet,
Willem

Geo4kant · 11 augustus 2020 om 06:45

Dank voor je reactie Raymond, was afgelopen 2 weken op vakantie, dus mijn reactie is even blijven liggen.

Mijn primaire vraag was eigenlijk waarom een vergelijkbare benadering van dezelfde PostGIS databases vanuit v.3 zoveel meer vertraging oplevert ten opzichte van die vanuit v.2.18. Die wordt hiermee nog niet beantwoord.

Vermoed zelf dat er in V.3 eerst een soort indexering/buffering van Postgis tabel(len) plaatsvindt, maar ben geen techneut (‘tikker’), dus kan dit niet overzien.
Vermoedelijk moet je hier dus anders mee omgaan om vergelijkbare performance te bereiken, maar wellicht is dit gewoon ook niet meer mogelijk vanwege nieuw gekozen ‘functionaliteit’ in v.3 waarvan ik de meerwaarde nog niet heb ontdekt.

Jouw eerste suggestie rept over ‘opties met vinkjes’. Moest even zoeken wat je bedoelt, maar deze staan helemaal rechts bij de betreffende tabel in het Postgis keuzescherm voor laag toevoegen (en bij mij meestal uit beeld). Ik zie eigenlijk maar 2 vinkjes, waarvan ik er bij mijn voorkeurstabel maar 1 uit of aan kan zetten ('Op ID selecteren)… Bij mij staan die standaard aan, maar ik kan eens proberen of dit anders werkt als ze uit staan…

Jouw tweede suggestie kan ik doen, maar tegelijkertijd heb ik het gevoel dat dit niet echt een issue is wat door velen zo wordt ervaren, dus het blijft een dilemma of dit de investering in tijd waard is. Zeker als je eerst allerlei varianten moet gaan testen in twee versies om daarmee bruikbare log’s te genereren. Overigens heb ik het idee dat daar meest niet zo heel veel in te vinden is …

Jouw derde suggestie lijkt me wat slagvaardiger en wellicht ook combineerbaar met de tweede suggestie. Is te overwegen maar tegelijkertijd ook een dilemma hoe ver je dan moet gaan met investeren voordat je ook maar enige zekerheid krijgt over een positief resultaat… Dus daar ga ik nog even goed over nadenken…

Geo4kant · 11 augustus 2020 om 06:58

Dank je Wilem voor je reactie. Ik zie overigens niet of jij het verschil in performance ook herkent tussen versies 2.18 en 3.x…? Ben ik wel benieuwd naar.

De actueelbestaand views gebruik ik standaard niet, ik kies altijd de tabellen zelf, dus ook inclusief historie, maar normaal gesproken dan wel weer met een aantal filters.

En jouw suggestie om het nodige weg te gooien van iedere nieuwe dump vergt dus wel het nodige extra werk, wat ik voor versie 2.18 dus niet hoef te doen… Bovendien heb ik af en toe ook de historie nodig, dus die wil ik niet verwijderen op voorhand.

Nogmaals, ik ben dus met name benieuwd wat v.3 nu precies initieel extra doet met het openen of ophalen met die Postgis tabellen en of dit met bepaalde instellingen ook te vermijden valt zoals dit blijkbaar in v. 2.18 wordt gedaan…? Wellicht met het vinkje waar Raymond naar verwijst…

Dat de databases steeds groter worden is een gegeven, met name die voor de BGT. Die is in de afgelopen 3 jaar zo’n 25% gegroeid, maar desondanks valt deze vanuit 2.18 nog steeds relatief snel te openen…

raymondnijssen · 11 augustus 2020 om 07:31

Ik bedoelde de vinkjes onderin het ‘create postgis connection’ dialoogje.

2e en 5e vinkje zijn hier belangrijk. En ik vraag me af of de oude postgis1 layer-registry tabel nog steeds werkt. Dat is sinds postgis2 dynamischer geworden, maar misschien kun je daar hard de geom-kolom, het datatype en crs zetten?

Waarom er een verschil is? Tussen versie 2 en 3 is heel veel veranderd, vaak ook gewoon opschoonacties in de code. Of nieuwe versies van onderliggende libraries worden geimplementeerd. Dat kan natuurlijk invloed hebben op de functionaliteit of performance in bepaalde gevallen, bijvoorbeeld (views op) hele grote datasets. Als je het echt wil weten moet je zelf in de code duiken, of kun je het beter vragen op de internationale qgis kanalen.
Ik begrijp je dilemma, maar als het voor jou als “gedupeerde” al (te) veel werk is kun je je vast voorstellen hoe het voor een buitenlandse qgis-ontwikkelaar is om hier zomaar in te duiken.
Op zich kan een ontwikkelaar een fixed price offerte met deadline afgeven voor het oplossen van dit probleem. De meesten werken gewoon bij een bedrijf of als freelancer. Als meerdere partijen in Nederland willen bijdragen kan de uitvraag misschien via de Nederlandse QGIS gebruikersvereniging lopen? (Laat mijn fantasie even de vrije loop nu…)

Geo4kant · 11 augustus 2020 om 07:47

Raymond, nogmaals bedankt voor de aanvullingen. Daar had ik nog niet gekeken, zal er later vandaar even induiken en ben benieuwd!

Voor de rest, tja wellicht kan het wat opleveren. Maar het is mooier als genoemde vinkjes direct wat effect kunnen hebben…

fsteggink · 12 augustus 2020 om 05:14

De standaard NLExtract database dumps voor de BAG, BGT en BRK (DKK) hebben voor alle geometriekolommen het juiste gemetrietype gespecificeerd. Dit is te zien in de geometry_columns view. Dit geldt ook voor de *actueel- en *actueelbestaand-views. Er is dus geen sprake van een “unrestricted” geometrie.

In geval een bepaald objecttype meerdere mogelijke geometrietypen kan hebben, worden deze uitgesplitst in meerdere geometriekolommen. Bijv. BGT kunstwerkdeel bevat de kolommen geometrie_lijn, geometrie_vlak, geometrie_multipunt en geometrie_multivlak.