(Stress) TILEJSON testset maken BAG panden + bouwjaar + verblijfsobjecten + energielabel in test collectie

[eoudejans]

No description provided.

[MaartenHilferink]

[MaartenHilferink]

In https://dh.wzwkaart.nl/app/map/3 blijft memory rond de 50 MB.

[eoudejans]

https://kaartviewer.asa2024.nl/app/map/main/101?center=6.026266217058492;53.26871641815899&zoom=10&layerIds=213;207;110

Twee TILEJSON kaartlagen nemen ~800 MB geheugen in beslag

[eoudejans]

Instanties van JSArrayBufferData nemen 92% van geheugen in beslag.

[baasgeo]

Volgens mij is dit deels hetzelfde probleem als #16: MapGallery maakt per vector tile source een nieuwe source aan, dit verklaart de toename van het geheugen gebruik. Dit vraagt een correctie aan de applicatie.

Daarnaast kan ik me voorstellen dat raster tiles (voorgerenderde png's) uiteindelijk minder geheugen vragen dan vector tiles.

[MaartenHilferink]

We hebben onderzocht of meerdere layers met dezelfde geometrie dit probleem veroorzaakten, maar die hypothese moesten we verwerpen aangezien ook bij 2 kaartlagen met verschillende geometrie het geheugen al onverklaarbaar hoog is. Zie bijvoorbeeld: https://kaartviewer.asa2024.nl/app/map/main/101/info?center=5.831843573965216;51.94794923420369&zoom=8&layerIds=213;207;110
Ik denk dat GeoJSON / vector tiles uiteindelijk efficiënter in geheugengebruik zouden moeten zijn dan raster data, maar het lijkt er op (hypothese 2) dat de garbage collector of een reusable blob cache genaamd JSArrayBufferData ooit is ontwikkeld voor fixed size png-data en nu is hergebruikt voor variable sized vector tile data hetgeen retentie van bijna alle memory allocaties veroorzaakt. Of, een andere oorzaak wat wellicht enkel nadere diagnose en fixen behoeft, of herontwikkeling van libre-maps.

Ik stel voor straks even te overleggen om fallback opties te bespreken en wanneer we daar dan een knoop over moeten door hakken.

• implementatie met raster tiles conform wzwkaarviewer
• alleen data tonen na flink inzoomen (schaal: enkele gemeentes of groter), en voor de overviews de raster oplossing
• beter simplifyen geometrieen.
• Martin tile server

Zie ook https://github.com/orgs/ObjectVision/projects/16

[baasgeo]

Zou het misschien aan de tiles zelf kunnen liggen?

Ter vergelijk heb ik twee kaartlagen uit de Martin tile server toegevoegd, Wijken 2022 TEST en Buurten 2022 TEST.

Wanneer beide kaartlagen zijn toegevoegd, komt het geheugengebruik uit op 133 MB, dat lijkt me acceptabel.

[MaartenHilferink]

Hoe groot was de CBS buurtkaart .shp en gerelateerde vector tiles op de Martin tile server ?

Wellicht was daar al geometry gesimplified, wat we bij ASA2024 ook nog wel verder willen doen, maar dan blijft er een (te) grote factor tussen brondata en geheugengebruik hetgeen aannemelijk maakt dat het datamodel niet past en/of de caching / garbage collection ergens op fout loopt.

Bij ASA2024 was Buurt.shp ongeveer 80 MB ?), in verctor tiles: XXXX (@eoudejans ?); resultaat in viewer zonder gaspijpen: 500 MB, en wellicht oplopend.

[baasgeo]

Dit zijn de standaard CBS shapes (geometrie en ca. 40 velden met data), dat zal ook rond de 80 MB liggen. Het is rechtsreeks in postgis gezet, zonder conversie of simplificatie. Martin server doet een realtime conversie via de postgis functies ST_AsMVTGeom en ST_AsMVT. Even bellen?

[MaartenHilferink]

Bij alleen OSM achtergrondlaag en uitzoomen zijn de volgende JSArrayBufferData geregistreerd:

[MaartenHilferink]

[MaartenHilferink]

[MaartenHilferink]

Hee, probleem lijkt ineens opgelost:

[MaartenHilferink]

BTW, op welk schaalniveau wordt er voldoende gesimplified? 1e plaatje is OK, 2e zou als 1e moeten zijn, zelfs na enorm inzoomen liever de eerste gesimplifyde versie dan een gecrashde telefoon.

[MaartenHilferink]

Maar op dit zoom-niveau (kennelijk zonder simpliciatie als ik naar de Friese kust scroll):

[MaartenHilferink]

Ter vergelijking: 3d tiles in Google Maps:

[eoudejans]

Zou het misschien aan de tiles zelf kunnen liggen?

@baasgeo Mogelijk gerelateerd, voor Mapbox gl is enige tijd terug een bug opgelost mbt pbf lezen met string velden >12 bytes en veel memory vasthouden: mapbox/pbf#109. Dit is natuurlijk wel voor de fork / ontstaan van Maplibre gebeurt, dus deze fix zou meegekomen moeten zijn.

[MaartenHilferink]