3D BAG v2024.12.16 is released

[Ylannl]

With this release published on 20th of December 2024, we included the AHN5 point cloud as input data for 3DBAG, available for north-west, west and southern parts of the country. There are also new attributes, and new features. See the full release notes.

This release counts 10 796 210 3DBAG models and was funded by the 3DBAG innovation platform.

This is the first time that we used the improved 3DBAG software pipeline made possible by a WaU subsidy from Kadaster.

For joining the open source 3DBAG developers community, join the Zulip 3DBAG chat.

3DBAG.nl is a collaboration between 3DGI and the 3D GeoInformation Group.

[ThomasBroos]

Hi,

Nice! Will look into transferring to the AHN5 as soon as possible.

However, this seems to be coinciding with endpoints that I have live being down at the moment. Does anyone know more about https://api.3dbag.nl/collections/pand/items (and others) being down? Im getting a 502 error.

Thanks for letting me know, best,

Thomas

[Ylannl]

The API should work again.

[ThomasBroos]

Hi,

Thanks for letting me know! I noticed the “floor” and “walls” of the buildings are generated correctly again. However, the “roofs” turn up empty in the configurator. When I test it, the response is a bit scrambled compared to a few days ago I believe. IFC Site maker

I investigated and see these roof geometries do not stick to the categories 0,1,2,3 anymore, but turn up in new categories from 4 up to 156 even. Since these categories iterate by exactly 1, I think there’s something off in the code there?

A snippet of the response is this:

{
    "surfaces": [
        {
            "type": "GroundSurface"
        },
        {
            "on_footprint_edge": true,
            "type": "WallSurface"
        },
        {
            "on_footprint_edge": false,
            "type": "WallSurface"
        },
        {
            "b3_azimut": 38.011844635009766,
            "b3_h_dak_50p": 17.736459732055664,
            "b3_h_dak_70p": 18.6976261138916,
            "b3_h_dak_max": 20.615514755249023,
            "b3_h_dak_min": 15.33699893951416,
            "b3_hellingshoek": 57.931278228759766,
            "type": "RoofSurface"
        },
        {
            "b3_azimut": 250.12811279296875,
            "b3_h_dak_50p": 26.105392456054688,
            "b3_h_dak_70p": 26.229551315307617,
            "b3_h_dak_max": 26.618423461914063,
            "b3_h_dak_min": 25.770401000976563,
            "b3_hellingshoek": 22.464656829833984,
            "type": "RoofSurface"
        },
        {
            "b3_azimut": 209.22584533691406,
            "b3_h_dak_50p": 25.164543151855469,
            "b3_h_dak_70p": 25.168018341064453,
            "b3_h_dak_max": 25.173435211181641,
            "b3_h_dak_min": 25.157184600830078,
            "b3_hellingshoek": 0.45628336071968079,
            "type": "RoofSurface"
        },

… and …

"values": [
                  [
                    0,
                    1,
                    1,
                    1,
                    1,
                    2,
                    1,
                    2,
                    1,
                    1,
                    1,
                    1,
                  
...
                    2,
                    2,
                    2,
                    2,
                    2,
                    2,
                    2,
                    3,
                    4,
                    5,
                    6,
                    7,
                    8,
                    9,
                    10,
                    11,
                    12,
                    13,
                    14,
                    15,
                    16,
                    17,
                    18,
                    19,
                    20
                  ]
                ]

If it’s supposed to be like that from now on, I’ll change code on my side of course.

Thanks for the effort in any case, hope this helps, best,

Thomas

[Ylannl]

The list of semantic objects can indeed be longer now, since the azimuth and slope attributes were added on the roof surfaces and these attributes have different values for each roof surface. Therefore the indices in the values list will also be larger. See also the CityJSON spec.

[ThomasBroos]

Hi Ylannl,

after a lot of puzzling with this “new structure”, I kept getting strange results for some buildings: Some parts of some roofs kept missing. I now isolated one of such buildings and traced the “error” back to the source:
When I do a request for the same coordinates, with different bbox, I get different vertices for the same building (for instance NL.IMBAG.Pand.0363100012168052) as an answer. I suspect something is still going on at serverside…?

Please compare the vertices in the response for NL.IMBAG.Pand.0363100012168052 :

https://api.3dbag.nl/collections/pand/items
GET
{
“offset”: “1”,
“limit”: “100”,
“bbox”: “121119.123682,487186.194359,121399.123682,487466.194359”
}

with
https://api.3dbag.nl/collections/pand/items
GET
{
“offset”: “1”,
“limit”: “100”,
“bbox”: “121109.123682,487176.194359,121409.123682,487476.194359”
}

Hope to hear from you, best,

Thomas

[erikvdv1]

Hi! Thanks for the update. Nice to see it is based on AHN5.

However, I’ve noticed that the b3_kwaliteitsindicator is always false in this release. This is not only the case for CityJSON (as mentioned in the known issues), but also for the GPKG output.

I could calculate the field myself using the definition in the link above. But it would be nice to see a release with this field set.

[Ylannl]

Thank you for reporting these issues @ThomasBroos and @erikvdv1. We will look into them.

[GinaSt]

Hi @ThomasBroos,

I tried the 2 different calls with the bboxes you suggested but the building (NL.IMBAG.Pand.0363100012168052) seems to be the same in both cases. Could you please elaborate a little on what kind of differences you experience?

Just for clarification, differences in the values of the vertices is expected since the cityjson files are not the same. Please compare the “translate” member in your files - it differs between the 2 files which is also the reason the vertices are different. Maybe this explains the differences you perceive in the files?

[ThomasBroos]

Hi Gina, thanks for your anwer.

I’m visualising the answers fully automatic with rhino 7 grasshopper.
It was fine before the AHN5 release. Now almost all are fine, but for some buildings, the roofs just don’t add up anymore while almost all other in the same response do. The logic on my side to produce the visualisations is the same, incl. translation etc.

Your comment made me realise the translate for in the second repsonse has an “e-07” in it.

“translate”: [
121097.350875,
487152.29175,
7.476806622719323e-07
]

That in itself is not a problem for the logic I wrote. It’s just a silly precise number. Also when I check the “vertices” value’s for both responses, I notice a lot of the vertices in the second response contain a z-value of 1.This is curious in itself. But combine that with the translate and the fact that that result is just not true for the building at hand, and I am quite sure its something on the serverside producing this.

  "id": "NL.IMBAG.Pand.0363100012168052",
  "type": "CityJSONFeature",
  "vertices": [
    [
      390990,
      292475,
      1
    ],
    [
      380728,
      301035,
      1
    ],
    [
      380800,
      301123,
      1
    ],
    [
      380369,
      301482,
      1
    ],

This building should not have z values near-zero, when you check reality. And especially since it contradicts the response for the first request.

Hope this elaboration helps, best,

Thomas

[GinaSt]

Hi @ThomasBroos ,

Indeed it can happen that there are changes to some roofs since we started using AHN5. However, you mention that “for some buildings, the roofs just don’t add up anymore”. Could you please send us a visual example or some building ids which have changed in a way that is not reasonable?

Regarding the building “NL.IMBAG.Pand.0363100012168052”, are there any visual changes you see on the roof? And do you see any differences in the building when the bounding box size is changed?

Focusing more on the cityJSON files, the file I receive from the API call is valid, validated with the CityJSON validator. This means that the precise values (“e-07”) do not affect its validity.

Regarding the coordinate differences between the 2 files (with different bounding boxes), have you also taken “scale” into account? Please have a look at the CityJSON documentation about the how the coordinates are calculated. The vertices are transformed based on the whole “transform” member not only the “translation”. I hope this helps!

[ThomasBroos]

Hi Gina, thanks for your answer.

Below a snapshot with NL.IMBAG.Pand.0363100012168052 (Bijenkorf Amsterdam) in the bottom right corner for instance. You can look right through the roof onto the light-blue floor because some roof-surfaces are “bad”. This is the result exported as IFC and viewed in Solibri, but I can see it in my online configurator as well, and also when I run the graph locally in grasshopper.

Regading NL.IMBAG.Pand.0363100012168052, yes I do see changes from request to request. In both requests in my jan. 9th post, the roof is “bad”, but differently so.

Here you can see multiple roofs turning up “bad” for a different bbox.

Regarding the cityjson validator: I believe you, it’s just not the issue in my opinion. It’s not the format, but the content that’s off.

Regarding scaling and transform: yes I’m taking those into account. Since those transormations apply to all vertices in the building, the floors and walls would have to turn up “bad” as well, right?

-T

[ThomasBroos]

Hey,

Does anyone have an update on this?

-T

[GinaSt]

@ThomasBroos

Bijenkorf Amsterdam

Hi @ThomasBroos

I have visualised the city.json file from the API on Azul and Ninja and I cannot see anything wrong with the roof:

This seems like a IFC conversion issue. How do you perform the conversion?
It might be that the converter cannot handle specific errors.

I have transformed this tile to IFC using our own converter (only LOD 2.2). Could you please visualise this file in your viewers and see if you experience the same issues?

In our next release we plan to make IFC format available so if you have any feedback on our conversion it would be very helpful.

[ThomasBroos]

Hi Gina, thanks for all the help.

Your conversion seems accurate!

Along with your statement that it stemmed from the same data made me hand-check one more time and I found the issue on my side. The component creating the meshes was doing too much thinking of itself let’s say. I thought it a lesson.

Cheers for making IFC available!

Best, Thomas