Hi everyone,
There’s an issue that’s been bothering me for quite a while, and I cannot seem to figure out what the issue is;
There seems to be a translation error between aerial images and their corresponding building footprint from BAG.
It doesn’t happen for all buildings, but seem to be more prevalent when there exist a parallax effect in the image, which I guess is an artefact of the ortho-correction?
Attached to images as example (raw aerial, aerial + BAG):
The BAG polygon should represent the walls at ground level. So this looks pretty accurate to me, looking at the north and east sides of the building.
At the ground level, you mean the roof overhangs the walls of the building?
That may be the case, but this is not the only instance where I have observed this, at times it fits perfectly, other times it does not.
Are you aware of documentation anywhere, explaining how PDOK created BAG? 
Yes, the roof overhangs the walls and that part is not in the building polygon.
The BAG is not created by PDOK, but by the municipalities. PDOK only provides the data. There’s a lot of documentation but not in English (as far as I know).
The BAG is not related to the annual aerial imagery and I’m not surprised that there are inconsistencies when overlaying them.
This is awesome, clarifies things. Thank you!
It’s an incredibly accurate fit.
The shadowlines should touch the corners of the grey shape and they do to the centimeter:
However, there could still be a east-west shift. We’ll have a look at that on the next aerial picture 
Anyways, the roof is off due to parallax.
Haha, right? Yeah this was my point also. I’m just dumbfounded when I’m thinking the images are ortho-rectified, but then the viewpoint seems to still be at an off-nadir angle 
Of course I understand @raymondnijssen’s response, the two datasets are independent. Yet I’m still not convinced this is the full explanation.
Here’s another one:
@R.A.Barber Are you aware of any way to mitigate these spurious variations in the dataset(s)? I see 3DBAG actually also suffers from the same problem, which I guess is given they use BAG as part of their input.
Using CV techniques to correct it would only bias the datasets unnecessarily, and I’d rather just filter on some criteria, but I’ve not been able to find one.
Unfortunately, it IS the full explanation. Like R.A.Barber said: look at the shadows of the building. Again with your latest example the shadowline connects exactly to the top-most corner.
What would you expect? Overhanging roofs, awnings etc will always, no matter how you correct the images, obfuscate the true outline at ground level. And it is that building outline at ground level which is part of the BAG. And no matter how you take your photographs: buildings (and especially taller buildings!) will always show parallax, which will be 0 in the dead center of the photo, and steadily grow bigger as you approach the edge of the photo. There is no way around that, it even happens in your own eyes. It’s because the rays of light all come in through the focal point - with the emphasis on point.
And then there is the fact that what you see on the aerial photograph is the roof structure, while in the BAG you’ll find the wall structure at ground level. So they are not even the same objects.
This is true, but it means something different than you think. It does NOT mean that all the parallax has been removed (that is impossible), it means that corrections have been made for the plane not flying absolutely horizontal while the photograph was taken. A plane will always be a little bit (or sometimes more, in case of turbulence) off a perfect level flight - and that is what is being corrected when you’re talking about ortho-rectified aerial photographs.
There isn’t. You’ll never get the aerial photographs to exactly fit the BAG geometry, if only for the reason that they show very different parts of the same object that aren’t even on the same altitude. Apart from the parallax which you will encounter in every single image.
I do not know what you mean by this, or what you want to achieve by it, but I think it would be a waste of time if you ask me. As I tried to explain: filtering on some criteria is not going to help you.
On the whole, if there is a specific reason that you were trying to achieve a perfect match between aerial photograph and BAG geometry, if you can explain what that is we might be able to figure out something - there are always more ways than one to achieve things in the geo-world
It will be 0 directly under the aeroplane.
I think you need control points on streets and accurate height data of the area that’s pictured. With those you can orthorectify aerial images.
Yes, you’re right: I was thinking of a theoretical exactly horizontally taken photo, but yes: it’s under the airplane.
That used to be the case, but they’re not entirely necessary anymore (a few here and there are good as extra check). Those planes now have at least 3 GPS units, using RTK, so the exact position and altitude and and rotation, pitch and yawn of the plane and the center of the camera is known at all times down to the last centimeter. Which makes the need for the control points on the ground a lot less (if not entirely zero).
There is a difference between an ordinary ortho photo and a “true ortho” photo. In the latter parallax is also corrected. For this much more additional data (like building heights / point clouds) is necessary in order to be able to generate them. The PDOK aerial photos are ordinary ortho photos.
Correct - the behavior that is described is the effect often visible in ordinary ortho photos. A True Ortho can be created from the same underlying stereo images. We have produced a True Ortho for the entire Netherlands - here’s a screenshot showing the difference between the classical ortho photo and the true ortho - both based on the same underlying data. The difference varies per region.
Classical ortho:
True Ortho:
Note the differences, in this case the building lean is towards the North.
This True Ortho is produced from the raw stereo imagery by using a software product and a lot of compute power to process the data using the software.
Wow! That is like sorcery! 
This must be what Google does.
Thank you for this clarification @JBak, @fsteggink and @sbjager - Good to be able to have an audience with the council of experts once in a while
Now the question is how to efficiently produce True Ortho without too much overhead. But I’ll look into that.
Cheers
