The third public beta release of the 3D BAG out!. It’s been a while since the second release. As it turns out it costs quite some work to properly maintain and update the 3D BAG next to our busy day jobs. Fortunately we were able to receive funding from the ERC to bring the 3D BAG to a level where it can be maintained and developed reliably. The current release is the first of three that is financed by the ERC budget, and it paves the way towards a stable, open 3D BAG service.
There are three major changes in the current release:
The use of AHN4 together with AHN3.
Completely rewritten data pipeline, which allows us to have better success rate in the reconstruction, but also a reliable update schedule in the future.
3DGI joins the 3D geoinformation research group in the maintenance and development of the 3D BAG.
But there is a lot more, so please read the full release notes
As usual, send us your questions, praise and criticism through our feedback forms, here on geoforum or info@3dbag.nl. We read all your messages, even if sometimes our response takes a while. From now on, you can also get updates on the 3D BAG on Twitter @3D_BAG
We are very happy to see that so many people found a use for the 3D BAG to help them with their business, research or hobby projects. And we remain committed to keep maintaining 3D BAG into the future, of course as an open dataset.
Congratulations on your achievement. Thank you so much for your work. We have used the data in the interactive maps for the Dutch tv-programme Ruimteschip Aarde. We’re looking forward to using the new dataset for our next project: the new 3D buildings will help us to make the scenes more realistic! Thanks again.
I don’t think the BlenderGIS addon is part of your scope. Any change this tool is furtermore maintained and kept up to date with relavant developments 3D BAG and AHN go through? Who to turn to?
In the Data Schema I’m seeing the variables b3_h_dak_50p, b3_h_dak_70p, b3_h_dak_max and b3_h_dak_min. But when I download the geopackage (the entire file or only a tile from the viewer) those variables are b3_h_50p b3_h_70p b3_h_max b3_h_min.
The variables in the Geopackage are higher than the actual heights of the buildings when I look at them in the viewer, or when I calculate the height myself via the geometries. I already substracted the `b3_h_maaiveld’ value.
Am I misinterpreting those variables? They just seem to high for every building
The tiles layer in wfs/wms has the tile ID-s. For instance for the tile above, the ID is ‘9/248/580’. As you see, the name of the file is the tile ID, where the ‘/’ are replaced with ‘-’.
Uhm, use CityJSON? This is our “subtle” way of forcing people to use the format that is most suitable for the data.
But jokes aside, it was removed, because we changed our pipeline and the semantics_values did not make the cut. We will probably put it back in the next release in some form.
The 3d bag has been very helpful for my purposes. Thank you very much. It would be great if in the future the OBJ tile version could have a different material assigned to the roof like last years version.
Edit: I’ve been experimenting with CJIO and the cityjson files. Is it possible to assign a material to different semantic surfaces?
Downloaded the master GPKG instead of the tiled GPKG and unzipped it to obtain the 3dbag_nl.gpkg file. Running the following query, shows there are 2 objects:
ogrinfo -sql "SELECT count(*) FROM pand WHERE identificatie = 'NL.IMBAG.Pand.1667100000000006'" 3dbag_nl.gpkg
To obtain the full list:
ogrinfo -sql "SELECT fid, identificatie FROM pand WHERE fid IN (SELECT fid FROM pand GROUP BY fid HAVING count(*) > 1) ORDER BY fid" 3dbag_nl.gpkg
Ok, I see what you mean, thanks for reporting
We compiled the master gpkg by merging the tiles, so apparently sth went wrong in this merging process. There really shouldn’t be duplicate objects on the tile boundaries, and NL.IMBAG.Pand.1667100000000006 is well inside the tile too. So this is something else.
