Trage download BGT zip-bestanden

Datasets BGT
#1

Het downloaden van BGT data via https://www.pdok.nl/downloads?articleid=1948972 duurt vaak erg lang, en bij vlagen extreem lang. Om wat voorbeelden te noemen: 4 tegels op hoogste zoomniveau stedelijk gebied duurde gisteren in de ochtend ruim 15 minuten, in de middag 7 minuten. Maar soms is het ook zo enorm traag dat je na een half uur wachten nog maar 2 MB binnen hebt van de data. Dit zijn niet alleen eigen ervaringen maar ook van tientallen van onze klanten die deze traagheid eveneens ervaren.

Bij vragen aan het Kadaster heb ik enkele malen een reactie terug gehad met daarin de mededeling dat bij testen aan hun kant altijd hoge snelheden worden gehaald en dat ze het probleem niet herkennen.

Nu kan het best zijn dat de netwerken en internetverbindingen van onze klanten allemaal beperkende factoren hebben, maar dan nog is het opvallend hoe traag het downloaden gaat. Andere downloads (ook andere bronnen van PDOK) gaan namelijk wel met hogere snelheden.

Nu is iedereen reuze blij met de beschikbaarheid van de BGT en hebben we heel veel waardering voor degenen die dit mogelijk hebben gemaakt. De klachten over de snelheid zijn dus geen aanval op de organisatie :slight_smile:

Maar toch zou ik graag willen weten of er veel meer mensen deze traagheid ervaren, en ook als storend voor hun werkzaamheden? Zijn er andere mogelijkheden om de BGT data als vectoren te downloaden maar wel sneller gaan? De WFS is volgens mij nog experimenteel dacht ik? Wat kan ik mijn klanten adviseren?

Downloaden BGT-extracten
#2

Ik herken dit zeker. Het downloaden gaat vaak maar met enkele kB/s.

Waar ik me echter meer aan erger is dat ik vaak (na lang downloaden) een time-out krijg en een corrupte zip overhoudt. Zie https://forum.pdok.nl/t/sommige-bgt-tegels-resulteren-altijd-in-corrupte-zip/792/16.

#3

Ik herken dit ook.
Sommige (veel) downloads vanaf de PDOK gaan met grote gezwindheid. Maar extracts uit de BGT gaat inderdaad met kb/s. Hij is minuten bezig om een extract van zo’n 32MB te downloaden. En inderdaad kans op afbreken van de download.
PDOK-BGT-download vanaf een onderwijskundige organisatie.

Aanvulling 2018-09-12: zelfde lage downloadsnelheid vanaf de locatie van een waterschap. Ik verwachtte je binnen de PDOK-Basis-voorwaarden een hogere performance, maar daar lijkt het niet op.

#4

Een BGT download tegel worden bij PDOK niet gecached dit in tegenstelling tot de landelijke download. Het lijkt erop dat dit samenstellen van de tegel te lang duurt. We moeten de oorzaak hiervan uitzoeken. Ik heb hier een issue voor aangemaakt (PDOK-7935)

#5

Klinkt goed. Kunnen we de issue volgen? Of wordt het resultaat hier gedeeld?

Ik kan me voorstellen dat de huidige methode is vanwege de dagelijkse verversing van de data en dat cachen geen zin heeft. Ik kan me voorstellen dat veel gebruikers evengoed blij zijn met een maandelijkse verversing.

Ik ben benieuwd of er een goede oplossing bedacht kan worden :slight_smile:

#6

Ik heb ook heel vaak corrupte tiles, timeouts, en als het goed gaat een downloadsnelheid van luttele kb/s. @John_Schaap

image
image1355Ă—318 24.5 KB
ik weet niet of het landelijke bestand nu veel beter is…

#7

Hallo @JvdB de door jou ervaren downloadsnelheid bij een tegel bestaat uit twee delen, de tijd om de zip te maken en de tijd om de zip te transporteren. Beide tijden zijn afhankelijk van de belasting van de systemen. De landelijke zip wordt tegenwoordig s’nachts klaargezet. De vertraging gerelateerd aan het “on the fly” genereren van een zip aan de hand van een specifieke selectie bestaat hier dus niet. Downloaden van de landelijke zip zou altijd veel beter moeten gaan. Bij de landelijke zip zou een download manager ook een “resume” moeten kunnen doen bij een onderbroken verbinding. Bij een tegel is dit door het “on the fly” genereren nu niet mogelijk.

#8

Bedankt voor het antwoord @John_Schaap. Het bovenstaande plaatje was voornamelijk ter indicatie dat (alhoewel de download bij de landelijke download mss wel gelijk begint) de verbindingsproblemen hetzelfde lijken.

#9

Die van Nlextract.nl is sneller, wel even 10 GB downloaden, omzetten naar een 40GB database met 5GB temp. 8MB geheugen en 1 processorthread wordt gebruikt door PostgreSql, ca. 3 uur.

Updates niet mogelijk daar, volledige download. Waar wel? Jaarlijkse volledige download, dan maandelijks een update: wijzigen, toevoegen en verwijderen?

#10

Intussen zijn we enkele maanden verder en de storingsmelding op Home heeft het over het “verhelpen binnen afzienbare tijd”.
Is het mogelijk om wat meer informatie te krijgen over de stand van zaken?

#11

Hallo @Anton,

Bedankt voor de opmerking. We zullen de tekst “binnen afzienbare tijd” aanpassen, omdat de oplossing langer op zich laat wachten.

Wel kan ik een update geven over de stand van zaken.
Om dit probleem structureel op te lossen hebben we een geheel andere BGT verwerkingsstraat gemaakt. In deze straat worden tegels klaargezet in de 3 download formaten. We hebben een API en een webpagina gemaakt waarmee de gebruiker m.b.v. een polygoon een gebied kan selecteren. Met een polygoon wordt dan een zipfile klaargezet waarin de klaargezette tegels gecombineerd worden. Op dit moment staat deze oplossing klaar op test infrastructuur. De landelijke voorziening moet deze test (Beta) omgeving dagelijks van data gaan voorzien. Hierna zullen we gebruikers uitnodigen om deze nieuwe downloads te evalueren. Na een succesvolle testperiode kunnen we dan deze verwerkingsstraat op productie infrastructuur aanbieden.

Voor nu blijft het advies om de landelijke downloads te blijven gebruiken.

1 like
#12

Bedankt John voor het antwoord! Als het geen open uitnodiging is om te testen dan zou ik alsnog graag willen testen op toepasbaarheid en snelheid.

Gaat de tegel-selectie er helemaal uit?

Ben benieuwd naar het resultaat!

#13

Tegels worden ondersteunt maar anders. In de nieuwe API ondersteunen we de huidige naamgeving van tegels niet meer. De huidige tegelnamen zijn een implementatie manier, die nu in de interface gebruikt wordt. De nieuwe API staat los van de implementatie. Op het moment dat je als polygoon de vierhoekpunten van een bestaande tegel gebruikt krijg je in ieder geval alle objecten binnen dit vierkant. Naast de objecten binnen dit vierkant komen er ook objecten mee aan de randen van de gevraagde polygoon (overshoot). Met het testen willen we beginnen zodra we de dagelijks data krijgen uit de landelijke voorziening. Om een indruk te krijgen hoe het een en ander gaat werken hebben we een bèta omgeving klaar staan met “oude” BGT data van vorig jaar december. Deze bèta is te vinden op https://download.pdok.io/lv/bgt/viewer/.

#14

Het ziet er cool uit @John_Schaap, maar inderdaad anders dan de huidige. Ik zal me tijdens de testronde gaan verdiepen in de API.

#15

Volgens mij is het wel weer tijd voor een update @John_Schaap :slight_smile:

Kun je al iets meer vertellen?

#16

Iemand anders misschien?

#17

Hallo @Anton, hier even een update. We hebben nu een aansluiting op de landelijke voorziening BGT. Hiermee zijn we nu testen aan het uitvoeren. Dit doen we om goed inzicht te krijgen in de performance en stabiliteit van het doorleveren. We weten nu dat een volledige doorlevering van de BGT naar alle uitleverformaten in 5 dagen kunnen realiseren. (dit volledig doorleveren in het bestaande systeem duurde vorig jaar ongeveer een maand) . We hebben ook dagelijkse doorlevering getest en weten ook dat de huidige test-data van vorige week die nu in dit Beta systeem zit niet helemaal correct is (b.v. geometrie type ontbreek in het stuff-geo formaat). We verwachten komende week een nieuwe volledige doorlevering vanuit de landelijke voorziening waarin dit gecorrigeerd is, waarna we dan weer dagelijkse doorleveringen kunnen gaan verwerken.

#18

Super @John_Schaap, bedankt voor de update!

Het geeft wel de volgende vragen :slight_smile:

  1. Wanneer komt het live?
  2. Is er een overgangsfase waarin het huidige systeem met de tiles ook actief blijft?
  3. Is er een beperking op de polygoongrootte? Heb net even een kleine test gedaan maar vanwege lat-lon mogelijk een te groot gebied aangegeven
  4. Kunnen ook RD coördinaten worden opgegeven als geofilter of alleen lat-lon?
  5. Is dit systeem alleen voor BGT of gaat dit ook gelden voor Kadastrale kaart?
#19

@Anton hier een update over je vragen:

  1. Voor BGT zal dit voorlopig alleen beschikbaar zijn als Beta naast de bestaande downloads op pdok.nl.
  2. Ja en het bestaande productie systeem blijft voorlopig gewoon bestaan.
  3. Het geofilter is in RD. Wij hebben technisch nog geen beperking in polygoon grootte kunnen vaststellen. Bij grote polygonen duurt het voorbereiden van data langer.
  4. We ondersteunen nu alleen RD.
  5. Ja en de verwachting is dat de Kadastrale kaart eerder live gaat met een vergelijkbare API, inclusief een mutatie API waarmee dagelijkse mutaties van BRK Geo (grenzen en percelen) downloadbaar worden.
#20

Ok, verrassend. Waarom blijft de BGT zolang in beta eigenlijk? Het huidige systeem is niet erg hanteerbaar meer, ik had verwacht dat deze het snelst vervangen zou gaan worden.

De beta zal dan wel met actuele data gaan werken? Zodat we het eventueel in productie kunnen gebruiken?