3D BAG v2023.06.22 is released

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:

  1. The use of AHN4 together with AHN3.

  2. Completely rewritten data pipeline, which allows us to have better success rate in the reconstruction, but also a reliable update schedule in the future.

  3. 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.

7 likes

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.

2 likes

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?

Hi @BalazsDukai,

What is the WFS address for getting the tile numbers.
For the last release it was: https://data.3dbag.nl/api/BAG3D_v2/wfs?service=wfs&request=GetFeature&typeName=BAG3Dv_2%3Abag_tiles_3k&outputFormat=application%2Fjson with boundingbox.
For getting the Geopackage we used the following adres: https://data.3dbag.nl/gpkg/v210908_fd2cee53/3dbag_v210908_fd2cee53_4966.gpkg. What should we use as new address?

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

3 likes

Why was the semantics_values array removed? How do we know if something is a roof or wall etc. now?

1 like

I am having the same issue as well. Did you find a solution?

1 like

Sorry, I don’t know much about the BlenderGIS addon. Maybe the developers could be able to help you.

1 like

If you check the download link of a gpkg file, by selecting a tile in the tile picker, for instance you’ll see https://data.3dbag.nl/gpkg/v20230622/tiles/9/248/580/9-248-580.gpkg .

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. :grimacing:
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.

Indeed there seems to be a problem with this. We’ll investigate it.

1 like

While you are at it, the following identificatie appear at least twice in the table pand, while the other attributes appear to be equal across fids:

  • NL.IMBAG.Pand.1667100000000006
  • NL.IMBAG.Pand.1667100000000009
  • NL.IMBAG.Pand.1667100000000020
  • NL.IMBAG.Pand.1667100000000021
  • NL.IMBAG.Pand.1667100000000050
  • NL.IMBAG.Pand.1667100000000132
  • NL.IMBAG.Pand.1667100000000141
  • NL.IMBAG.Pand.1667100000000255
  • NL.IMBAG.Pand.1667100000000657
  • NL.IMBAG.Pand.1667100000001205
  • NL.IMBAG.Pand.1667100000001262
  • NL.IMBAG.Pand.1667100000001458
  • NL.IMBAG.Pand.1667100000002330
  • NL.IMBAG.Pand.1667100000003063
  • NL.IMBAG.Pand.1667100000003090
  • NL.IMBAG.Pand.1667100000003631
  • NL.IMBAG.Pand.1667100000009358
  • NL.IMBAG.Pand.1667100000010902
  • NL.IMBAG.Pand.1667100000010907
  • NL.IMBAG.Pand.1667100000010908
  • NL.IMBAG.Pand.1667100000010909
  • NL.IMBAG.Pand.1667100000010912
  • NL.IMBAG.Pand.1667100000010913
  • NL.IMBAG.Pand.1667100000010915
  • NL.IMBAG.Pand.1667100000011058
  • NL.IMBAG.Pand.1667100000011130
  • NL.IMBAG.Pand.1667100000011428
  • NL.IMBAG.Pand.1667100000011630
  • NL.IMBAG.Pand.1667100000011659
  • NL.IMBAG.Pand.1667100000012089

I’d be curious be learn why these should be duplicated.

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?

Hi @BalazsDukai,
Thank you for the feed-back
But what is the new WFS address for getting the tile numbers of the latest realease of the 3D BAG.
In the previous version we used this address to get the tile number:
https://data.3dbag.nl/api/BAG3D_v2/wfs?service=wfs&request=GetFeature&typeName=BAG3Dv_2%3Abag_tiles_3k&outputFormat=application%2Fjson
But these tiles have different names than the new ones.

Well, it is in the release notes that I linked in the announcement.

If you visit the Downloads page, you will also encounter a warning about the changed endpoint.

In the documentation, you will find the list of available layers.

1 like

Hm, I think there are .mtl files delivered with the .obj files. They don’t work?

No, unfortunately you cannot assign materials with cjio, only remove them (at least in the CLI). If you want this feature, please open an issue at GitHub - cityjson/cjio: CityJSON/io: Python CLI to process and manipulate CityJSON files

1 like

I’ve just checked the first one on your list, NL.IMBAG.Pand.1667100000000006, from tile 3/256/0, the gpkg file, and the pand layer has only one of it.

Could you please double check how you calculated the duplicates, or your data import?

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

Maybe these objects span multiple tiles?

Ok, I see what you mean, thanks for reporting :+1:
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.

On a different note. In case you are transforming the data to some other schema, it might not be needed to unzip the gpkg file. If you have a modern-ish gdal, it can read from the zip directly with GDAL Virtual File Systems (compressed, network hosted, etc...): /vsimem, /vsizip, /vsitar, /vsicurl, ... — GDAL documentation . If you have gdal >=3.7, this will be faster, because the zip file is search-optimized.

1 like

Hi @BalazsDukai, did you find out what the issue is?

Thanks for this amazing new release :pray: