AHN2 - class 1 "unclassified" (because in AHN2 there is only ground and unclassified)
AHN3 - class 6 "building"
this is true also for the tiles that are on the border of the AHN2 and AHN3 coverage. these tiles are generated twice, then merged in order to really use the latest available height data for each building.
the reason for doing this merging is that the AHN3 tiles on the border with AHN2 only partially contain data. i reported an issue related to this on the forum ( https://forum.pdok.nl/t/error-in-ahn3-laz-files/1625?u=balazsdukai) .
thus one option would be to use only AHN2, in which case we have many buildings with potentially outdated heights, which is not good.
another option is to crop the AHN2 tile so that there is no overlap with the area where there is data in AHN3. but we don't know the boundary where to crop each tile, and cropping 2-3GB las files take longer than just generating the tile 2x, one with AHN2, one with AHN3, and then merging them
AHN2 - class 1 "unclassified" (because in AHN2 there is only ground and unclassified) AHN3 - class 6 "building"
this is true also for the tiles that are on the border of the AHN2 and AHN3 coverage. these tiles are generated twice, then merged in order to really use the latest available height data for each building. the reason for doing this merging is that the AHN3 tiles on the border with AHN2 only partially contain data. i reported an issue related to this on the forum ( https://forum.pdok.nl/t/error-in-ahn3-laz-files/1625?u=balazsdukai) . thus one option would be to use only AHN2, in which case we have many buildings with potentially outdated heights, which is not good. another option is to crop the AHN2 tile so that there is no overlap with the area where there is data in AHN3. but we don't know the boundary where to crop each tile, and cropping 2-3GB las files take longer than just generating the tile 2x, one with AHN2, one with AHN3, and then merging them