Alle corrupte zips zijn inmiddels vervangen.
Voor efficiënt offline gebruik zouden de tegels inderdaad veel kleiner mogen. Maak het Lean en sneller voor gebruikers! Misschien een grid onderverdeleing in de tegels. Nog mooier zou zijn een als je als gebruiker een gebied zou kunnen selecteren zoals met de BGT viewer nu kan.
1 like
Opknippen is vrij makkelijk (maar wel zwaar en duurt lang) met “cjio”.
Ik gebruik dit om de grond weg te halen:
cjio "je-tegel-id.json" subset --cotype LandUse --exclude subset --cotype PlantCover --exclude subset --cotype TINRelief --exclude save "je-tegel-id-no-TIN.json"
Daarmee gaat een landelijke tegel van 1.3gb naar ongeveer 15mb.
Er zijn ook functies om te clippen met een bounding box.
2 likes
Tegel 38fn1 heb ik inmiddels via de QGIS plugin ingelezen. Dit kost zeker een half uur (niet bijgehouden, liet het op de achtergrond draaien). En dat op een snelle computer.
Wageningen ligt op 4 tegels, dus dat ga ik nu nog maar even niet uitproberen. De tegels zullen echt kleiner moeten wil je gebruikers tegemoetkomen…
@David, voor een standaard gebruiker is dit opknippen geen doen. Ik neem aan dat dit een linux commandline is?
Werkt ook op Windows. Het is een python package met een command line interface.
Activeer een python virtual environment (met anaconda is dat niet moeilijk) en run:
python -m pip install cjio
Of dat te doen is voor een standaard gebruiker hang volledig af van jouw definitie van standaard gebruiker.
Casual gebruiker van GIS software pakketten, misschien niet. Ik heb me er nog niet erg in verdiept maar ik zag niet de meerwaarde van het inladen in QGIS. Volgens mij slaat QGIS alle geometrie plat en de attributen zijn niet uniek voor deze dataset.
Mijns inzien is dit meer bedoelt als basis laag waar ontwikkelaars hun 3D visualisaties van context mee kunnen voorzien.
Bedankt! 30gz1 is nu inderdaad ook in orde.
Ik heb m.o.m. dezelfde ervaring.
Ik dacht met 36hn2 een echt kleine tile (> 99% water) te hebben, maar zelfs daar is QGIS nu al 20 minuten op aan het ‘rekenen’.
Conversie naar CityGML ging wèl. dat leverde een bestand op van 68 kb.
Mijn eennakleinste tile (30dz1) was echter al te groot om (d.m.v. citygml-tools-1.4.0) te converteren. Dat leverde een Java out of memory error op na meer dan een half uur.
Zoals de vlag er nu bij hangt kan ik er nog niet zo veel mee.
Eén simpel advies m.b.t. de grootte van de bestanden:
Het zou al ettelijke tientallen procenten schelen als alle coördinaten er met maar 2 cijfers achter de komma in zouden staan.
Nu zijn het er vaak 9 en voor de z-coördinaten zelfs nog meer.
Dat viel me laatste ook op. Ik dacht dat AHN een nauwkeurigheid kon ‘garanderen’ van ca 3 cm. Het heeft toch helemaal geen zin om ubehaupt achter de comma te verwerken. Benieuwd naar de rede hiervoor.
Zelfde ervaringen als hierboven. Mooi dat een dergelijke set beschikbaar wordt gesteld, maar op dit moment zijn de tiles te groot om even wat mee te experimenteren. Dat zal de adoptie niet ten goede komen. Geprobeerd met QGIS, Blender en ninja. Zelfs het inspecteren van de json met een editor (bijvoorbeeld Sublime) is praktisch al niet te doen. Kleinere files zou denk ik al veel schelen.
Edit: op tweakers staan ook nog een hoop ervaringen in de reacties Het Kadaster stelt 3d-bestand van Nederland beschikbaar als open data - IT Pro - Nieuws - Tweakers
Wanneer we de bestaande tiles nog een keer gaan halveren komt er ook meer overlap. We gaan zeker nog kijken of we dit kunnen verbeteren.
We verwachten nog wel een kleine verbetering te kunnen doorvoeren door het aantal witregels te verkleinen. Hiermee zou het bestand zo’n 20% kleiner worden. Wat de gevolgen zijn voor het inladen moet dan nog getest worden.
De afronding van decimalen kunnen we helaas niet zonder meer aanpassen. De software doet een match op basis van de huidige hoeveelheid decimalen. Een verkeerde aanpassing kan grote gevolgen hebben.
Blender en Ninja zijn wel de programma’s die gebruikt kunnen worden voor het inladen en tonen van de 3D bestanden.
Ook ik heb uitdagingen het 3D Basisbestand Volledig te kunnen verwerken, maar dat moet uiteindelijk wel lukken.
Andere vraag: Wanneer wordt het 3D Basisbestand Gebouwen gepubliceerd?
Ik heb net in Qgis blad 37hn2 met de plugin “CityJSON Loader” v.0.6.2 ingelezen. Ik krijg hierbij 7 (objecttype) virtuele lagen. Heeft er iemand al ervaring om deze virtuele lagen op te slaan in een dusdanig formaat dat ArcGIS Pro deze zonder (weer een conversie) problemen kan lezen? Mijn doel is om dit uiteindelijk te ontsluiten naar een scene layer in de cloud van Esri.
De laatste weken is er veel 3d-functionaliteit aan QGIS toegevoegd, waaronder het exporteren van een 3d-scene naar .obj formaat. Geen idee wat “de cloud van Esri” voor 3d-formaten kan lezen/importeren maar misschien biedt dit uitkomst?
Om deze nieuwe functionaliteit nu al te gebruiken moet je de “nightly” versie van QGIS (3.15) downloaden en installeren, of zelf de broncode compileren. Of wachten op de normale 3.16 versie die in november uitkomt.
Wat heb je precies voor ogen om te ontsluiten? Alleen dat specifieke kaartblad, of uiteindelijk ook meer? Wij hebben zelf al workflows gemaakt om de data als scene te publiceren, dat hebben we voor een proefgebied van 4 kaartbladen rond Apeldoorn gedaan. Daarbij hebben we voor terrein twee opties bekeken om het om te zetten naar een mesh en als multipatch. Beide functioneren goed, beide wat voor- en nadelen.
Gezien de ervaringen rond CityJSON die we ook op o.a. dit forum lezen qua omvang, opknippen etc, zijn we aan het verkennen of we voor ArcGIS-toepassingen kunnen voorzien in een downloadvoorziening die het in fgdb-formaat aanbiedt. Dan kan je elk kaartblad als fgdb downloaden en direct met de workflows die we beschrijven de publicatie als webscene doen. Zou je daar bij geholpen zijn? Technisch hebben we de componenten, alleen kwestie nu van zien of het de moeite waard is of er genoeg mensen mee geholpen zijn als we fgdb’s ter download aanbieden. Het zou helpen om wat context te krijgen over wat je gewenste eindproduct is / doelgroep?
Het gaat voor ons om het gebied van Capelle aan den IJssel. Dat zijn dan de bladen 37fz2, 38az1, 38cn1, 37hn2. Het lieft vertaal ik dit in via Data Interop naar een fgdb. Maar onze DI (2019.0.0.0 (20190328 - Build 19238) kent geen CityJson vandaar mijn Qgis exercitie. Heb er nog weinig ervaring mee maar ik doe het liefst de werkstappen en in zo’n min mogelijk (conversie) stappen en met de esri software. Ik weet bijvoorbeeld ook niet of ArcGIS Pro (2.4) het direct kan lezen. Ik dacht het niet. Binnenkort gaan we wel naar de laatste Pro release. En ik ben ook wel benieuwd naar de exacte verschillen tussen mesh en multipatch. Uiteindelijk is het doel om het terrein weer te geven in o.a. ons 3D gebouwen model wat in onze Stadsatlas staat. Een downloadbare fgdb die julle eventueel maken zou zeker een welkome aanvulling zijn. Maar ik verwacht dat er dan meer medestanders moeten zijn.
@mverhart, je kan nu alle kaartbladen ook downloaden in fgdb-formaat: https://www.arcgis.com/apps/instant/minimalist/index.html?appid=db2b85a5433e460fa3b1636edfbbb218. Scheelt gedoe qua conversie. CityJSON support komt op termijn is de verwachting. Echter blijft het dan nog steeds heel veel data, dus de fgdb is wellicht een eenvoudigere flow voor je en scheelt conversie.
1 like
Bedankt voor deze update! Ik ga dit zo snel mogelijk beproeven. Ben nu al benieuwd naar het resultaat.
.fgdb is een vendor specifiek gesloten bestandsformaat van Arcgis toch? Hoe kan CityJSON geconvertereerd worden naar andersoortige 3D geometrie, liefst open? met een bruggetje naar 3D CAD ?
Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.