I can’t help but notice that some buildings are present in the AHN3 dataset but are absent in the 3DBAG version 21.09.08. I know for certain that the reconstruction of these buildings is based on the AHN3 and the bag footprints, so I want to know if this shortcoming is due to the footprints of these specific buildings not present in the used bag file or it is because of another reason (maybe their points in AHN3 do not respect some rules of the reconstruction algorithm).
Here is a screenshot of a set of buildings that are present in the tile 25GZ2_02 of AHN3 and absent in the tile 4354 of the 3dbag :
1 like
Hi, a new version was released recently: 3D BAG v2023.06.22 is released, please use that. There is no support for previous 3D BAG versions.
If you use the latest version, please read the release notes carefully, because there are many changes.
Hi Balazs,
I’m totally aware of the new version. However, I have been working with the 21.09.8 one for 3 months now in a change detection task (between the .obj model and the AHN4) and I was experiencing a lot of false changes (because of the discrepancies between the AHN3 and the model).
I just want to make sure if the reconstruction pipeline used is geoflow3D-like (uses footprints and pointcloud), and that maybe the reason some buildings are omitted is because their footprints are not present in the input data (Since they are present in the point cloud).
Thanks!
Hi @AbdelghaniTamort . I am the developer of the reconstruction algorithm (implemented in geoflow) that underpins 3D BAG and that we have used for both the current version and version 21.09.8 of 3D BAG.
There could be a number of reasons for a building that exists in AHN3 not to be present in 3D BAG. For example:
- building does not exist in the BAG dataset (our source for the building footprints). We only reconstruct buildings that exist in the BAG.
- The pointcloud is not adequate. Eg, there are not enough suitable points to reliable extract a roofplane. This can happen for example for very small buildings and/or insufficient point coverage for that building due to eg. occlusion effects in the pointcloud or other issues.
To know what exactly is the reason these buildings are missing here, I would have to look into it in more detail. But this should give you some general idea about why buildings can be missing.
1 like
Hi Ravi, Balazs,
Thank you for the clarifications.
I also have read some of the release notes of the newer version of the 3DBAG. While doing it I have noticed that you added a new attribute named “b3_mutatie_ahn3_ahn4” which outputs true for each building that significantly changed from AHN3 to AHN4. I was wondering if this attribute takes into account new buildings that appeared (that are absent in AHN3 and present in AHN4) or does it only take instances that exist in both pointclouds and compares their features (point density etc…) to assess the relevance of the change.
Thanks again !
The attribute that you speak of is based on the ground and building points for each BAG footprint that is processed for AHN3 and AHN4. In short it rasterises both point clouds and compares for those pixels that have data if there was a significant change in elevation (>1.2 meter). In cases more than 50% percent of the pixels changed, the attribute is set to true.
It should detect the case of a building that is not present in AHN3 but is present in AHN4, as long as there are at least ground points in AHN3 inside the building polygon.
I understand the logic. However, I have observed a peculiar case in the tile 25GN2_22 of the AHN:
On the upper left image you can see that the highlighted buildings are present in the AHN4, while absent in the AHN3 (upper right image).
But since they were reconstructed in the final model(lower left image), this implies that they indeed have a corresponding footprint in the bag input. You can also see that there are ground points in AHN3 which are in the supposed footprint.
When selecting one of the concerned building instances, the “b3_mutatie_ahn3_ahn4” attribute outputs the value false.
That’s an interesting case. Can you confirm that the points in AHN3 are indeed of the ground class (LAS classification code 2)? I see that b3_nodata_fractie_ahn3=1 which indicates that no points were available from AHN3 according to the algorithm. But that seems to contradict your screenshots…
Can you let me know the BAG identificatie code for this building?
Sure, its BAG indentificatie is NL.IMBAG.Pand.0363100012249390 and it’s from the tile 9-448-700.
I have selected a point from where the building should be in AHN3 and it is indeed a ground point (I’m not sure if the quality of the screenshot clearly illustrates that its classification is 2.0)
Thanks! I will have a look as soon as I have some time for it.
Very much appreciated!
Quick update. I just looked into this. And it turns out we have some AHN3 tiles (25gn2, 25hz2, 26cz1) missing on our processing machine. This led to wrong false values for ‘b3_mutatie_ahn3_ahn4’.
So this issue is limited to those 3 tiles, for the rest it should work as expected.
This issue will be fixed in the upcoming release.
I understand, thank you for taking the time to address the issue!