In 2.3.1 staat 'objecttype Verblijfsobject wordt uitgewisseld met puntgeometrie'.
Dit is niet compleet. Een verblijfsobject kan ook met vlakgeometrie uitgewisseld worden, zie http://www.kadaster.nl/web/artikel/download/BAG-grondslagen-catalogus.htm, PDF blz 60 “Het object wordt gerepresenteerd door een punt van het GML geometry type GM_Point. Voorwaarde is dat de verblijfsobjectgeometrie is gelegen binnen het pandcontour van het gerelateerde pand of een van de gerelateerde panden. Ook representatie door GM_Surface is toegestaan”
Wij begrijpen de gemaakte keuze voor geometrie niet. In StUF bg kent TGO (waar VBO een subtype van is) zowel puntgeometrie als vlakgeometrie (niet het één of het ander, maar het kan ook naast elkaar). Vanuit StUF familie-overwegingen verwachten wij dat met geoBAG al de geometrie uitgewisseld kan worden die in StUF bg is gedefinieerd. Dus bij VBO is dat punt én vlakgeometrie.
Overigens is de vraag of we gezien de ontwikkelingen niet ook gelijk 3D geometrie in dit koppelvlak moeten opnemen. Anders zullen we het koppelvlak al op heel korte termijn weer moeten aanpassen.
Overigens geldt deze wens van afstemmen op StUF bg niet alleen voor het VBO. Ook bij het pand (PND) missen we in de geoBAG berichten de dubbele vlakgeometrie die in StUF bg wel is gedefinieerd.
Het Geo-BAG koppelvlak beperkt zich in een eerste versie tot uitwisseling van vooral de verplichte BAG-gegevens. In StUF-BG zijn vlakgeometrie bij een VBO en maaiveldgeometrie bij een Pand optionele attributen.
Optionele BAG-kenmerken zijn nu in deze eerste versie buiten-scope geplaatst. Leveranciers zullen eerst deze versie van het koppelvlak implementeren. Later kan een uitbreiding volgen met ook andere optionele BAG-kenmerken, indien deze behoefte bestaat en niet op andere wijze wordt ingevuld.
Hoewel er inderdaad voornemens zijn om 3D geometrie op te nemen in de BAG, is dit nu nog niet het geval en lijkt het ook voorbarig om dit nu al op te nemen in dit koppelvlak.